The product backlog is a great tool to capture ideas and requirements. But it is less suited to describe how the product is likely to develop in the longer term. This is where the product roadmap comes in. But how do the product backlog and the product roadmap relate? Is the backlog derived from the roadmap or is it the other way round? Should the product owner be responsible for both artefacts? Read on to find out my recommendations.
Product Roadmap vs. Product Backlog
The product roadmap and the product backlog are two important product management tools. Each tool has its own strengths and weaknesses: The product roadmap is a strategic product-planning tool that shows how the product is likely to grow across the next, say, 12 months. It creates a continuity of purpose, facilitates stakeholder collaboration, helps acquire funding, and makes it easier to coordinate the development and launch of different products.
The product backlog contains the outstanding work necessary to create a product including epics and user stories, workflow diagrams, 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 development progress using, for example, a release burndown chart. The following diagram summarises the main differences of the product roadmap and the product 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 progress the product in the next few months.
Derive the Product Backlog from the Product Roadmap
I Find it helpful to derive the product backlog from the product roadmap. This assumes, however, that you have a realistic roadmap in place that provides the right input for the backlog, particularly product goals that capture the desired benefits or outcomes your product should provide. Sample goals might be acquire users, increase engagement, and remove technical debt to future-proof the product.
You can take this approach further and focus your product backlog on the next product goal. This creates a concise backlog that is easy to update and change, which is particularly useful as long as your product changes and grows. To do so, use the next product goal on your roadmap to scope your product backlog and determine the right contents, as the following picture illustrates.
Minimise any Overlap between the Roadmap and the Backlog
Unfortunately, I find that product roadmaps can contain too many details, including epics and user stories, and that some product backlogs look too far into the future. This blurs the line between the two artifacts; it results in a product roadmap that is difficult to understand, prone to change, and overly long and hard to manage.
Therefore keep the two tools separate and leverage their respective strengths. Employ the roadmap to describe your product’s overall journey and the backlog to capture the details. Don’t add epics and stories to your product roadmap. Stick to high-level features and product capabilities instead.
Keep the Product Roadmap and Product Backlog in Synch
Be aware that the product backlog also influences the product roadmap: Bigger product backlog updates can trigger product roadmap adjustments. Similarly, if the development progress is not as anticipated, you may have to update the product roadmap and modify, for example, the goal or date.
It is therefore important that you keep the product roadmap and the product backlog in sync. Use the product roadmap to determine the backlog contents, as mentioned above, and consider the product backlog changes when you review the product roadmap. Reviews should happen on a quarterly basis, as a rule of thumb, and involve dev team representatives and the key stakeholders.
