Why Product doesn’t matter for Product-Market Fit

This is a work-in-progress concept and post. Feedback welcome, just DM me on Twitter!

I know this is a controversial statement – almost nonsensical – especially for the CEO of a software startup. I swear, I'm not having a seizure. Bear with me.

It's especially weird because the world doesn't seem to agree. People obsess over product. It’s sexy. Code is magical. You press some buttons and you’ve created something. It’s infinitely scalable.

But I’m struck by so many examples of companies that succeeded not because of a good product, but despite a bad product: Bill.com. Salesforce. (To those who say "these are good products," I'd respectfully but vehemently disagree. They are terrific businesses – which is the point here – and they may get the job done, but they're really really awful "products".)

On the other hand, there are so many examples of good products getting zero traction.

How can this be? What ends up mattering instead? Sales? Luck? Timing? A strong contender for this dilemma is well-known tweet by Justin Kan:

Hmm... Distribution isn't quite the same as the "Market" half of Product-Market Fit. It's how your Product is sold to the Market. So how do these fit together?

You can build the best Product and have the best Distribution; but unless you have a Great Problem, it's going to be nearly impossible to cross the chasm.

When you do have a Great Problem, then the other stuff kicks in to help in the journey, to reduce the number of detours you must take – a great Team building a delightful Product, with high-octane Distribution helps you reach PMF and escape velocity quicker. But the biggest factor in determining whether you get there at all is the quality of your problem.

But don't take my word for it – below, I'll elaborate how it very clearly fits with a wide range of advice on achieving PMF, including from people that inspired and coined the phrase Product-Market Fit.

Back to the origins of the term PMF

Take a fairly basic depiction of PMF:

And then lets dig deeper on the origins of the term. The phrase PMF has been attributed to Andy Rachleff (the founder of Benchmark), but he credited Don Valentine (the founder of Sequoia) with much of the inspiration.

I can tell you the origin story of the concept. I learned it from Sequoia Capital. Don Valentine really invented it. Don used to say, "I'm looking to invest in companies that can screw everything up and still succeed because the customer pulls the product out of their hands."

OK so that's interesting. Because:

1. It doesn't really talk about the strength of the Product playing a critical role. In fact, it assumes the Product is "screwed up." It just has to exist.
2. It talks about a specific customer – not a vague allusion to the market at large.
3. It also doesn't place much emphasis on Distribution, which Justin Kan stressed. It assumes that the buyer will "tear the product out of the company's hands."

Which brings me to the goal of my reframing. In our search for PMF at AbstractOps, I misunderstood these concepts for a long time, and wrestled with apparent contradictions in (very smart peoples') advice. And I made almost every one of these mistakes! Over time, as we tweaked our approach, I've come upon a reframing that incorporates all of the advice above (and many more).

(If you're curious, we'll soon be publishing specific examples of what we did wrong, and how we learned and iterated from our mistakes.)

I hope this reframing will help others... because it has changed the way I think.

The Problem-Product Bridge

1. Instead of "Market" (which is broad) let’s peel off a few elements, and ask the narrow this component down to the Problem: what are you trying to solve, and for whom?
2. Product conceptually stays the same, perhaps with a slight clarification. (See below.)
3. Let’s move the “peeled off” elements from Market into a third component called the Bridge: how do you convey your Product to solve the Problem? This includes, but is not limited to, Distribution.

You need all three. But far and away the most important one, the non-negotiable one, is a Great Problem.

The Problem

Let's say you're trying to sell better Customer Success software.

When someone asks you about "Market" you might say "CS at 200+ person companies" which is useful and a technically correct answer, but not precise enough to draw much of any conclusion or develop a proper strategy.

However, if you're asked about the "Problem" then that answer sounds silly. You'd probably say something like a) "create better workflows for junior CS to level up to CSMs" or b) "help CSMs work faster and increase NPS by giving them visibility into sales conversations, product analytics, [...]."

The reason this is important is that it allows you, your customers, your advisors, your investors to give you better feedback. (a) is a Bad Problem. Few would be willing to pay for it. Results are unclear and hard to measure. (b) is closer to a Good Problem. Because results are measurable, and it's a painful problem for the customer, it might actually have legs.

I use “Bad” and “Good” intentionally as a binary measure. If a customer is “close” to signing but decides not to buy your product, you don’t get 50% of the revenue, you get $0.

So what determines if a Problem is a Good one? There are many, many subjective and objective questions to determine this, but here are a few:

1. Is this a hair on fire problem, or a top 3 concern for the customer?
2. Do customers actually want this problem solved? Are their incentives aligned, or would a user protest because it threatens their livelihood?
3. Do customers believe the problem can be solved?
4. Is the problem clear to the customer already, or do they need to be educated?
5. Would the buyer be willing to pay for it?
6. How much would the buyer be willing to pay for it? How much is too much that they wouldn’t be willing to pay for it? How much is so little that they wouldn’t trust it?
7. Is the amount they’re willing to pay for it enough to support a meaningfully-sized business?
8. Does any reasonable contemplated solution fit into their workflow, or would it require a substantial change in buyer/user behavior?
9. Does the problem touch many different buyers / users / stakeholders at the customer, in a way that would pose a barrier to adoption?
10. Is the nature of the Problem such that someone keeps coming back to you after the initial efforts to solve this?
11. … The list goes on.

The Product

This is substantially similar to the definition commonly used today in the startup ecosystem. The "holistic" definition below isn't anything new; I'm just being precise for the sake of later posts where I'll reference "Product" in this sense.

1. First, we’ll consider a more holistic definition of Product, as not just software Product but including other kinds of Product. For example, an investment platform such as Robinhood will have investment Products (perhaps enabled by software Product), e-commerce companies like Away or Allbirds will have consumer Products, and a marketplace like Airbnb should consider its breadth of properties to be a core part of its travel Product offering.
2. Second, there are temporary “stilts” you can build to push your product over the finish line, before you’ve fully finished building it out. Implementation / Professional Services is one of the most common layers you can add on your product to give it a bit of an edge.

The Bridge

To start with, you usually have a chasm between the problem and your proposed solution:

This is the gap that people talk about when they exhort "your product won't sell itself."

But wait! Sometimes products do sell themselves. Take any remote-first software during the pandemic.

But that's really really rare. And if it was that easy, someone else would have done it. So usually this only happens when you're in the Right Place at the Right Time.

So most of the time, it looks like this you start out with this:

And you're trying to get to this.

The Bridge could be:

• Solid distribution (hence Justin Kan's tweet) – sales, partnerships, etc.
• Terrific product marketing (this is sort of distribution, but perhaps adjacent, because you can tweak this much more easily: pricing, messaging, etc.)
• Regulation or another "why now"
• Having unfair advantages (e.g., when Microsoft Teams had a worse product but was able to create a Bridge by bundling it with Office 365)
• Absent or bad competition (though this also plays a role in the existence of the Problem in the first place)
• Platform & network effects for lock-in
• Inherent virality / flywheels / growth loops for rapid adoption
• ...

This is the reason I said earlier that Bridge includes but is not limited to distribution; it refers to the overall “business model” and approach to the Problem & Market.

Over time, the best Bridges act like staples or sutures on broken skin — they pull the Product towards the Problem (synthesizing customer feedback, and bringing the Product closer to customer needs) and pull the Problem towards the Product (through brand awareness and network effects).

At scale, if you've done well in creating lock-in, network effects, etc., it looks like this.

And if you're Salesforce, it looks something like this.

OK cool, so maybe this is a good mental model or framework. Those are nice, but why do these distinctions actually matter?

Why does this matter?

This matters because Product, Bridge, and Problem differ in how much a team can impact them, and awareness of this fact can result in very different decisions regarding where you build, what you build, and how you go to market.

I’ve come to realize that

• it’s basically impossible to force the Problem or change the Problem.
• the Bridge is mostly in the team’s hands, and is where great pricing strategy, product marketing, partnerships, sales, viral loops / flywheels, etc. come into play
• the Product is almost 100% in the team’s hands, and the area where software shines

How this fits into other advice on finding PMF

"Is this a Vitamin or a Painkiller?"

Asked in a vacuum, this seems like it’s a question about the Product. But it’s really not — how could you possibly sell someone a Painkiller for something that’s not painful? You cannot convince a customer of a problem they do not think they have.

This is really a question about the Problem. If you try to answer this common VC question with how great your product is, you’re probably not answering their question. It’s not your fault! It’s an ambiguous question.

The better way to answer this is by discussing the acuteness of the Problem (and secondarily, how your Team / Product / etc. sets you up to solve it).

Sell-Design-Build

A Packy McCormick newsletter described the approach taken by Tegus, a midwestern startup that doesn’t design → build → sell; they sell first, in order to determine what to build.

What they’re actually doing is “presales” — gauging willingness to pay, getting LOIs in place, etc. And this activity isn’t actually quite the Bridge (which would normally contain Pre/Sales). They’re actually doing discovery, trying to determine what Problem is worth solving — and only if the answer is yes, do the expend the (much more expensive effort) of designing & building Product and setting the Bridge in motion.

Is This 10x better?

This is one of my favorite questions when considering an angel investment. It encapsulates so many of the questions in this post.

If the Way Things Are Done produces 1 Units of Happiness, then getting to 10 Units of Happiness is a 10x improvement. This means your Product + Bridge needs to add 9 Units of utility, and reaches a tipping point of “I’d pay for this."

However, If the Way Things Are Done produces 5 Units of Happiness, then

• Expending the same Product + Bridge effort of 9 Units, resulting in 14 Units is only an 2.8x
• To create a 10x leap, you would have to add 45 Units of Happiness, which is literally 5 times as hard (this sort of effort is usually out of reach for most early stage startups to build in 1-2 years before they run out of money).

(All of the above addresses a binary "I'd pay;" how much they’re willing to pay scales with how business-critical the Problem is.)

That is, no matter how business-critical the activity is, if it’s not a sufficient improvement on the Problem, they will not reach the tipping point.

This is why picking the right Problem is so important.

Product-Market-Sales Fit

This is one of the closest narrative descriptions I've read to many of the concepts in this post. Jyoti Bansal, who founded AppDynamics discusses Product-Market-Sales Fit, which expands upon PMF in 2 ways:

1. Understanding user needs more deeply (i.e., identify Problem), specific to a narrow user segment. This also touches on elements of Sell-Design-Build.
2. Think about how your sales motion scales efficiently (i.e., what your Bridge looks like at scale). Does your business have the right building blocks to go from $10M to $100M ARR efficiently?

This concept maps very neatly. The whole podcast / article is worth a deep review.

"Make Something People Want"

YC’s “Make Something People Want” is powerful in its simplicity (a trademark Paul Graham trait). It emphasizes the Problem (great!) and Product (great!). Side note, I love the fact that it uses “Want” not “Need” — if a customer needs something but doesn’t know it, you can’t easily sell it to them.

Additionally, YC constantly exhorts you to talk to your customers – this is their way of making sure that you're iterating on the Problem you're solving until you get to something where Product x Problem can meet.

Really, YC's approach is one of the most concisely complete descriptions I've seen of how to get your Product to intersect with the Problem. This is consistent with other aspects of their philosophy: if you find young technical founders who are terrific at engineering & product, and relentlessly remind them to talk to customers, that's a really good start.

However, IMHO, both the quote and what I've often seen of YC companies' approach underestimates the importance of the Bridge, especially in a rapidly evolving market.

This may be why successful YC companies worked on intrinsically huge Problems and had great Products built by stellar Teams. But even the most successful YC companies out there (Airbnb, Dropbox, Instacart, Doordash) succeed on the merits of the Product and Problem; unassailable moats appear rare which reflects the under-emphasis on Bridges.

Even some counter examples – Coinbase and Stripe have great moats – really created lock-in based on Product, not market dynamics (Coinbase = security, scale; Stripe = developer ease of use).

From the outside-in, Rippling and Brex some of the most creative Bridges (multi-product cross-sell, catchy advertising) amongst later-stage YC companies.

For a clear example of how a Bridge can be transformational over the long term, look no farther than Google. They had a great Problem (information discovery) and built a generational Product (PageRank) but it is their exceptional Bridge-building that made it one of the greatest businesses in history: they created a monopoly on the discovery of information, which is uniquely monetizable via ads. And they created an absolute monopoly, through things like Android, the iOS search partnership, and more. If Google had charged a monthly subscription fee instead of monetizing via ads, or missed out on some of the platform lock-in, it may have been one of the greatest missed opportunities in the history of entrepreneurship. But they didn’t, so here we are.

Building a Wedge versus a Platform

The answer to this is one of the most obvious in building a startup. And this is the biggest mistake I made in the early days of AbstractOps.

You should solve as few problems as possible. And if it’s more than one, they need to be as adjacent, even conjoined, as possible.

There are two simple reasons why:

1. Building more than one product introduces exponential complexity, at a stage where keeping things simple for speed is absolutely essential. You’re only allowed to introduce complexity later, once speed matters less (but still a lot) as a larger company.
2. Where the hell do you build the bridge?

Brian Chesky had a terrific quote on this recently:

We can't do new things unless we have permission. And we don't have permission to work on new things until people love our core service.

If you don't believe Brian Chesky (and you should), here's a visual representation of two strategies with the same product bandwidth:

See how much simpler and easier the second option is?

But what if you want to build a “platform” business? Your vision for your platform should affect how you build, but not what you build, and certainly not what you sell. Your customer does not care about your grand vision to change the world. They care about whether you’re solving their problem.

And even then, build the bare minimum of the platform needed to enable your wedge in a forward-looking way. When you’ve hit PMF (or I suppose Product-Problem-Bridge), you will have earned the right to build out your platform to your heart’s content.

What is your Earned Secret?

The question of the Earned Secret or “what do you understand that no one else does?” are not about your long-term prospects, but about speed to market, about the ability to get to the first and best wedge efficiently, so that you can crack the market open as quickly as possible.

What Bezos did with Amazon is a canonical example of this:

This is a common strategy used by entrepreneurs who are building new categories in existing markets. Parker Conrad did something similar with both Zenefits and Rippling (Benefits & Onboarding) en route to building a much broader vision.

This is often the reason to bet on repeat founders in the same space, or those with deep industry experience coming in. They know how to fish around in the fuzzy problem space to find the spiky areas that can be more easily reached, and speak to those problems effectively and eloquently.

In the next post, I'll cover other ways that iconic companies (Google, Stripe, etc.) reached PMF with the help of many more colorful and creatively-placed bubbles... and a few different strategies that are unlikely to work (based on my past experience and reasoning from first principles).

Bringing it Home

Andy Rachleff, the cofounder of Benchmark Capital, who actually crystallized and coined the term Product-Market Fit had a great reminder on what matters in this equation:

When a great team meets a lousy market, market wins. When a lousy team meets a great market, market wins. When a great team meets a great market, something special happens.

This seems pretty unequivocal in the conclusion. The Market (proxy for the Problem) is much more important and powerful than the role played by the Team. It's the non-negotiable.

But the strength of the team influences their genius in building better product faster, and building better bridges quicker.

Lousy Team, Lousy Problem:

Great Team, Lousy Problem:

Lousy Team, Great Problem

Great Team, Great Problem

They don't even need a Bridge! That something special just happened.

All in all, it seems clear that the best team in the world usually cannot affect the nature of the Problem. They have to work with what they have, and even if they out-execute a lousy (or even a good team) by 2x or 5x, the gap to the Problem is so vast that they can't make enough progress before they run out of money.

Pick a specific Problem with great care. Build a narrow Product to directly tackle that Problem. Start with the most efficient Bridge, but keep additional ones in the back of your mind if you can, to create a moat.

And good luck :).