Framework library · Innovation and product
Opportunity solution tree
An opportunity solution tree starts from a measurable outcome and branches into opportunities: the needs, pain points and desires found by talking to customers. Each opportunity branches into candidate solutions, and each solution into the tests that would show whether it works. The tree makes a team choose between opportunities before it chooses solutions, and shows why each piece of work is being done.
Use it when
- A team has been given an outcome to move, such as lower churn or higher take-up, rather than a list of features to build.
- Ideas are arriving faster than the team can test them, and it is unclear which customer need each one serves.
- Stakeholders keep proposing solutions and you need to show where each fits and what it would have to beat.
- The team is talking to customers every week and needs somewhere to put what it learns.
Avoid it when
- There is no measurable outcome yet. Agree one first, for example through OKRs or a north star metric.
- The work is fixed by regulation or a contract and the only question is how to deliver it. Use a project plan.
- Nobody is talking to customers. A tree of opportunities invented in a meeting room only rearranges the team's assumptions.
- You need to break down a business problem rather than a customer one, such as falling margin. Use an issue tree.
How to run it
Put one measurable outcome at the root
An outcome the product team can influence, with a number and a date: "cut 60-day returns from 14% to 8% by June", not "grow the business".
Map opportunities from customer interviews
Needs, pain points and desires in the customer's words, grouped where they overlap. An opportunity is a problem to solve, not a feature request.
Choose a target opportunity
Compare opportunities by how many customers have them, how much they matter and how far they would move the outcome. Work on one at a time.
Generate several solutions for it
At least three, so the team compares ideas instead of falling for the first one. Each sits under the opportunity it addresses.
Add a test under each solution
Find the assumption each solution depends on and the quickest test of it: a prototype, a one-question survey, a trial with a few customers.
Update the tree as results come in
Prune solutions that fail, move to the next opportunity when the outcome stops moving, and keep the tree visible to stakeholders.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Writing solutions as opportunities ("customers need an app"). If it can be built, it is a solution.
- Choosing an outcome the team cannot influence, such as total company revenue, so the tree cannot be tested against it.
- Testing only one solution per opportunity, which turns discovery back into delivery of the first idea.
- Letting the tree go stale. A tree that is not updated after each round of interviews soon describes last quarter's customer.
Where it comes from
Developed by Teresa Torres, who first described the tree on her Product Talk blog in 2016 and set it out in Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value (2021). Source.
Use it with
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.