Validation fails most often not because founders skip it, but because they run it in a way that can only produce a yes. They describe the idea to people who like them, ask whether it sounds useful, and collect a stack of polite encouragement that feels like data and is not.
Real validation has one property: the person on the other side gives up something. Money, time, data, a commitment, their reputation with a colleague they introduce you to. Everything else is conversation.
That is the whole principle. The rest of this is how to run it without wasting two months.
Separate the two questions you are actually asking
There are two, and they need different evidence.
Is the problem real? Does this pain exist, does it recur, is it sharp enough that people already spend money or effort on it?
Is your solution the right answer? Given the problem exists, does your particular approach beat what they do today by enough to justify switching?
Founders almost always jump to the second. It is more interesting, and it is where their idea lives. But a brilliant solution to a mild problem is a harder business than a mediocre solution to an agonising one, and you can only tell which you have by investigating the problem on its own terms first.
Steve Blank's customer development model puts this first stage — customer discovery — before anything resembling a build, and the underlying instruction has not aged: "There are no facts inside your building, so get outside." The purpose is not to pitch. It is to find out what people's top problems actually are and what they currently pay to make them go away.
Stage one: twenty conversations, and how to not ruin them
Twenty is roughly the floor. Todd Jackson's guidance, drawn from First Round's work with early-stage founders, puts it at 20 to 50 conversations, weighted higher for B2B where each customer matters more and the buying process is more complex.
The failure mode is not the number. It is the questioning.
Ask about the past, not the future. "Would you use something that did X?" produces fiction, because people are bad at predicting their own behaviour and good at being nice. "Walk me through the last time you dealt with this" produces facts. What did they actually do, what did it cost them, what did they try first, why did it not work?
Ask what they already spend. Money, hours, headcount, workarounds. A problem with an existing budget attached is a problem with a proven willingness to pay. A problem everyone agrees is annoying but nobody has ever spent anything on is a much harder sell than it sounds in the room.
Do not describe your solution until the end, and then only to see how they react. The moment you pitch, the conversation stops being research. They will start being polite and you will start hearing what you want.
Listen for intensity, not agreement. Jackson's warning is worth internalising: settle only for strong enthusiasm, not "meh." The signal you are looking for is someone who is visibly annoyed about the problem, who interrupts you, who has already built a spreadsheet to cope with it. Mild agreement is a no wearing a polite face.
Notice who contacts you. The strongest signal in early discovery is unprompted pull — people coming to you after hearing about it secondhand. Jackson cites Vanta receiving unsolicited inquiries from network contacts. You cannot manufacture this, but you should count it when it happens.
Keep a written record of each conversation on the same day, in the same format, with a one-line answer to: what did this person already do about this problem? After fifteen, patterns are visible. After twenty-five, you are usually confirming rather than learning.
What counts as evidence, ranked
Not all yes is equal. Roughly, from weakest to strongest:
- "That sounds useful." Worth almost nothing. Costs the speaker nothing.
- An email address on a waiting list. Weak, but not zero — it is a small deliberate act.
- Time given. A 45-minute call, a follow-up meeting, an introduction to a colleague. Their calendar is a real budget.
- Data given. Someone who exports their spreadsheet and hands it to you has stopped being polite and started being invested.
- A prototype-based commitment. A signed letter of intent or a design partner agreement on the strength of screens alone. Cocoon, in Jackson's account, secured early customers this way.
- Money. Pre-payment, a deposit, a paid pilot. Even a small amount changes the conversation completely, because the person has now defended the decision to someone else.
The jump from 1 to 6 is not gradual. There is a cliff somewhere around 3, and most "validated" ideas sit below it.
A useful discipline: before you start, decide what level of evidence you will require before you commit engineering time, and write it down. Deciding afterwards, with a stack of encouraging emails in front of you, is not a decision.
Stage two: test the solution without building it
Once the problem holds up, you need to know whether your answer to it lands. You do not need software for this.
Show a prototype. Screens that look real, a flow someone can walk through, realistic content rather than lorem ipsum. Watch where they hesitate. The point is not whether they like it — it is whether they understand it without narration.
Run a demand test. A landing page describing the product as though it exists, with a real call to action and real traffic pointed at it. This is the technique behind the Dropbox story that usually gets told badly: the famous explainer video was not the first move. A landing page test preceded it, and a later paid-acquisition experiment failed on unit economics — around $233 to acquire a customer for a $99 product — which is arguably the more useful lesson in the whole sequence. The experiment that fails tells you more than the one that goes viral.
Do it manually. Deliver the outcome by hand for five customers before automating anything. It is slow, unscalable, and it teaches you more about the real workflow than any amount of planning. It also occasionally reveals that the service is the business and the software was never necessary.
Sell before you build. In B2B especially, a deck, a prototype and a conversation can produce a signed pilot. If you cannot sell it with a prototype, there is a reasonable chance you could not sell it with a product either — the missing ingredient is usually clarity of value, not features.
The traps that cost the most
Talking to the wrong people. Friendly, available, and easy to reach are all uncorrelated with being the buyer. If you cannot get twenty of the right people on a call, that is itself an important finding about distribution.
Building vitamins. Nice-to-have products can work, but they need a fundamentally different go-to-market and a lower price point. Know which one you have before you set the plan.
Ignoring distribution. Jackson lists this among the recurring traps, and it is the one that shows up latest and hurts most. A validated problem and a validated solution with no repeatable way to reach customers is not a validated business.
Confusing enthusiasm with a market. Ten delighted people who are structurally unlike each other do not constitute a segment. Look for whether the ten share a describable characteristic that you could target.
Validating for too long. There is a point where further conversations stop changing your plan. When the last five interviews taught you nothing new, stop. Validation is a phase, not a lifestyle, and the purpose was always to earn the right to build something.
What "done" looks like
You are ready to move when you can write, without softening it:
- The specific person who has this problem, described precisely enough that you could find fifty more of them.
- What that person does about it today, and what that costs them.
- Why your approach is better in a way they recognised themselves rather than one you explained.
- The evidence, at level 4 or above, and how many people produced it.
- How you will reach the next hundred of them.
If any line requires a caveat, that line is your next piece of work — and it is usually cheaper to close it now than after a build.
The clarity that comes out of this stage is also, conveniently, the raw material for everything you will say publicly afterwards. The language customers used to describe their own problem is better positioning copy than anything written in a workshop. That connection between discovery and brand strategy is why we run them close together rather than treating positioning as a later exercise.
Once the problem is proven, the next question is how little you can build to test the solution with real stakes attached. That decision is easier once you are clear on what an MVP actually is and on which of an MVP, a prototype or a proof of concept your next step should be — both are downstream of the work described here, and both are cheaper when this part is done properly.
Common questions
How many customer interviews are enough?
Twenty is a reasonable floor, with 20 to 50 a common range and the higher end appropriate for B2B, where each customer is worth more and buying processes are more complex. The practical signal is saturation: when five consecutive conversations teach you nothing new, stop.
What questions should I ask in a validation interview?
Ask about past behaviour, not future intentions. "Walk me through the last time you dealt with this" produces facts; "would you use something that did X" produces politeness. Ask what they already spend in money, hours or workarounds, and hold your solution back until the end.
Can I validate an idea without talking to anyone?
Partially. A landing page test with paid traffic measures whether strangers will act on a proposition, and that is real evidence. But it tells you what happened, not why. Without conversations you learn your conversion rate and nothing about how to improve it.
What if people say they like the idea but never buy?
That is the normal result, and it is why stated interest ranks near the bottom of the evidence scale. Raise the cost of saying yes: ask for a deposit, a paid pilot, a signed letter of intent, or a calendar commitment. Enthusiasm that survives a real cost is the only kind worth planning around.
Sources and further reading
- Steve Blank, *The Customer Development Methodology* (PDF)
- Todd Jackson, *How to validate your startup idea*, Lenny's Newsletter
- *Dropbox's MVP: you're missing most of the story*, Launch Tomorrow
