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.
Post a Comment or Ask a Question
39 Comments
Hi Roman, How do you differentiate between KPIs (in your article https://www.romanpichler.com/blog/how-to-choose-the-right-kpis-for-your-product/) and metrics in the GO Product Roadmap? What’s the difference? Does the time until goal attainment determine whether a given KPI should be listed as a metric on the GO Product Roadmap or not?
Thanks for sharing your question Maggie. The metrics on the GO product roadmap are the measurements that allow you to determine if the goals are met. As I mention in the article you referenced, I recommend adding the roadmap metrics to your set of key performance indicators (KPIs). They are therefore a subset of your KPIs. You are right that roadmap metrics are often associated with a time frame, unlike other KPIs that measure the progress towards meeting the needs and business goals (stated in the product strategy) and the product health. But I would always discover the metrics based on the goals of a specific roadmap–not based on a general set of KPIs. Hope this helps.
Gracias Roman , sos muy claro y generoso para explicar. Celebro que haya profesionales como vos , que dan acceso al conocimiento gratuito. Eso es un valor etico para la sociedad.-
You’re welcome Luz and thank you for your feedback!
Hi Roman,
I have a question here. While objectives can be used as goals and key results as more the product backlog as these are work items that lead to results. Second, why have Q4 in the roadmap, are we not locking the future feature and making it less flexible ?
Thank you for sharing your questions Afroze. Please take a look my article OKRs in Product Management, which should answer your first question. I left out Q4 for the sake of simplicity. Your second question should be addressed by article Should Product Roadmaps Have Dates? Hope this helps!
Hi Roman,
My teams are using objectives and key results (OKRs). Do you think this approach could complement or substitute a goal-oriented product roadmap? I am asking this because I can see some similarities in the elements of these two concepts.
I am looking forward to hearing your perspective 🙂 Thank you.
Hi Nora,
Thank you for sharing your question. You can view the product goals on the GO product roadmap as objectives and the features, metrics, and dates as key results, based on John Doerr’s definition of OKRs. Doerr states that an objective describes what is to be achieved. Key results determine how we get to the objective. You can therefore view the two approaches as being compatible.
This is probably no coincidence: I worked in the late 1990ies at Intel, where OKRs were invented. I’ve been a fan of working with goals ever since, see also my article “Leading Through Shared Goals“.
If I get round to it, I’ll write an article on OKRs and my product management tools 😉
Does this help?
Hello Roman, yes thanks, that helped a lot! Looking forward to that new article 🙂
Thank you! Nora
👍Hi Roman,
One question I have on this is should each time frame focus on one goal? In your example everything is neatly split into quarters for new goals, but would the value if the roadmap be diluted if for example there were 3 columns with a timeframe of Q1?
Thanks,
Dan
Hi Dan,
Apologies for replying to your questions so late. I don’t know how I managed to forget to answer it.
I recommend that you work with a single goal that describes a specific benefit or outcome your product should create for a given time frame. Having a single goal offers the following benefits:
It’s usually no big deal if you occasionally use more than one goal. But if you frequently struggle to select a single goal, then you may want to explore why that is. For example, are the time frames too big, or is it hard to get the stakeholders to to agree one goal?
Hope this helps!
Hi Roman
Thanks for this. I have been using it with my team and the idea if the Roadmap works really well with our OKRs. The Goal can be an OKR if we use the business lense, or it is required to address an OKR when we are using a customer lense.
One area I am struggling to answer is on the feature level and how it works with product discovery. We like to validate the hypothesis before the feature is added to the feature backlog.
In the example above are the features validated? Do we know that in Q3 our users want (or there is a business logic) to adding new characters and dance moves?
If so, when does this validation discovery happen? It seems like the features are added for a 12 months ahead, and they are granular enough to snooker us should something change in the market?
TL;DR – When do we do discovery and validation to get these features? What do we put down for features if the discovery and validation isn’t done?
Thank you again for the post and the tool.
Hi Paddy,
Thank you for your comment. To ensure that the features on a goal-oriented roadmap are valid, try the following:
Carry out initial product discovery work to create a validated product strategy. From the strategy, derive your product roadmap. Break the user, customers, and business goals on the product strategy into two- to three-months subgoals and order them by creating a compelling narrative or using cost of delay. Then explore which features or capabilities have to be in place to meet the goals–just like you determine key results based on the objectives selected. Keep the features coarse-grained and limit their number to three to five per goal.
While the upfront discovery work should equip you with enough knowledge to derive meaningful features from the roadmap goals, they need to be refined and tested. Start by deriving product backlog items from the features of the goal you are working towards and order them by risk. Then implement the riskiest ones, collect feedback from users, customers, and stakeholders and use the data to validate the features and decide if and how you proceed with them.
Finally, make sure that you regularly review and adapt your product strategy and roadmap–I suggest once per quarter as a rule of thumb–and make the reviews part of your continuous discovery process.
Does this help?
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!
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.
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!
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?
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.
Hi Toby,
Thanks for sharing your question. As you are developing a new product and plan to leverage experiments to decide how to evolve the product, I recommend that you use a goal-oriented product roadmap. Additionally, I would suggest using a release plan to develop the first release (MVP). Please see my article “The Product Roadmap and the Release Plan” for more information on how the two plans relate.
Does this help?
Many thanks Roman – much appreciated! It sounds like the sensible way to go. I notice you don’t attend Product Tank anymore. Do you do any other meetups?
Glad that my answer was helpful. You can find the events I attend at https://www.romanpichler.com/talks/. And I always try to attend ProductCamp London, which is my favourite product management conference. Would be nice to see you there!
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,
Hi Miles, You can find the GO Portfolio Roadmap article here: https://www.romanpichler.com/blog/the-go-portfolio-roadmap/
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?
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?
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.
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: https://www.romanpichler.com/blog/top-ten-product-backlog-tips/
P.S.:
I’m looking forward for your posts 😉
Thanks!