Creating strategic product roadmaps
A UX strategist's quick guide on how product roadmaps are different from backlogs.
A traveler encounters three stone cutters on the street. When asked “What are you doing?”, the first man replies “I’m cutting stone”.
Still curious and confused, the traveler approaches the second man, who says “I’m cutting this stone into a rectangular shape so that it can fit into the wall”.
Starting to get an idea but still not fully sure what’s going on, the traveler approaches the third man who says “I’m building a cathedral”.
This parable is usually linked to leadership and the importance of always starting with the big picture first. But it’s also a great metaphor for product management, and for explaining why a strategic product roadmap is not the same thing as a product backlog.
A product roadmap is a daring vision that brings the entire team together, unites us in our ambition to create the most beautiful product the world has ever seen, and puts us in a state of organizational bliss. But while all teams generally agree it’s important, things often tend to get mixed up when it comes to formats and objectives. One of the most common confusions on this topic comes from mixing up the product roadmap with the product backlog. These two inevitably share multiple characteristics, but have an inherently different purpose.
Where roadmap meets backlog
They both break down the plan into smaller components. They include some sort of timeline arrangement. They ensure that every product iteration creates added value for the user and for the business. They are extremely useful for improving team alignment. They are dynamic and likely to constantly change based on the team’s learning. But they’re also quite different from each other on multiple dimensions.
Let's talk about differences
A product roadmap is a strategic tool that outlines the long-term product vision. It performs a few key functions:
- Aligns the team; communicates the wider vision and approach for the product to all stakeholders without getting stuck in the tactical details
- Focuses on the value created by the product and the “why” behind it, by keeping a clear view of the problems we solve for our users, and the benefits we bring for the business
- Encourages conversations regarding product growth and scoping
- Outlines key assumptions to be validated
- Helps the team prioritize and plan with the bigger picture in mind, before moving on to the detailed development-oriented backlog
- It’s useful for every stakeholder, from the “I have 5 minutes to hear about this” CEO to the “This is at the core of my responsibilities” product owner
A product backlog is an operational tool focused on the development approach . It breaks down a complex product into manageable user stories and has the following value:
- Translates a strategic vision into manageable chunks
- Clarifies features and functionality
- Defines development sequence and priorities
- Enables effort estimates
- This is mostly useful for product teams and hands-on stakeholders
There’s no doubt that both of them are useful, it’s more of a matter of time and occasion of use. And there’s a conceptual sequence to it.
Overlooking a strategic roadmap hurts the team’s abilities to see the big picture. It hinders the ability to consider the “why” behind what the team activities and thus simply makes the team and the output less intentional. But shifting from a backlog to a strategic roadmap approach can be done with just a few minor adjustments.
1. Center conversation around themes and goals
A product roadmap should be visionary. It should be inspiring and build enthusiasm. And while there’s definitely some people who can get inspired by things like “build a secure log-in system” because they think of all the complexity and intricacies it involves, most people won’t share this view. What most people can get behind though is the ability to make an impact, i.e. to address meaningful goals for the consumers. Highlighting the enablers linked to the product rather than the detailed features is a simple yet very effective way to map out the bigger picture instead of the development log.
Grouping more detailed items in a set of higher level themes is also a great way to communicate about the roadmap — and much more likely even your high-up-there-super-busy stakeholders get to understand the product vision. And if you can link those to tangible business goals, you’ve got the full package.
And even going beyond the communication-inspiration idea, themes or goals can help the team keep an open mind for finding the best way to solve a problem instead of blindly focusing on a pre-defined solution. As Jared Spool puts its, “themes are a promise to solve problems, not build features” (great read by the way).
2. From MoSCoW to prioritization
Ah, good old “Must Have Should Have Could Have Would Have” framework! How many business minds it ignited over the years, how many billed hours it generated! I’m not here to argue the overall viability of the model, but in the context of a product roadmap there are better ways to approach this.
Beyond the fact that MoSCoW is inherently feature-oriented, it also creates the erroneous impression that certain aspects are not worth pursuing. “Feature X is a would have” is most likely to be perceived as something that is simply not worth the effort, and will never happen. Why, then, would you have this category in your roadmap? Does a business ever get to a state when they have a surplus of resources and decide to spend it on items that bring no value but cost a lot? And whose perspective does this cover? Is this a “must have” for the end-user because it solves a meaningful problem, or is it a legal requirement?
The alternative? A prioritization matrix. It can help address the issues covered above and provide a solid foundation for product discussions. In a prioritization exercise, the team can shift the conversation upstream towards goals and objectives — and arrange them according to importance for end-users, business and technical sides. It’s really the relative importance we’re looking for here. This is not about goal B not being important enough, it’s about goal B being less impactful than goal A. A prioritization matrix can make it easier to ensure all perspectives are taken into account, and it can decrease (if not remove) subjectivity from the conversation.
3. From timelines to journeys
You’ve probably seen the typical product roadmap structured in a gantt chart, and linked to quarterly plans or release dates. In fact, that’s pretty much the only thing you’ll see if you run a Google image search.
Again, this makes sense for a product backlog (which is step 3 in our high level product approach from earlier). But when it comes to a strategic product overview, it might not be the best approach for multiple reasons: it’s too detailed to be easily understood, it’s not inspiring enough for a high level ambition setup, it’s linked to production capabilities rather than value-added for consumers, and it’s likely not accurate enough in the long-term.
A more versatile (and coincidentally easier, yay!) approach is to think of a few simple phases. It can be as straightforward as short-term, mid-term and long-term. Or you can group them into more goal-oriented phases, like Pilot, Minimum Lovable Experience, Delightful Experience. Whatever you name them, it’s best to aim for 3–4 phases in total. The later the phase, the more likely it is that it will change by the time you get to it, based on what the team has learned in the previous phases. The last phase can also be used as the dot on the horizon, the one you know you’ll never reach but will always try to get closer to.
What we’re really doing here is the describing the product’s journey as we envision it. And the cool part about a journey is that it’s unpredictable, it’s about learning and pivoting as much as it is about reaching specific milestones. It’s about accepting the fact that what you encounter today will affect where you want to go tomorrow.
Same same but different
With a few simple tweaks, it's really quite simple to get over a team's natural tendency to dive head-first into details and talk big-picture first. And knowing where you're headed does tend to make a big difference in terms of where you end up.
