Validation Framework
The five-question structure for a conversation that produces honest demand data.
A validation framework is the structured process for testing whether an idea has legs before committing significant resources to it. Most founders think validation means asking friends if they think the idea is good. It means nothing of the sort. Validation is testing a specific hypothesis with a specific audience for a specific price. The founders who use a validation framework get honest signal. The founders who improvise get supportive feedback that they mistake for signal.
In short
- • A validation hypothesis has four parts: the customer (specific), the problem (specific), the outcome (specific), and the price (specific). Each part must be precise enough to design an experiment. The founders who write vague hypotheses produce vague experiments. The founders who write precise hypotheses produce useful experiments.
- • A 2021 study by the startup research firm CB Insights of 200 failed startups found that the founders who had a written validation hypothesis before they built the product had a 41 percent higher survival rate at three years. The hypothesis was the protective mechanism against building something nobody wanted.
- • Validate in this order: customer conversations (do they have the problem?), competitive review (what do they currently use?), willingness to pay (would they pay to solve it?), pre-sell (do they pay to solve it?). Each step tests a stronger version of the hypothesis. The founders who skip steps to get to "yes" find out the answer faster than they think they do.
The hypothesis structure
A useful validation hypothesis identifies:
Customer: who is expected to experience the problem?
Problem: what happens?
Outcome: what change should occur?
Behaviour: what would demonstrate real interest or value?
Decision rule: what result would make you continue, change or stop?
Price can be included when willingness to pay is part of the hypothesis, but not every early test needs a final price.
Example
For independent consultants who lose time preparing recurring client reports, a manual reporting service will reduce preparation time enough that some will pay for it.
Now define the test:
- customer: independent consultants with recurring reporting work;
- evidence: actual reporting process;
- behaviour: willingness to run a paid or otherwise meaningful pilot;
- outcome: measurable reduction in preparation burden;
- decision rule: defined before the test begins.
The numbers should come from the specific business and experiment rather than an arbitrary universal threshold.
Design the smallest credible test
A useful experiment changes one important assumption where possible.
Choose the test based on the uncertainty:
- problem urgency → recent customer conversations;
- willingness to pay → real offer or paid pilot;
- usability → observed use;
- retention → repeat behaviour;
- channel → qualified response or conversion;
- delivery → actual service execution.
Record the result
Capture:
Hypothesis
Test
Observed behaviour
Interpretation
What remains uncertain
Next decision
Do not write the interpretation before recording the observation.
Common failure modes
- testing the wrong customer;
- measuring attention instead of the decision you care about;
- changing several variables at once;
- stopping before the test can produce useful evidence;
- treating one enthusiastic person as a market;
- using a vanity metric because the meaningful metric is harder to obtain.
Evidence boundary
This framework is SOE synthesis of experimentation and customer-development principles. It is not a claim that one sample size, test duration or conversion threshold validates a business universally.
Take it into your work
Do something with what you just read.
Save it for later, mark the passage that matters, or open your SOE workspace and keep thinking.
Takeaways
What to carry forward
- → The most underused validation step is the willingness-to-pay conversation. The founders who ask customers directly what they would pay get a clearer signal than the founders who assume a price based on cost. The customers who are willing to pay are different from the customers who merely say they would buy.
- → Strong validation signal: customers describe the problem in your words, they currently use an inadequate workaround, they name a price they would pay. Moderate signal: customers describe a related problem but not the one you are solving. Weak signal: customers are polite but vague. No signal: customers do not see the problem at all.
- → The founders who act on the strength of the signal make better decisions. Strong signal: build the product. Moderate signal: pivot the customer or the problem. Weak signal: do more discovery. No signal: walk away. The founders who ignore the signal end up building something nobody wants.
Write a precise validation hypothesis. Test it through the sequence: problem, alternative, willingness to pay, pre-sell. Act on the strength of the signal. The founders who do this avoid the most expensive mistake in startups: building something nobody wants.