CB Insights' analysis of startup post-mortems found "no market need" is the top killer of new companies, named in 35% of failures. You validate a business idea by talking to 15 to 30 real potential customers about a problem they already have, watching what they currently do and pay for, and writing code only after people show they want the outcome. Validation tests demand, not opinions.
What does it mean to validate a business idea?
Validating a business idea means getting evidence that real people will pay to solve a specific problem, before you build the full product. It is the difference between "people said they liked it" and "people gave me money or their time."
Opinions are cheap and polite. The Mom Test by Rob Fitzpatrick makes the core point: ask about the customer's past behavior and real spending, never about your idea. "Would you buy this?" invites a lie. "Walk me through the last time you dealt with this problem" gets you facts.
Good validation produces three things: proof the problem is frequent and painful, proof people already spend money or effort on it, and a signal they will switch to your solution.
You might also like
How do I validate a business idea in one week?
You can run a credible first validation pass in five working days without writing any product code. The goal is signal, not certainty. Here is a tight sequence a solo operator can execute this week.
- Write one sentence naming the customer and the problem, not your solution.
- List 20 people who have that problem and can be reached directly.
- Run 10 to 15 problem interviews using past-behavior questions.
- Publish a one-page offer describing the outcome and a price, with an email capture or pre-order button.
- Drive 100 to 300 real visitors through a small ad budget or a relevant community.
- Count concrete actions: sign-ups, replies, deposits, or booked calls.
If nobody acts when it is easy to act, that is your answer. A lukewarm response now becomes silence after you spend three months building.
Which validation methods actually work?
The strongest methods force a real decision from the customer; the weakest ask for opinions. Direct problem interviews and a paid pre-sale beat surveys and family feedback every time. Use this comparison to pick your next test.
| Method | Signal strength | Cost | Best for |
|---|---|---|---|
| Problem interviews | High | Low | Confirming the problem exists |
| Landing page + pre-order | High | Low | Testing willingness to pay |
| Concierge / manual delivery | Very high | Medium | Proving people want the outcome |
| Small paid ads to a waitlist | Medium | Medium | Measuring cold demand |
| Surveys | Low | Low | Broad context, not decisions |
| Asking friends and family | Very low | Low | Emotional support only |
Steve Blank's customer development method calls this "getting out of the building." The best signal is money or a firm commitment; the second best is repeated, specific behavior you can observe.
How we validate features at Botensten before we build
We build production software with AI every day, and we still refuse to build a feature until a real request forces it. Our rule is simple: a feature needs two unprompted requests from paying members before it enters the build queue.
We learned this the expensive way. We once spent four days building a detailed analytics dashboard because it felt obviously useful. Usage after launch was near zero. Members wanted a single weekly email, not another screen to log into. We rebuilt it as a plain email digest in an afternoon, and open rates were strong. The dashboard was our opinion; the email was their behavior.
Now we validate cheaply first. Before writing the real feature, we ship a fake door: a button that records intent and shows a short "want this?" capture. If clicks are flat, we drop it. That costs an hour and saves weeks. Talking to customers is not a phase we finished; it is the input to every build.
What are the most common validation mistakes?
The most common mistake is asking leading questions that fish for a yes instead of the truth. The second is treating enthusiasm as demand when no money or time changed hands.
- Pitching your solution instead of studying the problem.
- Asking "would you buy this?" instead of "what do you use today?"
- Counting compliments and likes as validation.
- Interviewing friends who cannot say no to you.
- Building an MVP before a single person committed anything.
- Ignoring what people already pay to solve the problem.
When should you stop validating and start building?
Stop validating and start building once you have clear, repeated evidence of demand: several people committed money, time, or a firm pre-order for the same specific outcome. Validation never fully ends, but you have enough to build the smallest version when the signal is consistent, not just polite.
Eric Ries' Lean Startup frames this as the minimum viable product: the smallest thing that keeps you learning from real users. A practical bar is three to five customers who paid or pre-committed and describe the same problem in similar words. Below that, keep testing. Above it, build the smallest slice that delivers the outcome and put it in front of those exact people first.
0 Comments
Log in to comment
Not a member yet? Join the community
Pick a meme
KlipyHave a great take?
Drop your email — we'll send a magic link so you can post it. No password.
Not a member of the community? Join today.
Join the community →