Validation is not a survey

The survey measures politeness, not demand

Three things go wrong the moment validation becomes a questionnaire.

• The question describes a solution. Once someone has heard your idea, they answer about the idea rather than about their week.
• Saying yes is free. Agreement costs the respondent nothing, so it carries no information about what they would trade for it.
• You wrote the question. You already believe the problem is real, and that belief is in the wording whether you meant it or not.

The result is a page of encouraging answers and no more certainty than before. Worse, the encouragement is now something you have to argue against later, when the same people do not sign up.

Intent is a prediction. Behaviour is a record. Only one of them has already happened.

Look for what the problem already costs

A problem worth building for is usually already being paid for — not necessarily in money. The three currencies are money, time, and tolerated mess, and the third is the one most founders walk straight past.

Somebody maintaining a spreadsheet to work around missing software is paying. Somebody who re-types the same data between two tools every Monday is paying. Somebody who has bought a product that half-solves it is paying twice — for the tool and for the gap.

That payment is the evidence. It happened before you arrived, it was not prompted by your question, and it is specific enough to size.

Four questions that produce evidence

All four are about the past. None of them mention your product, which is the point — the moment you describe it, you stop learning and start pitching.

• When did you last hit this?A date anchors the answer in something that happened. “All the time” usually means once, memorably.
• What did you do about it?The workaround, in detail. This is the single most informative answer you will get, because it shows what they were willing to spend.
• What did that cost you?Hours, money, a lost client, an evening. A cost they can name is a cost they would pay to remove.
• What have you already tried buying?Tools tried and abandoned tell you the shape of the gap far better than a feature request does.

Notice that none of these can be answered on a form. They need a conversation, and about eight of them is usually enough for the pattern to stop surprising you.

What you cannot validate before building

An honest process also names its limits, and validation has real ones. Some things only a shipped product can answer, and pretending otherwise is how founders spend three months not building.

The left column is research. The right column is the reason to build a small, complete first version rather than a large one — which is the whole argument for shipping the smallest complete outcome. Validation narrows the bet. It does not remove it.

Validation ends where scope begins

You are done with this step when you can write three sentences without hedging: who has the problem, what it costs them today, and what they currently do instead. Not “founders struggle with planning” — a specific person, a specific cost, a specific workaround.

Those three sentences are also the first section of a build plan. The positioning line, the target user, and the one problem v1 must solve are exactly what the planning method starts from — which means good validation does not stop at a verdict, it hands you the opening of the plan.

And if the three sentences will not come out clean, that is the finding. An idea that cannot name its cost has not been rejected; it has just not been narrowed enough yet. Vagueness is not neutral — it is the thing that later turns into a product with four directions and no boundary.