Determining your product roadmap contents will depend on a few factors: the constituencies who will be viewing your roadmap, your plan for the roadmap, your company’s culture, etc. So before discussing what items should go into your product roadmap, it is worth stepping back to think about a roadmap’s overall purpose. That will give us a better framework for determining what should go into yours, and why.
The key role of a product roadmap is to communicate strategy. Product managers use their roadmaps to share the vision and objectives for their products with various constituencies and to show how those product objectives support the larger strategic goals of the company.
When you understand this fact — that a roadmap should communicate a product’s strategy — it becomes clear why a product roadmap cannot simply be a long list of product features. The roadmap needs to be a higher level than that, to tell your product’s story.
What Should a Product Roadmap Include?
Based on our experience working with thousands of product managers, our view is that a roadmap is most effective when it presents a strategic view for a product.
Then, depending on circumstances and the needs of the product manager, the roadmap can also include more tactical levels of detail. In other words, your product roadmap should first tell your product’s story at the highest possible level, and then work its way down into the smaller, more detailed aspects of that story.
Below we will discuss what items you can include in your roadmap. We will be borrowing concepts and terminology from the agile approach to software development, but these concepts could apply equally to non-agile environments and to products other than software.
Note: For those new to product management, we will also define the terms we introduce below.
What Product Roadmap Contents Should You Include?
A theme in product management is a high-level objective for the product, usually built on a related set of features or stories (which we will also define below).
Think of a theme as a broad strategic goal for your product, which you can easily communicate to your various constituencies in plain language. If your product is an enterprise software application, for example, a theme for a future release might be to “ensure the product complies with federal regulations such as HIPAA.”
In communicating this theme to constituents such as your executive stakeholders, you would also want to present data to articulate the value of assigning resources to this initiative. For example, perhaps a large portion of your enterprise customers are in the healthcare field and are subject to HIPAA regulations for protecting the privacy of their patients’ data.
From here, the theme level, you can begin working your way into the more granular details that will help you achieve this goal.
An epic, like a theme, is typically a group of features or stories with a common strategic aim. You can think of an epic as one level of detail below a theme, such as that a theme might be comprised of several related epics.
Using our compliance example above, if one of the themes for your product roadmap is to build compliance into your product, you could break that into several epics — each addressing compliance with a different federal regulation.
HIPAA addresses data security for patient health records, for example, while Sarbanes-Oxley, or SOX, places similar demands for protecting customers’ personal data on any publicly traded business. Your compliance theme, then, could be broken into an epic for HIPAA compliance and another epic for SOX compliance.
The key to remember here is that, as your product roadmap presents these increasing levels of detail, you always want to be sure you are communicating the broader strategic objectives — your product’s story.
A story is a self-contained unit of development work designed to accomplish a specific goal of the product. A story is a level more granular than an epic, which in turn is a level more granular than the theme.
Sticking with the compliance example, your product roadmap’s stories might include, for example, the front-end work needed to complete the epic of SOX compliance. This could include building in a 2-step verification process or other user security measure that limits access to regulated data, to ensure only authorized personnel within your enterprise customers’ companies are able to access sites or databases that contain this data.
Another related story could involve back-end work, such as upgrading your encryption protocols for transmitting your customers’ data — for example, from Secure Socket Layer (SSL) to the more advanced Transport Security Layer (TLS) encryption. In the cases of many federal regulations, the more sophisticated the encryption of your data-in-transit, the more likely the process is to comply with those regulations.
By using this process of introducing increasing levels of granularity into your product roadmap — each tied strategically to the level above — you are using your roadmap effectively to explain the “why,” or the purpose of each initiative you are proposing for the product.
Ultimately the stories, epics, and themes for your product will be built on the features you add. But if you are following the hierarchy above, the features you include on your roadmap will have the appropriate context. In other words, the reasons you included these features in your roadmap will be clear.
How to Structure Your Product Roadmap Components?
Structuring Your Product Roadmap Contents:
Another strategic question you will need to answer when building your roadmap is whether to include timeframes and deadlines in your plan. There is no one-size-fits-all answer to this question.
Using our compliance example, if a new federal law that will affect your product’s use is expected to go into effect at the beginning of the next year, that would be a strategic reason to build in a deadline for your release that includes the “compliance” theme. You would then want to build a series of relevant shorter-term deadlines into the roadmap — for completing the feature builds, stories, epics and other details needed to accomplish the overall theme.
Another reason to structure your product roadmap around timelines might be organizational. If your company’s executives or other stakeholders demand to know what you expect your product to offer, and when, you might need to build these time-based details into the roadmap.
If, however, your focus (or your stakeholders’ focus) is more on achieving specific strategic goals with your products than on the timeframes needed to accomplish these goals, you might want to structure your roadmap based on criteria other than time. In that case, you might want to group various initiatives on your roadmap by swimlane.
Structuring Your Product Roadmap Contents: Swimlanes
Definition: A swimlane is a method of grouping tasks together in your product roadmap (or for your project managers to do so on their project boards). You can group swimlanes according to a number of different criteria, such as by stories or features, by department, or by priority level.
One benefit of organizing your product roadmap by swimlanes is that anyone involved in the product’s development can quickly view your vision for the overall project hierarchy — to see what they should be working on, and where it fits into the bigger picture.
Structuring Your Product Roadmap Contents: Color-Coding
Yet another way to arrange your product roadmap is to group various components of the project (stories, epics, teams) according to color-coded bars or columns (or other elements).
Like grouping your initiatives by swimlanes, creating color-coded bucket lets you give your various constituents an at-a-glance view of the major elements of your product roadmap.
In other words, using color-coding to organize and present your product roadmap supports your overall goal for the roadmap itself — to quickly and clearly communicate your product strategy.
This is also why it can be helpful to use visually based product roadmap software to build and maintain your roadmaps.