Photo courtesy of Pexels

The GO Product Roadmap

Published on 25th November 2013 3 min read

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 product roadmap template: the GO product roadmap, a goal-oriented roadmap that combines goals and features in a novel way.

A product roadmap is a high-level, strategic plan, which describes how the product is likely to develop and grow over the next months. This creates a continuity of purpose, and it helps product managers and product owners acquire funding for their product; it aligns stakeholders and facilitates prioritisation; it makes it easier to coordinate the development and launch of different product; 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 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, 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 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.

GO Product Roadmap Template

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. I find dates particularly valuable on internal roadmaps. If you use an external one, you may want to remove the row or use loose timeframes, such as, in the first six months of 2014.

The second row states the name or version of the releases, for instance, iOS 7 or Windows 8.1.

The third row provides the specific product goal of each major release or product version, the user/business benefit that should provide or the outcome you want to achieve. 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, key 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. 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 release was successful. Make sure that the metrics allow you to measure if and to which extent you have met the goal. Consider how long it takes after the release has become available to determine to determine goal attainment. For instance, if your goal is to acquire 1000 new users, then you may have to wait a few days to understand if your goal has been met.

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:

Sample GO Product Roadmap

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.

Learn More

Post a Comment or Ask a Question


  • Timothy Field says:

    Thanks for this Roman, really useful. The goals you have in your example roadmap are clearly business goals rather than user. Where do you see user needs fitting in here? The reason I ask is that you are clearly measuring business value against business needs but not articulating user success here. The two should be interrelated but sometimes they aren’t. For example a business need may be to shorten help desk call duration to reduce costs, this may lead to more automation features to achieve its aims. At the same time the customer satisfaction tanks as the service is downgraded. So from a roadmap perspective we measure “success” in this endeavour and actually fail our end customers. What’s your view on this?

    • Thank you for sharing your excellent question Timothy. You are absolutely right: I use business goals in the sample roadmap in the article. Generally speaking, I like to establish user/customer goals in the product strategy before I identify the business goals. The latter are derived from the former. User goals come first in my mind. When selecting product roadmap goal, I recommend deriving them from the user and business goals stated in the product strategy (as I explain in the article Leading Through Shared Goals). Practically speaking, you can either choose business-focused roadmap goals and indirectly express the user goals through the features (as I have done in the sample roadmap). Alternatively, you can work with dual goals that combine a user and business objective.

      As you indicate in your example, user and business goals can sometimes conflict. But this does not prevent you from formulating a dual goal like “Reduce cost whilst persevering customer satisfaction levels”. The challenge is to set a realistic cost saving target (in the metrics section of the GO roadmap) that does not lead to a drop in the appropriate customer metric like NPS. If you get it wrong, then user feedback on early product increments should indicate that the automation is going too far thereby impacting customer satisfaction and the cost saving target is too aggressive.

      Hope this helps!

  • Nosa says:

    Hey Roman! Thanks a lot for this! Your posts are really helpful. 2 Questions.

    1. Given the requirement of making the roadmap an [internally] public tool, is there a way of building the GO Product Roadmap in a cloud software like Trello? To make it easily accessible for stakeholders.

    2. Since you came up with this, is there anything about the Roadmap you would change/adjust to adapt to trends in the industry?


    • Thanks for sharing your feedback and questions Nosa. As I am not a Trello expert, I recommend that you refer to the Trello documentation to understand how you best use the tool to create a roadmap.

      My intention with the GO Product Roadmap template is to provide a starting point for product people. Adapt and extend the template as you wish (in accordance with the license agreement).

      Hope this helps!

  • Product Owner says:

    Hi Roman,

    Thank you for this article. This helps in a structured way of articulating the product value. I have a slightly different setup.
    We are looking at consolidating the XXX processes for a large global bank, across multiple regions. We want to offer a lot of these capabilities to the customer in a self serve manner and also keep the customer experience consistent across the various product lines and regions. Given that, what I feel is we are tasked with prioritizing across two parallel planes:
    1. Product features (the product capabilities, largely consistent across various business scenarios, but different enough to lead to additional specific development)
    2. Business scenarios (each business scenario is very specific to the product line and the business problem it is trying to solve)

    In such a setup, I’d like to understand your take on how to prioritize these from a product focus as my inputs are across two different perspectives.

    • Hi Ramya, Thanks for your question. I recommend you start with your business scenarios and clearly describe the value proposition, the target market, and business goals of each product line. Then think about how to differentiate the products in the marketplace and derive a portfolio roadmap for each line. You may also want to take another step and add separate roadmaps for the individual product. You may want to look at my Product Vision Board to capture and visualise the key pieces of information to enable you to create a roadmap. Does this help?

  • Toby says:

    Hi Roman,

    I am reading your book, Strategize, and am struggling a little as to whether a GO or featured based roadmap is most appropriate to the product I am developing at the moment. Essentially the team is working on a MVP, which is the consolidation of two market proven (albeit legacy) apps, so the level of risk in the first instance is low. Once released, the product will provide the foundation to start learning more about user needs through running small experiments and developing the product iteratively. The agreed approach is that we maintain the existing apps in their current form while we rebuild the front-end and refactor the backend in the background. This means we can bypass a significant amount of tech debt but it also means the first release to customers will further downstream, which may not appeal to many agile practitioners but in this circumstance I believe to be the right move as the MVP concept is already validated. From my perspective, we could initially generate a featured based roadmap as the first steps are based on the delivery of known needed features. We can then change to a GO approach when the MVP goes live and we are then working toward goals that require further validation from the market. Alternatively we could just establish a GO roadmap from the outset but I am not sure we would be using it as intended. I would really appreciate your thoughts.

  • Miles says:

    Hi Roman, I was interested in viewing the article on the Goal Oriented Portfolio Roadmap, however, the link takes you to this article. Is there a separate article explaining the Portfolio Roadmap?

    Thank you,

  • Amber Weaver says:

    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?

    • 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?

  • 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?

    • 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?

  • Scrum Sprint says:

    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.

  • Gab says:

    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?

    • 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?

  • Laura says:

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

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

4 Trackbacks

    Warning: call_user_func() expects parameter 1 to be a valid callback, function 'blankslate_custom_pings' not found or invalid function name in /nas/content/live/romanpichler/wp-includes/class-walker-comment.php on line 179

Leave a Reply

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