TAM: you might be doing it wrong

Marcus Flores
3 min readOct 3, 2021

So far in my product career, I’ve had the great fortune of working at the newer end of the product lifecycle (closer to the “Innovation” PM if you’ve read the latest Reforge article on product management’s growing specialization). In my experience, the most important part of this kind of work is securing executive buy-in, and I’ve come to realize there’s a right and a wrong way of doing it.

First, the wrong way.

Suppose you believe that a new feature or product is likely to drive increased revenues. Chances are your executive team will want an idea those revenues. The problem is that if you’re doing something novel, then almost by definition, there aren’t likely to be valid points of comparison out there. To quote the Good Book, “markets that don’t exist cannot be analyzed.”

Let’s use a well-known example to illustrate the point.

For Airbnb, you’d start building a business case with a TAM:

  • You might study the number of homes with an extra bedroom across the US and perhaps the number of rental properties.
  • You make some inferences about the number of them willing to house a traveler. You make some assumptions about the difference in prices of each.
  • Then you pad in some corrections for common tourist destinations, which vary significantly from region to region.
  • And on that note, seasonality is a thing; folks will probably leave Aspen by spring and won’t return again to winter. Better throw in some variables for that.
  • …and so on.

Basically, if you’re trying to model all of this out, you’re soon to end up with an interminably complex spreadsheet. Small changes in your assumptions are going to lead to dramatically different outputs. At best you’ll end up in the ball park, but more than likely you’ll be off by an order of magnitude.

Moreover, someone is going to ask how you ended up with a $212.5bn TAM. With 25 different variables in play, you won’t have an easy explanation to your stakeholders, and you might also find yourself navigating conversations about your TAM vs SAM vs SOM, etc.

This is just a waste of time.

In my view, the better way to think about these new endeavors is as a set of hypotheses. To reframe the case for Airbnb, I think the following approach is much better:

  • Huge heavy hypothesis: Given a good enough way to do it, individual property owners will readily list their unused rooms / properties so total strangers can book them while traveling.

The huge heavy hypothesis is valid if all supporting hypotheses are also valid:

  • Given a sufficiently credible system (ID verification, etc), property owners will trust strangers to stay with them or at their property.
  • Guests and property owners will rate one another, enhancing the system of credibility and creating incentives for good behaviors on both sides of the market.
  • In general, travelers would rather stay in local housing near areas of interest rather than commercial hotels near business centers.
  • We can stand up a rudimentary website to test these things for $30,000 (and do some clever Craigslist redirection and fancy photography to jumpstart it).
  • …etc

At each hypothesis, you can assign criteria that can be used to validate a hypothesis and move on to the next. However, you might just as well find that one of your supporting hypotheses was completely wrong. At that point, you should contemplate a pivot or kill decision. For example, if Airbnb found that there was no scalable system that made people comfortable enough with trusting total strangers to stay with them, the company would probably look quite different today — if it ever came to exist at all.

And that’s the whole point. Hypothesis testing like this is easy to communicate with stakeholders. It gives them comfort that you’ll pull the cord when needed and fail fast. On the other hand, if you’ve aligned them around a $216.43bn TAM, you might find yourself in worse shape: susceptible to the sunk cost fallacy, building more stuff while trying to find the pot of gold at the end of the rainbow.

Thoughts? Are there are any other modifications you’d propose for this? Where doesn’t it work? Let me know in the comments or reach out directly!

--

--

Marcus Flores

Product manager with a background in mid-late stage startups.