The importance of discovering solutions beyond opportunities - Our learnings with the Opportunity Solution tree
For a while now many of Hemnet’s product teams are working with continuous discovery techniques like Teresa Torres’ opportunity solution tree. What I really like about the framework is its simple visual design, making it really clear how the work every product team is doing, clearly connects to a specific customer opportunity which in its turn connects to a business metric.
Working with this framework has been really beneficial for many of our teams in many ways. It clearly connects and visualizes which opportunities best align with the product strategy, and therefore we should pursue. And it also forced us to be much more proactive in talking with our target groups. But, there is a but..
One thing that I believe we have not nailed yet while working with continuous discovery is how to decide which opportunity to pick, and for how long we should work on it.
Once you have it all mapped up: how do you decide where to start and when do you decide to stop?
I have been thinking about what is the root cause of it, and why is it so difficult to decide where to start and decide when to stop? And I couldn’t really put a finger on it, until the other day I had a eureka moment while looking at this interview with Steve Jobs.
Around minute 32 Jobs really condenses the very heart of what I was trying to articulate when he says
”Many people think that great ideas are 90% of the work. While there is a tremendous amount of work between a great idea and a great product. Designing a product is keeping 5000 things in your brain and keep them together, and fit them together in a new way. It is the process where the magic is.”
<It is the process where the magic is> this sentence made me see things in another light.
Jobs really puts a finger on continuous discovery of solutions and not only of opportunities. Which was really a mind-shift to me. In an opportunity solution tree, you should start with an opportunity, but spend at least double the amount of time on the solution side of the tree. Unless you realize it was the wrong opportunity to pursue, then you should start the process again.
When I think about our experience that totally makes sense. Starting to formulate ideas as opportunities was challenging at the beginning, but once we started to build our trees, it has been quite easy to populate them with ideas and data, but the real question has become: how do you choose between all the different opportunities? And once you put your eyes on one, how do you make sure that you stay with it long enough?
The real issue is rarely coming up with an idea, and even picking one could be done in a fairly easy way by combining product strategy, opportunity size, stakeholders’ inputs, data, and a bit of blind trust. But committing to executing a solution long enough, has been hard for the majority of teams I have been working with.
When thinking about it, I came to realize that this common pattern is a combination of 2 factors:
Keep on betting on improving one solution might feel counter-intuitive when the first solution already does its job
Optimizing for a short-time goal for a solution that has a longer adoption and takes time
I’ll explain a bit more what I mean with both.
How the Opportunity solution tree can clearly connects strategy and OKRs
Compare and contrast to find the right solution
Looking back at our journey with the opportunity solution tree, one of the biggest learnings for me has been that we have never regretted comparing and contrasting different solutions to an opportunity. Every time we did that, we learned something and the final solution we delivered was better. Every.Single.Time.
But understanding that we needed to put the extra time into comparing and contrasting different solutions, either with prototypes, user interviews, or actually different variations live, has been and still is a journey. One of the causes for us might be that our opportunity solution tree has a built-in FOMO: oh, so many different opportunities we could pursue.
We got such gigantic trees that could really live in a national park as millenary oaks, for all the branches that they have, and therefore choosing to keep on digging deeper in one single opportunity once the first solution is working fine, is a bit painful.
This is because, indirectly, you are actively choosing to not look into all the many other opportunities you have lined up in front of you. But as I always advocate ”focus is to say no to good opportunities, not to bad ones”, and with the opportunity solution tree is even more important to go back to that mantra.
One stunning real-life example of this is the work that one of our team is doing with content recommendations. The final goal is to improve user engagement, and content recommendations are the opportunity the team decided to pursue. Still, no matter the vast number of opportunities in front of them, the team had the guts and the perseverance of testing multiple different recommendations contexts. They spent one quarter comparing and contrasting, even if the very first context they picked worked well. The result? By comparing and contrasting solutions, we got to an even better outcome.
One example of comparing and contrasting opportunities, with learnings from the team
This is not easy to do though, and not only because of FOMO but also because of the sometimes contrasting goals between short-term goals and the very nature of behavioral change: it takes time. This brings me to the second piece of the puzzle…
Having short-time goals can be risky when the product takes time
As a product leader, I can’t not think about what is the role I play in creating a culture where teams want to jump from one opportunity to the other. There is definitely the human factor I described above, but I believe that another important component is connected to goal-setting.
What I observed is that short-time goals, like the quarterly OKRs we are using, for example, might be deleterious for teams that are working with opportunities that require behavioral changes, because those take time.
I honestly never saw a behavioral change that was executed and brought results within a quarter. Yet, putting quarterly goals on a product team will push them to have an even higher pressure on focusing on short-term wins and a lower inclination on dedicating a lot of time on discovering different solutions.
Striking the right balance of goal-setting, product adoption, and clear leading indicators for product success or failure is the nut I am trying to crack right now. My working hypothesis is to set a 6-month product goal for the opportunity the team wants to pursue, as well as define clear success/exit metrics that should be leading indicators we can look at more regularly. Has anyone tested something similar and is willing to share their learnings?
