How to Validate a Startup Idea Before You Build

Describe the problem before the solution

Write down who has the problem, when it appears, what they do today, and what makes the current approach difficult. Keep the statement about an observable situation rather than a feature. “Independent repair shops lose time coordinating parts between calls” is easier to investigate than “shops need our AI marketplace.” The second sentence already assumes a solution and a reason people will adopt it.

Separate facts from beliefs. A founder may know that several shop owners complained about delays, but may only suspect that those delays cause lost revenue or that software is the preferred fix. Put each belief on a list and mark how it could be disproved. This keeps enthusiasm useful: it gives the team questions to answer rather than conclusions to defend.

• User: a specific role or group, not “everyone.”
• Situation: the moment the problem occurs.
• Current workaround: what people actually do.
• Cost of the problem: time, effort, missed goals, or another observable consequence.

Choose the assumption that could invalidate the idea

A startup idea usually depends on several linked assumptions: that a group has the problem, that it matters enough to change behavior, that the proposed approach can solve it, and that the team can reach users. Test the assumption that would make the rest irrelevant if it proved false. If customers already solve the issue adequately, polishing a prototype will not answer the central question.

A useful test has a clear audience, action, observation, and decision rule. For example, a hypothetical team exploring repair-shop coordination might ask five independent shop managers to walk through the last time a part delay disrupted a job. The team would record the steps and existing tools, not pitch a product. Before starting, it could decide that recurring manual follow-up across several interviews warrants another test, while a one-off inconvenience does not.

Run customer conversations that produce evidence

Ask about recent behavior, not imagined intent. “Tell me about the last time this happened” invites a concrete story. “Would you use an app for this?” invites politeness and speculation. Ask what happened next, who else was involved, how the person handled it, and what they tried before. Avoid explaining your preferred answer until you have heard their account.

Take notes in a consistent format and capture the person’s words separately from your interpretation. After each conversation, record what surprised you, which assumption changed, and what remains unknown. A small number of interviews cannot establish market size or prove demand. They can reveal vocabulary, workflow details, and whether the problem merits a more focused test.

Use a decision memo, not a confidence score

At the end of a test, write a short memo: the question, the method, what was observed, what was not observed, and the next decision. Possible decisions include continue testing, narrow the audience, change the problem framing, or stop. “We learned that managers rely on phone calls” is more useful than “validation was positive” because it points to a next experiment without overstating what the evidence means.

Worked hypothetical: after interviews, the repair-shop team finds that parts coordination is frustrating, but each shop has a different supplier process. The team should not immediately claim product demand. It might next observe one complete workflow or test whether a single repeatable step can be simplified. The idea remains a hypothesis until people repeatedly choose the solution in a real setting.