Most failed products didn't fail during development. They failed the moment the idea was accepted without being tested, and development just made that failure expensive and visible months later.
The three assumptions every idea rests on
Problem assumption: is this actually painful?
Not "would this be nice to have," but "does this cost someone real time, money, or risk today, often enough that they'd change behavior to fix it."
Solution assumption: does this specific approach solve it?
A real problem can still have the wrong proposed solution. Discovery tests the fix, not just the pain.
Viability assumption: will someone actually adopt or pay for it?
Interest is not adoption. People often say they'd use something and then don't change any behavior when it's available.
Discovery methods ranked by evidence strength
| Method | Evidence strength | Speed | Best for |
|---|---|---|---|
| Opinion surveys | Weak | Fast | Early problem framing only, never a go/no-go signal |
| Customer interviews about past behavior | Medium | Fast | Confirming the problem is real and frequent |
| Clickable prototype test | Medium | Medium | Testing whether a proposed flow makes sense |
| Concierge or manual pilot | Strong | Medium | Testing willingness to pay or adopt before building anything |
| Working MVP with real usage data | Strongest | Slow | Confirming retention and habitual use, not just first use |
A lightweight discovery process
Write the assumption you're most worried about
Not the whole idea, the single assumption that, if false, kills the idea. Test that one first.
Talk to 8 to 12 people who've experienced the problem recently
Ask about specific past behavior, not hypothetical future behavior. "Tell me about the last time this happened" beats "would you use a tool that did X."
Run a manual or concierge version before building anything
Deliver the outcome by hand, even inefficiently, to a handful of real users. If nobody wants the manual version, the automated version won't fix that.
Set a kill criterion in advance
Decide what result would make you stop, before you see the results. Without this, ambiguous data always gets interpreted as "promising."
Pros
- +Catches fatal problem or solution mismatches before engineering cost is spent
- +Produces real user language and constraints that improve scope once building starts
- +Forces a specific, falsifiable claim instead of a vague product vision
Cons
- −Can be used to stall indefinitely if there's no kill criterion or deadline
- −Weak methods (surveys, opinions) can create false confidence if treated as strong evidence
- −Some problems genuinely require a working product to test properly; discovery has limits
Discovery doesn't prove an idea is right. It's the cheapest way to find out it's wrong before the expensive way does.
Once an idea survives discovery, the next question is usually build vs buy vs assemble, followed by scoping the first version narrowly enough to keep testing as you build.
FAQ
FAQ
What is product discovery?+
Product discovery is the process of testing whether a problem is real, whether a proposed solution actually solves it, and whether someone will pay for or adopt that solution, before committing engineering time to build it.
How long should product discovery take?+
Most discovery efforts should take days to a few weeks, not months. If discovery is taking longer than a small build would, the process itself has usually become the problem.
Do I still need discovery if the idea seems obvious?+
Yes. Obvious-seeming ideas fail validation constantly, usually because the assumed problem isn't as painful, frequent, or unsolved as the team believed. A short discovery pass is cheap insurance against an expensive build.
Related resources
Product-Market Fit: How to Know You Actually Have It
Product-market fit is claimed far more often than it's real. A concrete definition, the signals that actually indicate it, and the signals that commonly get mistaken for it.
BusinessWhen Does a Business Need Custom Software? A Decision Framework
Custom software is expensive to build and expensive to skip at the wrong time. A concrete framework for deciding whether your business has actually outgrown off-the-shelf tools.
BusinessSaaS MVP — Build vs Buy Decision Framework for 2026
A practical framework for deciding whether to build a custom SaaS MVP, assemble no-code tools, or buy existing software — with cost, risk, and speed trade-offs.
Newsletter
Product notes, not noise.
Occasional frameworks on portals, SaaS MVPs, and automation. No agency spam.