Photo courtesy of Pexels

The Product Roadmap and the Release Plan

Published on 16th August 2016 Last Updated on: 21 Dec 2021

Release planning and product roadmapping are both important practices to achieve product success. But what’s exactly the difference between a release plan and a product roadmap? How do the two tools fit together? This post answers these questions so you can apply the two planning artefacts effectively.

What is a Release Plan?

A release plan forecasts how a major release is developed. It’s a type of project plan—albeit an agile one—and it usually covers the next three to six months. I use the term major release to refer to a version of your digital product that introduces a noticeable change, for instance, by adding or optimising functionality or enhancing the user experience, and it typically results in a new product version—think of Windows 10 or iOS 9.3, for example.

Release plans come in different shapes and sizes depending on the process used. In Scrum, the release burndown chart is the default release plan. It helps you track the progress from sprint to sprint, anticipate if the relevant product backlog items can be delivered on time and budget (or how long it will take and how much it will cost), and make the necessary adjustments, such as, reduce or remove a feature, or add a new team member to the team. The following picture shows a sample release burndown chart.

The Release Burndown Chart as a Release Plan

In the chart above, the vertical axis captures the remaining effort in the product backlog required to create the next release, and the horizontal axis captures the number of sprints necessary or available to develop the release. The first data point on the chart is the estimated effort of the entire product backlog before any development has taken place.  To arrive at the next data point, you determine the remaining effort in the product backlog at the end of the first sprint. Then draw a line between the two points. The burndown line shows the progress that has been made, and after a few sprints you should see a trend emerge and be able to forecast future progress. The forecast is represented by the dotted line in the chart above.


What is a Product Roadmap?

A product roadmap communicates how a product is likely to evolve across several major releases. Unlike the release plan, it is a product plan that looks beyond an individual project or release: It describes the journey you want to take your product on over the next 12 months or so—much like a roadmap helps you plan a road trip.

Product roadmaps vary in their format. I prefer to work with goal-oriented roadmaps (also called outcome-based roadmaps). As their name suggests, these roadmaps focus on the goals the upcoming releases should provide. The picture below shows the GO Product Roadmap, a specific goal-oriented roadmap format that I have created. You can download the roadmap template from romanpichler.com/tools or by clicking on the following image.

The GO Product Roadmap Explained

Let’s take a quick look at the rows of the GO roadmap in the picture above from top to bottom. The first row captures the date or the time frame when a new product release should be available—for example, 1 March 2015, or first quarter 2015. As explained in my post 10 Tips for Creating an Agile Product Roadmap, I recommend using dates or timeframes on internal product roadmaps and omitting them on external ones, that is, on roadmaps that are shown to (prospective) customers. The second row states the name of the release like iOS 9.3 or Windows 10 mentioned before.

The third row is the most important part of the GO roadmap. As its name suggests, it states the goal you want to achieve, the benefit you want to offer. You can think of the goal as a release goal if you work with major releases that package up feature enhancements or releases to make them available at the same time to the users. Sample goals include acquiring users, improving the user experience, and removing technical debt. The fourth row lists the product’s features that are necessary to meet the goal. Derive the features from the goals and ensure that they help create the desired benefits. Focus on what really counts; limit yourself to five features per goal, and keep the features coarse-grained. The fifth and final row captures the metrics to determine if a goal has been met—for example, x amount of users employ the product for at least thirty minutes per day within two weeks after the release becomes available. Stating the metrics ensures that the goals on your roadmap are specific and measurable.


How do the Release Plan and Roadmap Relate?

I find it helpful to think of the product roadmap as a high-level plan that sketches out the major stages of a road trip, including overnight stops. The release plan then states how each stage is likely to unfold. My preference is therefore to derive the release plan from the product roadmap (with the help of the product backlog) and to use the release plan to forecast how a specific product goal on the product roadmap is met. The following picture shows the relationship between the three artefacts.

The Product Roadmap, the Release Burndown, and the Product Backlog

Don’t forget to keep the product roadmap and the release plan in synch. Bigger changes in the release plan are likely to impact the roadmap. If, for instance, the development progress is slower than anticipated, then this will not only impact the release plan but it might also affect the product roadmap.

The following table summarises the key differences between the release plan and product roadmap.

Artefact Characteristics Timeframe Contents
Release Plan Project plan, tactical 3 to 6 months Product backlog items, including user stories
Product Roadmap Product plan, strategic 12 months Product/release goals, high-level features / product capabilities

Post a Comment or Ask a Question

12 Comments

  • Priya Venkatesan says:

    Very practical amazing article. Can you recommend a tool for tracking release burndown?

    • Roman Pichler Roman Pichler says:

      Thanks for your feedback Priya. Personally, I like to create a release burndown using simple tools like paper and pen or an electronic spreadsheet, preferably together with the development team. The latter helps with developing a realistic forecast. Hope this helps!

  • Barak says:

    Hi Roman,
    First of all thanks for your blogs they are very helpful. I downloaded the tool of The GO Portfolio Roadmap and I have few questions to ask you about, I will be glad to get some answers.

    1. What kind of data should I suppose to write there?
    2. Do I need to write only the features that I want to develop?
    3. I am building a new digital product from scratch and now I am in the phase of customers and users interviews – it takes time 🙂 do I need to add this to my roadmap? I am little bit confused.

    I am new in the product management world , I am coming from a software development so I don’t know how to do strategy and roadmap.

    Hope you understand my issues 🙂 Thanks

    • Roman Pichler Roman Pichler says:

      Hi Barak,

      Thank you for sharing your feedback and question. As you are developing a new product, I suggest that you first create an initial product strategy as part of your product discovery work and validate it, for example by conducting more user interviews or carrying out direct observation. Second, derive a product roadmap form your strategy and ensure that it is actionable. Finally, use the roadmap to stock the initial product backlog. I wouldn’t worry too much about creating a product portfolio roadmap, unless the new product extends an existing portfolio and needs to be aligned with the other portfolio members.

      Hope this helps!

  • Kanny says:

    in agile what should trigger updates to the information in a release plan? list what are all the factors?

    • Roman Pichler Roman Pichler says:

      Hi Kanny,

      A release plan like the Release Burndown Chart takes into account three factors: the outstanding work in the product backlog (which is to be done to reach the release goal), the development team’s progress (velocity), and the rate of change in the product backlog (items being added or removed; items being re-estimated). I find it helpful to review the progress at the end of a sprint and update the Release Burndown Chart, as I describe in my book Agile Product Management with Scrum.

      Hope this helps!

  • Ronny Matthies says:

    Hi, I´m currently writing on my masters thesis which is about how to use agile practices in order to achieve certain maturity levels of the CMMI-DEV (1.3) model. For the process area of project planning, CMMI is requesting a release plan that not only contains a fixed release date but also comes with a given resource allocation and a cost and budget estimate. Working as a product owner for over 10 years now, I never encountered such a release plan within an agile environment; in fact for me this sounds much like a typical “Waterfall” project plan. However I would be really interested on your statement regarding this topic.
    Thanks lots!

    • Roman Pichler Roman Pichler says:

      Thanks for sharing your question Ronny. It’s been a long time since I’ve sone some work with CMMI, and I am probably not the best person to answer your question. You can, however, happily have a fixed date and budget on an agile project if you are flexible on the scope. Assuming that the development team composition stays constant throughout the project and that you don’t require any upfront work item / task allocation, there might not be a contradiction between the CMMI requirements and an agile way of working. Hope this helps!

  • Blake Browning says:

    Hello, I am a product owner of a 3 different delivery teams that at once could be working on more than 20 products. We are trying to consolidate so we can focus on the most important ones, but would you build a product roadmap by delivery team or by product? It seems that by product may have less meaning in this context.

    • Roman Pichler Roman Pichler says:

      Hi Blake,

      Thanks for sharing your question. If you have three products, then I would use a separate product roadmap for each product–unless the products are closely related and from portfolio, think of Microsoft Office, for example. In the latter case, you might find it helpful to create a portfolio roadmap that shows the products together in a single plan. I would also recommend aligning the teams with the products so that each team works on one product. This facilitates teamwork and continuous improvement. Hope this helps!

  • Gabe Storm says:

    I’m a bit confused by the GO Product Roadmap. Having the release date at the top implies that the roadmap is driven by the release plan. But it seems like the flow should go in the opposite direction, with an actual release date only committed to once the work is assigned to a sprint.

Leave a Reply

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

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.