The GO product roadmap is a goal-oriented product planning tool designed to work with Lean Startup and Scrum. By focusing on goals, the roadmap shifts the conversation from debating features to establishing shared outcomes. This post explains how you can apply the GO product roadmap--from deriving it from the product strategy to keeping it updated.
Step 1: Do the Prep Work
Before you create your GO product roadmap, you should carry out the necessary problem validation work. Investigate the target group, the problem to be solved, the business goals, the standout features, and the technical feasibility of your product. The product vision board, business model Canvas, and lean canvas are great tools to capture and validate your ideas.
To see how this can work in practice, take a look at the product vision board below. The board captures the idea of creating a digital dance game together with the intended audience, the benefits, the key features, and some aspects of the business model:
Step 2: Build the Product Roadmap
The product vision board helps describe the market, the value proposition, and the business goals. But it does not tell us how the strategy will be executed and the specific outcomes the product is likely to achieve. Will the first product version deliver the entire value proposition and generate the desired business benefits, for instance, or will this take longer? Say we focus the first version of the dance game on user acquisition. While this is a necessary step towards the vision, it does not answer the question when revenue will be generated. This is where the product roadmap comes in.
I used the sample product vision board above to create the GO product roadmap shown below. You can download the roadmap template by clicking on the picture.
The roadmap shows how the strategy captured in the vision board will be executed over the next 12 months. It states the product goals, the key features, and the metrics together with a target timeframe and release/version name, indicating that achieving the goals will result in a new product version. Version 1, for instance, is focussed on user acquisition, version 2 on activation and revenue generation. Version 3 is about retaining existing users, and version 4 targets a new segment and tries to acquire new users. (I discuss in more detail in my post “The GO Product Roadmap”.)
Your roadmap should tell a coherent story about how the product is likely grow: Choose the goals carefully and consider their relationships.
Which timeframe your roadmap should cover and how often you want to create a major release / new product version depends on your product. You should be reasonably confident about your roadmap and avoid speculation.
If you cannot look further than the next product goal, then do not employ a roadmap!
Step 3: Derive the Product Backlog
With your GO roadmap in place, you can now take the next step and use the product roadmap to stock your product backlog. Use the next product goal and the key features associated with it to discover the product details including the user journeys, epics, the visual design, and the nonfunctional requirements.
By following this approach, the GO roadmap connects the product strategy to the product backlog. This allows you to focus your backlog on the next product goal, which results in a smaller and more manageable product backlog that is easier to change and update.
Step 4: Regularly Review and Update the Roadmap
A product roadmap is not a fixed plan that is created once and then simply executed. Instead, it needs to be reviewed and adjusted on a regular basis, particularly when your product is young or the market dynamic. The picture below summarises my recommendations or reviewing and updating the roadmap. Make sure that you involve the key stakeholders in the roadmap reviews to benefit from their expertise and create strong buy-in.
Post a Comment or Ask a Question
4 Comments
Hi Roman,
Is there a particular reason you left out the target values in the Metrics areas? For my roadmap, I have “Penetrate Power Markets” and included features of new product introductions that will help us do this. For metrics, we would measure sales of these new products as they relate only to the power markets. However my leadership wants to see target sales or increase percentages in the metrics area. I suspect these are not included in your example for a reason and would like to convey.
Hi German,
Thanks for your sharing your questions. I recommend that you make the goals on your product roadmap specific and measurable. You may want to say, for example, “penetrate power markets and increase market share by 10%” or “Increase sales in power markets by 5-10%”. The metrics section then states how you measure goal attainment, for instance, the products or product lines and the regions, like EMEA, whose revenue you take into account.
Does this help?
Hi,
How can you forcast what kind of features you will have in the quarters without estimation ?
How the delivery team will feel about that ? You are telling what to deliver and when !
Could you help me to understand it ?
Regards,
Eduardo
Hi Eduardo,
Great question! There are two things I’d like to point out before I share my answer: First, the features on the GO roadmap serve the goals, and every feature should be derived from a goal. Second, state the features so that they create a shared understanding of what needs to be done, but keep them coarse-grained. Don’t include details, or say to which extend they will be delivered.
Understanding how much can be achieved in a given timeframe is always particularly tricky when a new product or major product update is developed. In this case, I recommend determining the Window of Opportunity, that is, the latest point in time when you have to have a first product (the Minimal Marketable Product) ready for launch. (I have described this planning approach in more detail in my book “Agile Product Management with Scrum”.) Then consider the people necessary to create the product and derive the initial budget.
Once you have started the first iteration, measure how fast the team can go, and how much your Product Canvas/backlog changes. In Scrum, you can use the release burndown chart assuming that the team has estimated the items on your canvas/backlog; in Kanban, you can calculate the average lead time. Then compare the data to your target launch date.
Does this help?