Photo courtesy of Pexels

10 Tips for Creating an Agile Product Roadmap

Published on 20th July 2016

A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders, and to acquire a budget for developing the product. But creating an effective roadmap is not easy, particularly in an agile context where changes occur frequently and unexpectedly. This post shares ten practical tips to helps you create an actionable agile product roadmap.

10 Tips for Creating an Agile Product Roadmap

 
Play/Pause Episode
00:00 / 00:18:34
Rewind 30 Seconds
1X

1 Focus on Goals and Benefits

Whenever you are faced with an agile, dynamic environment—be it that your product is experiencing significant change or that the market is dynamic with new competitors or technologies introducing change, you should work with a goal-oriented product roadmap, sometimes also referred to as theme and outcome-based.

Such a roadmap focuses on goals, benefits, or outcomes like acquiring customers, increasing engagement, and removing technical debt. Features may still exist, but they should be derived from the goals and used carefully. I like to recommend using no more than three to five features per goal, as a rule of thumb.

To help you develop your agile product roadmap, I have created a goal-oriented roadmap template called the GO Product Roadmap. It consists of five elements: date, name, goal, features, and metrics, as the picture below shows. You can download the template for free from romanpichler.com/tools, and you can find more information on how to use it in my post “The GO Product Roadmap“.

The GO Product Roadmap Template


2 Do the Necessary Prep Work

Before you create your roadmap, capture and validate the product strategy. I like to regard the strategy as the path chosen to realise your vision and the roadmap as an actionable product plan that communicates how the strategy is implemented. In other words, I like to derive the roadmap from the strategy.

An effective strategy should describe the product’s value proposition, the target market. standout features, and business goals. Make sure that you can confidently state these, that you have done the necessary product discovery and validation work. Otherwise, you risk creating a product roadmap that is not realistic and actionable.

Product Strategy and Product RoadmapI like to use my Product Vision Board to describe the product strategy. The board captures the vision, the target group, the problem to be solved or the benefit to be provided, the key features of the product, and the business goals. You can download the Product Vision Board template from romanpichler.com/tools/ for free.


3 Tell a Coherent Story

Your product roadmap should tell a coherent story about the likely growth of your product. Each goal should build on the previous one, particularly as long as your product has not reached maturity.

To come up with the right roadmap narrative, try the following two tips: First, break the user, customer, and business goals stated in the product strategy into specific and measurable subgoals. Then order the subgoals so that they form a coherent story. If I wanted to offer a healthy eating product, for example, that helps middle-aged men reduce the risk of developing type-2 diabetes, the the goal of the first, initial release (MVP) might be to build a user community. The goal of the second release might be to increase engagement, and the goal of the third one might be to generate revenue.

Second, resist the temptation to add goals and features to the product roadmap to please powerful stakeholders or broker a deal. While I am a big fan of collaborative product roadmapping, this should not result in weak product decisions and compromises, see my tips “Secure Strong Buy-in” and “Have the Courage to Say No” below. 


4 Keep it Simple

Be careful not to add too many details to your product roadmap. Keep your roadmap simple and easy to understand. Capture what really matters and leave out the rest by focusing on the goals. Keep the features on your roadmap coarse-grained and derive them from the goals. Do not show epics or user stories on your product roadmap but keep them in the product backlog. Use the product roadmap as a strategic product plan and the product backlog as a detailed one that facilitates execution, as the picture below shows.

Product Roadmap and Product Backlog


5 Secure Strong Buy-in

The best product roadmap is worthless if the people required to develop, market, and sell the product don’t buy into it. A great way to get to agreement is to collaborate with the key stakeholders and involve them in creating and updating the product roadmap. This allows you to leverage their ideas and knowledge, it creates shared understanding, and it makes it more likely that people will support the plan.

Running a collaborative roadmapping workshop is a great way to engage everyone and create a shared product roadmap, as the following picture illustrates.

Product Roadmapping Workshop

Make sure, though, that you ask a skilled facilitator, for instance, your Scrum Master, to facilitate the workshop. This includes choosing the right decision rule, for example, consent, and ensuring that everyone is heard and nobody dominates.


6 Have the Courage to Say No

While you want the key stakeholders to support the product roadmap, you should not make the mistake to say yes to every idea and request. This would turn your product into a feature soup, a random collection of features. “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features,” said Steve Jobs. Use your vision and product strategy to make the right decisions.

But before you explain why an idea or request cannot be added to the product roadmap, carefully listen to the stakeholder’s idea. Take a genuine interest in what the individual  has to say and seek to understand her or his underlying need or motivation. This makes the person feel valued and understood, which will make it more likely that the individual is able to hear a negative answer and is still willing to support the roadmap.


7 Know When to Show Dates

Dates on product roadmaps has been a hotly debated topic amongst some product people for a while. I recommend using dates or time frames on an internal roadmap that coordinates the work carried out by the internal stakeholders, such as, marketing, sales, and support, and the development team. This helps you make important trade-off decisions between shipping on time and fully meeting a goal. What’s more, it provides clarity for the stakeholders and development teams helping them do their work.

But when you use an external roadmap that is shown to customers and users and often used as a sales tool, then I suggest not showing any dates or time frames but sequencing your releases and possible employing a now-next-later grid to order them. Please see my article “Should Product Roadmaps Have Dates?” for more information.


8 Make your Roadmap Measurable

When using a goal-oriented roadmap, ensure that every goal is specific and measurable so you can tell if you have met the goal or not. If your goal is to acquire customers, for example, then ask yourself how many new customers should be acquired; and if your goal is to reduce technical debt, determine how much of the bad code should be removed or rewritten.

If you don’t state a target, it will be hard to tell if you have met the goal or not. Make sure, though, that you state a realistic target, and that the goals on your roadmap are realistic. Then select the metrics that will help you determine if a goal has been met and if a release has delivered the desired benefit.


9 Determine Cost Top-Down

Whenever your product experiences a significant amount of change and innovation, I recommend that you do not attempt to determine the development cost bottom-up but rather top-down. It’s virtually impossible to derive the right epics and user stories from the roadmap features, get correct estimates from your team, and accurately anticipate the velocity and the rate of change in the product backlog. Even if you manage to make it work, you will end up with an overly long and complex product backlog that is difficult to adjust and maintain. What’s more, it can take days—and in some cases weeks—to turn the features into well-defined requirements and to come up with detailed estimates.

Instead, determine how many people with which skills are likely to be required to create the desired releases on the roadmap. Draw on your experience of developing similar products or previous versions of the same product; consider whether enough people with the right expertise are available in your company, or if you will have to hire or contract people. This should give you an indication of the likely labor cost required. Then add the cost for facilities, infrastructure, materials, licenses, and other relevant items. Carry out this exercise together with the development team.

Determine Cost Top Down


10 Regularly Review and Adjust the Roadmap

Last but not least: If the environment you’re in is agile, then change is likely to occur. You should therefore regularly review and update your product roadmap—between every four weeks to every three months depending on how young your product and how dynamic the market is.

Product Roadmap Review Frequency

Combine your product roadmap and product strategy reviews. This ensures that the two plans are kept in synch, that bigger roadmap changes are reflected in the strategy and vice versa.

Post a Comment or Ask a Question

18 Comments

  • Your blogs are always helpful and who are managing the agile projects, they can get useful tips after reading this article. Thanks for sharing this useful info.

  • Wei Zhu says:

    Hi Roman,
    Thank you for sharing your knowledge of Agile product management! I learned a lot from your books (Strategize) and your blogs.

    Regarding setting the release goals on product roadmap, I have one question:

    Should we set goal from perspectives of company’s benefits (business goals) or from user’s perspectives? Example of company business perspective goal might be “increase retention rate by 2%”. Example of user perspective goal might be “Optimize the user experiences” .

    Thanks,

    Wei

    • Hi Wei,

      Thank you for your feedback and question. If your product’s business goals are tied to the user needs/goals, which I would recommend, then you can choose either option. I’ve used business goals in past and expressed the user benefit indirectly by deriving the appropriate features. But you may want to try working with dual goals, for example, “Make it easier for users to do and increase retention by “, in order to clearly express the benefits for the users and business. I’ve written more about the relationship of product strategy and roadmap goals in my article “Leading through Shared Goals“.

      Hope this helps!

  • Steve Forbes says:

    I just stumbled upon this article – still relevant in 2019!

    I think the hardest part of product management is getting buy-in, and creating alignment to go from vision to execution via the feature roadmap.

    I have been running a bunch of workshops using a tool similar to your Product canvas, and simply getting people to focus on our goals up front has been great at killing off any discussion about features that aren’t contributing to our strategic objectives.

  • Jessie Beck says:

    Number 8 is so important — thanks for mentioning that! I think it’s really easy to launch something and forget to look back and report on the success of it after the fact, but by writing in metrics to measure it by during the planning process, you’re in a sense holding yourself accountable to measure by those metrics later on.

  • Simon Emery says:

    Great article – I just finished reading Strategize and this is a good breakdown of the key points I used to get buy in from/feedback from the team/senior management .

    One question if I may. Our current roadmap also has the development time blocked out to show when the team is working on a feature – does this need to be included or should the roadmap just show targeted release?

    Many Thanks
    Simon

  • Wilson Peng says:

    Very good post. User feedback and surveying is another important part that I think all product managers should do as well 🙂

  • ms dynamics says:

    Very insightful! Thank you for this article. I especially like the part about creating a story about the product. I’m now thinking of launching a new product on the market and this article helped me a lot.

  • Carolyn Bimrose says:

    Fab article. So clear and straightforward. Thanks for sharing.

  • Josh Carroll says:

    Great article. Very helpful and simplistic way to break down some of the challenging pieces of managing products in an Agile environment.

  • Özmen Adıbelli says:

    I am trying to find ways to start a new product. I am reading your posts and video for the last 2 hours, and convinced to use these steps you wrote above 🙂

    I am curious about “5 Get Buy-in” step in details. Another post just for this step would be great. Just a little feedback.

    Thank you.

  • PeterL says:

    Answered a lot of questions that I had from watching the video; many thanks. Looking forward to using the GO roadmap for new proects going forward.

  • Hodmi says:

    Like so many brilliant ideas, the greatness lies in it’s simplicity.

    I’ve spent weeks trying to explain a new product concept to senior management without success.

    Then I took a couple of hours to put together a Vision Board and Go Roadmap with my team. The bosses finally get it and the development team has a well defined sense of direction.

4 Trackbacks

  • Your blogs are always helpful and who are managing the agile projects, they can get useful tips after reading this article. Thanks for sharing this useful info.

  • Wei Zhu says:

    Hi Roman,
    Thank you for sharing your knowledge of Agile product management! I learned a lot from your books (Strategize) and your blogs.

    Regarding setting the release goals on product roadmap, I have one question:

    Should we set goal from perspectives of company’s benefits (business goals) or from user’s perspectives? Example of company business perspective goal might be “increase retention rate by 2%”. Example of user perspective goal might be “Optimize the user experiences” .

    Thanks,

    Wei

    • Hi Wei,

      Thank you for your feedback and question. If your product’s business goals are tied to the user needs/goals, which I would recommend, then you can choose either option. I’ve used business goals in past and expressed the user benefit indirectly by deriving the appropriate features. But you may want to try working with dual goals, for example, “Make it easier for users to do and increase retention by “, in order to clearly express the benefits for the users and business. I’ve written more about the relationship of product strategy and roadmap goals in my article “Leading through Shared Goals“.

      Hope this helps!

  • Steve Forbes says:

    I just stumbled upon this article – still relevant in 2019!

    I think the hardest part of product management is getting buy-in, and creating alignment to go from vision to execution via the feature roadmap.

    I have been running a bunch of workshops using a tool similar to your Product canvas, and simply getting people to focus on our goals up front has been great at killing off any discussion about features that aren’t contributing to our strategic objectives.

  • Jessie Beck says:

    Number 8 is so important — thanks for mentioning that! I think it’s really easy to launch something and forget to look back and report on the success of it after the fact, but by writing in metrics to measure it by during the planning process, you’re in a sense holding yourself accountable to measure by those metrics later on.

  • Simon Emery says:

    Great article – I just finished reading Strategize and this is a good breakdown of the key points I used to get buy in from/feedback from the team/senior management .

    One question if I may. Our current roadmap also has the development time blocked out to show when the team is working on a feature – does this need to be included or should the roadmap just show targeted release?

    Many Thanks
    Simon

  • Wilson Peng says:

    Very good post. User feedback and surveying is another important part that I think all product managers should do as well 🙂

  • ms dynamics says:

    Very insightful! Thank you for this article. I especially like the part about creating a story about the product. I’m now thinking of launching a new product on the market and this article helped me a lot.

  • Carolyn Bimrose says:

    Fab article. So clear and straightforward. Thanks for sharing.

  • Josh Carroll says:

    Great article. Very helpful and simplistic way to break down some of the challenging pieces of managing products in an Agile environment.

  • Özmen Adıbelli says:

    I am trying to find ways to start a new product. I am reading your posts and video for the last 2 hours, and convinced to use these steps you wrote above 🙂

    I am curious about “5 Get Buy-in” step in details. Another post just for this step would be great. Just a little feedback.

    Thank you.

  • PeterL says:

    Answered a lot of questions that I had from watching the video; many thanks. Looking forward to using the GO roadmap for new proects going forward.

  • Hodmi says:

    Like so many brilliant ideas, the greatness lies in it’s simplicity.

    I’ve spent weeks trying to explain a new product concept to senior management without success.

    Then I took a couple of hours to put together a Vision Board and Go Roadmap with my team. The bosses finally get it and the development team has a well defined sense of direction.

  • […] Mole and Sandy Mamoli of Trade Me on Migrating to Spotify’s Squad Model – Rafiq Gemmail 10 Tips for Creating an Agile Product Roadmap – Roman Pilcher The day video games ate my school child – Mind Hacks How to Take Notes […]

  • […] Learn how to create a powerful agile product roadmap that helps you describe how your product is likely to grow and aligns the stakeholders.  […]

  • […] 1 Do the Prep Work Describe and validate the product strategy – the path to realise your vision – before you create your roadmap and decide how the strategy is best implemented. The following picture illustrates this approach.  […]

Leave a Reply to PeterL Cancel reply

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