Rolling Wave Planning for Product Roadmaps

 

For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) toolkit, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few. This article explores how to apply rolling wave planning in a pragmatic manner to product roadmaps.

An important aspect of product management is to develop and evolve an overall business vision, an important part of which is your organization’s product roadmap. This is sometimes called a “multiple product roadmap” or “product offerings roadmap” although more commonly just a “product roadmap.” This roadmap indicates upcoming product releases (or application releases for non-product companies), potential product ideas, and the retirement of any products. The goal is to manage customer expectations regarding your product portfolio.

An example of a product roadmap for a fictitious company is depicted in Figure 1 below. For product planning this company’s very near term (green) is a three month, rolling period. In this case we’re seeing the roadmap as of September 2016. For the very near-term the expected release dates of each product are indicated. This company has chosen to also do this for some, but not all, of the products being release din the near term (yellow) – In some cases it isn’t yet clear exactly when a release will occur so the company doesn’t want to set unrealistic expectations by giving an exact date yet. In the case of Katana 12.1 they are committing to a date whereas with Webshooter 1 they are committing to sometime during quarter 2 (April through June). The other product releases do not have published dates yet.

Figure 1. A product roadmap (text approach) from September 2016.

It’s interesting to note that for upcoming (red) they are choosing to just indicate new products they hope to release during that period but not releases of existing products. This is because this period is nine months or more into the future so promising exact dates to people becomes a questionable proposition, far better to indicate ranges for now. For the distant future (gray) the product roadmap shows potential ideas for new products but these are only vague “wish list” items at best right now, not all of which will be invested in.

Figure 2 depicts a timeline version of a product roadmap. It focuses on currently planned product releases and so it does not depict the future product ideas that we saw in Figure 5.   These product ideas would be captured elsewhere, perhaps as a list on a whiteboard some where.

Figure 2. A timeline version of a product roadmap.

What Should the Planning Horizon Be?

Product roadmaps tend to have a multi-year planning horizon. Figure 1 showed about two years of planning whereas Figure 2 a bit more than a year. There are several key considerations to take into account when determining your planning horizon. First is how often can your teams release? You typically want to be able to indicate several releases of your major products/solutions on your roadmap, which you can see in both examples. Second, how often do your customers want releases?   Third, how far in advance do your customers need to plan? This is a reflection of the sales cycle for your products, the longer the sales cycle the longer between releases of your product (usually) and the longer the timeframe covered by your roadmap.

How to Capture Product Roadmaps

There are two basic strategies for depicting product roadmaps:

1. Text lists. Figure 1 is an example of this format. The advantages are that this format is compact and easy to create with simple tooling. The main disadvantages are that it doesn’t show relationship between releases well nor is it very attractive visually.
2. Timeline diagrams. See Figure 2 for an example. The advantages of this approach are that it is visually appealing, which is particularly important when you are showing the roadmap to customers; it depicts timing relationships well; this format is supported by several product management tools; and you can even show dependencies between product releases, in a similar manner as you would do so on a Gantt chart (we didn’t do this in Figure 6). The primary disadvantage is that this format requires more sophisticated tooling to create.

Your product roadmap is an important part of your organization’s overall business vision. Another part of that vision is your business roadmap, the topic of a future blog.