Follow us on LinkedIn'Roadmap' is a pretty controversial word in tech jargon. Basically, everyone agrees that we should have one — but no one agrees on what it actually is.
Executives usually want the roadmap to predict the future like those good old crystal orbs: they want to see Gantt charts and day-by-day progress and to know “When that new product is going to be released”.
Things get even more confusing when you throw OKRs into the mix: What is the relationship between OKRs and roadmaps? Should you choose one? Which should come from who? Is there any rational way to reconcile the two? Does a product team need both?
The two are more intertwined than one might think, but there are many modern models that enable us to use the best of both — I have been using Teresa Torres’s Opportunity Solution Tree described in Continuous Discovery Habits for a few iterations, and I am very satisfied with the result.
This is a summary of what we did and how and the mechanisms by which it improved our team’s productivity and outcome, focusing specifically on:
Let’s begin with a question as old as modern product management...
Roadmaps vs OKRs
Traditionally, the roadmap was a prioritized list of features with due dates and deadlines that were to be built by the technical team.
It was a solution-based approach to define the tasks that needed to be done. Now while the concept of a roadmap has changed a lot by the lean movement, it is still solution-based: any document labeled “roadmap” is one filled with solutions and maybe some fuzzy deadlines.
OKRs on the other hand, are a problem-based approach to define the tasks that should be done. When we talk about Objectives and Key Results, we want to define which problems are best to work on, somewhat independent of what the best solution is.
One can easily see that the best way to reconcile the two is to put OKRs first, dig up solutions that address both customer needs and business requirements and then put them in a document labeled the roadmap.
There are quite a few models around that aspire to do just that. One of the best I’ve tried is the Opportunity Solution Tree (OST).
Teresa Torres’s Opportunity Solution Tree
Described in the fantastic read Continuous Discovery Habits, the Opportunity Solution Tree is a structured approach to build the right thing in the right way:
The business objective, usually translated to a key result, is our first step. We start here and conduct research about the customer problems which when solved, will result in the business objective.
Imagine something like “Get the customer 30-day retention rate up to 30%” for an e-commerce product. we start here and ask questions such as:
- Why do customers NOT return after 30 days?
- What do customers remember about our product after 30 days?
- How do customers feel about our product after their first month?
- What is the difference between a 1-week customer and a +30-day customer?
Here, our tools are customer interviews, surveys, demand tests, and data analysis, and our output is the opportunity space (Or the problem space in Dan Olsen’s Lean Product Playbook Terminology).
The opportunity space is a list of customer problems prioritized with respect to their share of the business objective. For our customer retention example, imagine that seven out of ten customers churn after 30 days because packages get delivered when it’s inconvenient for them (either they are not at home, are in a meeting, and …).
This means if we deliver 100% of the packages when it’s convenient for the customer, we will have made 70% progress in our business objective. Essentially what we do is traverse the Objective Space to Opportunity Space:
Moving down the tree, we arrive at the solution space. There are many ways to solve a product problem, which is why Torres herself calls them “ill-structured problems”. Here we hypothesize, conduct competitive intelligence and benchmark against rivals, design, use design sprints and etc. to come up with possible solutions.
The complete set of solutions for a custo5rmer problem is the solution space. For our convenience in delivery problems, maybe we should use a progress bar showing the different delivery stages and notify the customer via text message an hour before delivery.
Or rather, use push notification for notifying? Maybe we should call them one day before and ask for a convenient time? Perhaps we should have a default delivering time (e.g. 9 AM), or hold on to the package until the customer chooses a convenient time in our product? Should we give the customer the ability to delay delivery?
These are all seemingly viable solutions but usually, we shoot for one with the lowest time to money and highest conversion. We do some research and choose a handful to test against one another if we are not sure about one, which brings us our last branch, Test space.
No matter which solution we choose, we must be able to test its performance in some way. Borrowing from Marty Cagan’s iconic book Inspired: How to Create Tech Products that Customers Love, We must address four principal risks with our test solution:
- Value Risk (Does the customer want it?)
- Usability Risk (Can the customer figure out how to work it?)
- Feasibility Risk (Given our resources, can we implement the solution?
- Business Risk (Is there anything wrong with the solution in a business sense?)
After testing and coming up with a viable solution, it goes into the roadmap.
How did OST work for us?
Product discovery in itself is a very messy phase since the team is dealing with many unknown parameters, and if we fail to employ an effective structure this swarm of unknowns can be a major bottleneck, which, admittedly, sometimes was for my team. Employing Teresa Torres’s OST, we were able to define who was working on which branch with a clear deadline.
My technical team is comfortable with two-week-long sprints (give or take one or two days). In the two weeks, the developers had their hands full with sprint I, my APM and the designer were mainly responsible for the Solution Space for sprint II, while I was mainly responsible for the Problem Space for Sprint III:
This is exactly what I was looking for: A structure to ensure that the discovery work is continuous and agile.
