What it is and why you need it

We’ve all been there. An ideas fest of some description where someone has a bit more sway than others: they are a little louder or a little more senior. It’s annoying, but it’s their ideas that seem to carry the most weight.

Everybody shuts up after they talk, even if the idea is not well founded, misaligned with what the team is trying to achieve, or others have put forward better ideas.
Not only does it leave everyone else in the room feeling disengaged and deflated, it frequently leads to poor outcomes for the team and organisation they’re part of.

Facilitators of gatherings like this need techniques in their kit bag; trusted tools they can pull out with the timing of a seasoned tradie. One of the tools I’ve found useful to use when countering the ‘dominant contributor’ scenario outlined above, is the Opportunity Solution Tree, or OST (please, can someone come up with a name that is less of a mouthful!).

Recently I’ve been applying this to help product teams within digital businesses, where I’ve been in the role of a product manager or product coach, but I think it is transferable across a bunch of domains.

What is it? Where did it come from?

As much as I would like to, I can’t claim the OST framework as my own. That honour goes to Teresa Torres, and you can read more about her description of it here. In this post, Teresa goes into much more detail about the origins and theory behind the model than I do in this article.

The OST falls into the category of tools that encourage structured thinking. There are a bunch of these in use, value-stream mapping and the Organisation Leadership Architecture being a couple of examples.

What is particularly useful about the OST is that it enables us to visually represent what is happening in our heads when we are trying to determine what to work on. It also helps us get some distance between ourselves and our solution ideas so that we can have better discussions about the best thing to work on.

Teresa talks specifically about four gaps the OST helps fill:

  1. Not examining our ideas before investing in them
  2. Not considering enough ideas
  3. Not multi-tracking ideas in a systematic way
  4. Avoiding solutions that do not connect to what we are focused on achieving

In my experience, I’ve found the following also to be the strengths of this approach:

  • The visual linking of one goal (desired outcome) all the way through to solutions
  • Encouraging everyone to contribute ideas that are aligned with the goal
  • Abstracting a solution idea to an opportunity, and using the identified opportunity as a way to generate more solution ideas
  • Focusing people on compare and contrast decisions when selecting the best ideas
  • Keeping a record of discussions, and the reasons why one opportunity or solution was chosen over another

What does it look like?

Here is a mocked up example I have created. I would love to show you one that I have put together with a client, but understandably, most clients like to keep these from the eyes of those outside their organisation. Each tree represents so much thinking, research, experimentation and learning that it becomes a competitive advantage they don’t want to pass off quickly to others.

So, given that, I hope you get some value from this example (it’s small, but I’ll draw out the sections as we go):

Mocked up example of the Opportunity Solution Tree

Mocked up example of the Opportunity Solution Tree

Here is a description of each of the elements:

  • Desired Outcome (DO): What we want to achieve
  • Opportunities (O): The reason for a solution; one direction that could help fulfil the desired outcome
  •  Solutions (S): What we will create or do; a way of implementing the opportunity
  • Experiments (E): Ways a solution will be tested (not included in the example)

Given these are the different components, I propose renaming the OST to DOOSE, or DOOSET, but as I mentioned, please let me know if you can do any better. If this thing is going to catch on, we need something as catchy as ‘lean canvas’, ‘build-measure-learn’, or ‘feedback sandwich’.

Now, let me take you through the flow of a typical Doose workshop.

The Doose workshop

Step 1: The team or leader picks the desired outcome

Step 1: The team or leader picks the desired outcome

The most important thing to be clear on is the Desired Outcome. Selecting this and deciding how it’s success will be determined is probably a long story/workshop/blog post in itself. Suffice to say for this post, having something that is concise, measurable, important for the business, and unambiguously understood by everyone is crucial.

Ideally, it is the most important thing for a team to influence right now. These can be generated from things like a team vision, an OKR, or pirate metrics.

If this isn’t done, cancel the meeting and go back to your desk to work it out. The potential for doing a whole lot of thinking and then a whole lot of work that is unhelpful for the organisation is way too high to continue the workshop without it.

Step 2: Generate opportunities for achieving this desired outcome

Step 2: Generate opportunities for achieving this desired outcome

Opportunities may come from people’s imaginations, but they need to be backed by data and research. This could be a contextual inquiry, data analysis, customer support calls or some other research source.

Sometimes opportunities are grouped under a broader opportunity heading to give clarity and to help us create more sub-opportunities.

Opportunities can also be generated from a solution. To do this, reframe the problem that the solution is solving. This makes explicit the problem framing the solution and allows us to generate alternative solutions.

Once a team has listed and grouped our opportunities, we make decisions about which is best by contrasting and comparing each one against the other. As winners and losers are picked, I typically document the reasons why this was the case on the tree (e.g. lost out due to technical complexity; selected because 80% of users requested this). The tree becomes pruned, enabling us to focus on developing further the opportunity branch that has won.

Step 3: Brainstorm solutions for the opportunity we select

Solutions for opportunities come from everyone in the workshop, and sometimes from those outside the workshop if you’ve asked them beforehand. Each idea is put on the board and linked to the opportunity it relates to. If a solution idea does not connect to an opportunity, it may be that a new opportunity needs to be articulated, or the solution idea discarded as it is not one that can help us impact our desired outcome.

Once the ideas are added to the tree, again the team can go through a compare and contrast exercise to determine which solution ideas are our best ideas. This could be through dot voting or something similar.

Step 4: Create experiments for the top three solution ideas

At this point, it has been decided which of the solution ideas have the best chance of helping the team achieve the desired outcome. If there is more than one idea the team thinks is a good candidate at this point, it is time to craft experiments that can run to determine which of the solutions is the best option. Ideally, these are run over a short time frame so that the best option can be selected and implemented with minimal delay.

If the solution ideas are small enough, it is probably low risk to implement them and observe the impact. The team may still craft an experiment for this so they are intentional about learning from the results.

Wrapping it all up

So there it is. A structured thinking tool to try out at your next product planning meeting. It can take a few tries to get into the swing of it, but as you get into the flow of it you will get contributions to solutions from all members of your team, and ideas that clearly link to the outcome you are focusing on.

As always, I am keen to hear your questions, your doubts, and any experience you have in putting this into practice.