Product discovery framework

A product discovery framework is a repeatable method for deciding what to build before anyone builds it. It turns opinion into evidence using interviews, demand tests and prototypes, so a team spends its next quarter on something a customer actually asked for.

A minimum viable product is an output of this work, not the method behind it. A team can build an excellent one of something nobody wanted, which is exactly what discovery exists to prevent.

Discovery owns customer needs. It is not validation of a thing already built, and it is not a launch plan; both of those start after discovery has named the problem that is worth the effort.

Key takeaways

• Discovery decides what to build; delivery decides how to build it, and mixing the two wastes a quarter.
• Every stage needs a decision rule agreed in writing before the evidence arrives.
• Talk to the people who did not buy, not only to the customers who already like you.
• Most discovery output should be discarded on purpose — that is the saving, not the waste.

How it works

A product discovery framework moves a team through four questions in order: which problem are we chasing, what do people do today, which unmet need is worth solving, and will anyone act when we offer a solution?

Framing comes first and most teams skip it. Write down the problem, the segment that has it and what you would accept as proof, because an unframed study collects interesting facts — and settles nothing.

Interviews fail in a predictable way. Ask somebody what they want and you get a wish list; ask what they did last time the problem arose and you get a story you can check — with dates, workarounds and a cost attached.

Discovery also needs a stopping rule. Decide before you start what finding would send you back to framing, because a team without that rule keeps interviewing until the answer flatters the plan it already had.

Discovery is a named phase in public sector practice, not a private habit. Digital.gov’s guide series names discovery as one of four phases of human centered design work, alongside design, delivery and measurement.

That series splits each phase in two: a concepts guide covering why the phase works as it does, and an operations guide carrying the checklists. It is a useful split for anyone writing their own framework.

Design thinking and human-centered design are the traditions most frameworks borrow from. Treat them as sources of method; your framework is the order you run them in and the decision each step unlocks.

Design standards say it plainly. The US Web Design System’s principles tell teams to include real people in the design process from the beginning, then test the assumptions they make with those same people.

Continuous discovery habits describe the cadence that keeps this alive: small weekly contact with customers rather than one research project before each big bet. The customer discovery process is the interview craft inside it.

Examples

Discovery looks different by industry, but three shapes recur. None needs a large budget, and each ends in a decision the team wrote down before any evidence arrived, which is what stops a study turning into a debate.

An insurer sits with the adjusters. A claims team spends two weeks watching assessors work in the field before specifying anything, and finds the delay sits in photograph handling — not in the form everyone wanted rebuilt.

A public agency runs a named phase. Government service teams commonly complete a discovery phase before a build is approved, and a legitimate result is a recommendation that the service should not be built at all. That outcome saves whatever the build would have cost.

An offshore team runs the demand test. A Manila based product group publishes one page describing a new service tier and counts how many existing customers ask to join it, settling in ten days a question that two roadmap reviews had dodged.

Related terms

• Minimum viable product: the smallest build that tests one assumption; an output of discovery, not the method.
• Experimentation program: the standing machinery for running tests once discovery has named them.
• UX researcher: the role that runs the interviews and usability sessions a framework calls for.
• Customer discovery process: the interview craft that sits inside the wider framework.
• Design thinking: a problem solving tradition most discovery frameworks borrow their methods from.

FAQ

What is the difference between discovery and delivery?

Discovery decides which problem is worth solving and what evidence would prove it. Delivery builds the chosen thing properly. A team running both at once usually ships quickly in the wrong direction.

How long should a discovery phase take?

Long enough to answer the named question and no longer. Weeks rather than quarters is the usual shape, and a framework that cannot produce a decision inside a quarter is a research habit rather than a method.

Who should run product discovery?

A small group that can actually decide: a product manager, a designer and an engineer, with a researcher where the questions are hard. Discovery run by people who cannot change the plan is a report, not a decision.

What evidence counts in discovery?

What people did, not what they say they would do. Accounts of recent behaviour, observed commitment to an offer and recorded task sessions all beat the strongest opinion in the room.

Can discovery be done with an offshore team?

Yes, and interview work travels well when researchers share a market and a language with the customers. Keep the decision rule written down, so findings do not stall across time zones.

Find teams you can brief for a discovery phase on Outsource Accelerator.