An opportunity solution tree connects a desired outcome to customer needs, possible solutions, and the assumptions you need to test. Its value comes from explaining why you are pursuing one problem and comparing ways to solve it. A diagram filled with feature requests does not supply that reasoning.
See the difference a real opportunity makes
Product Talk’s trivago case describes travelers who manually checked accommodation details because they did not trust filters to reflect their preferences. That is more specific than a request to improve search. It led the team to consider ideas such as highlighting selected criteria in hotel details and surfacing relevant reviews. The case describes exploration, not a proven conversion increase from those ideas.
The transferable decision is to investigate the reason behind behavior before choosing a feature. More filters and clearer evidence that an existing filter worked address different problems. Keep that distinction as we build a separate music-practice example.
Choose an outcome you can define and measure
Our worked product helps adult beginners plan short guitar-practice sessions. The outcome is to increase the share of new learners who begin a second planned practice session within seven days after completing their first guided session. Define the eligible cohort as new learners who completed their first guided session; count each learner once. Starting the app or viewing a reminder does not count as beginning practice.
Before setting a numerical target, measure a baseline with the same cohort and event definition. A team might then agree a target and review date. Do not insert a convenient percentage just to make the tree look measurable. The outcome definition can be precise while its baseline is still unknown.
| Field | Worked definition |
|---|---|
| Population | New learners who completed a first guided guitar-practice session |
| Desired behavior | Begin a second planned practice session within seven days |
| Numerator | Distinct learners in the completed-window denominator who began a second session within seven days after first-session completion |
| Denominator | Distinct eligible learners whose full seven-day observation window has elapsed |
| Do not count | App opens, reminder views, or duplicate start events as additional learners |
| Baseline / target | Measure baseline first; then record an agreed target and review date |
Attach opportunities to customer stories
Interview learners about a recent attempt to practice between lessons. Ask what happened before they started, what they chose, and what stopped them. A request for streaks is a proposed solution; the underlying need might be remembering a plan, choosing a small enough task, or seeing progress. Those needs belong on different branches.
The table below supplies practice inputs for learning the method. In a real tree, replace each input with a dated interview or observation reference and retain its context. Do not turn an AI-generated list of possible problems into research evidence.
| Practice input | Opportunity | Evidence to attach in your project |
|---|---|---|
| Learner has 10 minutes but spends it deciding which exercise to do | I need to know what to practice when I have a short gap | Interview story and sequence of choices |
| Learner planned an evening session but the instrument was elsewhere | I need a practice plan that fits my actual setting | Recent missed-session context |
| Learner repeats an exercise but cannot tell whether it is improving | I need to recognize useful progress | Observed session and learner’s interpretation |
Draw the tree and choose one branch
Place the outcome at the top, the three opportunities below it, and choose the short-gap decision problem for this example. It is a bounded moment that the product can address directly. In a real prioritization, compare evidence of frequency, importance, and current dissatisfaction before choosing; the diagram itself does not establish which problem is most common.
For the selected opportunity, compare three solutions: a next-exercise card, a ten-minute practice plan, and a resume-last-exercise shortcut. Keep the other opportunities visible but do not generate a large feature roadmap under every branch at once. The goal is to make the next decision tractable.
Test the assumption behind each solution
A next-exercise card assumes the recommendation is relevant and trusted. A ten-minute plan assumes the learner can follow its scope in their available time. A resume shortcut assumes the previous exercise is still the best next action. Testing whether people like all three mockups would miss these different dependencies.
Use a recent practice context supplied by the participant. Ask them to decide what to do with a short gap, then observe the choice and, where appropriate, the start of the exercise. If comparing variants, plan assignment and sequence so familiarity with one version does not silently become evidence for another.
| Solution | Risky assumption | Smallest useful test | Result that changes direction |
|---|---|---|---|
| Next-exercise card | The recommendation matches the learner’s current need | Show a specific recommendation and ask the learner to choose what to practice | They reject it because the skill is irrelevant: improve selection before polishing the card |
| Ten-minute plan | The sequence is feasible in the available time | Observe an attempted short session using the plan | Setup consumes the available time: shorten or change the sequence |
| Resume shortcut | Repeating the last exercise is a useful next step | Offer the actual previous exercise in the learner’s current context | They need a different skill: do not default everyone to resume |
Turn a finding into an explicit product decision
Worked finding: a learner understands the recommended exercise but spends the first minutes finding the required backing track. The problem is not necessarily the card label. The proposed next version puts the exercise and required audio together and shows the expected setup before starting. That change follows from a specific obstacle in the task.
Attach the session reference to the relevant assumption and record the decision: retain the next-exercise concept, include its materials, and retest the start of practice. Keep the other solutions as alternatives. If the recommendation itself is consistently unsuitable, revisit selection or choose another solution rather than repeatedly adjusting presentation.
After implementation, inspect the defined second-session outcome over complete observation windows. Successful use in a small prototype study supports a local interaction decision; it does not establish an increase in seven-day practice behavior. The tree should link those two levels of evidence without treating them as equivalent.
Copy the structure and keep it current
Use this blank structure in a document or whiteboard: Outcome [population, behavior, window, baseline, target]; Opportunity [customer need and evidence references]; Selected opportunity [reason]; Solution A/B/C [different approaches]; Assumption [what must be true]; Test [procedure and decision condition]; Result [evidence]; Next action [owner and review date]. Duplicate solution branches only under the opportunity you are actively exploring.
Teresa Torres provides editable templates for common whiteboard tools in her guide. Use a familiar tool and keep the evidence links beside the nodes. Update the tree when a new story changes the problem, a test contradicts an assumption, or the outcome changes. A smaller tree with a current decision is more useful than a polished map no one can explain.