The Product Roadmap and the Release Plan

By Roman Pichler, 16th August 2016
Photo courtesy of Pexels

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 to 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 theme-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

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 of a release, the benefit it should provide, and the reason for creating it. 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 release, and keep the features coarse-grained. The fifth and final row captures the metrics to determine if a release 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 release 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 Planning Horizon Contents
Release Plan Project plan, tactical 3 to 6 months Product backlog items, including user stories
Product Roadmap Product plan, strategic 12 months Release goals, high-level features / product capabilities
Summary
Article Name
The Product Roadmap and the Release Plan
Description
Release plans and product roadmaps are important tools. Discover how the two plans plan differ and how they complement each other.
Author
Pichler Consulting

Learn More

You can learn more about release planning and product roadmapping with the following:

Source: http://www.romanpichler.com/blog/product-roadmap-vs-release-plan/

RSS Feed

Tags related to this post:


4 comments on “The Product Roadmap and the Release Plan

  1. Blake Browning

    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

      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!

  2. Gabe Storm

    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 *