The GO Product Roadmap – a New Agile Product Management Tool

By Roman Pichler, 25th November 2013

Product roadmaps are an important product management tool. But applying them effectively can be challenging. Roadmaps are too often focused on features, and product managers spend too much time getting the stakeholders to agree on when which features will be developed. This post introduces a new roadmap: the GO product roadmap, a goal-oriented agile roadmap that combines goals and features in a novel way.

A product roadmap is a high-level, strategic plan, which provides a longer-term outlook on the product. This creates a continuity of purpose, and it helps product managers and owners acquire funding for their product; it sets expectations, aligns stakeholders, and facilitates prioritisation; it makes it easier to coordinate the development and launch of different products, 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 Canvas or 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.

The GO Product Roadmap Explained

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 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.

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 reason why it is worthwhile to develop and launch it. 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. 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 Canvas or product backlog, and commitments should be limited to individual sprints.

The last row states the metrics, the measurements or key performance indicators (KPIs) that help determine if the goal has been met, and if the release was successful. Make sure that the metrics you select allow you to measure if and to which extent you have met the goal.

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.

My post “Working with the GO Product Roadmap” explains the GO product roadmap in more detail including its relationship to the Vision Board, Business Model Canvas, and Product Canvas.


The GO product roadmap provides a new, powerful way to do product roadmapping. Rather than focussing on features, GO emphasises the importance of shared goals. This makes it easier to communicate the roadmap, create alignment, and use it as a strategic planning tool that provides an umbrella for the Product Canvas and the product backlog. The metrics provided by the tool ensure that the goals are measurable rather than lofty and fuzzy ideas. Download the template now, and try it out!

You can learn more about creating effective product roadmap and working with the GO product roadmap by attending my Agile Product Planning training course. Please contact me for bespoke product roadmap workshops and webinars.


RSS Feed

Tags related to this post:

17 comments on “The GO Product Roadmap – a New Agile Product Management Tool

  1. Amber Weaver

    Hi Roman – We are struggling with our “feature driven” roadmaps and looking to move to goal or theme oriented approach. I would love to hear your thoughts on one concern that we continue to struggle with – Dates.

    How do we convey that these are target time frames for achieving these goals, but not committed dates?

    • Roman Pichler

      Thanks for your question, Amber. I suggest that you literally use timeframes instead of dates, for example, Q2 2017 instead of 1 May or second half of 2017 instead of October 2017. If your roadmap is externally facing and used as a sales tool, then you may want to omit timeframes altogether and simply state the goals in the appropriate sequence.

      Does this help?

  2. Christian Prison

    I am wondering about one thing here: the metrics for achieving a goal are many times lagging behind the release dates: only after I released a new version of my App, I can measure how many people are downloading it. But if I realize that I have not met my goal then what? Do I create a new release with the same goal? And when do I plan successor releases? Only after my goal has been achieved? Too late if the metric is lagging.

    Obviously the best option is to find a metric which is not lagging. Another idea would be to find an “alternating” mode f.ex. if I have my App shipped, I start working on the website as long as my metric is collecting data for the App. During development of the Website, I plan the next release of the App but I don’t start development before the new Website is released (and then reverse and so on).

    Any other bright ideas or recommendations?

    • Roman Pichler

      Hi Christian, Thanks for your comment. You are absolutely right: there are some goals where goal achievement can only be determined after the release. If, for example, your goal is to acquire new users, then I recommend stating how many new users in which market or segment you want to acquire and how soon after the release date you expect to meet the target. Additionally, gather feedback and data on the product increments you create to get an indicator if you are likely to meet your goal or not. Does this help?

  3. Scrum Sprint

    Hi Roman Pichler, Thank you for introduce good project management tool.
    This is very nice tool.We are also develop one project management tool “quickscrum” .so your valuable input will become very help ful to us.

  4. Gab

    Thanks for sharing this great idea!
    For me, it’s important to have a set of tools like GO, Product Canvas, Backlog or Vision Board, which do not compete with each other. So I try to focus on the questions: which tool for what purpose and for what not?

    • Roman Pichler

      Hi Gab, Thanks for your feedback and your great questions. I have planned to write a couple of post that should answer your question properly. But to give you a brief answer now, here is what I do:

      I use the Vision Board for brand-new products and for major product updates – updates that change the customer segment/target group, the need/value proposition, or the business model. I use a product roadmap to show how the vision could be attained, and what the next two to four major releases may look like. The Product Canvas provides the details to create a major release/product update, the personas, the journeys, the functionality, the visual design, and nonfunctional properties.

      In the example in my post, the sequence of creating the different artefacts would be: Vision Board -> GO Product Roadmap -> Product Canvas -> Version 1.

      Does this help?

      • Gab

        Hello Roman,
        thanks a lot. As in my case, we have a huge initial backlog, which is terrible. So I think about using a backlog map ( for reducing and focussing the backlog.
        In this case, my sequence will be:

        Vision Board -> Backlog Map -> GO Product Roadmap -> Product Canvas -> Version 1.

        • Roman Pichler

          Hi Gab, Alternatively, you may want to consider starting with a new Product Canvas/product backlog/story map, which is derived from the roadmap and focusses on meeting the next release goal. I find it helpful to keep the Product Canvas/product backlog focussed and concise:

      • Gab

        I’m looking forward for your posts 😉

        • Roman Pichler


    • Laura

      Roman–do you have a B2B example of a go product roadmap?

      • Roman Pichler

        Yes I do 🙂 But what prevents you from applying the GO format to your B2B product?

Leave a Reply

Your email address will not be published. Required fields are marked *