Idea validation: how to test a startup idea

Validation is not asking friends if they like the idea. Almost everyone says yes to be kind, and a yes costs them nothing. Rob Fitzpatrick's The Mom Test is built on this observation: people will lie to you about your idea, so you have to ask about their life instead.

A useful definition: an idea is validated when a specific group of people shows, through behavior, that they have the problem and will take a costly step to solve it. A costly step can be time (a 30 minute call), reputation (an introduction to a colleague), effort (filling a long form) or money (a pre-order). The higher the cost, the stronger the signal.

The Lean Startup puts the same idea as a question. The point is not "can this product be built?" but "should this product be built?"

Before talking to anyone, write the idea as a list of claims that must all be true:

• Who has the problem (be specific: "freelance designers who bill by the hour", not "creatives").
• What the problem is, and how often it happens.
• How they solve it today, and what that costs them.
• Why your solution is better enough to switch.
• What they would pay, and who in the company decides.

Then pick the riskiest one. Usually it is not "can I build it" but "do they care enough".

For each assumption, decide in advance what result would prove you wrong. For example: "If fewer than 5 of 15 interviewees describe a workaround they built themselves, the problem is not painful enough." Writing this down first stops you from moving the goalposts later.

Paul Graham's essay How to Get Startup Ideas warns against "made-up" or "sitcom" ideas: ideas that sound plausible but that nobody needs. He suggests that the best ideas are something the founders themselves want, that they can build, and that few others realize are worth doing. He also describes a useful shape: a small number of people who want something a lot is a better start than many people who want it a little.

Cheap ways to check, before any interview:

• Search for complaints. Forums, subreddits, app store reviews and support communities of existing tools. Note the exact words people use.
• Look for workarounds. Shared spreadsheets, scripts, templates and long tutorials are proof that people already spend effort on the problem.
• Check interest over time. Google Trends shows whether searches for the problem or the existing solutions are growing, stable or fading. It gives relative interest, not volumes, so use it for direction only.
• List the competitors. Competition is usually a good sign: it shows people pay to solve the problem. The question is what they do badly for your specific group.

Aim for 10 to 20 conversations with people who match your "who". Ask about real events, not hypotheses:

• "Tell me about the last time this happened."
• "What did you do about it?"
• "What have you already tried? What did it cost?"
• "Who else is involved when this goes wrong?"

Avoid "Would you use a tool that...?" and "How much would you pay for...?" Answers about the future are guesses. Answers about the past are data.

Listen for what Steve Blank calls earlyvangelists: people who know they have the problem, are actively looking for a solution, and have often built an interim fix themselves. If you meet several of them, you have a lead. If nobody has tried to solve it, the problem may not hurt enough.

Conversations tell you about the problem. A demand test tells you whether people will act on your solution. Buffer's founder Joel Gascoigne described a clean example in Idea to Paying Customers in 7 Weeks: a two page site explaining the product and collecting emails, then a pricing page added in between to see whether people would click on paid plans. Only after people kept clicking through did he start building.

You can run the same test today:

1. Build a one page site with a clear headline, three benefits and one call to action. Our guide to the coming soon page covers what to put on it.
2. Add a pricing step before the sign up, to measure interest in paying, not just curiosity.
3. Send targeted traffic. Share it in the places where you found the complaints, and with the people you interviewed. Tag each link with the free UTM builder so you know which channel worked.
4. Compare the result with the threshold you wrote in step 1.

Other options, depending on the product: a manual service that delivers the result by hand, a pre-order with a refund promise, or a short demo video.

At the end of the test, make one of three decisions:

• Build: the problem is real, people took costly steps, and you know who your first users are.
• Change: the problem is real but your solution, price or target group is wrong. Adjust one variable and test again.
• Stop: nobody had the problem badly enough. This is a good outcome if it took three weeks and not a year.

Do not treat the first sign ups as proof of a business. They prove interest. Usage and payment come later.

Once you decide to build, the people from your interviews and your sign up list are your first audience. The guide to finding early adopters explains how to turn them into your first real users, and finding beta testers helps when you need more people to try an early version. When the first version is ready, you can list it on MegaLaunch to put it in front of people who look for new products every day.