Soon into my new role as Chief Product Officer at Zava - a leading European health-tech startup - I realised we had a problem with Product Discovery. Our product teams were smart and committed, but they were struggling to tie team objectives and key results to research insights, ideas and the day to day work of the squad.
After asking around, Marty Cagan and two others recommended Teresa Torres. After checking out her blog and having a few calls to discuss her team coaching offering we brought her on to coach two of our squads in Product Discovery through a mixture of face-to-face coaching, exercises and online learning.
Having now used them for around 3 years I'd like to share a short guide to using them effectively.
Opportunity Solution Trees are visual tool to help teams develop a mental representation for product discovery. It was developed by Teresa Torres, an experienced product discovery coach and outlined in a blog post in 2016.
I like to define them as follows:
A visual tool that helps product teams follow rigorous product discovery techniques and ensures solutions built deliver outcomes
Opportunity-solution trees have four basic, connected components connected as follows:
A quantifiable measure of success for the team.
Problems, needs, desires and pain points you've identified through customer research and analysis.
Potential solutions you could build that exploit an opportunity in a way that delivers the outcome
Activities the team runs to test key assumptions
To build your opportunity solution tree, follow these 8 steps:
Step 1: Define a clear product outcome
Step 2: Map customer opportunities to your outcome that you've identified in your research
Step 4: Pick one or two opportunities to focus on
Step 5: Generate solutions with your product team to exploit the selected opportunities
Step 6: Surface and prioritise assumptions to test for each of your solutions
Step 7: Run experiments to test assumptions and compare/contrast potential solutions
Step 8: Repeat until you discover a solution that delivers your outcome
Shared understanding amongst team members is crucial for effective product discovery. When built collaboratively, OSTs act as an easy-to-understand visual guide to the discovery work of the team.
Unlike documents or wikis, having the tree on a physical or virtual 'space' is easier for the brain to process and 'connect the dots'.
Some product teams struggle to explain clearly how what they're doing in product discovery connects to the objectives they've been asked to work towards. This applies to stakeholder conversations and conversations within the team.
The OST makes that easy. As each experiment is visually connected to the outcome it's easy to explain, understand and discuss the work.
Product teams often fall into 2 common thinking traps:
Whilst still possible, this is harder to do when work is oriented around an Opportunity Solution Tree. You can instantly spot if a single solution has been generated for a particular opportunity or if there are no experiments associated with a solution.
Many traditional organisations measure teams' success by how much output they have, rather than the the impact they have on the business. Although outputs are important and fast shipping is critically important for effective product teams, blindly delivering outputs without defining outcomes is a slow, painful route to waste and failure.
A better approach is for product teams to focus on ensuring that their outputs deliver outcomes.
Opportunity-solution trees help by ensuring that outputs are validated through product discovery work.
Now you know what they are how do you make them work?
Opportunity solution trees don't work without product outcomes. The tree makes no sense at all if a teams isn't using it to drive towards an outcome - that's the whole point.
I've also seen product teams struggle when an outcome is poorly framed. One team I was working with had an objective that was akin to "grow company revenue" - an objective so broadly framed (and lagging) it would have resulted in an enormous tree.
When advising teams on product outcomes, I recommend checking they have the following criteria:
There is little more demotivating for a product team than to be told to go and build someone else's ideas. It's also a horrendous waste of human energy, talent and company resources. Yet this often happens.
If you're on a product team and introducing opportunity-solution trees for the first time, it's 100% OK to bring ideas to the table - but make sure you do the construction of the tree with the team the first time, rather than on their behalf.
Even if you end up pursuing an opportunity and set of solutions along lines you originally envisaged, you'll get a huge energy and motivation boost if the team understand and are bought into the direction.
The most successful product teams I've worked with have developed high trust with peers, senior managers and execs. One of the most effective ways I've seen them develop that trust is by explaining their thinking, asking for feedback and genuinely taking it into consideration.
Proactively scheduling a session to walk through an OST is a great way of facilitating that sort of conversation.
As your team progresses with experiments, you'll discover things that work and don't work. A nice twist I've seen a few teams deploy is colour coding results. Deploying a little red and green to distinguish between experiments that have been successful and unsuccessful can give a near-instant clue as to what's working and what isn't.
The work you'll come up with in when developing your tree doesn't happen in isolation from other parts of your process. Depending on how you work, there are likely multiple areas where the work you do using your tree directly links to other areas of your process.
Here are a few examples:
I'd recommend synchronising your internal processes to the work you do in your tree so it becomes a core part of how your teams works instead of "yet another" thing for a team to do.
Occasionally, product teams don't have a PM, Tech Lead and Designer. If it's a PM and Designer, this is sometimes justified as "getting ahead of the engineers" or saving precious engineering time. Unfortunately, it's a false economy and I've never seen it. The reality of discovery is you need the combination of all 3 skillsets to ensure solutions generated are valuable, feasible, usable and viable. So, if you don't have a minimum of a Tech Lead, a Product Manager and a Designer on your team, pause and sort that first.
Occasionally product teams fall victim to magical thinking after discovering and getting excited about a new tool or technique. It's important to remember that opportunity-solution trees are just another tool. They are not the work itself, and they aren't the only tool you'll need to use from your discovery toolbox. Remember to engage your brain, adapt it to suit your purposes - and use it in the appropriate context.
If you're wanting to read more about OS Trees, I'd highly recommend reading Theresa Torres' blog - producttalk.org or employing her services. I doubt you'll regret it.