How I structure the product roadmaps
I call it the OPPOSITE approach and it has helped every team own the parts of roadmapping
I am sharing below how I structure product roadmaps. I call it OPPOSITE approach. You can also access this on my Miro Template and copy to your own board.
Now an explanation on how I got here:
1. Ever since I started designing roadmaps, one of the biggest challenges was connecting all moving parts. From outcomes to problems, to linking all into a coherent plan.
2. I’ve always been inspired by Teresa Torres’ Opportunity Solution Tree. But when empowering less senior people with OSTs I usually needed to do handholding. It requires nuanced product thinking that often doesn’t exist in new product builders.
This led me to build on top of OSTs & get to OPPOSITE.
Why call it this way? 1) because even when teams know they should “start from why” or “begin with the problem”, most still jump to solutions first. This approach forces the opposite. And 2) because the acronym works 😂
Let’s dive in 👇
𝐎𝐛𝐣𝐞𝐜𝐭𝐢𝐯𝐞: You should always have a number to achieve. The objective is the sole focus of problem solving. Start by defining and quantifying it clearly.
𝐏𝐫𝐨𝐛𝐥𝐞𝐦: Any objective has a set of problems in front of it. Break it down into the blockers preventing you from getting there. Focus on customer problems.
𝐏𝐚𝐫𝐭𝐬: Needle-moving problems tend to be large. It’s important to break down each problem into its parts. Occasionally, a problem is already narrow enough. Go deep.
𝐎𝐩𝐩𝐨𝐫𝐭𝐮𝐧𝐢𝐭𝐢𝐞𝐬: achieving an objective might not require you to solve every problem and all it encompasses. Smart product teams prioritise the parts for the timeframe they have. These are your opportunities. An opportunity might be linked to a single part, a single problem or solve a combination of parts or problems.
𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧𝐬: to seize an opportunity (and solve the underlying problem) you have to ideate solutions. These are all the ways to use your product, processes and people to get the job done. A solution might connect into a single opportunity, or it could seize multiple opportunities at once.
𝐈𝐧𝐢𝐭𝐢𝐚𝐭𝐢𝐯𝐞𝐬: To deliver a solution to the market you have to translate it into a team initiative. This is your epic. It ties directly to your roadmap. You can group multiple solutions into a single solutions, or have a one-to-one relationship between an initiative and solution.
𝐓𝐚𝐬𝐤𝐬: Each initiative should then be broken down into all the tasks that get it to customers' hands. These include engineering, design, product, GTM and all other tasks. It gives you an overview of the project.
𝐄𝐱𝐞𝐜𝐮𝐭𝐢𝐨𝐧: The last layer is the actual execution of tasks, tying to your sprints. Ceremonies, tools, and oversight to deliver the fastest and highest quality solution. It goers across the entire solution space for the timeframe.
I hope this helps every product builder, founder or executive empowering their teams to design a plan that really achieves your objectives.