The following blog post summarizes the second chapter of the Product Roadmaps Relaunched book by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors. Published on November 28, 2017. The second chapter is reviewed and summarized using my best judgment of the most essential information.
In a roadmap, there are standard items that are shown on a roadmap plan. But, some product managers, organizations, teams or even workflows require or prefer different information to appear on their roadmaps. And that’s fine! There is no set-in-stone rule regarding what your roadmap should or should not contain. At the end of the day, you have to do what’s best for you, your organization, your team and the workflow. Although, in this chapter, some standard items (called primary and secondary components in the book) are listed. This gives the reader a better idea of what they are and how they can be used during the roadmap planning process.
Product vision
Your product vision is an excellent addition to your roadmap. It helps stakeholders align the plan they see with the product vision. This gives context to the importance of what you plan to work on and what you try to achieve.
Business Objectives
In addition to your product vision, including business objectives in your roadmap helps your stakeholders understand your plan and see why the elements addressed in your plan contribute to the business’s bottom line.
Time frames
Indicating time frames on your roadmap is a great way to provide an idea of when certain roadmap elements will be addressed. But how these time frames should be presented is extremely important. If possible, refrain from giving exact dates so as not to over-commit or disappoint internal or external stakeholders when these items are not accomplished and delivered on time.
A common solution to this problem is to use the Now-Next-Later template. It gives enough context to understand what priorities are to be addressed first and which will wait until later.
Themes
Focus on outcomes (themes) instead of outputs (features). This is a classic trade-off that most product managers must make. It is much easier for stakeholders to understand exactly what will be done, what features will be created, and when they will be released. But, these decisions may not have already been made. Therefore, suggesting possible features that have not been vetted may lead to disappointment when it is shown that it is not the best solution.
Therefore, when possible, list themes of problems that will be addressed instead of the specific features that will be outputted.
Features and Solutions
Although there is a time and place for features on the roadmap, it is nested under themes. This is a great place to list them as the primary focus becomes on the theme you will be addressing and the features or solutions as possible ways to tackle them.
Stage of Development
Including the stage of development on your roadmap is one way to present to your stakeholders when this theme may be addressed and how long it will take. Simple labels such as “Design”, “Development”, and “Testing” shows at what stage that theme is.
Confidence
Similarly to the stages of development, a confidence rating also helps provide context. But in this case, it helps set expectations for the likelihood that it will be addressed on their roadmap.
Target Customers
Again, to provide context to stakeholders, including the target customers, those specific themes are addressed is always a great idea.
Product Area
If, within your organization, multiple products exist, providing the product area is also a good idea. Giving context to which area(s) specifically that theme will address.
Disclaimer
An essential part of your roadmap is your disclaimer. To avoid disappointment and ensure clarity with stakeholders, disclosing that your roadmap can and will be changed at any time will allow for that flexibility when it inevitably comes.