The product roadmap is an important product management tool. But effectively applying it 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 article 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.
Introduction
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; it sets expectations and aligns the stakeholders and development teams; it facilitates prioritisation and unburdens the product backlog; it can help you acquire a budget; and in the case of a public product roadmap, it can also provide reassurance to the customers.
Unfortunately, I find that many product people struggle to fully leverage product roadmaps. All too often, the plans are dominated by features: There are too many features, and the features are sometimes too fine-grained. Such a roadmap makes it hard to secure agreement and create alignment; it overlaps and competes with the product backlog; and its features are sometimes regarded as a commitment rather than as a 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. As its name suggests, goals or outcomes are at the heart of this plan, not features or other pieces of functionality. 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 specific 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 product goal, or goal for short, which is located right in the centre 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. These goals should describe the specific value the product will create and answer the question of why it is worthwhile to (continue to) invest time, money, and energy in developing the product. Sample goals are acquire new users, retain users by enhancing the user experience, or accelerate development by removing technical debt.
Additionally, the product goals should be in line with the 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 objectives. Then order the newly created goals to tell a meaningful story of how the product is likely to evolve. I recommend using one product goal at a time. This creates clarity and alignment, and it makes it easier to track progress and understand if the desired outcome has been achieved or not.
While I find it very beneficial to work with goals, in practice these have to balanced with time frames or dates—at least when you create an internal roadmap whose purpose it is to align and guide the stakeholders and development teams. 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 on dates, please 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. Examples include iOS 14 and Windows 10, as well as the more creative release names Jelly Bean and Marshmallow of Android 4.1 and 6.0.
The fourth row provides the features or product capabilities necessary to reach the goal. The features are therefore a means to an end, but not an end in themselves: They serve to create value and to reach the goal and they should be closely aligned 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. Don’t make the mistake of detailing the features. Your product roadmap should be a high-level plan, and the product details should be covered in the product backlog. Epics and user stories don’t belong on your roadmap.
The last row states the metrics, the measurements that help you determine if a 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 will take 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 might have to wait a few days or even weeks to be able to understand if you’ve achieved this goal. You may want to add the metrics for the current product goal to the set of product KPIs used to determine the product performance.
You can also watch me explain the GO roadmap template in the video below.
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 compound goals in the example above, business and user goals that are closely related and depend on each other. While you can happily work with only business goals on your roadmap, adding user goals helps ensure that the people who should benefit from the product are not forgotten. Additionally, note that 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 improved.
