Between 2014 and 2017, a San Francisco startup called Juicero raised $120 million from Google Ventures, Kleiner Perkins, and Campbell's Soup, among others, to make a Wi-Fi-connected juice press. The original price was $699. They cut it to $400. The founder, Doug Evans, compared himself to Steve Jobs and told reporters the machine could exert four tons of pressing force, "enough to lift two Teslas." Then in April 2017, two Bloomberg reporters published a story showing you could squeeze the juice packets by hand in roughly the time the machine took. Within five months, the company shut down.
The Juicero post-mortem has been written a hundred different ways, mostly as a Silicon Valley vanity tale. The piece of it that interests me is less obvious. Juicero did validate. They had interviews. They had press. They had paying customers leaving positive reviews. What they never tested was whether the underlying problem (juicing at home is too messy and time-consuming) was painful enough to anyone, in numbers, to justify a $400 machine plus a $5-to-$8-per-packet subscription. The product was tested constantly. The job it was supposed to do was never tested at all.
This pattern is, by a wide margin, the largest single killer of startups. CB Insights tracks the reasons companies die through founder post-mortems. "No market need" has sat at the top of their list for over a decade. The 2014–2021 dataset put it at 42 percent. The 2024 update with four times the sample landed on 43 percent under slightly different language. The number stays steady no matter how many validation frameworks come out. The Lean Startup is sixteen years old. Customer Development is older than that. The Mom Test is taught at Harvard, MIT, UCL, and inside Y Combinator. Every accelerator runs a "talk to your users" curriculum. And still, more than four in ten startups go to launch and find out nobody actually wanted the thing.
Most founders are validating, in some literal sense. They're just validating the wrong thing.
What you're actually testing when you ask "would you use this?"
Listen to how founders describe their idea. Almost always, the description starts with the solution. "It's an app that helps small businesses track their inventory." "It's a marketplace connecting freelance designers to startups." "It's a Chrome extension that summarizes long emails." Then comes the validation round. The founder books a few interviews. They describe the solution. They ask whether the person would use it. The person says yes. The founder hears yes a few times, then a few more, and the green light feels earned. Building starts.
Six months later, nobody is using it.
Those interviews tested one thing: whether the solution sounded reasonable when described in a coffee shop. They didn't test whether the underlying problem was real, frequent, or painful enough that someone would actually rearrange their day to solve it. Those are very different questions with very different answers, and the second one is the one that decides whether a business exists.
The milkshake nobody could fix
The canonical story here is the McDonald's milkshake, popularized by Clayton Christensen in Competing Against Luck. McDonald's wanted to sell more milkshakes. They did what most product teams do: surveyed customers about milkshake preferences. Sweeter or less sweet? Thicker or thinner? More flavors? The customers gave clear answers, McDonald's made the changes, and sales didn't move.
A researcher named Bob Moesta got involved and asked a stranger question: when do people actually buy milkshakes? The data was odd. About half of all milkshake sales happened before 8:30 in the morning. People bought them alone, in drive-throughs, and took them away in their cars. Nobody was buying milkshakes for the milkshake-tasting experience. They were buying them for the commute.
The job, in Jobs-To-Be-Done language: I need something I can drink one-handed in traffic, that doesn't make crumbs, doesn't fill me up too fast, and lasts the whole drive. The milkshake wasn't competing with other milkshakes. Its real competition was bagels, which left crumbs in the lap; bananas, which were gone in three minutes; donuts, which left sticky fingers on the steering wheel. Once McDonald's understood the actual job, the redesign was easy: thicker, with small chunks of fruit so it stayed interesting, available in a faster lane for the commuters. Sales went up.
The reason this story keeps getting told is that surveys about the product itself yielded nothing useful, no matter how many times they were run or how clearly the answers came back. The validation that mattered was of the job, not the milkshake.
Why solution-first questions almost always lie
There's solid research behind why this fails, and it's worth knowing.
Humans are bad at predicting their own future behavior. There's a body of work on this going back to Kahneman's affective forecasting research, and you've seen the everyday version: people who say they'll go to the gym three times a week go on average less than once. When you ask "would you use this?" you're asking someone to imagine a future version of themselves in a future scenario. They'll overwhelmingly say yes. Saying yes is socially easy; saying no requires explaining why, which is awkward in a coffee shop where someone just bought you a coffee to ask the question.
The deeper reason is the one Rob Fitzpatrick built The Mom Test around. Nice words from a stranger don't predict whether they'll cancel a competing tool, set up an account, learn a new workflow, and pay you monthly for the next two years. Compliments are easy. The thing that costs something to share is past behavior, and past behavior turns out to be the only reliable signal you can collect in an interview. What did they actually do about this problem before they met you? How much did that cost them, in money or time? How long did they stick with whatever they tried? Those answers are checkable against reality, and they tend to predict whether someone will buy your thing once it exists.
There's a third effect, harder to name, which is that solution-first questions create their own gravity. Walk into a conversation with a solution and every question you ask is downstream of that solution. You can do twenty of those interviews and never learn whether the problem you're solving is even the one that matters to the person sitting across from you.
Doing it the other way
Tony Ulwick has been working on this for thirty years through a methodology he calls Outcome-Driven Innovation. He frames it as arithmetic. The question to ask isn't whether someone would buy your solution. It's how important a given outcome is to them, and how satisfied they are with whatever they're using now to achieve it. Important plus satisfied is a non-opportunity; someone already has that market. Important plus badly unsatisfied is where the money is. You score these on a scale, rank dozens of outcomes against each other, and look for the largest gaps. None of this requires having a solution in mind. You can do the whole exercise before you've decided what to build.
In practice it's a duller kind of work than a sales pitch. The conversations are about the person's life, not your product. Tell me about the last time you tried to do X. What did you do? What was annoying about that? How much time did it cost? What did you try before that one? You're mapping a problem domain and trying to disprove your own assumptions, which is the opposite of the energy a founder brings naturally.
Steve Blank has a phrase for the activity itself: get the hell outside the building. Customer development is structured conversation with the people who actually live the problem, and the goal is to find the parts of your model that are wrong before you've built around them. Once you've mapped what the job is, who's hiring something to do it, and which outcomes are important and unsatisfied, then you start generating solutions. Multiple ones, anchored to outcomes you've already established matter. You score each against criteria you set before scoring anything, you pick the highest-leverage option, and you go back to the same people whose problem you mapped to test whether your candidate actually fits.
Most founders never make this inversion. They start with a solution and look for a problem to fit it onto. The order is supposed to run the other way: find a problem worth solving, then let the constraints of the problem shape the solution.
A few things to change in your next round of conversations
Don't describe your product in the first ten minutes. The pitch contaminates everything that comes after. Lead with the person's life and the problem you suspect they have, let them correct your understanding of their life, and then keep asking about it. You'll learn more from a thirty-minute conversation that never mentions your product than from twelve that all do.
Ask about past behavior instead of future intent. "The last time you faced this problem, what did you do?" is a question with an answer you can check against the world. "Would you use this if it existed?" is a question whose answer is mostly an invitation to imagine being a better version of yourself.
And learn to recognize the difference between the dull yes and the bright yes. The dull yes sounds like yeah, that's been bugging me for two years, I've tried three different things and none of them stuck. Write that one down. The bright yes sounds like oh, that's such a great idea, you should totally build that. Bright enthusiasm from someone who has never bothered to solve the problem on their own time is not validation; it's politeness, and the two are easy to confuse in the moment.
One last thing
Bandos exists because doing this in the right order is genuinely hard, and skipping the problem mapping is the path of least resistance for almost everyone. The product walks you through it: rough idea, customer, need, then solutions, then evaluation against criteria you set ahead of time, then a customer interview script with Mom-Test discipline built in, then real responses scored against the criteria you committed to. You can see how the whole flow works or start a project for free. You can also run the same loop on paper with a notebook and a phone. The order matters more than the tool.
The forty-two percent of startups that died from no market need didn't die because the founders were lazy. They built fast and shipped on time. They tested the wrong thing.
Before the next line of code, try one interview where you don't mention your product at all. See what comes back.