My Journey Using the Opportunity-Solution Tree

I've been a fan of Teresa Torres since I discovered her ProductTalk website, and one of the things that caught my attention was the curriculum she uses to help teams to structure their discovery process in order to solve customer needs / pains while achieving a business outcome.

Among all the dynamics, activities, tools referenced on her website, the Opportunity-Solution tree (OST), is a great way to put a mental representation that teams can leverage upon to achieve a certain outcome.

I came across recently with the chance to fully tested with a team within a bank and I would love to share my learnings and riffs I've tried with the aim of helping this team.

Things to keep in mind:

• The team involved in this activity is not a Product Team. It's a discipline that is in charge of achieving a certain outcome (which was compelling enough to use the OST)
• The team had no idea about concepts like Outcome / Opportunity / Experiments whatsoever
• The only thing they had done so far, was to market research about which tools provide which capabilities, a.k.a solution they want to implement
• Their main goal was to find a compelling case (pitch) to raise money for the upcoming three monts

Setting the Stage

A couple of days ago I've publish the following picture that encapsulates a variation on how I intended to use the OST:

Some people asked me, why I've added things like Purpose, Business Problem, Lagging and Leading Indicators.

I want you to imagine that you get into a room with a group of people eagerly ready to find the shiny gem that will help to obtain money for the next three months and work on something, and they come to you and say, "Fede we have tons of tools within the bank to help us achieve our [non-yet-validated] idea".

So with that scenario in mind, I've decided to go several steps back, and ask them. What do you do within the bank? Why is that important?

You wouldn't be surprised that all them had to dig into their laptops and several decks we have used to answer that questions. Furthermore when I asked them to write it down individually, the results where different, and there were shown How (Solution) they think they can do it.

So for that reason, I've decided to use the Nine Whys activity from Liberating Structures to frame the main purpose of this team.

Be more like doctors and less like waiters

Right after the purpose was clear to every person (even myself) on why on earth this team exists, they kept talking about the solution they should implement, based on its brand new purpose.

I recall the workshop with Jeff Patton where he says “When I behave like a waiter, a customer tells me what they want and I need to work it out and get it to them. A doctor’s job is to solve your problems, not do what you want.”

I wasn't sure whether the team really knew what was problem they were trying to solve. I asked them, "Hey guys, could you tell me what problem we are solving to the customers out there?, if there is any". I was shocked when the answer I heard was "We are not capturing valuable insights with the interactions we have with our customers. That that will allow us to offer better products". You see what's wrong here. First and foremost, the customer is still a mirage and even worst they were seeing everything from the bank standpoint. At this stage the most important thing was the "valuable insights".

Long story short, we have spent almost an hour digging into the problem space, breaking the previous statement down into a series of questions and thanks to the help of LeanUX business problem statement template, I've created my own to focus on the customer pains and current gaps. It came out like this:

As of today our [product / service / experience] is not considering [gap] which is causing [pain points]. In order to improve our [product / service / experience] we should focus on [issue] with the aim of achieving our [goal] measured by [measurable criteria]

The team came to the conclusion that there were more problems than time to spend addressing them - that's the reason in the picture I've depicted more than 1 Business Problem circle - so armed with knowledge they have decided to focus on one particular problem that is aligned with both, their purpose and with the bank strategy. I love the balancing act of deciding on which problem devoting all the energy.

Why the bank should invest in this?

Now we have a clearer picture in mind (purpose, business problem, strategy) it was the time to understand what was the benefit the bank could potentially obtain if we start working on that business problem.

Frankly speaking, this was not a "big problem", the team was pretty aware what the bank wanted. The great realization was to understand that the ultimate outcome of "Increasing Sales" was something they cannot achieve by themselves.

Therefore I thought it was appropriate to introduce the concept of lagging and leading indicators (at Amplitude they call them Input Metrics, and at Netflix 'Proxy Metrics') to clarify what was on the realm of the team.

They understood they needed some sort of strategy items and leading indicators to know whether they were close enough the reach the business outcome and the lagging indicator.

So at this point based on the Business Outcome and Lagging Indicator we have posed the following questions to the team: "What is the behaviour we should see and what would the best way to measure it?"

Much of the things that started to emerge where still focused on the solution, for instance "the operator is able to identify certain gaps in the conversation to offer the cliente the best product" rather than "the customer is hiring more products from us" or "the customer is calling proactively to renew his insurance policy which is about to expire". Worth to mention is we have never interrupted the team while they were brainstorming, after they were finished we reflected whether the things were on the right path.

Wearing the customer shoes

It was time again to walk a mile in the customer shoes. I found this was the most difficult thing along with stating the business problem the team faced.

This is something we have iterated and they were stuck thinking as an "operator responding a call" rather than "being the customer making that call". In order to ease this step, I noticed they were talking about different "use cases" they have been talking and analyzing in advance. So I decided to brainstorm, based on the previous outcomes, different use cases and role play them to pinpoint the opportunity, as a customer, we were letting go.

Very interesting things resulted from this role play, for instance, "I need a loan for my son's MBA and I don't know where I'm going to get the money", "My insurance polity is about to expire and I'll be illegally driving my car", "I don't know what to do with my money because my actual bank is not giving me the service I need" and so on...

It was very useful listing several use cases to understand the customer problem space / needs. It worked like a reverse engineering exercise.

Shoot me with a solution

As you may imagine, the initial solutions the team were proposing at the beginning of the article (tools and more tools), might resurface at this point in the workshop.

Surprisingly, they didn't mention any tool at all, I don't know whether it was the conversations and how they were deeply engaged with the problem and opportunities, but the solutions were fairly simple and straightforward.

Simultaneously we were repeating that the solution was not something we know it was going to work for sure. In the best-case scenario it's something we will have to validate and potentially the customer behaviour changes, the leading indicator will move and ultimately the lagging indicator will be achieved.

We did this, because we want to create solutions at the same time they start thinking which was the cheapest and fastest way to test the solution was the good one. Yes we were getting them into the experiment space. As soon they have a solution we didn't give them any time to fall in love with it. We said "if you think in a solution, what is the way to are going to test this is the way to go".

Wrapping up

I've had a great time in the hours we spent with this team. It was worth it every second. Before we finished the 2nd day, they affirmed they were more prepared and equipped to start working on the experiments to showcase their results and raise money to build an MVP, may be using some specific tool.

This is a summary after the session we created to reflect the ideas and outputs that came throughout the workshop.

I completely agree with Teresa's words when she says this is something that the team can use from now on, to explore the customer space, and they don't need much help. In fact, another business outcome surged during the 2 days and they felt pretty confident they can run the same exercise.

Key Takeaways

• Sometimes you must adapt the tools to your own context / environment - Don't be afraid of doing that, the team can benefit from that change
• Be ready to use the Experiment Design Template when creating experiments - The process of experimenting can be derailed if you are not taking it seriously
• If you're not working with a product team, framing certain aspects like Purpose / Business Problem / Strategy pay off
• Solution might become the main topic during the conversation, slowly and gently point the conversation towards the problem first. It's not easy, but you will be doing the team a favour saving up money and time.

I want to thank Hope Gurion for the idea of writing this case so anyone can take this iteration and adapt it to their own case.