The GO Product Roadmap is a simple yet effective tool to help teams create goal-oriented, outcome-based roadmaps. Despite its simplicity, I find that it’s not always correctly applied. To address this challenge, I’ve created a checklist, which I share in this article and which you can download for free.
Listen to the audio version of this article:
Overview
The GO Product Roadmap consists of five elements, as the image below shows: Date, name, goal, features, and metrics. The most important element is the goal: It describes the outcome you want to achieve or the benefit you want to provide. Sample goals include “acquiring new users,” “increasing conversion,” and “reducing cost.”
The checklist I’ve created offers criteria for each element as well as the entire roadmap. You can download the checklist together with the GO Product Roadmap by clicking on the image below. Applying the criteria will significantly increase your chances of creating a realistic, actionable product roadmap that clearly describes the value your product should create and that aligns stakeholders and development team members.
Before You Start
If you are new to the GO Product Roadmap, then I recommend reading the article The GO Product Roadmap and watching my YouTube video below before you apply the template and use the checklist.
Goal
Outcome-based: Clearly state why it is worthwhile to progress the product. Describe the specific value it should create, for example, “increase engagement,” “generate revenue,” or “reduce development time by removing technical debt.”
Specific: Make the goal—a.k.a. product goal—so detailed that you can tell what needs to be roughly done to achieve it and how long it is likely to take.
Measurable: Describe the goal so that you can determine if it has been met. To achieve, this you might state a target, for instance, “increase engagement by 5%.”
Prioritised: Place the goal in the right position on the roadmap considering, for example, its semantic dependencies to the other goals or its cost of delay.
Single: Choose a single goal to effectively align and guide people. Avoid using multiple goals that are worked on concurrently.
Date
Appropriately detailed: For an internal roadmap, state a target date or a specific time frame to communicate when the goal will be met. For instance, “1st February” or “Q1.”
For an external, public roadmap, use large, coarse-grained time frames, for example, “first half of 2024” or just “2024.” Alternatively, don’t show any temporal information and remove the row.
Realistic: Ensure that the date or time frame stated is achievable—without sacrificing sustainable pace and overworking people.
Metrics
Precise: Clearly state how you will be able to tell if the goal has been met. Say you want to increase engagement by 5%. How can you then determine that this goal has been achieved? Will you, for example, measure daily active users? And if that’s the case, will the figure include unique new users and returning ones?
Time-bound: Say when you will be able to find out if the goal has been met, for instance, “one week after the software is released.”
Features
Goal-directed: Each feature must be required to meet a product goal on the roadmap.
Coarse-grained: The features describe big product capabilities, which act as placeholders for specific functionality. Do not state any product details such as user stories. (These are captured in the product backlog).
Focused: Only sketch those features that are crucial to meeting the goal. Limit their number to three to five per outcome.
Name
Relevant: Choose a name, which communicates the essence of the work carried out. This is helpful especially when meeting the goal results in a new product version or major release.
Memorable: The name is easy to remember.
Overall Criteria
Connected: Ensure that the product goals on the roadmap are connected to the product strategy and the product backlog. They should help you meet the needs and business goals in the strategy, and they should direct the product backlog content: The backlog items should help you meet the respective product goal.
Adaptive: The roadmap is regularly inspected and adapted, at least once every three months as a rule of thumb.
Shared: Everyone who uses the roadmap has a shared understanding of it and supports the plan. A great way to achieve this is to collaboratively create and update the roadmap.
Actionable: The roadmap can be actioned, and it does not contain any speculative information. You can achieve this by basing the plan on a validated product strategy, not being overambitious, and only planning as far ahead as you can realistically see.
Post a Comment or Ask a Question