The short answer
Before building, identify a reachable customer, investigate a recent problem, test a specific offer, and try delivering the outcome by hand if someone commits. Record what people did and what they agree to do next, then decide whether to build, revise, or stop.
Test the riskiest assumption first
- What you need to learn
Is the problem real?
Your next moveAsk about the last time
What to observeFind a reachable customer. Ask what happened, what they tried and what it cost them.
1 source behind this suggestion
Maurya suggests asking what happened the last time someone faced the problem and what they tried, listening for time, money, or workarounds already spent.1
Behind this tip1 source · Select to explore - What you need to learn
Does the offer matter?
Your next moveAsk for a concrete action
What to observeDescribe the outcome and terms. Record what someone actually commits to, beyond a compliment.
1 source behind this suggestion
Aakash Gupta describes Mark Pincus proposing a simple site behind an ad to test demand before building a product.3
Behind this tip1 source · Select to explore - What you need to learn
Can you deliver the benefit?
Your next moveTry doing it by hand
What to observeWith someone willing to try, deliver the outcome manually and note what helps or breaks.
1 source behind this suggestion
Dan Martell recommends fixing a problem by hand before automating it, so the founder can learn the workflow steps rather than start with features.2
Behind this tip1 source · Select to explore
Your validation record
Customer and problem: [who, and what happens] Risky assumption: [what must be true] Test and requested action: [what you will ask] Observed commitment: [what they actually did] Delivery result: [what changed] Decision: [build, revise or stop]
Build
A clear customer commits and receives the intended benefit. Build the smallest version that supports that job.
Revise
The problem is real but the offer or delivery misses it. Change the weak part and test again.
Stop
You cannot find meaningful demand or a useful outcome. Preserve what you learned and reconsider the idea.
Detailed reasoning and examplesThe full playbook, source comparisons and related questions
Use this when
Use this if you have an idea but have not established whether prospective users experience the problem or want your proposed outcome.
You’ll leave with
Leave with a validation worksheet containing a customer definition, problem accounts, an offer, commitments, delivery evidence, and a build decision.
Your playbook
Choose a customer and problem to investigate
- Do
Write down who encounters the problem, when it arises, where you can reach those people, and what they might use instead. Choose a problem you can investigate directly rather than drafting features.
- Make
Start a validation worksheet with a customer definition, problem hypothesis, and contact route.
- Check
If you cannot identify and reach people in that situation, narrow the customer definition or change the problem before proceeding.
Preview the template
Customer: [who experiences the problem] Trigger: [when it happens] Suspected cost: [time, money, or lost opportunity] Current alternative: [what they use now] Contact route: [where to find them] Recent accounts: [what happened and what they tried] Offer: [outcome and terms] Requested action: [what you will ask them to do] Commitment: [action actually taken] Delivery evidence: [what happened when they tried it] Decision: [build, revise, or stop]
Why this step is in the plan
Collect accounts of recent behavior
- Do
Contact people who match your worksheet definition. Ask them to recount a recent occurrence, what they tried, what it cost them, and what remained unresolved. Record their accounts before describing your solution.
- Make
Add recent accounts and existing workarounds to the worksheet.
- Check
If accounts remain hypothetical or the problem has little consequence, revise the customer or problem; otherwise use their descriptions to frame an offer.
Why this step is in the plan
Test an offer and record commitments
- Do
Turn the recurring problem into a proposed outcome and terms. Decide in advance what response would justify a trial. Present the offer directly, or use a simple page if you can reach suitable traffic. Ask for an observable next action.
- Make
Add the offer, requested action, decision criterion, and actual commitments to the worksheet.
- Check
If people praise the idea but decline the requested action, revise the offer or problem before building. Treat a page click as interest, not acceptance of the offer.
Preview the template
For [customer] facing [specific problem], I can help you get [outcome] through [proposed approach]. The terms are [price or effort, if relevant]. Would you [specific next action]?
Why this step is in the plan
Aakash Gupta describes Mark Pincus proposing a simple site behind an ad to test demand before building a product.3 Gupta instructs readers to choose their click-through bar before looking at results.3 In contrast, AnnaOwner2084 reports a B2B feature demand test whose results were not strong enough to justify development.4
Deliver the outcome without building the product
- Do
For someone who commits, deliver the promised outcome manually where feasible. Note each task, handoff, difficulty, and the user's response. Compare what delivery required with the offer they accepted, then decide what, if anything, needs software.
- Make
Complete the worksheet with delivery evidence, workflow steps, and a build, revise, or stop decision.
- Check
Consider building if a committed user can use the delivered outcome and you can identify a workflow worth repeating. Otherwise revise or stop.
Why this step is in the plan
Dan Martell recommends fixing a problem by hand before automating it, so the founder can learn the workflow steps rather than start with features.2
When this works
- Use direct conversations and manual delivery when you can reach affected people and reproduce the proposed outcome safely without a product.
When to avoid
- Do not treat compliments, page visits, or an unaccepted offer as a build decision. If manual delivery is unsafe or impossible, test a smaller observable commitment instead.
Compare the real examples
What 1 source did and reported Explore examples ↓
- Reddit
AnnaOwner2084
The author reports that the test results were not strong enough to justify building the feature.
Described a B2B SaaS company testing demand for a feature before committing to development.