Validation guide
How to plan a useful venture validation test
A useful validation test begins with a decision. Specify what you are considering, what remains uncertain and what evidence would change the next commitment. Then choose the smallest scoped experiment capable of answering that question with the customers who matter.
01
Match the method to the question
Customer interviews can investigate needs, current workflows and buying considerations. A prototype can make an idea tangible enough to discuss or try. An offer or pricing test examines a proposed commercial choice. A live pilot can expose practical questions about use and operation. Decide which uncertainty each activity is intended to address.
Write down the customer group, recruitment approach and interpretation criteria before collecting responses. Keep observations separate from your interpretation. If the participants or test conditions do not represent the intended setting, carry that limitation into the conclusion.
02
Decide what the evidence supports
Review the findings against the original question. Proceeding, changing direction, stopping and gathering more evidence are all valid next steps. A positive interview response is not the same as a purchase, and a useful pilot does not automatically establish repeatable economics or readiness for production.
From previous experience
An actual case, not a hypothetical
In a small-business insurance assignment from Ben Shaw’s previous work, customer interviews and prototypes helped make a proposed MGA concept tangible. The insurer approved a seven-figure investment commitment. That specific decision is the reported outcome; it should not be read as evidence of a completed launch.
Selected experience from Ben Shaw’s previous roles and ventures. Client organisations are unnamed.
Read the small-business insurance caseHypothetical example
Illustrative worked example: a missing-document workflow
Imagine a founder considering a tool that helps operations teams chase missing customer documents. The immediate decision is whether to build a pilot. An initial assumption is that repeated follow-up creates enough difficulty for a team to change its existing process.
Begin by asking prospective users to describe a recent case: what was missing, how they followed up, who was involved and what happened next. Then use a simple prototype to explore how the proposed tool would fit that workflow. If participants report that the real obstacle is unclear responsibility, revise the problem before adding reminder features. This hypothetical example illustrates a decision process; it is not an Aught case study.
03
Produce an evidence log
Record the assumption, participant context, observed behaviour or response, interpretation and remaining uncertainty. Keep direct observations identifiable as such. Finish with a decision note explaining which findings support a pilot, which challenge it and what the pilot would still need to establish.
Template
A record you can copy
Copy this table into your own document. The third column is a hypothetical example, not a record from a real project; replace each role with an agreed owner.
| Field | What to record | Hypothetical example |
|---|---|---|
| Decision | Commitment this test informs | Whether to build a working prototype |
| Audience | Specific people and context | Operations leads handling small-business insurance submissions |
| Assumption | Belief with consequences | Incomplete submissions create recurring rework |
| Method | How to observe it | Interview users about a recent submission and inspect their current workflow |
| Evidence | What was actually observed | Pending—record concrete examples and counterexamples |
| Decision rule | Conditions agreed before research | Proceed only when recurring examples and access to a pilot workflow are established |
| Owner and review | Who decides and when | Venture lead at the agreed research review |
04
Avoid this interpretation mistake
A participant saying that the idea sounds useful does not establish willingness or authority to adopt it. Explore what changing the workflow would require, who controls the decision and what an appropriate next commitment would be. Keep enthusiasm and evidence of adoption distinct.
Checklist
Test-plan checklist
- What decision will this evidence inform?
- Which customer group needs to participate?
- Which assumption does each activity examine?
- What response or observation would change the decision?
- What are the test’s operating boundaries and dependencies?
- Which limitations and unresolved questions will travel with the findings?
- What evidence would be needed for the next, larger commitment?
Resources
Further reading
GOV.UK’s research-planning guidance starts with actionable learning objectives. Its interview guide explains how to investigate users’ circumstances through concrete examples and neutral questions.
Related