The Four T’s: a PM-turned-VC’s framework for evaluating startups, part two

This is part two of a series on The Four T's. Check out part one here.

Evaluating startups is part dark arts, part science. No two companies are the same, and certain traits just can’t be quantified effectively. But like any (former) product manager, I’ve put together my own framework that has helped me to assess startups in a structured and straightforward manner. I call this framework The Four T’s: Team, TAM, Tech, and Traction. Check out last week's article for more background. This week, we discuss Tech and Traction.


This is the area that most founders focus on, and on the surface it makes sense--people naturally want to talk about what they are building and how it will fundamentally disrupt the status quo. The truth is that most founders spend a bit too long on this section and not enough time on the team and problem context. if you don’t believe me, read this report from DocSend that analyzes which slides early stage investors tend to focus on. Spoiler alert: it’s the Team and “Why Now?” sections.

That said, as a former product guy who helped build cloud-native infrastructure and apps, I am definitely interested and will want to dive into the technical details of you are building. However, I tend to take a PM-oriented, market-driven approach to assessing the technology:

What are you building and why does this matter? The most straightforward question, though often the hardest as an investor to evaluate. After all, the founders who are hacking away at the product 24/7 will understand this far better than any VC could ever hope to. Thus, part of what I am checking here is your ability to explain the product, technology, and value proposition in a clear and straightforward fashion--if you can't convey it to a reasonably technical investor like me, good luck trying to get a customer on board. As an infra focused investor, I also try to understand where your product fits in the stack--what does it replace, what does it integrate, where does it compete?

Is there something fundamentally different and valuable about your technology? Let’s have an open and honest deep-dive into how your technology helps build a sustainable competitive advantage for your product. Technology for the sake of technology doth not a business make. If you’re doing “X for blockchain” or “AI/ML for Y”, I’ll attempt to sniff out whether the value proposition for customers still stands when you remove the technology from the picture. In addition, how unique is the value prop? “Better, faster, cheaper” is a common mantra in the enterprise world, but one that usually results in modest M&A, not a large, sustainable business. As always, there are exceptions, Zoom being the most recent. But this is an exceptions-driven business, and that's why the Four T's are a framework and not dogma.

How well do you understand the key personas involved? Who are your key users, buyers, and influencers? Do you deeply understand their primary workflows and motivations? Will they care about what you are building? In the context of infrastructure, typical buyers are either in IT, Security, or more increasingly Line of Business (e.g. VP Eng, VP Product). Users include product development (developers, PM, UX, etc.) and IT (app ops, sys admins, etc.). Some common mistakes made by technical founders--Devs and IT are not the same, and for that matter Silicon Valley companies differ heavily from other enterprises in both usage and buying patterns. This is an area where industry experience and empathy-building can make a huge difference.

How well do you understand the competition? It’s a common refrain that a PM should build their roadmap based on customer needs and not competitor features. But I do expect product-oriented founders to understand who their competition is, what they are building, and why the startup can do better. Most founders have the ubiquitous 2x2 grid with their company in the upper right and everyone else nowhere near. I prefer to take the conversation a level deeper and understand your technology differentiation versus competitors--do you use similar OSS frameworks underneath the hood? Is the barrier to entry the technology itself, or is some other effective moat that keeps you ahead?

Side note: If you are an investor, this is an area where taking the time to deeply understand technology is helpful. As a former product guy, I like going to practitioner conferences, attending architecture sessions and asking questions to engineers and end users alike on the show floor. Many investors I know say they "don't really have time for watching sessions." I disagree with this strongly. It's all about prioritization, and this kind of prep just makes for better conversations with entrepreneurs.

Ultimately it comes down to this: What are you building, what is the value proposition, and how well do you understand the industry context?


The elusive product-market fit...the white whale of many a startup and the most common pass excuse for many investors. The truth is that there is no single definition for traction--it varies heavily by industry and by stage of company. 

At the seed stage I want to understand whether the founders are user-oriented and have thus spent time engaging with the potential market and validating the potential of their idea. Thus, evidence of customer investigations or beta testing is important, and paid customers are a nice bonus.

At the Series A level, assessing traction is kind of like evaluating a university application. There many factors that go into it, and usually no single number makes or breaks the decision. That said, I am usually looking for evidence of three things:

What are the signs of your growth?  At the Series A, there has been a lot of discussion and focus in the SaaS world on milestones like achieving $1M ARR, a focus on T3D2 growth, or having a magic number > 1. While all of these are potentially useful guide posts, these aren’t necessarily universal, and often vary widely by industry. For example, infrastructure companies often take longer to scale up revenue due to longer technology development cycles, growing adoption of open-source among enterprises, and longer sales cycles in IT. So, I do look for evidence of revenue and growth trajectory, but I don't put a hard number on it. In addition, with open source based companies, I also study growth that sit squarely in the community--examples include Github stars, pull requests that come from outside the company, trending on Hacker News and key subreddits, etc.

Have you found and solved a burning pain point for customers? As a product-focused investor, I spend a decent chunk of my time talking with CIOs and CTOs (for a top-down sales) as well as chatting up developers and IT admins (for bottoms-up adoption) to understand what their pain points are, and I look for founders who think the same way. Going back to "vitamins vs painkillers" (discussed in my post on developing empathy in product) have you picked a problem that is a "must solve" for your target user, to the point that somebody in the organization is willing to pay you $$$ for it? Furthermore, do you have early customers who not only purchased your product, but are willing to work with you to improve it and even to evangelize on your behalf? If you need a primer on this, Roy Bahat of Bloomberg Beta has a nice post on picking your first set of customers who will be both design partners and evangelists on your journey to product-market fit. 

Have you found evidence of a transactable and repeatable sales process? Let's break these down. Transactable means that you've established a straightforward process by which customers give you money--whether it is no-touch freemium conversion, medium touch inside or channel sales, or a traditional high touch field sales team. Repeatable means that this process is scalable and doesn't require significant custom work for each new customer. Put both of these together, and you have a path to growing revenue and a solid understanding of what kind sales team you need to build out in order to be successful. Of course the devil is in the details with these areas (e.g. are you going after large and mid-market enterprises with six figure average ACVs and long sales cycles, or SMBs with high volume low ACV deals, etc.).

Ultimately, traction for me is a proven understanding of your customer's burning needs coupled with strong evidence of a scalable sales process.

Wrapping it up

The Four T's aren't perfect, nor are they set in stone, but they provide a good framework for how this PM-turned-VC evaluates early stage enterprise companies.

As a summary, Team is by far the most important component, TAM includes evaluation of the startup's potential to capture or create large markets (with a healthy dose of Go-to-Market discussion), Tech is about understanding the fundamental disruptive value proposition and competitive defensibility, and Traction varies widely but usually centers around solving a burning pain point and having a repeatable and transactable sales process.

Questions, comments, rotten tomatoes? You know where to find me.
Image Citations: Yup, still making memes.


Popular posts from this blog

The Four T’s: a PM-turned-VC’s framework for evaluating startups, part one

Welcome to The V Formation

From Servant Leader to Servant Investor: Year One of a PM Turned VC