Product in Practice: Getting Started with Opportunity Solution Trees at SuperAwesome

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

Hi there, Product Talk readers! It’s me, Melissa. I’m Teresa’s blog editor. I mostly work behind the scenes here, polishing and proofreading posts prior to publication. But every once in a while, I’ll contribute a post like this one.

Here at Product Talk, we’re excited about showcasing what good product management looks like. That’s why we recently launched the Product in Practice series, where we’re highlighting excellent work that different product teams are doing.

At Product Talk, we recently launched the Product in Practice series where we’re highlighting excellent work that different product teams are doing. Check out our latest post here! – Tweet This

Did you miss the first post in this series? Check out our interview with Rachel Allen, Director of Product at Omnitracs.

For today’s post, we sat down with Chris Hockley, an agile delivery manager and lean agile coach at SuperAwesome. Chris shared the story of how he introduced the opportunity solution tree to several teams at his company and a few of the iterations that helped make the tree an indispensable tool at SuperAwesome. We love stories like this one that showcase how different teams adopt the opportunity solution tree to fit their needs, and we hope you find it as inspiring as we do.

Have your own Product in Practice story that you’d like to share? Submit your story here.

Chris Hockley of SuperAwesome

Meet Chris Hockley. He works at SuperAwesome, a UK-based company that develops tools and services to make the internet safer for kids. In his cross-functional role, Chris coaches individuals and teams and facilitates discovery sessions and workshops.

SuperAwesome is a UK-based company that develops tools and services that make the internet safer for kids.

SuperAwesome has been working toward having a more structured and process-driven way of approaching product discovery, which led Chris to research continuous discovery. After reading a few articles on Product Talk, he came across the opportunity solution tree. Chris says, “It instantly jumped out at me as something that could be useful to our teams; I was already having discussions with one of our product managers around ways to make sense of the unstructured backlog of ideas that the team had put together to deliver on their OKRs.”

One of the things that appealed to Chris was how the opportunity solution tree would create a visual representation of the work the product teams were doing: “The opportunity solution tree provides a great way to visualize the relationships between the team’s ideas and the outcomes they are trying to realize.”

The opportunity solution tree provides a great way to visualize the relationships between the team’s ideas and the outcomes they are trying to realize. – Tweet This

In this post, we’ll explore how Chris rolled out the opportunity solution tree across several teams at SuperAwesome. How did he do it? What did he learn from the process? What might this mean for you and your teams?

First Impressions: A Staggered Rollout of the Opportunity Solution Tree

The opportunity solution tree provides a visual framework for thinking through decision-making.

Seeing potential in the opportunity solution tree for various product teams at SuperAwesome, Chris decided to introduce it in a staggered manner, starting with a team that had already been looking for a way to structure their thinking around discovery.

Next, he introduced the tree to another team that was working on a fairly new product. They found the tree to be a very effective way to plan their initial discovery and experimentation.

According to Chris, the tree was well received across both teams. They’ve found it enables the whole team to be involved in the discovery planning process and keeps everyone on the same page. At the same time, it prevents teams from jumping into solutions too quickly before considering the opportunity that is being addressed.

Using the opportunity solution tree prevents teams from jumping into solutions too quickly before considering the opportunity that is being addressed. – Tweet This

One of Chris’s biggest takeaways from this experience? The importance of introducing the tree to one team at a time rather than trying to roll it out across multiple teams simultaneously.

Chris recommends taking the time to run a session with each team separately to help them see how the tree can be applied to their specific product. “It can be quite difficult for product teams to see the value in this tool from an abstract explanation,” explains Chris. “However, by applying the framework and using real-world examples we have found that teams quickly start to see the value it provides, and how it might be adapted to suit their needs.”

Chris would start with one of the product KPIs that a team was actively looking to improve and set it as the outcome for the exercise. Using a collaborative whiteboard, he’d draw the diagram of the opportunity solution tree, working his way down and explaining the concepts at each level. He recommends preparing some example ideas for each level of the tree to stimulate thinking and get the discussion going.

Another important lesson from Chris: As the team starts generating ideas of their own, it’s important to help guide the categorization so that opportunities and solutions are correctly identified. You may find that the discussion begins to stray from opportunities into solutions or vice versa. Chris says, “When this does happen, I would usually capture the idea on the board under the relevant section so it is not forgotten or seemingly dismissed, but then gently bring the team back to focusing on the section of the tree that we were working on.” This approach helped reinforce the meaning behind the different concepts, especially between opportunities and solutions.

When the discussion strays from opportunities into solutions and vice versa, capture the idea in the appropriate section of the opportunity solution tree so it’s not forgotten or seemingly dismissed. – Tweet This

Getting Stuck: Learning to Run Iterative Experiments

Question: How many experiments are realistic to run during one sprint? Answer: It depends who you ask! At least that was what Chris discovered with one of the product teams he was working with.

Chris had set a target for the number of experiments each team should be running during each sprint. He believed this was a conservative target, so he was surprised when he received pushback from one of the product managers. As Chris and the product manager discussed the topic in more detail, it became clear that the team was defining experiments that tested the solution as a whole against the desired outcome.

Chris says, “This invariably meant building and delivering the solution into production and running an A/B test to test the solution. As a result, each experiment took far too long to prepare and run and only gave us limited insights into the success of the solution whilst telling us nothing about why the solution was successful or not.” And, of course, this meant a lot of work was completed before the team had any data to validate whether the solution in question was the correct one to build.

Running this kind of experiment was far too time-consuming to be the only test they ran for a given solution. Chris believed that it should have been the final test to confirm the validity of a solution following a series of shorter experiments carried out during discovery.

Realizing he needed a way to encourage the teams to run quicker, cheaper experiments without building too much, Chris came to the conclusion that they were skipping an essential part of the thought process: their assumptions. He encouraged the teams to break their solutions down into the underlying assumptions that needed to be true in order for those solutions to be viable.

Your team may need support and training to break their solutions down into underlying assumptions. Considering value, usability, and feasibility risks can help. – Tweet This

The Aha Moment: Remembering to Uncover Hidden Assumptions

Chris had previously run a workshop on how to break down solutions into assumptions. In this workshop, he’d help teams consider everything that needs to be true in order for a solution to work. The workshop focuses on the following four areas of risk:

1.  Value risk

Value risk considers whether the solution meets a specific need of users, as defined by the opportunity, and whether it will drive the desired outcome as a result. For example, you might assume that a change will increase sign-up conversion because it enables the user to verify their identity in a way that is readily available to them and doesn’t feel too intrusive. These assumptions could then be tested through a survey or some form of user testing.

2.  Usability risk

Usability risk assesses whether users understand and can use the solution. For example, you might assume that a verification method can easily be understood and that the instructional copy at each stage is unambiguous. These assumptions could then be tested through user testing or through an A/B test in the case of any copy changes.

3.  Feasibility risk

Feasibility risk examines whether you can build the solution. For example, you might assume that the technology exists for a specific verification method and that it is accurate enough to be a viable solution. These assumptions could then be tested through some research into the technology or through a proof of concept where existing data is not readily available for a particular technology.

4.  Business risk

Business risk considers whether stakeholders support the solution. For example, you might assume that the solution aligns with the wider vision of the company and that there are no legal issues. These assumptions could then be tested through stakeholder conversations or a discussion with the legal team where required.

Chris explains, “By breaking the solution down into multiple underlying assumptions, we are effectively setting ourselves learning objectives that will broaden our understanding of the opportunity, any potential solutions, as well as the behavior of our users.”

By breaking the solution down into underlying assumptions, we are setting ourselves learning objectives that will broaden our understanding of the opportunity, potential solutions, and our users. – Tweet This

Chris saw an opportunity to create a process for the teams to go through when considering potential solutions. He met with product managers to consider how they could ensure this approach was followed across different product teams.

These discussions led Chris and the product managers to a critical decision: They would experiment with adding a new section for assumptions to the opportunity solution tree between solutions and experiments. This section prompted the teams to break down their solutions and look at how they would test these specific assumptions rather than the solution as a whole.

Introducing an “assumptions” section to the opportunity solution tree can prompt teams to consider their assumptions and look for ways to test these rather than the solution as a whole. – Tweet This

An example of how the product teams at SuperAwesome break down a solution into the underlying assumptions and record whether ideas have been validated or invalidated through experiments.

Additionally, Chris and the teams he works with have made a few iterations on the opportunity solution tree. They’ve added a section for results after the experiments section in order to capture what they learn from their experiments. Chris says, “This, combined with the approach of color-coding validated and invalidated nodes on the tree, allows anyone to look at the tree and gain an understanding of why certain product decisions have been made with an overview of the data that has driven the decision.”

What Continuous Discovery Looks Like at SuperAwesome Today

At SuperAwesome, teams are now approaching experimentation by testing the assumptions underpinning a solution rather than the solution itself. They’re looking for ways to gain insights and gather data with minimal development work wherever possible.

SuperAwesome’s adaptation of the opportunity solution tree, with additional nodes for assumptions and experiment results.

For example, now they might add a fake door into their product (a button for a feature that doesn’t exist yet but instead leads to a page that explains this and thanks the user for registering their interest by pressing the button). This quantifies the interest in a feature before making the decision to implement the full functionality of the feature.

Now the product teams at SuperAwesome regularly use opportunity solution trees to guide their work and capture experiment results.

Chris also shares that use of the assumptions section has already resulted in a three-fold increase in the number of experiments they are running each sprint, allowing them to test and learn much more rapidly.

Chris’s story offers a practical approach to rolling out a new tool or process. If you feel daunted by the task of introducing the opportunity solution tree to your entire organization, consider how you might introduce it incrementally with the most receptive team first. And remember that the opportunity solution tree isn’t a static tool—it can be adapted to fit each team’s needs and challenges. Don’t be afraid to keep iterating until you find a version that works for you.

The opportunity solution tree isn’t a static tool—it can be adapted to fit each team’s needs and challenges. Don’t be afraid to keep iterating until you find a version that works for you. – Tweet This

Do you have a story of how you’ve used or iterated on the opportunity solution tree? We’d love to hear it. Leave us a comment here and we may end up featuring your story in a future post!