A product roadmap is a high-level, strategic plan, which describes how the product is likely to develop and grow over the next months. This creates a continuity of purpose, and it helps product managers and product owners acquire funding for their product; it aligns stakeholders and facilitates prioritisation; it makes it easier to coordinate the development and launch of different product; and it provides reassurance to the customers (if the product roadmap is made public).
Unfortunately, I find that many product managers and product owners struggle with their roadmaps, as they are dominated by features: There are too many features, and the features are often too detailed. This turns a roadmap into a tactical planning tool that competes with the product backlog. What’s more, the features are sometimes regarded as a commitment by senior management rather than part of a high-level plan that is likely to change.
Faced with this situation, I have developed a new goal-oriented agile roadmap — the GO product roadmap, or “GO” for short. GO is based on my experience of teaching and coaching product managers and product owners, as well as using product roadmaps in my own business.
The GO Product Roadmap Explained
The following pictures shows what the GO product roadmap looks like. You can download a PDF template by simply clicking on the picture.
The first row of the GO roadmap depicted above contains the date or timeframe for the upcoming releases. You can work with a specific date such as 1st of March, or a period such as the first or second quarter. I find dates particularly valuable on internal roadmaps. If you use an external one, you may want to remove the row or use loose timeframes, such as, in the first six months of 2014.
The second row states the name or version of the releases, for instance, iOS 7 or Windows 8.1.
The third row provides the goal of each release, the benefit the new release should provide or the outcome that you want to achieve. Sample goals are to acquire or to activate users, to retain users by enhancing the user experience, or to accelerate development by removing technical debt. Working with goals shifts the conversation from debating individual features to agreeing on desired benefits making strategic product decisions. The development team, the stakeholders, and the management sponsor should all buy into the goals.
The fourth row provides the features necessary to reach the goal. The features are means to an end, but not an end in themselves: They serve to create value and to reach the goal. You can think of the features as the output required to create the desired outcome. Try to limit the number of features for each release to three, but do not state more than five. Refrain from detailing the features, and focus on the product capabilities that are necessary to meet the goal. Your product roadmap should be a high-level plan. The details should be covered in the product backlog including epics and user stories.
The last row states the metrics, the measurements that help determine if the goal has been met, and if the release was successful. Make sure that the metrics allow you to measure if and to which extent you have met the goal. Consider how long it takes after the release has become available to determine to determine goal attainment. For instance, if your goal is to acquire 1000 new users, then you may have to wait a few days to understand if your goal has been met.
A Sample GO Product Roadmap
To illustrate how the GO template can be applied, imagine we are about to develop a new dance game for girls aged eight to 12 years. The app should be fun and educational allowing the players to modify the characters, change the music, dance with remote players, and choreograph new dances. Here is what the corresponding GO roadmap could look like:
While the roadmap above will have to be updated and refined at a later stage (particularly the metrics), I find it good enough to show how the product may evolve and make an investment decision.
When creating your GO roadmap make sure you determine the goal of each release before you identify the features. This ensures that the features do serve the goal. Filling in the roadmap template from top to bottom and from left to right works well for me.