Write the evidence test before the feature list

Most feature debates begin too late. By the time a team is comparing screens, it has already accepted the hidden premise that the proposed feature deserves to exist. The more useful question is earlier and harsher: what evidence would make us decline to build it?

This is not a generic MVP exercise. It is a way to buy one decision with the smallest credible test. The original research's validation sequence is worth reading alongside this guide at validation chapter.

Start with the expensive belief

List the beliefs that must hold for the idea to work: a specific person has the problem, notices it often enough, controls a budget, can adopt the solution, and receives enough value to continue. Rank them by damage if false and uncertainty today. Test the top item, not the easiest item.

The UK Government Service Manual advises teams to turn unfounded assumptions into research questions and choose methods that answer the most important questions for the least time, effort, and cost (GOV.UK user-research planning). That is government-service guidance, not startup outcome research, but the operating discipline travels well.

Write the experiment brief

Use six lines:

• Belief: what must be true.
• Risk: what the business loses if it is false.
• Method: the behavior you will observe, with whom and where.
• Measure: one primary signal and any guardrail.
• Threshold: the result that advances, pauses, or kills the bet.
• Decision owner and date: who will call the result and when.

Strategyzer's Test Card similarly asks for a hypothesis, test, measure, and success threshold (Strategyzer Test Card). That is the framework publisher describing its own method. Editorially, the missing line in many teams is the decision: a threshold without a promised action is only a dashboard target.

Worked hypothetical example

Hypothetical: A founder believes independent accounting firms will pay for an inbox that sorts client document requests. The expensive belief is not that accountants dislike email. It is that a firm will trust the workflow with a live client and change an existing routine.

The brief says: recruit eight firms that handled at least ten client-document chases last month; offer a two-week, manually operated test using the firm's normal inbox; measure whether at least four firms route three real client requests through it and ask to keep using it; stop if fewer than two do so, or if more than half of requests require founder interpretation that cannot be codified. The result does not prove a market. It decides whether a narrow workflow deserves another test.

Protect the falsification condition

Write the stop rule before recruiting. Do not substitute compliments for the named behavior, extend the window because two prospects were busy, or quietly change the segment after seeing weak results. Record exceptions, but do not let them rewrite the test.

GOV.UK's alpha guidance says to focus on the riskiest assumption and build only enough to test it (GOV.UK alpha phase). Again, this is service-delivery guidance. The editorial application here is to treat code, mockups, and founder labor as experiment costs, not progress in themselves.

Decision artifact

Before work starts, require this sign-off:

• The named assumption can be false.
• The participant group can encounter the problem for real.
• The primary measure records behavior, not stated enthusiasm.
• The threshold is set before results arrive.
• Passing leads to one named next test, not a roadmap.
• Failing removes or changes something consequential.

Limits

A clean experiment can still be badly sampled, too short, or distorted by founder attention. Small tests estimate direction, not a population rate. Regulated, safety-critical, hardware, and scientific products also need feasibility and risk work in parallel. The brief improves decision hygiene; it does not turn eight observations into certainty.