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 several major releases. 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 project progress in Scrum (using the release burndown chart). The following diagram summarises 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.
Derive the Product Backlog from the Product Roadmap
I recommend that you derive the product backlog from your roadmap, particularly when your product is still young or the market is dynamic. This assumes, however, that you have a realistic product roadmap that provides the right input for the backlog, such as a release goals and features.
You can take this approach further and focus your product backlog on the next product release. This creates a concise backlog that is easy to update and change—assuming that you expose product increments to users, collect and analyse user feedback and data, and incorporate new insights into the backlog. To do so, use the release goal on your roadmap to scope your product backlog, 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 Product Roadmap and Product Backlog in Synch
Be aware that the product backlog influences the product roadmap: the feedback you receive from exposing product increments to users may lead to roadmap adjustments, for instance. Similarly, if the work in the sprints does not progress as anticipated, you may have to update the roadmap and modify, for example, the goal or the date. It is therefore important that you keep the product roadmap and the product backlog in sync. Use the product roadmap to guide the grooming work 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 other key stakeholders.