The Product Discovery Process: How to Decide What to Build Before You Build It

What is product discovery?

Product discovery is the process of finding out which problem to solve and which solution to build, and of testing the assumptions behind that choice with real users before delivery begins. It answers "should we build this?" Delivery answers "how do we build it well?" Discovery without delivery is research, and delivery without discovery is guessing at scale.

• The product discovery process decides what to build by understanding users, defining the problem, and testing the riskiest assumptions before engineering commits.
• Marty Cagan of Silicon Valley Product Group frames discovery as retiring four risks: value, usability, feasibility and business viability (SVPG, The Four Big Risks).
• The Standish Group’s 1995 CHAOS report ranked incomplete requirements (13.1%) and lack of user involvement (12.4%) as the top two factors in impaired projects (CHAOS report).
• In a 2022 study in the journal Requirements Engineering, only 30% to 38% of documented requirements could be fully traced to the customer’s initial ideas (Ferrari, Spoletini and Debnath).
• A two to four week discovery phase should end with a scoped first release, a definition of done, an out-of-scope list, and a record of which assumptions were tested.
• The product manager owns discovery; the delivery lead owns the plan that comes out of it; the designer and lead engineer own usability and feasibility.

Sigi Technologies runs discovery at the start of its own builds. The Antrak courier platform engagement began with discovery and flows for all three user types, customer, driver and operations, before any user interface was designed. This guide describes that kind of phase in enough detail to run one.

Product discovery vs delivery: why the split matters

Product discovery vs delivery is a difference of question, not of team. Cagan is explicit that both belong to one cross-functional team, product manager and designer weighted towards discovery and engineers towards delivery, and that each team performs both activities continuously. Splitting them into a research group and a build group produces handoffs, and handoffs produce incomplete requirements.

Continuous discovery is the practice of keeping the "should we?" question open while delivery runs. Teresa Torres, whose book Continuous Discovery Habits set the current vocabulary, argues that good discovery teams engage with customers at least weekly. A time-boxed discovery phase is how a new product gets there: two to four weeks that set up the interview pipeline and the assumption backlog that continuous discovery then maintains. A phase without the habit decays into a document nobody re-reads; a habit without a phase leaves the first release scoped by whoever spoke loudest.

Which product discovery framework should you use?

A product discovery framework is a structure for ordering discovery work so that the team diverges before it converges and tests before it commits. Four are worth knowing, and a good phase uses all of them together.

• The Double Diamond from the UK Design Council: Discover, Define, Develop, Deliver. The first diamond exists to understand the problem rather than assume it, by spending time with the people affected (Design Council).
• Lean Startup: validated learning through the Build-Measure-Learn loop, where the smallest experiment that can move a decision is built first (Lean Startup principles). It gives discovery its bias toward tests over documents.
• The opportunity solution tree: Torres’s visual with a desired outcome at the root, the customer opportunities that could drive it beneath, candidate solutions under each opportunity, and assumption tests under each solution (Product Talk).
• The four big risks: the exit criteria. Cagan assigns value and viability to the product manager, usability to the designer and feasibility to the lead engineer (SVPG).

What does a two to four week discovery phase look like week by week?

The discovery phase in software projects is usually time-boxed to between two and four weeks for a new product or a major feature. Here is the four-week plan; for two weeks, run each pair of weeks in one, with fewer interviews and one prototype round.

Week 1: frame the problem and the users

1. Run a kickoff workshop with the sponsor and the people who run the operation today. Record the business outcome, the constraints and every belief the room holds about users.
2. List the user types and map the journey each takes today. On a courier product that is a sender, a driver and an operations team.
3. Write a one-paragraph problem statement and a measurable target outcome, and turn the workshop beliefs into an assumption inventory ranked by damage if wrong and by evidence.
4. Recruit interviewees for every user type now; recruiting takes longer than interviewing.

Week 2: learn from users and data

1. Interview six to ten people across the user types about the last time they did the task.
2. Pull whatever data exists: support tickets, the spreadsheets the operation runs on, analytics from a previous version.
3. Study competing products. In the Requirements Engineering study cited above, requirements inspired by app store analysis covered up to 42% more features than interviews alone.
4. Synthesize into an opportunity solution tree and re-rank the assumption inventory.

Week 3: test the riskiest assumptions

1. Build a clickable prototype of the one or two flows where value or usability risk is highest and walk interviewees through it.
2. Run assumption tests that fit the risk: a fake-door page for demand, a concierge run for operational viability, a technical spike for feasibility.
3. Have the lead engineer settle the questions that decide architecture: what must live on the server and which integrations are on the critical path.
4. Check business viability with the people who will run it: pricing, support load, legal and compliance.

Week 4: decide and scope

1. Choose the first release: the smallest feature set that proves the outcome, a definition of done for each piece, and an explicit list of what is out of scope and why.
2. Agree the architecture direction and the integration list.
3. Produce the roadmap, the estimate by scope tier and the risk register, and record each decision with its evidence.
4. Set the continuous discovery cadence for delivery: who interviews weekly and where new assumptions are logged.

Which product discovery methods actually reduce risk?

Methods are only useful against a named risk. Skip one of the four below and the product ships with that risk intact.

Customer interviews

Customer interviews are the primary method for value risk. A 2023 study in IEEE Transactions on Software Engineering found that in domains the analyst already knew, interview experience had a strong positive effect on elicitation effectiveness while general professional experience had a moderate negative one, and that in unfamiliar domains no kind of experience helped much (Aranda, Dieste, Panach and Juristo). So put the person who has run the most interviews in the chair, not the most senior person, and learn the domain first. Structure each interview around a recent, specific instance of the task: the last parcel sent, the last shift worked. Ask what happened and what was annoying. Do not describe the product. Record the session and have a second person review it for ambiguities.

Assumption mapping and assumption testing

Assumption mapping turns a list of beliefs into a test plan. Plot every assumption on two axes, importance and evidence, and test the important, unsupported ones first. Each test has a hypothesis, a method and a pass threshold written down before it runs. Fake-door pages, concierge runs and pricing tests are assumption tests; a survey asking whether people would like a feature is not.

Prototypes

A clickable prototype is the cheapest way to retire usability risk on a flow that matters, and it exposes value risk when the reaction is indifference. Prototype the flows where money or trust changes hands: booking and paying, accepting a job, approving an invoice. Skip the settings screens.

Data and operational evidence

Existing data answers what interviews cannot: how often the task happens, how it fails, what it costs. The spreadsheets an operations team keeps by hand are the best specification of an admin dashboard. On Bix Delivery, the problems defined before the build were operational: matching a delivery to a driver who is online and close, keeping the sender informed without support tickets, pricing every job so the quote equals the charge, and handling the unhappy paths. Each became a server-side design decision: a delivery state machine, server-side pricing, and an explicit online or offline toggle for drivers.

What are the deliverables of the discovery phase?

Product discovery deliverables should let a delivery team start without re-asking the questions discovery answered, and let a sponsor see the evidence behind the scope:

• Problem statement and target outcome, with the metric that will be read after launch.
• User types and journey maps for each, including the operations or admin role most teams forget.
• Interview synthesis: who was interviewed, the opportunities that recurred, and direct quotes.
• Opportunity solution tree or assumption map, with the tests run and their results.
• Clickable prototype of the highest-risk flows and the findings from testing it.
• Scoped first release: feature list, definition of done per item, and an explicit out-of-scope list.
• Architecture direction and integration list, then roadmap, estimate by scope tier, risk register and a decision memo that cites the evidence.

This is close to what Sigi states for its own engagements. The MVP development page describes the first step as pinning down the core problem, the smallest feature set that proves it, and a clear definition of done. The IT consulting page offers a Discovery Sprint of one to three weeks covering workshops, scope definition, risks, roadmap and technical direction, and asks for stakeholders plus access to existing documentation, codebase and system context. A vendor that cannot list its deliverables this plainly is selling design time.

Who owns product discovery: the product manager or the delivery lead?

The product manager owns discovery. Sigi’s guide to the difference between product managers and project managers draws the line there: product managers own discovery, prioritization and what gets built, while project managers and delivery leads keep cadence, scope and stakeholders visible. That is right but incomplete: owning discovery is not doing it alone.

• The product manager is accountable for the phase: the outcome, the assumption backlog, the interview program, and the value and viability risks. A phase that ends without a decision is their failure.
• The product designer owns usability risk: journey maps, the prototype and the walkthroughs, and sits in the interviews rather than a briefing afterwards.
• The lead engineer owns feasibility risk and joins in week one; the architecture questions in week three cannot be answered by someone who missed the interviews.
• The delivery lead or project manager owns what comes out: roadmap, estimate, risk register and cadence, and protects the time box, which product managers are bad at protecting for themselves.
• The sponsor owns the decision to proceed, pivot or stop, and should see the evidence, not only the recommendation.

When there is no product manager, common for a founder-led first product, the founder plays the role and the vendor’s product lead facilitates, provided the founder accepts that discovery may contradict the pitch. If you are staffing the seat, Sigi staffs product managers and product owners into client teams, and the guide on staff augmentation versus a dedicated team versus outsourcing covers which engagement model fits.

How long does discovery take, and what does it cost?

Torres’s answer to how much time to spend is the right one: enough discovery to mitigate unacceptable risk, and no more. The tiers below are typical planning estimates, not a Sigi quote; Sigi scopes discovery from a written brief.

On cost, a discovery phase is a few weeks of a product manager, a designer and part of an engineer, a small fraction of any build tier in Sigi’s guide to how much it costs to build a mobile app, and cheaper than the first rewrite.

Where does the product discovery process go wrong?

The product discovery process fails in the same handful of ways on most teams, and each failure is visible in the deliverables.

• Discovery as documentation. The phase produces a specification but no tests, so every assumption is still an assumption.
• Interviewing stakeholders instead of users. Sponsors know the business; they do not know the last shift a driver worked.
• Pitching in the interview. Describing the product and asking whether they like it produces polite agreement.
• Retiring value risk and stopping. Viability is the risk that kills products after launch, when the operation cannot support them.
• Discovery that never ends. Extend the time box only for a named risk with a named test.
• Forgetting the unhappy paths. On Bix they were listed before the build, and cancellation shipped on the customer side in version 1.1 in February and on the driver side in 1.1.1, within two months of the January launch. A path on the list gets built; a path nobody listed becomes a support ticket.

Related reading

For how the product and delivery roles divide the work after discovery, read product managers versus project managers. For how to staff the phase and the build, see staff augmentation versus a dedicated team versus outsourcing. For build scope tiers, see how much it costs to build a mobile app. The discovery step in practice is recorded in the Antrak courier platform case study and the Bix Delivery case study. Sigi’s MVP development service starts with discovery and scope, and the IT consulting practice runs a stand-alone Discovery Sprint. To talk through a brief, contact Sigi.