Validation
Problem validation vs solution validation: do them in order
Validating your solution before validating the problem is how smart founders build polished products nobody needs. Here's the right sequence.
"Validation" gets used as one word for two different jobs, and conflating them is a classic, expensive error. Problem validation asks is this pain real? Solution validation asks does my approach fix it? You have to do the first before the second — and most founders rush past it.
Problem validation
This confirms that a specific group of people has a specific pain that's real, frequent, and acute enough that they'd pay to make it go away. The evidence is behavioral and historical: are people already spending money on workarounds? Hacking together solutions in spreadsheets? Complaining about it publicly? You're looking for a problem with magnitude (it hurts) and frequency (it hurts often). A pain that's intense but rare is a hard business; a pain that's mild but constant is hard to monetize. The sweet spot is intense and frequent.
The way to get this wrong is to ask leading questions. "Would you find a tool that does X useful?" invites politeness. "Tell me about the last time you dealt with [problem] — what did you do?" invites the truth, because it asks about past behavior instead of hypothetical future enthusiasm.
Solution validation
Only once you've confirmed the problem is real do you test whether your solution is the right one. Does your approach actually solve it? Is it meaningfully better than what people do today? Will they switch? This is where prototypes, fake doors, and concierge MVPs earn their keep — they test the solution against a problem you already know exists.
Why order matters
Run solution validation on an unvalidated problem and your results are meaningless. People might love your prototype in a demo and never use it, because the underlying problem wasn't painful enough to change their behavior. You'll have "validated" enthusiasm for solving a non-problem. Validate the problem first, and a failed solution test tells you something useful: the problem is real, so pivot the solution rather than abandoning the whole idea. That's the difference between Burbn becoming Instagram and a startup quietly shutting down.
- Problem validation: confirm the pain is real, frequent, and acute enough to pay to solve.
- Solution validation: confirm your specific approach solves it better than the alternatives.
- Do them in order — solution validation on an unvalidated problem proves nothing.
- If the problem is real but the solution misses, pivot the solution, not the whole idea.
Try the Business Plan workflow in Cadenly
Cadenly separates problem and validation steps so you confirm the pain is real before you commit to a fix.
Start free →