Unit 5: Discovery: finding problems worth solving

Learning objectives

By the end of this unit, you should be able to explain why discovery matters and what happens when teams skip it, describe the continuous discovery framework, and plan a lightweight discovery cycle for a product problem.

Video script

Reading material

The opportunity solution tree

The opportunity solution tree (OST) is Teresa Torres' framework for organizing discovery work. It has four layers.

The outcome sits at the top. This is the measurable goal your team is pursuing. It should be something you can observe and measure, like "increase the percentage of new users who complete onboarding in their first session from 40% to 60%."

Opportunities branch off the outcome. These are the customer needs, pain points, and desires that are connected to the outcome. "New users don't understand the value of the product during onboarding" or "The setup process requires information that new users don't have readily available." Opportunities come from customer research.

Solutions branch off each opportunity. For each problem, there are multiple possible solutions. The solution level is where features live, but they're connected to specific opportunities, which means every feature has a clear reason for existing.

Experiments branch off each solution. Before committing to building a solution, you test the riskiest assumptions through lightweight experiments. Can users complete this task with a prototype? Do they actually experience this pain point with the frequency we assumed? Would they change their behavior if this capability existed?

The OST is useful because it makes your reasoning visible. Instead of jumping from outcome to solution ("We need to improve onboarding, so let's build a wizard"), you map the intermediate steps and test the assumptions that connect them.

Discovery anti-patterns

The annual research project. Some teams do discovery once a year, usually before annual planning. They conduct a bunch of interviews, synthesize the findings, and use them to plan the next year's roadmap. Then they don't talk to customers again until the next planning cycle. By the time they build the features, the insights are stale.

The survey trap. Teams that rely primarily on surveys for user research are getting data without context. Surveys tell you what people check on a form. Interviews tell you why. Use surveys for scale and interviews for depth.

Discovery theater. Teams that conduct interviews but don't actually use the findings. The research goes into a slide deck, the slide deck goes into a shared drive, and the team builds whatever was already planned. Discovery is only useful if it influences decisions.

Solution-first discovery. "We've decided to build a chatbot. Let's do some research to validate it." This isn't discovery. This is confirmation bias with a research budget. Real discovery starts with the problem, not the solution.

AI-assisted discovery tools

Use AI for transcription and synthesis after customer conversations. Have AI identify themes across 10+ interviews you wouldn't have time to cross-reference manually. Use AI to generate prototype content and mockups for assumption testing. Let AI analyze product usage data to identify behavioral patterns that suggest unmet needs.

Don't use AI to replace customer conversations. Don't trust AI-generated personas as if they were real customers. Don't let AI-synthesized insights bypass the team's judgment about what matters.

Practical exercise

Exercise: Build a mini opportunity solution tree

Pick a product you use that has a noticeable problem (something that frustrates you regularly).

1. Define an outcome that solving this problem would support.
2. List 3-4 opportunities (different aspects of the problem or related pain points).
3. For your top opportunity, brainstorm 3 possible solutions.
4. For your top solution, list 2-3 assumptions that would need to be true for it to work.
5. Design one lightweight experiment to test the riskiest assumption. What would you do, who would you test with, and what result would tell you the assumption is valid?

Keep the whole thing to one page. The goal is to practice the structure, not to be exhaustive.