Product roadmaps are an important product management tool. But effectively applying them can be challenging. Roadmaps are too often focused on features. This can make it hard to achieve agreement and alignment, and it can result in a plan that is too detailed and prone to change. This post introduces a new product roadmap template: the GO product roadmap, a goal-oriented roadmap that combines goals and features in a novel way, making it ideally suited for agile, dynamic environments.
A product roadmap is a high-level, strategic plan, which describes how the product is likely to evolve over the coming months. Using such a plan creates a continuity of purpose, and it creates clarity of the specific value the product is likely to create and therefore helps acquire a budget; it aligns stakeholders and facilitates prioritisation; it makes it easier to guide the development team and coordinate of different product; and it provides reassurance to the customers (in the case of a public product roadmap).
Unfortunately, I find that many product people struggle to fully leverage product roadmaps. A common reason is that the plans are dominated by features: There are too many features, and the features are often too fine-grained. 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. It is based on my experience of teaching and coaching product managers and product owners, as well as using product roadmaps in my own business. I did not, however, invent this roadmap format. It has been around for several years, and I honestly do not know who first suggested it.
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.
Let me start explaining the structure above by discussing its central and most important element, the goal, which is located on the third row. I like to start creating a GO product roadmap by identifying the desired outcomes or benefits the product should create over the coming months. The goals should describe the specific value the product should create and answer the questions, why it is worthwhile to (continue to) invest in and develop the product.
Additionally, these product goals should be connected to the value proposition or needs and the business goals described in the product strategy. In fact, a good way to discover the right product goals is to start with the product strategy and ask yourself how the user, customer, and business goals it contains can be broken into smaller, specific, and measurable ones. Then order the goals to create a meaningful narrative of how the product is likely to evolve. Sample product goals are acquire new users, retain users by enhancing the user experience, or accelerate development by removing technical debt.
While I find it very beneficial to work with goals, in practice these have to balanced with a time frame or date. Say you work on an entertainment product like a new game that has to be available in time for the Christmas sales, then meeting this deadline will be important to create the desired value. I have therefore included a row in the template above that encourages you to state when you intend to meet the goal and realise the desired outcome or benefit. If you use the GO product roadmap to capture and external, customer-facing roadmap, then you might want to either work with coarse-grained time frames or simply remove the row. (For more advice, see my article “Should Product Roadmaps Have Dates?“.)
The second row states the name or version if meeting the goal results in a major release or new product version like iOS 7, Windows 8.1, or maybe even better, Jelly Bean and Marshmallow (Android 4.1 and 6.0).
The fourth row provides the features necessary to reach the goal. The features are therefore means to an end, but not an end in themselves: They serve to create value and to reach the goal and they should be derived from it. You can think of the features as the output required to create the desired outcome. Try to limit the number of features for each goal 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 desired value has been created. Using metrics helps ensure that the product goals identified are specific and measurable. When stating the metrics, consider how long it takes to determine to determine goal attainment after the product has been made available. For instance, if your goal is to acquire 5-10% more users, then you may have to wait a few days or even weeks to understand if you’ve achieved this goal.
A Sample GO Product Roadmap
To illustrate how the GO template can be applied, imagine that I’d like to offer an app that helps people eat more healthily. Here is what the GO product roadmap might look like:
Note that I have used dual goals in the example above, business and user goals that are closely related and depend on each other. While you can happily work with business goals on your roadmap, adding user goals helps ensure that the people who should benefit from the product are not forgotten. Additionally, the metrics sections from version two onwards will have to be refined before the appropriate goals are being worked on. But that’s OK in my mind, as long as the product roadmap is regularly reviewed, updated, and refined.
This article was last updated in October 2020.