Product discovery: finding problems worth solving

Most product teams have plenty of ideas and very little evidence about which problems are worth their time. A sales call produces a feature request, a competitor launches something, a founder has a thought in the shower, and the backlog grows. Product discovery is the habit of slowing down long enough to ask whether a problem is real, whether it matters to enough people, and whether solving it would help the business.

This guide covers the purpose of discovery, Teresa Torres’ opportunity solution tree as a way to organise it, and the practical steps to run it without turning it into a months-long research project.

What discovery is for

The UK Government’s service manual has one of the clearest descriptions of a discovery phase. It says discovery is where you learn about the problem before committing to build anything: who the users are, what they are trying to achieve, what constraints apply, and how you would measure success. It tells teams to reframe any proposed solution as a problem and to quantify what that problem costs today. It also says plainly: do not start building during discovery.

The manual’s view of stopping is worth borrowing. If discovery shows the problem is not worth pursuing, that is not a failure. It saves time and money. Typical government discoveries take around 4 to 8 weeks, though the manual is clear there is no fixed length.

In a product company the same idea usually runs continuously rather than as a phase. The aim is to reduce what Marty Cagan calls value risk, the risk that customers will not buy or use what you build, before engineering time is spent.

The opportunity solution tree

Teresa Torres, author of Continuous Discovery Habits, introduced the opportunity solution tree in 2016 as a visual map of the paths a team could take to reach an outcome. It has four levels.

1. Outcome. The root. Torres prefers a product outcome, a measure of customer behaviour in the product that the team can influence, over a distant business number such as revenue.
2. Opportunities. Customer needs, pain points and desires that, if addressed, would drive the outcome. They are arranged in a hierarchy, with broad moments in the customer’s experience at the top and more specific needs beneath.
3. Solutions. Ideas for addressing one chosen opportunity, not the whole tree.
4. Assumption tests. Small experiments that check the riskiest assumptions behind each solution.

The value of the tree is that it makes the team’s reasoning visible. Anyone looking at it can see which outcome a solution serves, which customer need it addresses, and what the team still needs to learn.

Where opportunities come from

Torres is firm on this. The main source of opportunities is story-based customer interviews, where you ask about specific past behaviour (“Tell me about the last time you…”) rather than opinions about the future. Opportunities pulled from real stories come with context.

Support tickets, sales notes, feature requests and analytics are useful prompts for what to explore in interviews, but she advises against adding them straight to the tree because they usually lack that context. She also warns against building the opportunity space from memory or assumptions, which brings in the team’s own bias. Her practical rule is to start mapping after three or four interview stories and revisit the map every three or four interviews after that.

Torres recommends that the interviews and the tree belong to a product trio: a product manager, a designer and an engineer who share responsibility for the outcome and interview customers together. When all three hear the same stories, decisions get faster and arguments get shorter.

Running it step by step

1. Agree one outcome. Pick a product outcome the team can move in a quarter, such as the share of new users who complete a key action in their first week.
2. Interview for stories. Talk to recent customers about specific moments. Record their words, not your summary.
3. Draft the opportunity space. After three or four interviews, group what you heard into needs and pain points, arranged from broad to specific. Torres encourages a “crummy first draft” rather than waiting for perfection.
4. Choose a target opportunity. Compare a few opportunities by how many customers they affect, how badly, and how they connect to the outcome. Do not rule one out because it looks hard to solve.
5. Generate at least three solutions. Torres advises comparing several ideas for the target opportunity so the team does not fall in love with the first one.
6. Test assumptions. For each solution, list what must be true for it to work, then test the riskiest ones cheaply with prototypes, one-question surveys or data you already have.
7. Keep the tree alive. Update it as you learn. Start a new tree only when the outcome itself changes, not when the target number shifts.

A worked illustration

An example (illustration only). A small UK company sells an app that helps independent gyms manage memberships. Its product trio agrees on an outcome: increase the share of new gyms that send their first member invitation within seven days of signing up.

Interviews with eight gym owners surface stories. One owner spent an evening retyping 300 members from a spreadsheet. Another did not invite anyone because she was not sure how the app would handle members who pay in cash. A third wanted to test the app on staff first. These become opportunities: “I don’t want to re-enter existing member data”, “I’m worried about edge cases like cash payers” and “I want to try it safely before members see it”.

The team picks the first, since it came up in six of eight stories and sits directly in the path to the outcome. Solutions include a spreadsheet import, an offer to import data for the gym, and integrations with two common booking tools. The riskiest assumption behind the import is that gym owners’ spreadsheets have consistent columns. The team tests it by asking five owners to send a sample file. Four are messy, so the team prototypes a guided import with column matching before writing any production code.

Common mistakes

• Starting with solutions. If the first branch on your tree is a feature, you have skipped the opportunity layer.
• Treating requests as opportunities. “Customers want an import button” is a solution. The opportunity is the need behind it.
• One tree for the whole company. Torres advises one tree per product trio, with a separate outcome for each.
• Interviewing only at the start. Discovery that stops after a kick-off workshop goes stale within weeks.
• Testing only the easy assumptions. Test the ones that would kill the idea if they turned out false.

When to use it, and when not

The opportunity solution tree suits teams that own an outcome and have regular access to customers. It is less useful when the work is fixed by regulation or contract, where the main question is how to deliver rather than what to build. It is also overkill for small, low-risk changes that are cheap to reverse; just ship them and measure.

If you only take one habit from this, make it the weekly customer conversation. The tree is a way to organise what you learn. Without the stories, there is nothing to organise.