Validate before building: the one-day evidence sprint

Write the riskiest assumption

Choose the assumption that could make the product commercially irrelevant even if the software works. Early on, this is usually the buyer, urgency, promise, access channel, or willingness to change—not whether a button can be implemented.

Phrase it so evidence could prove you wrong.

We believe [specific buyer] urgently wants to [outcome] because [trigger], and will [meaningful action] when offered [promise] through [channel].

Create the smallest believable offer

Describe the outcome, scope, timeframe, and next step. You may deliver the first version manually. The buyer is evaluating whether the outcome is worth attention or money, not whether your internal automation is elegant.

• One buyer
• One painful situation
• One measurable outcome
• One short timeframe
• One clear next step

Contact five qualified people

Five is enough for a one-day signal but not enough for certainty. Select people who visibly match the situation and contact them individually. Ask for an action appropriate to the stage: answer one question, review a concrete promise, try a prototype, or discuss a paid pilot.

Record who you contacted, why they qualified, and when a response would reasonably be due. Otherwise a failed test can always be explained away as “the wrong people,” while premature silence can be mistaken for a verdict.

Score behavior, not encouragement

A compliment is not validation. Weight actions by commitment. A detailed reply is stronger than a like. Sharing a workflow is stronger than saying the problem exists. Trying the product is stronger than agreeing to a call. Paying is the strongest early evidence that the problem, promise, trust, and timing align.

• 0: no response or vague praise
• 1: specific problem confirmation
• 2: shares workflow, data, or objection
• 3: tries, books, or introduces another buyer
• 4: pays, pilots, or commits meaningful resources

Make one decision before sunset

Choose one: continue with the same buyer and promise, narrow the buyer, change the promise, change the channel, or pause the idea. Do not turn mixed evidence into a list of features.

Then select one Product move only if the evidence identifies a concrete blocker. Validation ends with a decision, not a prettier backlog.

END-OF-DAY RECEIPT
Qualified people contacted: [number]
Meaningful replies: [number]
Strongest exact quote: [words]
Highest-commitment action: [action]
Assumption changed: [what changed]
Tomorrow’s Revenue move: [next test]
Product work explicitly cut: [list]

Match the test to B2B or B2C reality

B2B validation usually needs fewer but more qualified conversations because role, authority, workflow, implementation, and budget all affect the decision. B2C validation can use faster behavioral tests, but low-friction interest still does not prove repeated use or payment.

In both cases, select the commitment that matches the stage. A problem interview can validate language and workflow. A prototype can test comprehension and value. A paid pilot or preorder tests a stronger part of the value exchange. Do not ask one weak signal to prove the entire business.

• B2B: role, trigger, existing process, authority, security, implementation, and budget.
• B2C: trigger frequency, immediate value, habit, alternatives, and payment behavior.
• Marketplace: validate supply and demand separately before claiming liquidity.
• Sensitive product: validate trust and risk tolerance before collecting real data.

Use an evidence ladder instead of one verdict

Evidence accumulates. Problem confirmation tells you the situation exists. Sharing a workflow proves the person invested effort. Trying a prototype tests whether the promise and interaction create movement. Returning, referring, preordering, piloting, or paying creates stronger evidence about value and urgency.

Write down what each test can and cannot support. Five interviews cannot prove retention. A landing-page signup cannot prove willingness to pay. One payment proves one buyer committed—not that the channel scales.

EVIDENCE LEDGER
Assumption: [one falsifiable belief]
Test: [what the buyer can do]
Signal strength: [0–4]
What this can prove: [bounded conclusion]
What it cannot prove: [important limit]
Minimum sample / response date: [number / date]
Decision if weak: [narrow / change / stop]

Walk through a one-day validation receipt

A founder considers an AI handoff tool for small design agencies. The riskiest assumption is not whether AI can summarize a project; it is whether agency owners lose enough time reconstructing decisions to change their workflow. Five owners receive a request to describe the last difficult handoff and share the artifacts they used.

Three reply. Two describe searching Slack and Figma comments, but only one says the delay affected a client deadline. The decision is not “build the AI tool.” It is to narrow the trigger to agencies handing projects between freelancers and full-time staff, then offer a manual handoff packet to test whether the outcome earns repeated use or payment.