6 Ways Roadmaps Help You Be Better at Your Job (and Your Career)
As product managers, creating and maintaining product roadmaps are regular duties. Product roadmaps enable us to do our entire jobs easier. It only requires...
What is the best product roadmap style?
Sounds like a straightforward question, right? But it’s actually like asking, “What’s the best way to present our findings?” or “What’s the best organizational hierarchy for a new company?” Before you can answer intelligently, you need more information.
For example, who are your constituents for the roadmap? Is it an internal or external document? What is its ultimate purpose? What are the advantages and disadvantages of emphasizing certain details over others in the roadmap?
And, just as important, should you limit yourself to a single type of roadmap? Or should you start with a versatile roadmap that you can easily recast in different styles, to emphasize different details in different situations?
At ProductPlan, we talked to many product managers and have seen thousands of roadmaps, giving us a rare perspective on the various styles that product managers use, and the benefits and drawbacks of each. Although there are endless permutations of product roadmap styles, we see the following three used most commonly: Timeline-Based Roadmaps, Roadmaps without Dates, and Kanban Roadmaps. Following is a brief discussion of each.
Note: Before we explore each roadmap style, it’s important to point out that they are not mutually exclusive. When you’re building a product or beginning a new initiative, you might find all three of these styles useful for various audiences or for different stages of your process.
Every product manager has heard the question, “What are you working on and when will it be done?” If your CEO asks you this question, a timeline-based roadmap can be a great tool to help you to respond in a way that will resonate with your executive.
A timeline-based roadmap, depicted in the screenshot here, shows your initiatives relative to each other in the context of time. It visually communicates how long you intend to focus on certain initiatives and when you plan to complete them. Typically, you arrange your initiatives in a bar chart on a grid that represents a specific timeframe.
A word of caution: Oftentimes, you want to keep your dates high-level, showing initiatives spanning a few months and not designating exact start and end dates.
Why? In the same way that adding a price tag can dramatically change the focus of a sales conversation — your prospect will be able to focus on little else once they have seen the price — it can be counterproductive to place a great deal of emphasis in your roadmap on specific dates and deadlines. Your stakeholders or other constituents will be drawn to those dates, and that will become the focus of your roadmap discussion.
A primary reason to include timelines in a roadmap will be to provide your stakeholders with a sense of the context in which your development will be taking place. In other words, you want to give them a big-picture view of when and in what order you will be making progress on various components of your initiative.
A visual representation of all of your initiatives moving ahead in relationship to each other, in the context of time, also underscores for your stakeholders the reality that you are working with finite resources and limited time — an implicit reminder that you cannot simply speed your progress on a given theme or project without slowing progress elsewhere on the initiative.
When you are presenting your roadmap to external audiences such as customers, or to internal constituencies such as your sales or marketing groups, often the best roadmap style will be one that emphasizes themes, strategies and other high-level areas of focus — but without dates or deadlines.
Why? Because if you are sharing your product’s vision with prospects, customers or other external audiences, you want to provide them with a high-level view of what to expect from your future releases — to earn their interest and anticipation in the forthcoming product — while not setting expectations about a specific day when it will be available. Why risk undermining all of your work and a great product by disappointing customers with a release delay?
If you are sharing your product roadmap with internal groups like your sales reps, you want to give them the information they will need to communicate the benefits of your forthcoming product to their prospects and customers. You do not, however, want to risk these reps sharing expected release dates with customers — because this creates the same risk of disappointment in the event of a delay.
Group similar items together in the same swimlane to better emphasize related initiatives. The length of each initiative, depicted as bars in the example roadmap above, could represent their strategic importance or rough effort level.
Even though you don’t need to commit to a specific deadline, a roadmap without dates still allows you to order all involved initiatives sequentially. You can model the process based on what must get done first, and put your initiatives in context with everything else going on.
Whereas timeline-based roadmaps and roadmaps without dates are future-looking and can present roadmap details spanning a great deal of time (months or even years), a Kanban roadmap provides you a snapshot focus of your initiative’s progress right now.
In other words, Kanban is more of a high-level project management view than a long-term strategic view of a product’s future plans and objectives. A Kanban roadmap is a great project management tool in particular for internal audiences — developers, manufacturing teams or other groups that have responsibility for building your product.
A key tenet of Kanban is to limit the amount of work in progress (WIP), because WIP limits can highlight bottlenecks and backups in the team’s process due to lack of focus, people or skill sets.
For a Kanban roadmap, like the one depicted in the screenshot here, you want to show stakeholders the status and priorities for each stage of your development. For example:
By matching the amount of WIP to the team’s capacity, Kanban gives teams more flexible planning options, faster output, clear focus and transparency throughout the development cycle.
There is no one-size-fits-all answer to the question, “What’s the best roadmap style?”
A product manager overseeing complex initiatives, like creating or updating a product, might find circumstances at different stages of the process where each of the three styles we’ve discussed here represent the best way to present their strategy and progress.
A timeline-based roadmap might be a great way to communicate a high-level plan to executives who are focused on the product’s timeframe. A roadmap without dates, on the other hand, can be better suited to communicate a product’s strategy and planning to customers or sales reps, when the PM wants the focus on the product itself, and not to set expectations on deliverability. And when it’s time to roll up their sleeves and focus on the progress of each component of a project, PMs can use a Kanban roadmap to get a real-time snapshot of what’s done, what’s in progress and what’s still outstanding.
With the right product roadmap software — a high-level, visual tool — product managers can build a core roadmap and then quickly and easily shift its visual focus to display any of these (or other) roadmap styles as needed.