The cheapest evidence that the problem is real

The second stage of my method is Validate: find the cheapest evidence that the problem is real and worth the build. The important word is cheapest.

Teams usually validate too late and too expensively. They build a working version, launch it, and wait for usage to tell them whether they were right. That is validation, technically. It is also the most expensive way to learn something you could often have learned in an afternoon.

A ladder of evidence

I think of evidence as a ladder, where each rung costs more and proves more.

1. Someone describes the problem unprompted. You ask what is hard about their week, and without being led they describe the thing you were planning to solve.
2. Someone is already paying to work around it. A spreadsheet maintained by hand, a contractor doing it manually, a tool bought and abandoned. Workarounds are evidence of pain with a price attached.
3. Someone commits something small. Time for a second conversation, a sample of real data, an introduction to a colleague.
4. Someone uses a fake. A clickable prototype, a manual process behind a simple form, a concierge version where a person does what software eventually will.
5. Someone pays. Even a little. Even a pre-order.

Each rung is roughly an order of magnitude more expensive than the one before. The discipline is to climb only as high as the decision in front of you requires.

Matching evidence to the decision

Not every decision needs the top of the ladder.

Deciding whether to spend two weeks exploring a problem needs rung one or two. Deciding whether to build an MVP needs three or four. Deciding whether to hire a team and commit a year needs five.

Most waste comes from the mismatch: building a product (the price of rung five) to answer a question that rung two could have answered.

Evidence that proves nothing

Some signals feel like validation and are not.

• Compliments. "That's a great idea" is politeness, not evidence.
• Hypothetical future behaviour. "I would definitely use that" predicts almost nothing. What people have already done predicts a great deal.
• Aggregate market size. A large market says nothing about whether your approach solves their problem better than what they do now.
• Your own enthusiasm. Useful for motivation, worthless as data.

The point

Validation is not a gate you pass once. It is a habit that runs through the whole build: before each significant commitment, ask what the cheapest thing is that would tell you whether you are wrong.

Sometimes the answer is to build it. Often it is a conversation, a spreadsheet or a week of doing the job by hand. Those are not detours from building. They are the reason the build, when it happens, is the right one.