Building Opportunity Solution Trees for Product Discovery

Build and maintain an opportunity solution tree that links one measurable outcome to customer opportunities, candidate solutions, and assumption tests.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

An opportunity solution tree is the central visual artifact in Continuous Discovery Habits. As Teresa Torres's own guide to opportunity solution trees describes it, it's a tree diagram that starts with a single desired outcome at the top, branches into the customer opportunities (needs, pain points, and desires) that influence that outcome, and then branches again into the potential solutions your team might build to address each opportunity. Below the solutions sit the assumptions you need to test before committing to build. The tree serves as both a decision-making framework and a communication tool, it shows leadership what you're pursuing, shows the team why you're pursuing it, and shows stakeholders that every solution idea traces back to validated customer insight.

The specific problem the opportunity solution tree solves is the disconnect between business goals and customer reality. Without it, product teams oscillate between two failure modes: building whatever stakeholders request (output-driven) or pursuing interesting customer insights that don't connect to business results (research for research's sake). The tree forces explicit links between layers. Every solution must trace upward to an opportunity, and every opportunity must trace upward to the outcome. If a stakeholder requests a feature, you can point to the tree and ask which opportunity it addresses. If a researcher surfaces a fascinating insight, you can check whether it connects to the outcome you're responsible for. This traceability is what makes the tree powerful, it's not a brainstorming artifact, it's a strategic filter.

The concrete artifact you produce is a four-layer tree: outcome at the root, opportunities at the first branching level (organized hierarchically from broad to specific), solutions at the next level, and assumption tests at the leaves. A healthy tree for an active product team typically has one outcome, eight to fifteen leaf-level opportunities, two to four candidate solutions per opportunity being actively explored, and a handful of assumption tests in flight at any time. The tree lives on a shared wall or digital whiteboard and is updated at least weekly as you learn from customer interviews and assumption tests. A stale tree is a dead tree, the value comes from the ritual of returning to it, pruning what you've learned doesn't work, and growing new branches as new insights arrive.

How It Works

The opportunity solution tree works because it makes the implicit structure of product decisions explicit and visual. Every product team carries a mental model of why they're building what they're building, but those mental models are fragmented across individuals and rarely aligned. The tree externalizes that model so the entire team, and stakeholders, can see the same picture, point to specific nodes, and have precise conversations about where to invest.

The tree's power comes from its hierarchy. At the top sits a desired outcome, a metric the team can influence, like increasing activation rate or reducing time-to-value. This is the constraint that bounds all exploration. Beneath the outcome sit customer opportunities, structured as a hierarchy from broad themes to specific, actionable pain points. Teresa Torres, who developed this framework within Continuous Discovery Habits, uses the term 'opportunity' deliberately, it encompasses needs (things customers want to do), pain points (things that frustrate them), and desires (things that would delight them). By organizing opportunities hierarchically, you can zoom in and out: a broad opportunity like 'struggling to get started' might decompose into 'overwhelmed by options,' 'can't find relevant templates,' and 'unclear on first steps.' This hierarchy lets you choose where to focus without losing the big picture.

The branching from opportunities to solutions is where the framework prevents premature convergence. The rule is: generate at least three distinct solution ideas per opportunity before evaluating any of them. This matters because teams naturally anchor on the first plausible solution they think of, usually the most obvious one, which is also the one competitors have already built. By forcing breadth, the tree increases the odds of finding a differentiated approach. The solutions don't need to be fully specified; they're hypotheses about how you might address the opportunity.

Below solutions sit assumptions, the beliefs that must be true for the solution to work. One summary of the book describes the tree as starting at the singular desired outcome, mapping the opportunity space, leading to the solution space, and attaching assumption tests to drive evaluation. These connect the tree to experimentation. Rather than building an entire solution and hoping it works, you identify the riskiest assumption (the 'leap of faith') and design a small test to validate or invalidate it. This is where the tree connects to running assumption tests. The tree thus creates a continuous loop: interview customers to discover opportunities, generate solutions for those opportunities, test assumptions behind those solutions, and update the tree based on what you learn.

A critical mental model is that the tree is not a project plan. It doesn't flow left to right on a timeline. It's a snapshot of your current understanding, and it changes shape as you learn. Opportunities get added when new interviews reveal unmet needs. Opportunities get pruned when you learn they don't actually influence the outcome. Solutions get crossed out when assumption tests fail. New solutions sprout when old ones die. The tree is alive, and its vitality is the signal that your team is actually doing continuous discovery rather than building off a stale roadmap.

Step-by-Step Guide

Step 1: Define your desired outcome

Before you draw a single branch, you need a clear, measurable outcome at the top of the tree. This is the business or product metric your team has been assigned to move, for example, 'increase 30-day activation rate from 35% to 50%' or 'reduce median support ticket resolution time by 40%.' The outcome should be something your team can directly influence through the product, not a lagging business metric like revenue that depends on factors outside your control. Work with your product leader to define this if it hasn't been set.

Write the outcome as a specific metric with a current baseline and a target direction, you don't always need an exact target number, but you need to know which direction is better. Place this outcome at the very top of your whiteboard or digital canvas. Every other node in the tree will trace back to this single point.

Pro tip: If your team has been given a vague goal like 'improve onboarding,' push back until you get a metric. A goal without a metric produces a tree without focus, you'll branch endlessly because anything could be relevant. Ask: 'How will we know if onboarding improved? What number moves?' That answer is your outcome.

Step 2: Gather your customer opportunity raw material

Pull together the customer insights you've collected from recent interviews, support tickets, usability tests, and any other qualitative sources. You're looking for statements that express needs ('I need to quickly see whether my campaign is working'), pain points ('I always get confused by the settings page'), and desires ('I wish I could just share this with my client directly'). Write each opportunity on a separate sticky note or card, one insight per card. Use the customer's language, not your internal jargon.

If you've been doing weekly customer interviews, you should have a steady stream of these. Aim for at least 15 to 25 opportunity statements before you start organizing. For example, if you have fewer than 10, you likely need more interview data before you can build a useful tree.

Pro tip: Don't filter for relevance yet. Include opportunities that seem tangential, the hierarchy step will sort them. Filtering too early kills the opportunities you haven't thought about yet, which are often the most valuable.

Step 3: Organize opportunities into a hierarchy

Now cluster your opportunity statements into a parent-child hierarchy beneath the outcome. Start by looking for natural groupings, opportunities that relate to the same phase of the customer experience or the same underlying job. For example, under an activation outcome, you might see clusters around 'understanding value proposition,' 'completing initial setup,' and 'experiencing first success.' These clusters become your top-level (parent) opportunities.

Within each parent, arrange the specific opportunity statements as children, ordered roughly by how specific or narrow they are. A parent opportunity like 'struggling with initial setup' might have children like 'can't connect their data source,' 'don't know which plan fits their team size,' and 'confused by the difference between workspaces and projects.' The hierarchy should be three levels deep at most: outcome, parent opportunities, and child opportunities. If you find yourself going deeper, you're likely splitting too finely.

Pro tip: Use the 'sniff test', for each child opportunity, ask: if we fully addressed this child, would the parent opportunity improve? If yes, the hierarchy is sound. If no, the child might belong under a different parent. Also watch for opportunities that don't clearly connect to the desired outcome at all, park those in a 'parking lot' for future trees.

Step 4: Prioritize which opportunity space to explore first

You can't pursue every opportunity simultaneously. Look at your tree and select one or two opportunity areas to focus on. Prioritize based on three factors: opportunity size (how many customers are affected and how severely), opportunity frequency (how often does this come up in interviews, is it every conversation or one outlier?), and strategic fit (does addressing this opportunity give your team a realistic shot at moving the desired outcome metric?). You can use a simple dot-voting exercise with your team, or refer to a more structured approach via mapping and prioritizing customer opportunities.

Mark the selected opportunity areas visually, highlight them, add a star, or move them to the center. The unselected opportunities stay on the tree; they're not discarded, they're deferred. This is important for stakeholder communication: you're not ignoring those areas, you're sequencing.

Pro tip: Resist the urge to spread thin across many opportunities. A team exploring one opportunity deeply will learn faster and ship more impact than a team dabbling in five. If you've selected half of the leaf-level opportunities on your tree, you've selected too many.

Step 5: Generate at least three solutions per target opportunity

For each opportunity you've chosen to focus on, brainstorm at least three distinct solutions. This follows Torres's guidance to choose three solutions to explore further after brainstorming and practitioner guidance to generate multiple candidate solutions instead of committing to the first idea; it prevents your team from latching onto the first idea and never considering alternatives. Run a structured ideation session: set a short timer for silent individual brainstorming, then share and discuss. Push for genuinely different approaches, not three variations of the same idea.

If the opportunity is 'users can't find relevant templates,' your solutions shouldn't be 'better template search,' 'slightly better template search,' and 'much better template search.' Instead, aim for 'AI-powered template recommendations based on user profile,' 'curated starter kits organized by industry,' and 'community-contributed template gallery with ratings.' Place each solution as a node beneath its parent opportunity. Label them clearly, a short name and a one-sentence description is enough at this stage.

Pro tip: If your team can only generate one or two solutions, it usually means you haven't understood the opportunity deeply enough. Go back to interview notes. The more specific your understanding of the customer's context, the more creative and varied your solutions will be.

Step 6: Identify assumptions beneath each solution

For each candidate solution, list the assumptions that must hold true for that solution to work. There are several categories to check: desirability assumptions (do customers actually want this?), viability assumptions (can we sustain this as a business?), feasibility assumptions (can we build this with our team and tech stack?), and usability assumptions (can customers figure out how to use it?). Write each assumption as a testable statement, 'Users will understand that the recommendation engine uses their profile data' is testable; 'Users will like it' is not. For each solution, you'll typically uncover three to eight assumptions.

Place these as leaf nodes beneath their solution. Then identify which assumption is the riskiest, the one most likely to be wrong and most consequential if wrong. This is your 'leap of faith' assumption and it's what you'll test first.

Pro tip: The hardest assumptions to spot are the ones you're most confident about, they feel like facts, not assumptions. Ask your team: 'What would have to be true about the customer, the market, and our technology for this solution to succeed?' Then challenge each answer: 'How do we know that's true? Have we tested it, or are we assuming?'

Step 7: Visualize the complete tree and review for structural integrity

Step back and look at the full tree. Check for structural issues: Does every solution trace upward to a specific opportunity? Does every opportunity trace upward to the desired outcome? Are there any orphan nodes, ideas floating without connections?

Are there any opportunities with only one solution (violating the 'at least three' rule for your priority areas)? Check for balance: if one branch of the tree is dense with nodes and another has only a couple, you may have over-indexed on one area or under-explored another. Check for level consistency: are all nodes at the same level roughly the same granularity? A parent opportunity like 'onboarding is confusing' sitting next to another parent like 'the hex color code input doesn't accept shorthand notation' suggests a granularity mismatch.

Clean up the tree, ensure labels are readable, and add a legend if needed (color-coding for priority, status, or confidence).

Pro tip: Take a photo or screenshot before cleaning up. The messy version often contains spatial relationships (which stickies were placed near each other) that carry implicit meaning your team recognized subconsciously during clustering.

Step 8: Share the tree with stakeholders and get alignment

Walk your key stakeholders through the tree in a dedicated session. Start at the top with the outcome, explain how the opportunities were discovered (real customer interviews, not team brainstorms), show which opportunities you're prioritizing and why, and highlight the solutions and assumptions you're testing. The goal isn't to get approval, it's to create shared understanding and invite challenge. Stakeholders often surface opportunities you've missed because they have different customer exposure.

They may also push back on prioritization, which is a healthy conversation to have in front of the tree rather than in a slide deck. Use the tree as a negotiation tool: if a stakeholder insists on a specific feature, ask them to identify which opportunity it addresses. If they can, add it to the tree. If they can't, you've just had a productive conversation about why it might not be the right bet.

Pro tip: Don't present the tree as finished or final. Frame it explicitly: 'This is our current understanding. It will change every week as we learn more.' This sets expectations that the tree is a living tool, not a project plan they're signing off on.

Step 9: Establish a weekly update ritual

The tree only works if you maintain it. Establish a weekly cadence, typically during or right after your team's discovery sync, where you update the tree based on what you learned that week. Add new opportunities from recent interviews. Prune opportunities that turned out to be edge cases or don't influence the outcome.

Cross out solutions whose critical assumptions failed testing. Add new solutions that emerged from learning. Update the status of assumption tests in progress. This weekly ritual is what transforms the tree from a one-time workshop artifact into the operating system of your product discovery process.

Block a short, fixed slot for the update, for example half an hour. If the tree hasn't changed in two weeks, something is wrong, either you're not conducting interviews, not running tests, or not being honest about what you're learning.

Pro tip: Keep a 'graveyard' section next to your tree for pruned opportunities and failed solutions. This prevents the team from re-proposing ideas you've already invalidated, and it shows stakeholders the volume of learning happening, a tree with a big graveyard signals rigorous discovery.

Best Practices

• Use customer language, not internal product jargon, when labeling opportunity nodes. If a customer said 'I waste so much time every morning figuring out what to work on,' write that, don't abstract it to 'inefficient task prioritization.' Customer language keeps the tree grounded in reality and makes it harder to subtly reframe opportunities to fit solutions you already want to build. When you notice jargon creeping in, it's a signal that the team has started designing solutions in their heads and is reverse-engineering the opportunity to match.
• Keep exactly one desired outcome at the top of each tree, as one practitioner guide to opportunity solution trees also recommends. Teams with multiple metrics try to create multi-root trees, which collapse into unfocused messes because every opportunity can be rationalized as relevant to at least one root. If your team owns two outcomes, build two separate trees. You can cross-reference them, but maintaining separate trees forces separate prioritization conversations, which is the point.
• Physically or digitally co-locate the tree where the team works, not buried in a Confluence page. The tree should be visible during every standup, planning meeting, and design review. Teams that keep their tree on a physical wall next to their desks reference it spontaneously in conversation. Teams that store it in a folder check it once a month. Visibility drives usage.
• Resist the urge to perfectly organize the tree before you start using it. A rough, imperfect tree that gets updated weekly is infinitely more valuable than a beautifully designed tree that took three weeks to create and is already stale. Start messy, clean as you go. The first version should take a couple of hours, not a couple of weeks.
• When you cross out a solution because an assumption test failed, celebrate it visibly. Cross-outs are evidence of learning, not failure. If your team treats pruning as loss, they'll unconsciously avoid testing assumptions rigorously. A tree with no cross-outs after a month means the team is either not testing or not being honest about test results.
• Color-code or tag opportunity nodes by how they were discovered, interview, support ticket, usability test, analytics, stakeholder input; practitioner guidance recommends linking opportunities to evidence such as customer quotes, usage data, or support tickets. This metadata lets you audit the tree's evidence base. A tree where most opportunities came from one stakeholder's intuition is weaker than a tree where most came from customer interviews. The tagging makes this visible and actionable.
• Review the tree's connection to the desired outcome metric monthly. Ask: has the outcome metric moved? Which branches of the tree contributed? Which didn't? This retrospective links the tree to actual business results and prevents it from becoming an intellectually satisfying exercise that doesn't drive impact. If the metric hasn't moved in two months despite active tree work, re-examine whether you're targeting the right opportunities or whether the outcome itself is poorly defined.

Common Mistakes

• Starting with solutions and reverse-engineering opportunities to justify them: This is the most common and most damaging mistake. It usually happens when a team has a feature they're already excited about, or that a stakeholder has mandated, and they construct an opportunity solution tree as post-hoc justification rather than genuine discovery. The symptom is an opportunity node that's suspiciously specific and perfectly matched to one solution ('users need an AI-powered dashboard' beneath which sits… an AI-powered dashboard). To catch it, read each opportunity aloud and ask: 'Would a customer say this in an interview, or did we invent this to justify a feature?' Real opportunities describe problems and desires in customer terms. Fabricated opportunities describe solutions wearing opportunity clothing.
• Building the tree once and never updating it: A team builds a beautiful tree during a workshop, photographs it, and never touches it again. Within three weeks, the tree no longer reflects what the team is working on or what they've learned. The tree becomes a historical artifact rather than a living tool. The root cause is usually that the team didn't establish a weekly update ritual (Step 9). The fix is to schedule a recurring 20-30 minute session explicitly for tree maintenance. If you notice the tree hasn't changed in two consecutive weeks, treat it as an urgent process problem, either discovery has stalled or the team has decoupled their work from the tree.
• Creating only one solution per opportunity: Teams naturally anchor on the first reasonable solution and skip the brainstorming step because it feels inefficient. 'We already know what to build, why generate alternatives?' The problem is that the first idea is almost always the most obvious one, the one competitors have already built, the one with the highest effort and lowest differentiation. The 'at least three' rule exists to push past the obvious. When you catch a branch with a single solution, pause and run a quick divergent brainstorm. Set a five-minute timer and force three more ideas, even if they feel silly. Often the 'silly' third or fourth idea contains the seed of something genuinely novel.
• Making the opportunity hierarchy too flat, listing dozens of child opportunities directly under the outcome: A flat tree looks like a list with a header, and it's just as useless for decision-making. With that many peer-level opportunities, the team can't see patterns or choose a focus area. This happens when the team skips the clustering step and dumps individual interview insights directly onto the tree without organizing them. The fix is to group opportunities into three to five parent categories first, then nest specifics underneath. If you have more than seven items at any single level, you likely need an intermediate grouping layer. Use affinity mapping, silently group related stickies, then name the groups, to find natural parent opportunities.
• Confusing opportunities with solutions masquerading as needs: An opportunity like 'users need a search bar on the templates page' is actually a solution, not an opportunity. The underlying opportunity might be 'users can't find templates relevant to their industry.' This confusion is pervasive because customers often express needs as solution requests, 'I wish you had X feature.' Your job is to dig beneath the request to the underlying need using follow-up questions like 'What would that let you do?' or 'What happens today without that?' In the tree, test each opportunity node: if you could address it with multiple fundamentally different solutions, it's a genuine opportunity. If it can only be addressed one way, it's probably a solution in disguise.
• Trying to capture every possible opportunity on a single tree: Ambitious teams try to map the entire customer experience on one tree, resulting in an unreadable wall of stickies that no one can navigate. The tree becomes a research archive instead of a decision-making tool. Remember that the tree is scoped to a single outcome. Opportunities that don't plausibly influence that outcome, no matter how interesting, belong in your research repository, not on this tree. If an opportunity is genuinely important but connects to a different metric, start a separate tree for that metric. The discipline of keeping trees focused is what makes them useful.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Continuous Discovery Habits

Related Skills

• Conducting Weekly Customer Interviews
• Defining Product Outcomes Over Outputs
• Mapping and Prioritizing Customer Opportunities
• Running Assumption Tests
• Story Mapping Customer Experiences
• Automating Continuous Research Recruitment
• Comparing Solutions with Compare-and-Contrast Decisions

Sources

• Opportunity Solution Trees: Visualize Your Discovery to Stay
• DRAFT Summary: Continuous Discovery Habits
• Opportunity Solution Tree (OST) - pm-skills - GitHub
• Opportunity Solution Trees: Visual Framework for Product

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.