The roadmap is probably the most relevant result of product strategy planning. But while they are sometimes considered as Gantt charts with feature-level granularity and exact release dates, they should instead be seen as a strategic communication tool, as a means to communicate the current stage of the product and an explanation of the strategy.
Let’s actually start with a not-so-good definition by one of the product management gurus:
Sorry, Marty, we disagree. Yes, roadmaps, as defined here, might cause more harm — but then the definition is wrong.
When there are so many misunderstandings and misconceptions, why do we need roadmaps at all?
Regardless of the tool, in the following we provide a few tips for building good roadmaps:
This is what was discussed already: Good roadmaps reflect the strategy, e.g. by explicitly mentioning themes or strategic intents, and using these to group related work items together. This offers several benefits:
Sometimes, these metrics are not as straightforward as in the case of Netflix (and I even wonder whether these were so straightforward back then or are only in hindsight). Sometimes the data for these metrics is hard to collect. Sometimes the feedback loop is much slower thereby making it difficult to act upon that data. But, still, any such item should start with a hypothesis on the business value it provides.
A great roadmap does not yet name solutions but instead still operates in the problem space. We will go deeper into problem space vs. solution space in part 3 of this playbook. For now, imagine a hypothetical company that decided to support business growth by addressing enterprise customers thereby increasing average deal size. Listing relevant product initiatives for that could yield initiatives to tackle the following problems:
But regardless of whether an approximate timing is explicitly mentioned in the roadmap or not, it is critical to state that there are other aspects more relevant:
To illustrate the need and also find a way to deal with engineering, who frequently hesitate to give estimates, we sometimes compare these estimations with route planning as delivered by a GPS:
To emphasize the analogy: based on well-defined destination, you always know where you are, you adjust based on circumstances, and you have clear data when you have achieved your goal.
As mentioned above, the act of creating and updating the roadmap jointly in a team to achieve alignment might even be more valuable than the actual roadmap artifact itself. Likewise, roadmaps are a highly efficient tool to communicate the status quo and progress of the product inside the organization:
Of course, Product Managers shouldn’t be dogmatic about the guidelines sketched above:
We would argue once the Product Manager is aware of the above guidelines, and when exceptions are consciously decided, then she is already on the safe side.
A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering. Learn all there is to know about roadmaps.
Ah, roadmaps. It seems like there’s a new article every week about whether they should have dates on, whether they’re delivery plans, whether they’re commitments or not. This is not one of those articles.