Product Discovery Frameworks: Which to Use, When and How They Fit Together

Many software projects fail not because they were built badly, but because the wrong thing was built. Product discovery is the work of reducing that risk: understanding users and their problems, exploring solutions and testing assumptions before committing to development.

There is no shortage of discovery frameworks. The challenge is knowing which to use and how they fit together. This guide explains the main ones and combines them into a practical process.

The four risks discovery addresses

The main frameworks

Jobs to Be Done (JTBD)

Focuses on the progress a person is trying to make in a particular circumstance — the “job” they hire a product to do. Instead of asking what features users want, ask what they were trying to achieve, what they used before and what made them switch. JTBD interviews are excellent for understanding motivations and competing alternatives, including spreadsheets and doing nothing.

Design Thinking

A human-centred approach usually described in stages: empathise, define, ideate, prototype and test. It is strong at framing the right problem and generating diverse solutions, especially when the problem is ambiguous.

Lean experiments

Turn assumptions into testable hypotheses and run the cheapest experiment that could disprove them: landing pages, concierge services, fake-door tests, prototypes. The emphasis is on learning quickly with minimal investment.

Opportunity Solution Tree

Popularised by Teresa Torres, this visual maps a desired outcome to opportunities (unmet needs and pain points), then to candidate solutions, then to experiments that test them. It keeps teams focused on outcomes and prevents jumping to a single solution.

Business Model Canvas and Value Proposition Canvas

The Business Model Canvas summarises how a product creates, delivers and captures value across nine building blocks. The Value Proposition Canvas zooms in on the fit between customer jobs, pains and gains and the product’s features. Both are useful for viability conversations with stakeholders.

MVP and prototypes

A minimum viable product is the smallest release that tests a key assumption with real users. Prototypes — from paper sketches to clickable mock-ups — test usability and value earlier and more cheaply. Our guide to MVP development cost covers scoping.

RICE prioritisation

Developed at Intercom, RICE scores ideas by Reach, Impact, Confidence and Effort, calculated as (Reach × Impact × Confidence) ÷ Effort. It makes prioritisation discussions explicit and comparable, though the numbers are still estimates.

Which framework answers which question

Putting them together

1. Understand: JTBD and contextual interviews with 6–10 users; review support data and analytics.
2. Frame: define the outcome and the core problem; write a problem statement.
3. Explore: build an Opportunity Solution Tree; generate solution ideas.
4. Test: identify the riskiest assumptions; run quick experiments and prototype tests.
5. Decide: check viability with canvases; prioritise with RICE; define the first release and success metrics.

A two-week discovery sprint

Running good discovery interviews

• Ask about past behaviour, not hypothetical future use: “Tell me about the last time you…” rather than “Would you use…?”
• Follow the story: what triggered the need, what they tried, what frustrated them, what they did next.
• Explore workarounds: spreadsheets, emails and manual steps reveal unmet needs and willingness to change.
• Listen for money and time: what the problem costs them and who pays.
• Avoid pitching: show prototypes only after understanding the problem.
• Interview in pairs: one asks, one notes; synthesise together the same day.

Discovery for B2B and enterprise products

In B2B, the user, the buyer and the approver are often different people. Discovery should cover:

Discovery for AI features

AI adds specific uncertainties: whether data exists and may be used, whether model quality is good enough for the task, and how users will react to imperfect outputs. Include a feasibility spike with real data, an early evaluation set and prototype tests that show realistic — not cherry-picked — AI outputs. Our guide to AI proof of concept versus MVP covers this in more depth.

Common pitfalls

• Confirmation-seeking interviews: asking users whether they like an idea rather than about their behaviour.
• Framework theatre: filling canvases without new evidence.
• Skipping feasibility: discovering late that data or integrations do not exist.
• Precise-looking scores: treating RICE numbers as facts rather than structured estimates.
• Discovery as a phase only: stopping learning once development starts.

Frequently asked questions

How long should discovery take?

For a focused product question, two to four weeks is often enough. Larger or riskier initiatives may need longer, but continuous discovery should continue during delivery.

Do we need all these frameworks?

No. Choose the ones that address your biggest uncertainties. Most discoveries use interviews, an opportunity map, prototypes and a prioritisation method.

Can discovery be outsourced?

A partner can facilitate and add skills, but your team and stakeholders must take part — the learning has to stay with the people who will make product decisions.

How do we know discovery worked?

It produced evidence that changed or confirmed decisions, a clear first release with success metrics, and fewer surprises during build.