Turn an idea into a small learning experiment

The goal: buy information before you build

A promising idea is not yet a reason to spend weeks coding. Your first job is to find the riskiest assumption and run the cheapest honest test that could change your mind. A useful experiment ends with a decision: continue, change the audience or problem, or stop.

1. Describe one person and one painful moment

Avoid audiences like “small businesses” or “creators.” Choose a reachable group with a shared workflow: for example, independent accountants who reconcile client expenses every Monday. Describe the trigger, current workaround, and consequence. If you cannot name a real person you could ask about the last occurrence, the audience is still too broad.

Write a one-sentence problem statement:

When [situation], [specific person] has to [workaround], which costs them [time, money, risk, or opportunity].

Do not put your proposed product in the problem statement. It biases the research toward defending your idea.

2. List assumptions and rank their risk

Write down what must be true for the business to work. Common assumptions include: the problem happens often, the person cares enough to change, you can reach them, the proposed outcome is valuable, they will pay, and you can deliver it safely at a sustainable cost.

For each assumption, score uncertainty (how little you know) and damage if false (how much work becomes wasted). Test high-uncertainty, high-damage assumptions first. A clever technical prototype is a poor first test if you have not established that anyone wants the outcome.

3. Choose a test that matches the question

• Is this a real recurring problem? Interview people about a recent instance and inspect their actual process.
• Can you reach this group? Try a small, rules-compliant outreach batch and track qualified replies.
• Can you deliver the outcome? Do it manually for one or two users before automating.
• Will someone commit? Ask for a paid pilot, deposit, or scheduled implementation only when the offer and terms are clear and lawful.
• Can the workflow be understood? Give a prototype to a target user and watch them complete a task.

Use the prototype workflow guide to choose the lightest artifact that can answer the question, and a small usability test to structure the observation session.

A landing-page signup measures interest in that page and offer; it does not prove retention, willingness to pay, or that the product works. Do not disguise a fake feature as available. Tell people what will happen with their information and honor any promised follow-up.

4. Pre-commit to a decision

Before running the test, write the audience, recruitment method, time limit, observation, and the result that would change your next step. For a small discovery sprint, a reasonable starting rule might be “speak with five people who recently did this task; continue if at least three independently describe the same costly workaround.” This is a learning heuristic, not a statistically valid market estimate.

Keep a simple evidence log: observation, source, date, interpretation, counterexample, and confidence. Separate what a person did from what you think it means. A positive quote is weaker than behavior such as time already spent, a workaround already paid for, or a concrete next step.

5. Decide and preserve what you learned

At the end, record: what happened, what surprised you, which assumption changed, and what you will do next. If the result is ambiguous, narrow the next test instead of adding features. If people do not recognize the problem or will not make any reasonable commitment, revisit the problem or audience before building more.

Use the experiment brief to plan a test, then continue to customer conversations or MVP scope. Y Combinator’s Startup School curriculum is a useful complementary founder resource; its advice is practitioner guidance, not proof that any particular idea will work.