Rethinking outcome-based product roadmap to plan for uncertainty (part 2).
Yes, this one has a new template and it's in Notion.
Previously, in part 1, I identified a few issues with my prior outcome based roadmap template. Today, I’m introducing a revised template created in Notion. I chose Notion because over the last two years, I’ve moved all of my documentation and writing to Notion [Note: This is not a sponsored Notion post]. Notion has more formatting features, shortcut keys that are easier to remember, and a feature to make interactive tables. Furthermore, organizating multiple documents with Notion is significantly easier than using Google Drive folders and Google Docs. If you haven’t used Notion before, I recommend you giving it a try. If you are a student or teacher, you can upgrade to the Personal Pro plan for free.
So, what’s new?
There are two fundamental problems I saw with my old outcome-based product roadmap.
First, it was still heavily feature or solution oriented. Yes, there were a sprinkle of OKR, so at least there was an objective statement. But is there a way to more clearly link features to a problem statement?
Secondly, readers of the feature roadmap in the Now, Next, Later section may disagree with the ordering/sequencing. Is there a way to address this issue?
Thus, I introduce three changes that all build upon existing techniques.
Introduction Situation/Constraints/Problem Statement, a modification of the SCQA framework
Introducing an issue tree, which identifies which Problem Statement and why
Providing more transparency in roadmap sequencing with RICE score
Situation, Constraints, and Problem Statement
You might have read about SCQ or SCQA framework. If not, I created a slidument to teach SCQA that you can reference. I’m borrowing and modifying it to create Situation, Constraints, and Problem Statement. The goal of the section is to provide context and define the problem statement. Formulating the correct problem statement is half the battle. In other words, a roadmap without a clear problem statement will read like a list of random features or projects.
Situation: What’s the current circumstances?
Constraints: What are known things you/we can’t do?
Problem statement: What are we trying to solve?
Issue Tree
Picking a single problem statement isn’t obvious or easy. In my template example, the situation is to increase revenue in 2020 by 2x. There are many different methods / problems that you can solve to increase revenue. The issue tree attempts to make you think though some of those options so you can pick a problem statement. The constraints in the prior section may help you narrow down which problem statement to select. This is a supporting document to communicate the why, which helps readers understand.
Roadmap Sequencing Transparency
If the prior sections is all about defining the problem and communicating why to focus on this specific problem, this update explains why the solution roadmap is organized in the particular Now, Next, Later configuration. Here, I’m not introducing novel concepts, but simply incorporation a prioritization score (in this specific case … RICE). But all scores are guides and may need to be modified either because of hard commitment dates or other reasons. So, there’s a place to simply write that down. Pretty simple stuff, but rarely document and mostly given as voice overs during the roadmap presentation.
Closing Thoughts
Each of these might not seem like much, but I believe the combination of them enhances the comprehension for outcome-based product roadmaps, so the reader now only understands the what (i.e., a list of features in a Now, Next, Later order), but also understand the problem that list of features is trying to a solve. Solving those problems should benefit both the user, but also the company.
If you’re actively contemplating putting the techniques above into practice by piloting it at your company or within your product organization, drop a comment. I’d love to work with you, free of charge in exchange for permission to write a case study. I’m also contemplating an roadmap that’s problem-oriented rather than outcome-oriented. For example, with the issue tree in hand, could organizations create problem-oriented roadmaps that span outside of the product organization for someone like the CEO.