The Product Roadmap and the Product Backlog

Product Roadmap vs. Product Backlog

The product roadmap is a strategic product-planning tool that shows how the product is likely to grow across several major releases. This creates a continuity of purpose, facilitates stakeholder collaboration, helps acquire funding, and makes it easier to coordinate the development and launch of different products.

I prefer to work with a goal-oriented product roadmap that clearly states the benefits provided by each major release, particularly in an agile, dynamic environment. You can download my GO product roadmap template from romanpichler/tools/product-roadmap where more roadmapping information is available.

The product backlog contains the outstanding work necessary to create a product including epics and user stories, workflow diagrams and storyboards, user-interface design sketches and mock-ups. It is a tactical tool that directs the work of the development team and that provides the basis for tracking the project progress in Scrum. The following diagram summarizes the main differences of the two roadmap and the backlog.

Applied correctly, the two tools complement each other nicely. The product roadmap provides an umbrella for the product backlog; it tells a longer-term story about the likely growth of the product whereas the product backlog contains the details necessary to create the product.

To successfully employ both tools, you have to decide if your product backlog should be derived from your product roadmap or the other way round. Let’s have a look at the two options and discuss when they are appropriate.

Option 1: Derive the Backlog from the Roadmap (Top-down)

Your first option is to derive your product backlog from your roadmap. This assumes that you have a product roadmap available and that the roadmap provides you with a helpful input for your backlog such as a product or release goal and some features.

If you choose this option then I recommend that you focus your product backlog on the next product version or the major release, as the following picture illustrates.

This shifts the longer-term planning work to the roadmap and it results in a concise, short product backlog, which is comparatively easy to create and to update or “to groom”.

Option 2: Derive the Roadmap from the Backlog (Bottom-up)

Your second option is to derive the product roadmap from your product backlog. This assumes two things: First, you have a fairly long product backlog whose items cover more than the next release. Second, the backlog is stable enough to serve as an input for the roadmap.

To employ this option, look through your backlog and identify common themes. Group the themes and assign them to major releases. If you use my GO product roadmap then you should also consider the benefit (or goal) of providing each release and you should state the appropriate metrics to determine if the benefit is realised. The picture below illustrates this approach.

While your product backlog might still cover the same timeframe as the newly created product roadmap, the latter provides you with a high-level view of the likely growth of your product. This makes it easier to collaborate with the stakeholders including marketing, sales, service, and other business groups.

Top-down or Bottom-up?

To select the right option for creating your product roadmap and your product backlog, take a look at the lifecycle stage of your product. If your product is still changing significantly as you are, for instance, developing a brand-new one or you have recently launched the first version, I recommend that you first create your product roadmap and then derive your product backlog from it. In other words, as long as you have not achieved product-market fit and your product does not yet satisfy the customer and users needs well, you should employ a top-down approach.

If your product is stable and you have achieved product-market fit, you can consider using your backlog to create the roadmap.

Bear in mind though that markets can unexpectedly change and cause products to loose their market fit. I therefore recommend applying the top-down approach as the default or norm. In doubt, derive your product backlog from the product roadmap.

Roadmap and Backlog Ownership

As the product owner or product manager, you should lead the strategic and the tactical product decisions. You should therefore be responsible for the product roadmap and the product backlog. In an agile context characterised by uncertainty and unexpected change, the strategic product decision do not only influence the tactical ones, but the product details can significantly impact the product strategy. Customer feedback on a product increment can, for instance, cause a strategy change (pivot), which is likely to invalidate the product roadmap.

But you should not be the only person working with the roadmap and the backlog. The development team and the stakeholders, as the following picture illustrates.

Use the roadmap as the primary tool to achieve stakeholder alignment, to agree on the overall product direction, and the go-to-market strategy (that is, when which features are released). Use the backlog to decide on the product details including the user interaction, the product functionality, and the visual design. The conversations with marketing, sales, service, and the other business groups about the product direction and the product goals should therefore happen in the context of the product roadmap rather than the product backlog.

Learn More

You can learn more about working effectively with an agile product roadmap by attending myAgile Product Strategy and Roadmap training course. You can improve your product backlog practices by participating in my Certified Scrum Product Owner training course. Please contact meif you are interested in having the courses delivered at your office.