Product Discovery
Product discovery is the work a team does to decide what is worth building before committing to build it. It investigates who has a problem, how much it matters, what they do about it today, and whether a proposed solution would be valuable, usable, feasible, and viable. Its output is not a specification but evidence — enough to make a confident bet, or to stop before spending weeks on the wrong one.
Most features fail quietly: they ship, a few people try them, and usage stays flat. Discovery exists because building is the most expensive way to learn whether an idea works. A conversation, a prototype, or a fake button can answer the same question in days for a fraction of the cost.
TL;DR
- Start from problems and outcomes, not feature requests; requests are clues about problems.
- Every idea rests on assumptions about value, usability, feasibility, and viability — find the riskiest and test it first.
- Interview about past behavior, not opinions or hypotheticals; "would you use this?" produces polite fiction.
- Use the cheapest experiment that can change your decision, and write the decision rule before you run it.
- Discovery is continuous: small weekly doses of customer contact beat a big research phase that goes stale.
- Engineers belong in discovery — they judge feasibility and often spot simpler solutions.
Quick Example
An assumption test written before the experiment runs, so the result cannot be rationalized afterwards.
The decision rule is written in advance; whatever the result, the team knows what it will do next.
Core Concepts
Problem Space and Solution Space
The problem space holds users, their goals, and their obstacles; the solution space holds the things you might build. Teams jump to solutions by default. Discovery deliberately spends time in the problem space first, because a well-understood problem usually has several possible solutions — and the first idea is rarely the best one.
The Four Product Risks
Value is the risk teams most often skip, and the one that most often sinks features.
Jobs to Be Done
The Jobs to Be Done lens asks what progress a person is trying to make in a particular situation — the "job" they "hire" a product for. A team that understands the job ("prepare for a technical interview next week") can compete with everything else users hire for it, including spreadsheets and a friend's advice, not just with similar products.
Opportunity Solution Trees
An opportunity solution tree connects a desired outcome to the customer opportunities (needs and pain points) that could drive it, then to candidate solutions, then to the experiments that test them. It keeps discovery anchored to an outcome and makes it visible when a team is pursuing a single idea without considering alternatives.
Discovery Techniques
Customer Interviews
Ask about specific past events: "Tell me about the last time you prepared for an interview. What did you do first?" Past behavior is evidence; predictions about the future are not. Listen for workarounds, money or time already spent, and emotional intensity — signs that a problem is real and painful. Five to eight interviews per segment usually reveal the main patterns.
Data and Support Signals
Analytics show where users drop off, which features are used, and how behavior differs between segments; support tickets and sales notes show recurring frustrations. Data tells you what happens; interviews tell you why. See Product Analytics.
Experiment Types
Choose the cheapest test that could change your decision. See Prototyping and A/B Testing.
Dual-Track Delivery
Many teams run discovery and delivery in parallel: a small group keeps validating the next ideas while the team delivers ideas that already passed. Discovery should feed the backlog with evidence, not a separate stream of documents.
Best Practices
Write Hypotheses and Decision Rules First
State the assumption, the metric, and the threshold that would change your mind before running the test. Without them, any result can be read as success.
Test the Riskiest Assumption First
Map assumptions by how important and how uncertain they are. Spend effort on the important, uncertain ones; skip testing things you already know.
Talk to Users Every Week
A steady cadence — even two conversations a week — keeps the team's picture of users current and makes discovery a habit rather than a project.
Include Engineers and Designers
The product trio — product, design, engineering — makes better calls together. Engineers frequently propose solutions that are cheaper and better because they know what the platform can already do.
Common Mistakes
Asking for Predictions
An MVP That Is Really Version One
Discovery Without Decisions
FAQ
What is the difference between product discovery and user research?
User research is a set of methods for understanding users. Product discovery uses those methods — along with data, experiments, and technical spikes — to decide what to build. Discovery is research tied to a product decision.
How many customer interviews are enough?
Enough to see the same patterns repeat, which for one user segment is often five to eight conversations. Keep interviewing continuously rather than in one large batch, because markets and users change.
What is a minimum viable product, really?
The smallest thing that tests your riskiest assumption with real users. It might be a landing page, a manual service, or a prototype rather than software. If it takes months and includes every supporting feature, it is a first release, not an MVP.
Should engineers take part in discovery?
Yes. Engineers assess feasibility early, notice cheaper solutions, and build better products when they understand the problem first-hand. Joining a few interviews per month is usually enough to change how a team builds.
When should discovery stop and delivery start?
When the evidence makes the bet acceptable: the riskiest assumptions are tested, the decision rule was met, and the remaining uncertainty is cheaper to resolve by shipping a small version. Discovery continues alongside delivery to inform the next decision.
Related Topics
- Problem Interviews and Assumption Tests — Collect behavioral evidence and design small experiments around uncertain assumptions.
- Product Management & Delivery — Discovery in the full product loop
- Requirements Engineering — Specifying what discovery validated
- Product Prioritization — Choosing between validated opportunities
- UX Research — Interviewing and usability testing in depth
- Prototyping — Choosing the cheapest artifact to test an idea
- A/B Testing — Measuring the effect of a shipped change
- Customer Feedback and Support Insights — Evidence from feedback and support