To be honest, I’ve built a lot of terrible roadmaps over the years. Some resembled Gantt-charts and came with work packages, milestones, and deadlines. Unsurprisingly, these created an unjustified sense of security and commitment. Others were too lofty and vague, needed lots of explaining and still left behind confused and irritated audiences. I came to try various formats and templates, adapted and tinkered to address some of these issues, but I am yet to uncover the holy grail of roadmapping. Be aware that Product Roadmaps Relaunched also offers no such silver bullet, nor does it provide a single, correct, gold standard roadmap template that everyone should use all the time. But had I stumbled upon the book already when it first came out in 2017, I might well have avoided a few unsatisfying sidesteps.
Anyhow, I’m happy that I picked up the book at this time, as it not only confirmed some of my intuitions and helped explain my earlier shortcomings, but it also establishes a structured framework of roadmapping that can be useful in various contexts.
Principles
First, and most importantly, the authors make it very clear what a (good) roadmap is not:
- It’s not a project plan.
- It’s not about output.
- It’s not a list of features and functions you want to ship.
- It’s not about promises you’re not confident you can keep.
So, what is it about, then?
Above all else, the roadmap is the product manager’s most valuable strategic communication tool. That makes it all about vision, intent, and direction, and most importantly about the value you propose to create. It helps rallying stakeholders around a common goal and getting them, as well as your customers, executives, and investors excited.
“Just as your first prototypes and MVPs are likely to get trashed in feedback sessions with your early customers, your roadmap is meant to change and adapt as you learn more.”
There is no such thing as a one-size-fits-all roadmap template which perfectly serves the aforementioned purpose and simultaneously fits the needs of all products, teams, and organizations alike. Acknowledging this basic truth, the authors introduce a flexible framework centered around five key elements which, in their view, build the cornerstone of a good roadmap. Beyond that, they suggest some complementary information that may be helpful in particular scenarios. So, what’s at the core?
- Product vision. Make it clear why your product exists, why addressing the customer needs that are on the roadmap is important, and which principles will underscore your decision making.
- Business objectives. What does success mean for you and your business? For instance, is the goal to grow fast and acquire many new customers? Or is it to stay competitive and retain a loyal user base? Or something entirely different? State clearly what results you’re trying to achieve and how those are measured, so that you have a foundation for arguing how the items on the roadmap will drive those metrics.
- Timeframes. While a roadmap is by no means a project plan, some temporal context still matters. Keep it as rough and high-level as possible though: Depending on your industry and your product, an appropriate scale might be weeks, months or quarters, and respectively the horizon of the roadmap can range from a few months to a couple of years.
- Themes. Which customer problems do you plan to address, and what are their respective priorities? Note that the authors argue strongly against adding specific features and functions to the roadmap. Instead, focus on your customer’s most critical needs and pains, as well as the order in which you plan to tackle them, and why.
- Disclaimer. Even the most well intended roadmap can, and probably will, be interpreted in the wrong way. Therefore, it’s crucial to make clear how the presented information can and should be read and used.
Item (4), the emphasis on themes over features and functions, often does not come naturally. But, the authors argue, by shifting our attention to the outcome we’re trying to achieve rather than the output we will create, we gain a lot of flexibility: No longer are we forced to presuppose specific solutions to what may be very complex customer problems. Therefore, we can also reduce the stress about one of my personal pet peeves with roadmapping in general: The idea that every single item needs to have a detailed and highly confident effort estimation upfront.
Not only is it unrealistic to expect our engineers to gauge, with any meaningful level of precision, how long it will take them to implement specific features many months in the future. In some cases, even posing the question can be actively counterproductive: In order to come up with an answer, diligent teams will ask in return for a granular description of what they’re supposed to deliver, therefore forcing us–prematurely–to commit to a specific solution.
Wouldn’t it be a lot wiser instead to give the team the freedom to come up with the best solution at the right point in time? On this, and many other aspects, the authors’ arguments are strongly influenced by Marty Cagan and his books Inspired and Empowered. Unsurprisingly, the notion that teams should be given “problems to solve”, rather than “features to build”, and that you should foster a culture of missionaries instead of mercenaries echoes throughout Product Roadmaps Relaunched as well.
Of course, we’ll also need to get some idea about the complexity of the things we’re talking about at some point. But instead of estimating the hours, days, and weeks it will take to build a specific solution, the authors say we should look at the relative sizes of the customers’ problems. In order to have a meaningful conversation about priorities, t-shirt sizing done by the product managers may already be good enough for example. After all, what we’re trying to achieve at this stage is not to create a detailed release timeline, but to bring things into a meaningful order.
“The roadmap has to tell the product story, but it doesn’t have to get the days right.”
— Jim Garretson, VP Product at Omnicell
Prioritizing
The distinction between prioritizing and scheduling may at first seem merely semantic, but it neatly ties back to the idea of outcome vs. output and customer needs vs. features. When talking about priorities in the context of roadmapping, the authors ask us to concentrate on the order in which it makes the most sense to tackle the most pressing problems our customers face. That activity is inherently different from mapping out when exactly who is going to build which feature and when it will be released to the market.
For the former, it’s perfectly fine to rely on ballpark estimations of the value we’re going to create and the effort that will take, because all we’re really interested in are relative differences of a meaningful size. The latter of course will require more precise tools such as resource allocation plans and task-level estimations, but applying these too soon will likely be wasteful and frustrating.
The book introduces some common ways of prioritizing, including the Critical Path method, which is related to the concept of User Story Mapping, the well-known Kano Model, and the good, old ROI scorecard. The authors warn, however, that it’s tempting to over-engineer these tools, especially the latter, thus spending more time building a seemingly perfect spreadsheet than thinking about the content we put in there.
Alignment and buy-in
“No plan survives contact with the enemy,” said Helmuth von Moltke the Elder. We would add: “or your stakeholders.”
Above and beyond the roadmapping techniques outlined so far, the book also includes a chapter on how deal with the stakeholders involved in the entire product process. The authors distinguish between alignment, consensus, and collaboration, therefore making clear that the goal isn’t full agreement between everyone on every minute detail, but that product management always is a game of tradeoffs between different interests. They don’t fail to point out the importance of listening to, understanding, and empathizing with the explicit and implicit needs of various stakeholders though. For that purpose, they even introduce a number of helpful workshopping techniques, as well as practical advice on how to best present and share a roadmap with audiences ranging from executives, to engineers, to customers and partners.
Summary & opinion
The authors of Product Roadmaps Relaunched wanted set the record straight about lean product planning and prioritizing and it’s fair to say that they achieved that goal in a stellar way. Going beyond pure roadmapping, they cover a broad range of topics relevant for product people in various roles. Identifying and prioritizing customer needs, crafting an inspiring product vision, turning it into reality with a fitting strategy, and measuring success and impact are just a few aspects of the many they share an informed perspective on. But what surprised me the most is that scope of the book isn’t limited to SaaS or software products at all, which makes it useful for people in different industries as well.
I definitely recommend everyone working in a product-related role to contemplate the ideas proposed in the book. As always, not everything will be agreeable to everyone and in every situation, but I’m sure most of us will be able to take away one thing or the other which will help us do our jobs just a tiny bit better.