Team or TAM? Wrong question…
For early stage venture investors a consistent debate has always been Team or TAM. Both sides share compelling evidence but where you land is typically a by-product of an innately human perception of risk and tolerance for the messy unknown. Generally, I’ve come away from this debate with the resolute opinion that team matters above all else, while the optionality of TAM is a great to have, the belief remains that a great team discovers great TAM.
As I think about the AI inflection point we’re all experiencing, I can’t help but be reminded of this perennial debate especially given the increasingly consensus belief that new businesses leveraging AI will experience an abundance of TAM. When combining this belief with well endowed private markets and increasingly lower barriers to code, we’ve created a framework (or justification) for throwing dollars at a phase shift with the hope that a rising tide lifts all boats. This is already resulting in orders of magnitude more companies (/projects) chasing this pot of gold and as seed investors, given the extreme convergence of time between ideas to production, we’re seeing A LOT of ostensibly similar looking startups.
If you're investing today, the debate has moved away from Team or TAM and has become Team A or Team B.
Assessing a potentially great company has always anchored on the bare minimum assessment that we are backing a great team. A common framework for assessing a team’s quality has often been the presence or absence of slope, often articulated as iterations per unit of time/evidence collected per unit of time. A steeper slope posed as a convincing signal for investors to adjudicate execution capability and therefore team quality. But in a world where the cost of iteration defaults to near zero, and therefore, software superficially stops differentiating, what artifacts exist for a team to be measured against, especially when previous relics of slope look superficially identical?
When posed with the Team A or Team B choice, the axes that are becoming increasingly more important are ‘Taste and Systems’, and the best teams must spike on both!
What do I mean by taste? Taste shows itself in the form of strong opinions. Strong opinions enforce tradeoffs, tradeoffs demand conflict and conflict breeds perfection. Explicit artifacts of taste range from how a product looks and feels to how it is communicated and sold. Implicit artifacts of taste range from personnel hired (and fired) to how data and architectural decisions might allow for a product to shine against a better funded competitor. As things start to click, benefits of taste emerge downstream. Spiky employees and customers attract more of their ilk. Scaling of product and feature capacity is a natural extension of customer demand as opposed to a net new write operation while wandering in the woods. Taste shows itself through strong opinions, but opinions are enforced by systems.
What do I mean by systems? These are deliberate mechanisms a team puts in place to ensure taste survives contact with reality and prevents product velocity from degrading into noise. Systems encompass everything from how you choose to build your team to how you build your product and service your customers. This means hiring benchmarks, non-negotiables on candidate quality or even where you locate your office. This means enforcement mechanisms of data and architectural opinions at the cost of cheap workarounds to ensure your customers are experiencing true AI leverage rather than human supported leverage. When iteration is nearly free and customers have a choice of multiple ostensibly similar vendors, including the option to build their own, what they are really buying are the underlying systems, not feature sets. As software becomes increasingly probabilistic, these underlying systems translate into assurance of performance standards, service quality and product maintenance, especially when the happy path breaks. As systems harden, they allow teams to leverage context, contain risk and assure accountability for outcomes promised.
When anyone can build anything, how and why teams choose to build "the thing" matters more than ever. Taste and systems don't pitch, they reveal themselves over time, under stress, in decisions made that are not immediately legible. Seed investors rarely get a window long enough to observe these. So the task is searching for those early fingerprints: a tradeoff that cost them something, a hire they passed on, a feature they killed. Signs that Taste and Systems already exist.