You can validate a problem completely and still build something nobody buys. The problem can be genuinely painful, widely felt, and exactly as your interviews described it, and the product that solves it can still fail the moment it meets the market. That is not a discovery failure in the way teams usually picture one. Your research was right about the problem. It was silent about the market, and most teams never notice the difference until the launch notices it for them.
When CB Insights read through startup post-mortems to find out why companies actually die, the single most common cause was not competition, not running out of cash, not a weak team. It was “no market need,” named in 42% of failures (CB Insights, The Top 20 Reasons Startups Fail). Read that number carefully. These were not mostly teams that failed to find a problem. Plenty of them had a real one. They failed to confirm that enough people cared enough to change what they were already doing.
“Yes, that’s a problem” and “yes, I’ll switch” are different sentences
Discovery interviews are very good at getting the first sentence and very bad at telling you whether the second one is true. When a customer nods along to a pain point, they are reporting a feeling. Whether they will act on it later is a separate question, and the psychology research on that gap is not encouraging.
Paschal Sheeran’s synthesis of the evidence, drawn across hundreds of studies, found that intention accounts for only about 28% of the variance in whether people actually do the thing they said they would do (Sheeran and Webb, “The Intention–Behavior Gap”). Intention and behavior are correlated, but the correlation is loose enough that treating a stated “yes” as a committed action is a mistake. People who fully intend to change and then do not are the rule, not the exception.
Marketing research puts a sharper edge on it for anyone selling something. When you ask consumers about a new concept, only around 30% of the people who say they “definitely will buy” go on to actually buy once it ships (MarketingProfs, on Chandon, Morwitz, and Reinartz’s work). The standard correction is to discount stated purchase intent by half or more before you believe it. If your business case is built on the raw “yes” count from a survey, your business case is off by a factor of two or three before you have written a line of code.
What problem validation leaves unmeasured
Problem validation answers one question: does this pain exist for real people. It does not answer three others that decide whether the pain is a market.
The first is prevalence. Five vivid interviews prove the problem exists for five people. They say nothing about how many others share it, and small, intense pains are the easiest thing in the world to over-weight because the person in front of you is so convincing. The second is intensity and frequency: how badly does it hurt, and how often. A problem that bites once a year rarely earns a switch, no matter how much it stings when it does. The third is the cost of the status quo, which is really the cost of doing nothing, because doing nothing is your true competitor far more often than another product is.
This is the distinction Teresa Torres draws when she defines an opportunity as an unmet customer need, pain point, or desire (Product Talk, Opportunity Solution Trees). An opportunity being real is the entry ticket, not the destination. The tree exists precisely so that a real need still has to prove it will move a business outcome before it earns a build. Marty Cagan names the same thing from the risk side: value risk, the risk that customers will not buy it or users will not choose to use it, is the first of his four big product risks and the one product managers own outright (Silicon Valley Product Group, The Four Big Risks). Discovery exists to kill value risk before delivery starts. Confirming the problem is real does not touch it.
The questions that turn a problem into a market
If you want to move from “this problem is real” to “this problem is a market,” the interview has to stop asking about the problem and start asking about behavior around it. A short battery does most of the work:
- How many people plausibly have this, beyond the ones I happened to interview? If you cannot sketch the size, you have an anecdote, not a segment.
- How often does it happen, and what does each occurrence cost them in money, time, or risk?
- What are they doing about it right now? Every problem worth solving already has a workaround, and the workaround is your real benchmark.
- Have they ever spent money, or built and maintained a workaround, to deal with it? Money and sustained effort already spent are the strongest signal that money will be spent again.
- If their current workaround vanished tomorrow, would they be blocked, or merely mildly annoyed? Blocked is a market. Mildly annoyed is a feature nobody adopts.
Notice that every one of those points backward, at what people have already done, not forward at what they say they might do. “Would you use this?” invites a hypothetical, and hypotheticals inflate. “What did you do the last three times this came up?” invites evidence. The same instinct is why so many teams misread requests: a loud ask for a feature is usually a solution wrapped around a problem, and the useful signal is the behavior underneath it, not the phrasing on top, a trap I have written about in why every feature request is a solution in disguise.
Behavior is the only vote that counts
Stated demand inflates. Behavioral demand does not, because it costs the customer something to express. That is the entire case for testing demand with an action rather than a question. A fake door, a landing page with a real call to action, a pre-order, a signed letter of intent, a card on file, a calendar hold, a prototype someone actually returns to: each of these makes the customer spend a small amount of intent, and spent intent is worth an order of magnitude more than the surveyed kind. This is why a crude demand test can be sharper than a month of polished interviews, the argument I made in fake door testing is the fastest path to real demand data.
There is a quieter trap on the other side of the same coin. The people who agree to your interviews are, by definition, the people willing to show up and talk to a product team, which skews toward enthusiasts. The market includes everyone who tried something like this and walked away, and they are the hardest voices to hear because they are not in the room. Studying only the customers who lean in is a form of the survivorship bias that quietly eats product discovery, and it flatters demand estimates every time.
The reframe
Discovery has two jobs, and teams routinely finish the first and skip the second. Job one: is the problem real. Job two: is the market real, meaning enough people, enough pain, enough frequency, and enough willingness to act. A validated problem sitting on top of unvalidated demand is the most expensive kind of false confidence, because it looks and feels like diligence. You did the interviews. You heard the pain. You have the quotes. None of that has told you how many people will change what they do to make the pain stop.
So before you commit a quarter to a problem you are sure is real, force the second question into the open. Not “did people agree this is a problem,” which they almost always will, but “what have real people already done, or spent, to solve it, and how many of them are there.” If you cannot answer that in behavior rather than agreement, you have validated a problem and imagined a market. The launch is a very expensive place to learn which one you had.