The Cost of Skipping Discovery
In 12 years of building software products, the most expensive mistakes we've seen weren't architectural — they were directional. Teams spent months engineering solutions to problems that weren't actually the problem.
Good product discovery is not a phase. It's a discipline that continues throughout delivery.
The Questions We Ask Before Anything Else
1. What is the job the user is trying to get done?
Not "what feature do they want" — what outcome are they trying to achieve? This distinction changes everything. Users asking for a faster horse were trying to get somewhere faster.
2. What does success look like in 90 days?
Specific numbers. "Improved user engagement" is not an answer. "DAU/MAU ratio above 40% in the target cohort" is.
3. Who is NOT the user?
Defining the out-of-scope user is as important as defining the target. Most scope creep happens because the team doesn't have a clear answer to this.
4. What already exists that partially solves this?
If users have workarounds, understand them deeply. They reveal the real job-to-be-done and what quality bar you need to clear to get adoption.
5. What's the smallest thing we can learn the most from?
The goal of early discovery is not to define the full product. It's to identify the highest-value, highest-uncertainty assumption and design the cheapest possible test for it.
The Discovery Anti-Patterns
- Conducting discovery as a one-time workshop before build starts
- Treating discovery output as requirements, not hypotheses
- Skipping discovery because "we know our users"
- Confusing stakeholder opinions with user evidence
The teams that ship products people actually use treat discovery as the most important engineering discipline — because it determines what you build, not just how you build it.