The Product Discovery Process: How to Decide What to Build

The product discovery process is how a team decides what to build before it commits engineering time to building it. Done well, it replaces opinion with evidence: instead of arguing about whether a feature is a good idea, the team runs small, fast tests that answer the question. The goal is not more research. The goal is to kill weak ideas cheaply and give strong ones a clear, de-risked path to build.

Most teams do some version of discovery, but they do it as a one-time phase, run by one person, that produces a document nobody uses. This guide covers what discovery actually is, the four risks it exists to test, a step-by-step process, the specific techniques for each kind of risk, how to run it continuously alongside delivery, and how to do it in an enterprise where getting time with real users is hard.

What product discovery is, and is not

Discovery is the work of reducing risk before you write production code. Marty Cagan’s framing is the useful anchor: every idea carries four risks, and discovery exists to test them before you commit.

• Value risk. Will anyone use it or pay for it? The most common killer, and the one teams test least.
• Usability risk. Can people figure out how to use it without a manual?
• Feasibility risk. Can we build it with the time, data, and systems we actually have?
• Viability risk. Does it work for the business, including sales, legal, compliance, support, and the economics?

Discovery is not a phase gate, and it is not months of research that ends in a slide deck. It runs continuously, in parallel with delivery, and every cycle ends in a decision to build, change, or drop. If your discovery ends in a report instead of a decision, it is research, not discovery.

The product discovery process, step by step

1. Frame the problem. Write down the specific customer problem and the outcome you want to move, in one or two sentences. If you cannot state the problem without naming your preferred solution, you are not ready to test anything; you are ready to defend a decision you already made.
2. Gather evidence. Talk to real users, watch real usage data, and mine what support and sales already hear every day. A handful of honest customer conversations usually beats a large survey, because you learn the why, not just the what.
3. Map opportunities. Before jumping to solutions, lay out the distinct problems and needs you found, often as an opportunity-solution tree, so you can choose which opportunity is worth solving rather than defending the first idea that came up.
4. Shape solutions. Sketch two or three approaches to the chosen opportunity, not one. Competing options keep the team honest about tradeoffs and make it easier to abandon a weak idea, because you are choosing between options rather than defending your only one.
5. Test the riskiest assumption. For each candidate, name the one belief that, if wrong, sinks it, and test that first. Match the test to the risk (see below). Cheap tests before expensive ones, always.
6. Decide. Build, change, or drop. Write down the decision and the evidence behind it so it does not get relitigated next quarter when someone new asks why you are not building the obvious thing.

Which technique tests which risk

The mistake teams make is testing everything the same way, usually by asking people if they like an idea. Match the method to the risk:

• Value risk: a fake-door or landing-page test, a concierge test where you deliver the outcome manually first, or a pre-sell. Watch what people do, not what they say they would do.
• Usability risk: a prototype put in front of five to eight real users, watching where they get stuck. You do not need statistics to find a broken flow.
• Feasibility risk: a technical spike or a small proof against your real data and systems, run by engineering, not a whiteboard estimate.
• Viability risk: a walkthrough with sales, legal, compliance, and support, plus a simple model of the economics. In regulated industries this is often where good ideas die, so test it early rather than at the end.

Continuous discovery, not a phase

Discovery and delivery are not sequential stages. The strongest teams run a discovery track a step ahead of the build track, so engineers always have validated work queued and never sit idle waiting on research, and researchers are never testing something that already shipped. In practice that means a light weekly rhythm: regular contact with users, a running opportunity-solution tree, and a standing decision point where the team commits, adjusts, or kills ideas. Teresa Torres’ continuous-discovery model is a useful reference for the cadence.

When a small first build is the fastest way to learn, discovery flows straight into an MVP that ships to real users. A working product in front of real customers is the most honest test there is, and for many value questions it is cheaper to ship a narrow version than to keep testing around the edges.

How to run discovery when user access is hard

In enterprise, finance, and healthcare, getting time with end users is often the real bottleneck, because they are busy, regulated, or reached only through account managers. Discovery still works; you adapt the sources. Lean on the people who talk to customers daily, support, sales, and account teams, as a first-pass signal. Use product analytics and support tickets as standing evidence. Recruit a small standing panel of friendly customers you can reach quickly. And when direct access is genuinely blocked, test with realistic proxies and be explicit about the confidence level so nobody mistakes a proxy for the real thing. The goal is to reduce risk with the access you have, not to wait for perfect access you will never get.

Where the product discovery process breaks down

• Discovery theater. Going through the motions after the decision is already made. If the outcome is predetermined, you are documenting a choice, not discovering one.
• One idea, defended. Testing a single solution you are attached to, and interpreting every result as support for it.
• Research with no decision. Interviews and surveys that never resolve into build, change, or drop. Every cycle should close with a call.
• Skipping the riskiest assumption. Testing the easy, comfortable things and shipping the genuinely risky one on faith.
• Solo discovery. One person doing discovery and handing conclusions to the team, which loses the shared context that makes the findings actionable.
• Asking instead of observing. Relying on what people say they would do rather than watching what they actually do. Stated preference is weak evidence for value.

Frequently asked questions

How long should product discovery take?

As long as it takes to answer the riskiest question, which is often days, not weeks. Discovery is measured by risk retired, not by time spent. If a week of testing can save a quarter of building the wrong thing, that is the best trade in product.

Who should be involved in discovery?

The trio that will own the result: product, design, and engineering, together. Discovery done by one person and handed over loses the context, the technical read on feasibility, and the shared conviction that makes the team move fast later.

What is the difference between discovery and validation?

Discovery explores what to build and why, across many possible problems and solutions. Validation confirms that one specific solution works. Discovery is broader and comes first; validation is one of the tools used inside it.

How is discovery different from market research?

Market research usually sizes a market or a segment for a business case. Product discovery tests whether a specific solution will be used, is usable, is buildable, and works for the business. They answer different questions, and a market-size number does not tell you whether your feature will get used.

Can you do discovery without talking to users?

Not well. You can lean on analytics, support tickets, and customer-facing colleagues when direct access is hard, but some contact with real users is what separates discovery from guessing with extra steps. Build a small reachable panel if formal access is slow.

How does discovery fit with agile delivery?

Discovery runs continuously, a step ahead of the sprint, feeding validated work into delivery. It is not a phase before agile starts; it is the parallel track that makes sure the sprint is building something worth building.

Put discovery to work

A discovery process only helps if it ends in shipped decisions. We embed with product teams to run discovery that kills weak ideas fast and moves strong ones into build, and we build the resulting product with your team so the learning is not lost in a handoff. See how we approach product design and digital product development, or get in touch to pressure-test your next idea before you build it.