CB Insights publishes an annual breakdown of why startups fail. For years, the number one reason has been the same: "no market need." Not poor execution. Not running out of money. Not a bad team. The product simply didn't solve a problem people cared enough about to change their behavior for.
That statistic is staggering when you consider how much effort goes into building products. Teams spend months — sometimes years — designing systems, writing code, arguing about architecture, and perfecting flows. And the most common reason they fail is that nobody asked whether any of it was solving a real problem.
Building products people actually want is not a talent. It's a discipline. It has a method, and that method can be learned.
The most common product mistake is falling in love with a solution before you deeply understand the problem. This is almost universal among first-time founders and surprisingly common among experienced ones. The pattern is always the same: someone has an idea, they find it compelling, and they start building. The customer is an afterthought — someone to be convinced, not understood.
The antidote is not complicated but it requires discipline: spend more time on the problem than you think is warranted, before you consider solutions at all. Talk to people who have the problem. Watch them work. Understand the workarounds they use today and why those workarounds are imperfect. Only then do you have enough context to design something that genuinely fits.
Good product development is not a straight line — it's a loop. Each iteration around the loop is an opportunity to replace assumptions with evidence. The teams that build products people want are the ones who complete this loop quickly and often.
The loop is not a formality. Each stage has a specific output that becomes the input for the next. Skipping stages — most commonly skipping directly from Problem to Build — is what produces products that miss the mark.
Not all problems are worth solving. A good product problem has three qualities: it is frequent (affects people often, not rarely), it is intense (people feel it enough to want relief), and the existing solutions are genuinely inadequate (not just slightly different from what you'd build).
The mistake is optimizing for the first quality and ignoring the second two. "People waste time in meetings" is frequent. But if the pain is low — if people have found good-enough workarounds — the problem may not be worth solving commercially. And if there are already twelve tools doing what you want to do, you need a very specific reason why yours would be chosen.
Research has a bad reputation in product circles — it's associated with slow consultancies, thick reports, and findings that nobody reads. That's a failure of execution, not of the practice. Good product research is fast, specific, and changes what you build.
The goal of research is not to confirm that the problem is real. You should already believe that before you invest heavily in research. The goal is to understand the problem deeply enough to know what a good solution looks like: who specifically has the problem, in what context, what they've already tried, what words they use to describe it, and what "solved" would look like to them.
A hypothesis is a specific, falsifiable prediction about what you believe is true. It forces clarity. If you can't write a clear hypothesis, you don't yet understand the problem well enough to build a solution.
A useful product hypothesis has three parts:
The signal is the most important part — and the most commonly omitted. Without a pre-committed signal, every experiment "kind of worked." Teams find ways to interpret ambiguous data favourably. A hypothesis without a falsification condition is just a wish.
The build phase is where most teams spend too much time. The goal is not to build the product — it's to build the minimum thing that will give you signal on your hypothesis. These are different objectives and they produce very different outputs.
For most early-stage hypotheses, the minimum is much less than teams think. Can you manually do what the software would do, for ten people, to test whether they value the outcome? Can you stitch together existing tools and test the workflow before you build new infrastructure? Can you sketch a prototype and walk it through with five users before writing any code?
The discipline here is to ask, before building anything: "What am I trying to learn?" and "What is the minimum thing that would let me learn it?" The answer is almost always smaller than what the team wants to build.
After launch — whether that's a prototype, a manual pilot, or a deployed feature — the measure phase is where teams most commonly fool themselves. They ask users if they liked it. Users say yes. The team marks the experiment as validated.
Sentiment is not signal. The only reliable signal is behavior: did people do the thing? Did they come back? Did they pay? Did they tell someone else?
For quantitative measurement, instrument before you launch. Know which specific actions you're tracking. Set a threshold in advance — "we'll consider this validated if X% of users complete Y within Z days." For qualitative measurement, conduct structured follow-up interviews, not open-ended satisfaction surveys.
The learn phase is about updating your mental model of the user and the problem, not just deciding what to build next. Teams that skip this step collect data but don't accumulate understanding. They execute quickly but don't improve their judgment over time.
A good learning session asks: What did we predict? What actually happened? What does the gap tell us about our assumptions? What's now the most important thing we don't know?
The output of the learn phase is a sharper problem definition, a revised hypothesis, or — if the experiment clearly failed — a decision to pursue a different direction entirely. All of these outcomes are valuable. The worst outcome is ambiguity: "we learned some things but aren't sure what to do next." That's a sign the experiment wasn't specific enough.
Product development never reaches a stage where you stop running this loop. The questions change — early on you're validating whether the problem is real; later you're validating whether a specific solution element is working — but the structure is always the same. Observe, hypothesise, test, learn.
The teams that build products people want are not the ones with the cleverest initial insight. They're the ones who complete the loop fastest and most honestly. Speed of learning, not speed of shipping, is the competitive advantage.