BYD TechThe short answer
To validate a startup idea, test the problem before the product. Find people who have the problem, ask how they deal with it today, and look for evidence that it costs them time or money. Then ask for a commitment, such as a pre-order, a signed pilot or their time. Compliments are not validation. Behavior is.
Key points
- Validate the problem first. A solution to a problem nobody has cannot be saved by good software.
- Ask about the past, not the future. "What did you do last time?" beats "Would you use this?"
- People who are already working around the problem are your best signal.
- A commitment of money, time or reputation is worth more than any amount of praise.
- Decide in advance what result would make you stop.
What validation actually means
Validating an idea means collecting evidence that a specific group of people has a problem painful enough that they will change what they do, and usually spend something, to fix it. It does not mean proving the idea is good. It means finding out, cheaply, whether you are wrong.
Paul Graham’s essay on startup ideas makes the point that the best ideas tend to be problems the founders have themselves, or have watched closely. That closeness is what validation tries to recreate when you are building for someone else.
Step 1: Name the person and the problem
Write one sentence: who has the problem, in what situation, and what it costs them. "Small clinics lose appointments because reminders are sent by hand" can be tested. "Healthcare is inefficient" cannot.
If you cannot list twenty real people or companies that fit, the group is too vague. Narrow it until you can.
Step 2: Talk to them, and ask about the past
Rob Fitzpatrick’s book The Mom Test is built on one idea: people will be kind about your idea, so do not ask about your idea. Ask about their life.
| Weak question | Better question |
|---|---|
| Would you use an app that does this? | How did you handle this the last time it happened? |
| Do you think this is a good idea? | What have you already tried to fix it? |
| Would you buy this? | What does this problem cost you today, in time or money? |
| What features would you want? | What is the hardest part of doing this now? |
Ten to fifteen honest conversations usually show a pattern. If nobody has tried to solve the problem, even with a spreadsheet or a workaround, it probably does not hurt enough.
Step 3: Look for behavior, not opinions
- They already use a workaround: a spreadsheet, a shared inbox, a person whose job is to do it by hand.
- They already spend on something close: a tool that half fits, a consultant, extra staff.
- They brought the problem up before you asked.
- They ask when they can have it, and who else they should introduce you to.
Step 4: Ask for a commitment
Interest is free. A commitment costs the other person something, and that is what makes it evidence.
- Money: a pre-order, a deposit, or a paid pilot.
- Time: an hour to test a prototype, or a slot in their calendar to try it with their team.
- Reputation: an introduction to their boss or to another buyer.
- A letter of intent, for products sold to businesses.
You can test this before any software exists. A landing page with a real offer, a clickable prototype, or the service delivered by hand for the first few customers will all tell you whether people commit.
Step 5: Decide what the result means
Before you start, write down what would count as a yes and what would make you stop. Without that, every result looks encouraging. If the people you spoke to do not commit, change the group, the problem or the offer and test again. That is far cheaper than changing a finished product.
When the problem holds up, the next step is the smallest product that can test real use. That is covered in How to build an MVP, and it is where our MVP development work starts: with scoping, not with code.
Sources
Checked when this guide was written.
