Validation is a sequence of claims, not a single launch test. Move from problem evidence to buyer access, current alternatives, a useful result, commitment and repeatability. At each rung, decide whether to continue, revise the claim or stop before the next test becomes more expensive.
Start with a falsifiable validation claim
Replace “small firms need better admin software” with a claim that can be contradicted:
When [trigger] occurs, [specific role] struggles to complete [job] because [current constraint]. They already use [alternative]. A bounded [result] would be valuable enough to justify [specific next commitment].
Write assumptions underneath the claim. Typical assumptions include access to permitted data, authority to change the workflow, acceptable delivery time, a reachable buying path and a result narrow enough to test manually.
The full pre-build evidence ladder
The rungs are ordered by dependency, not by a universal number of interviews or signups. Do not test price before you know which result is being bought. Do not test demand with people who cannot adopt the result.
| Rung | Claim being tested | Useful evidence | Stop or revise when… | Continue with… |
|---|---|---|---|---|
| 1. Problem | A recent, recurring job creates a consequence for a named role. | Incident notes, sequence, owner, artifact and counter-example | Answers stay hypothetical, consequences are negligible or incidents describe unrelated jobs. | A tighter problem statement. |
| 2. Access | You can reach people who own the same version of the job. | Relevant conversations, introductions, directories or an existing channel | Only peers respond, access relies on deception, or every reachable person has a different job. | A documented recruitment route. |
| 3. Alternative | The current solution leaves a trade-off worth changing. | Observed workaround, product, service, “do nothing” and reasons it persists | The alternative is adequate, trusted and cheaper than the expected change. | A statement of the specific trade-off. |
| 4. Result | You can produce one useful outcome without a full product. | Manual run, redacted data sample, calculation, report or prototype review | The result depends on undefined consulting, unsafe access or a much broader workflow. | A bounded delivery agreement. |
| 5. Adoption | The result can enter the real workflow without unacceptable friction. | Actual input handoff, reviewer, permissions, timing and acceptance criteria | Migration, trust, approvals or training outweigh the problem. | A live or closely simulated workflow test. |
| 6. Commitment | The problem owner will exchange something scarce for the result. | Booked time, permitted data, internal approval, paid audit, deposit or paid pilot | Interest disappears when a real next step is requested. | The one ethical test matched to the remaining uncertainty. |
| 7. Repeatability | The job, inputs and acceptable output can recur within clear limits. | Repeated manual runs, variance log, exception list and delivery effort | Every run is custom, exceptions dominate or the useful result changes by buyer. | A service boundary or first-version scope. |
| 8. Economics and risk | The bounded result can support its costs and obligations. | Delivery effort, provider costs, support load, failure consequence and price discussion | The test only works by ignoring review, support, data handling or founder time. | A build, managed service, narrower test—or a stop decision. |
Write stop/continue logic before running each test
A threshold is useful only when it is tied to the claim, acquisition route and cost of being wrong. A universal conversion rate or fixed interview count is not. Use decision rules that describe evidence quality and what would change your mind.
One-test decision record
“No result” is still a result when the recruitment route was valid and the offer was understandable. “Inconclusive” is appropriate when the test never reached the intended buyer, the message was ambiguous or the workflow could not be run safely.
Completed validation dossier
Illustrative scenario. Assumptions: a fictional bookkeeping practice prepares a weekly list of clients with missing documents; a founder is considering a narrow status-and-reminder service. No customer, result, percentage or market claim is implied.
| Rung | Illustrative evidence | Counter-evidence / unknown | Decision |
|---|---|---|---|
| Problem | An administrator can reconstruct the latest weekly list from a spreadsheet and inbox. | It is not yet known whether a missed item causes a meaningful delay. | Continue to consequence interviews; do not pitch automation. |
| Access | The founder can speak directly with administrators in the same role through a permitted professional introduction. | The reachable practices may use different document processes. | Keep the role fixed; compare workflow differences explicitly. |
| Alternative | The current method is a maintained spreadsheet plus email templates. | The method may be reliable and preferred. | Test the trade-off; do not assume “manual” means broken. |
| Result | A manual service could accept a redacted list and return a reviewed status report. | Reminder sending may require approval and safe contact handling. | Limit the first result to a draft report until permissions are clear. |
| Adoption | The administrator can define who reviews the draft and when it is useful. | No live data or client messages have been authorized. | Use synthetic or redacted input for a review session. |
| Commitment | The administrator agrees to bring a blank template to a scheduled workflow review. | No payment or internal approval has been discussed. | Evidence supports learning, not demand. Choose a commitment test next. |
| Repeatability | Unknown until a permitted manual run is completed. | Exception volume and review effort are unknown. | Do not estimate product scope yet. |
| Economics and risk | Unknown. | Delivery effort, data obligations, support and price are untested. | Building is not justified. |
Current dossier decision: continue research and run one bounded, permission-aware result review. Stop before code. The idea has problem and access clues but no adoption, commitment, repeatability or economics evidence.
Choose the next rung, not the most impressive test
If your dossier is weak at the problem rung, another landing page only measures response to copy. If the problem is clear but adoption is uncertain, a prototype review may be more informative than a presale. If delivery works but commitment is unknown, ask for a real commercial next step with clear terms. The next test should target the first unsupported dependency.