Product discovery: how to decide what to build
A product team can spend months building something that nobody urgently needs. Another team can spend just as long researching an idea without ever deciding whether it deserves a budget. Product discovery sits between those two failures and, in theory, should solve both before they fester. Its job is to reduce the uncertainty around a product decision enough for a team to know what it should build, what it should change, or whether it should build anything at all.
What is product discovery and what decision should it help you make?
Product discovery is the work a team does to decide what to build before it builds it. Teresa Torres of Product Talk describes it simply as “a decision-making process.” The inputs are familiar: user research, stakeholder interviews, existing product data, prototypes, technical investigation, and a business assessment. The aim is to understand the problem before committing significant budget to a solution.
Silicon Valley Product Group sorts what a team has to learn into four risks: whether anyone wants the product (value), whether they can work it out (usability), whether engineers can build it with the time and technology available (feasibility), and whether it works for the business (viability).
Good discovery tackles the largest of those four risks cheaply, before any sprint is spent on building. A team does not need to retire all four at once. It needs to know which one would sink the product and how to test that risk in days or weeks rather than in months of engineering.
Discovery ends in one of four decisions: build, change direction, investigate one risk further, or stop the project altogether. A negative result is still useful. A team that learns in a few weeks of research that an idea will not work saves the months of engineering it would take to learn the same thing in production.
Discovery vs delivery: what should you know before development begins?
Discovery asks what problem is worth solving, which direction appears promising, and what assumptions could make the decision fail. Delivery turns a chosen direction into a working product and exposes new information along the way. The two overlap in practice, but they need different exit points. Delivery ends when the product ships. Discovery ends when the team can name the decision and the evidence behind it.
Take a common request: a stakeholder asks for a dashboard, a mobile app, or an AI assistant. Discovery examines that request before the cost of changing direction rises. What is the user trying to accomplish? How do they handle the task today? Where does the existing experience break? What makes the proposed solution valuable? The answers often change the shape of the product.
Delivery then takes this decision into execution, but it brings a different kind of evidence. For example, a technical approach that looked reasonable early on may be difficult to maintain. A workflow that made sense in a prototype behaves differently when real constraints are introduced. Users may respond differently once a feature is part of an actual product rather than a test environment.
A useful way to think about the relationship is that discovery reduces the risk of committing to the wrong direction, while delivery produces evidence about whether the chosen direction works in practice. Neither replaces the other. Teams that treat delivery as their discovery end up paying for research in engineering hours.
Some teams try to skip discovery by launching a minimum viable product and calling the launch their discovery. That works when the question is narrow, but fails when the real unknown is which problem to solve, because an MVP can only answer the question it was built to ask. Our guide to what an MVP is for covers where that line sits.
The product discovery process, step by step
A product discovery process should reduce uncertainty in a deliberate order. Start with the decision, understand the problem, assess its importance, explore possible solutions, test the biggest risks that could derail the project, and decide what deserves the next investment.
- Define the decision and what could change your mind: Start by defining what you need to decide. Are you choosing a problem, evaluating a feature, or deciding whether a new product is worth building? Then name the evidence that could change that decision, and set the date by which the team will choose to build, change direction, or stop. A fixed date keeps discovery from drifting into a search for confirmation.
- Understand the problem: Find out what is actually happening today. Talk to affected people, examine their workflow, review available data, and understand the workarounds they use. The original brief is only a starting point. A request for an AI assistant, for example, might turn out to be a problem with search, navigation, or access to information.
- Establish whether the problem is worth solving: A real problem is not automatically a worthwhile product opportunity. Look at who experiences it, how often it occurs, what happens when it remains unresolved, and how people manage it today. This connects user need with business priority. If nobody would pay, switch, or change a workflow to fix it, the problem is real but not worth a product.
- Explore possible solutions: Do not move directly from a validated problem to the solution proposed in the brief. Consider a few plausible ways to address the same problem. A request for a dashboard might reveal a need for better alerts. A request for an AI chatbot might be solved by improving search. The point is comparison, not generating endless ideas.
- Test the assumptions that could derail the solution: Identify what could still make the chosen direction fail. Users may struggle with the workflow, the required data may be unavailable, or the technology may prove difficult to implement. Test those assumptions first, starting with the one that would be most expensive to discover after the build has started.
- Make the decision: Discovery should end with a decision: proceed, change direction, investigate further, or stop. Not every question needs an answer. The team should leave knowing what it believes, why it believes it, which risks remain open, and what happens next. If it cannot say those four things, discovery is not finished, however long it has run.
In our work on the California Department of Health Care Services dashboards, discovery started with the client’s business goals, moved to personas and their goals, and turned both into prioritized functional and business requirements, informed by in-person, remote, and group interviews. One of those requirements was that the dashboards work on desktop and mobile without training.
The way officials use the data decided how that worked. Government healthcare stakeholders open these dashboards in meetings, in the field, and during legislative sessions, so the mobile layout leads with the choropleth map of California counties and the Sankey chart, the two views they reference most in presentations. Filtering stays fully interactive on small screens.
Which discovery method should you use for each question?
The right discovery method depends on the uncertainty or the risk you need to resolve. A team that asks “should we build this?” needs different evidence from one asking “can people use it?”, and no single method covers both. Interviews can reveal how people describe a problem, product data can show behavior, prototypes can test an experience, and technical investigation can expose feasibility constraints.
The table below pairs each question with a method that can answer it, the output to demand, the condition that closes the question, and what the method cannot prove even when it passes. The last two columns matter most. A team that confuses a passed test with a settled question will stop too early.
The method should also reflect the cost of being wrong. A small interface change may need a handful of interviews. A new product, regulated workflow, or major AI capability justifies more rigorous testing. In either case, keep running a method only while its findings can still change the decision. Interview scripts and sampling are covered in the guide to UX research methods.
Product discovery before adding AI
AI can be an attractive answer to a product problem before the team has established what the problem actually is. A useful discovery process puts the problem first and asks whether AI offers a meaningful advantage over simpler, more affordable ways of solving it.
Consider a team planning an AI assistant for an enterprise product. What are users struggling with? Are they unable to find information, interpret it, complete a complicated task, or decide what to do next? Those problems could lead to very different solutions. An improved search experience might solve the first. Better information architecture could address another. A rules-based workflow could handle a predictable task.
AI may be appropriate where the problem involves ambiguity, natural-language interaction, pattern recognition, or a task that benefits from generating or interpreting information. Most AI models can attempt the task, so the fact that one can settles very little. What discovery has to establish is whether AI improves the outcome enough to justify the extra uncertainty around accuracy, evaluation, data, oversight, and user expectations.
Discovery for an AI feature adds three checks to the usual risk ranking: whether experts can specify the behavior, what answers can be tested against, and what safeguards a wrong answer requires. High stakes do not settle the choice on their own. They decide which controls the product needs, and many products end up combining rules and AI.
Three checks before choosing rules, AI, or both:
How long should product discovery take?
Product discovery for a new product usually takes from a few days to several weeks, depending on the decision and how much evidence already exists. On Fuselab’s MVP engagements, the Discovery and Scope Lock phase runs from day one to day three and ends with a signed screen inventory. A new product in an unfamiliar or regulated market can justify several weeks.
Three days is enough when the question is narrow, such as what belongs in a first release. Discovery stretches when the team must recruit users, get access to existing data, investigate technical constraints, align several stakeholders, or test competing solutions. The more expensive a wrong decision would be, the more evidence it justifies, and the longer the phase can reasonably run.
Set the decision date before discovery begins, along with what the team needs to know and what evidence would be sufficient. One practical method is to work backward from the planned kickoff and size the research to fit. If the window is too tight, narrow the question or move the decision date. Do not quietly cut the evidence instead.
When should you stop product discovery?
Stop discovery when the team can make a defensible decision about the next investment. That does not mean every question has been answered. It means the team has tested the important assumptions, understands the remaining uncertainty, and knows further research is unlikely to change what it does next. Most teams reach “we have learned a lot” long before they reach a decision, and mistake the first for the second.
The stop rule has four parts. A team that meets all of them should stop even if the schedule has weeks left, and a team that meets only some is not finished, however long it has been at it:
- The last round of research changed no ranking in the assumption list.
- Every top-ranked risk is retired, reduced to a named unknown the sponsor accepts, or has triggered a decision to stop.
- The team can describe the smallest build that would test what remains.
- The sponsor has agreed in writing what happens next.
Teams rarely overrun discovery because they lack data. They overrun because another round of interviews feels productive, and a decision exposes someone to being wrong. A sponsor who asks “what would change your recommendation?” at each review usually gets to a decision faster than one who asks for more research.
Stopping the project, and not only the research, can also be the right outcome. Agree on the kill criteria at the start: a demand signal that fails to appear, a feasibility blocker with no workaround, or a cost ceiling the build would exceed. If discovery shows the problem is too small or a simpler alternative works better, write that finding up as clearly as a decision to build.
Conclusion
Every product investment starts as a bet on where time, money, and engineering effort should go. Product discovery decides how well-informed that bet is. Before the next build, name the uncertainty that would hurt most if it proved wrong, set the date the team will decide by, and investigate that one question first.
Frequently asked questions
What is product discovery?
Product discovery is the phase where a team researches a problem, ranks the risks in its plan, and decides what to build before engineering starts. Its output is a decision with supporting evidence, and that decision can be to build, change direction, investigate further, or stop.
Why is product discovery important?
Product discovery matters because it is the cheapest point to be wrong. Changing a concept during discovery costs hours of rework, while the same change after engineering starts costs sprints, budget, and sometimes the release. Discovery also gives the sponsor a written basis for the decision.
What does a discovery phase deliver?
A discovery phase delivers an evidence-based decision. The working documents are typically a problem statement, a ranked list of risks and assumptions, personas or user maps, and a written scope or a recommendation to stop.
How does product discovery differ from UX research?
UX research is a set of methods, while product discovery is a phase with a decision attached. Discovery uses interviews, field studies, and prototype tests, but it also includes stakeholder alignment, risk ranking, and a stop rule that are not part of research.
How does a discovery phase differ from continuous discovery?
A discovery phase is a time-boxed effort that ends in a specific decision, usually build, change, or stop, while continuous discovery is an ongoing habit of customer contact that feeds an existing roadmap. The phase suits a new product, a new market, or an AI feature with open unknowns. Continuous discovery suits a team that already has a product, users, and a delivery rhythm.
How much does a discovery phase cost?
Discovery phase cost follows team size and duration, plus participant recruiting and incentives. Most of the bill is people’s time at specialist rates, such as Fuselab’s published $100 to $149 an hour on Clutch. That is why a three-day scope lock costs a fraction of a multi-week study in a regulated market.
How long should a discovery phase take?
A discovery phase takes from a few days to several weeks. Fuselab runs Discovery and Scope Lock in days one to three of an MVP engagement because the question is narrow, while a new product in an unfamiliar or regulated market can need several weeks of interviews, data access, and technical checks.
