The Product Roadmap and the Product Backlog

By Roman Pichler, 9th September 2014

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.

Product Roadmap vs. 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 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.

Deriving the Product Backlog from the Product Roadmap


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.

Keeping the Product Backlog and the Product Roadmap in Synch

Summary
Article Name
The Product Roadmap and the Product Backlog
Description
Find out how the product roadmap and the product backlog relate, and who should own the two artefacts.
Author

Learn More

You can learn more about product roadmapping with the following:

Source: http://www.romanpichler.com/blog/product-roadmap-product-backlog/

RSS Feed

Tags related to this post:


12 comments on “The Product Roadmap and the Product Backlog

  1. AMITABH KISHORE

    This is really helpful. We used to have a product backlog and called in Product Roadmap. I always though that the Product Roadmap should be different from Product Backlog as the prime objective of the Product Roadmap it to see the complete shape of the product after all the work is done. Maybe we take inputs from Product Backlog for Product Roadmap but it should be a separate document.

    • Roman Pichler

      Thanks for your feedback Amitabh, and good luck with separating the two artefacts!

  2. Prasanna

    This is very usefull.

    • Roman Pichler

      Thanks for your feedback, Prasanna.

  3. Jay Jay

    Hello Roman,

    Thanks a lot for this great work !

    I was wondering also where do User Stories stand in this planification ? Do User stories come after the backlog / roadmap or should we do it before in order to find out what are the best features to add ?

    Thank you !

    • Roman Pichler

      Hi Jay Jay, Thanks for your feedback. My preference is to derive the product backlog from the product roadmap. I then use the key features stated in the roadmap to discover the right user stories (together with the relevant personas). In a nutshell, the product roadmap provides the context for writing epics and user stories. This is particularly helpful as long as your product is young and there is a significant amount of uncertainty and change present. Does this help?

    • Roman Pichler

      Hi Jay Jay, Thanks for your feedback. My preference is to derive the product backlog from the product roadmap. I then use the key features stated in the roadmap to discover the right user stories (together with the relevant personas). In a nutshell, the product roadmap provides the context for writing epics and user stories. This is particularly helpful as long as your product is young and there is a significant amount of uncertainty and change present. Does this help?

  4. Ayang

    Hi Roman,
    Great Article! Are you able to shed some light on whether SCRUM or Agile practices (like epics and user stories) as a methodology can be used in situations when the business seeks to purchase a COTS solution? i.e. they want to choose between multiple software products and are not sure which product will meet their requirements? Is writing a requirements document to provide to suppliers the only way to go in this situation, especially when the business is unsure of which product they want to go with? Your thoughts on this are very much appreciated.

    • Roman Pichler

      Hi Ayang, Thanks for your feedback. I recommend that you run one or more tests to evaluate different COTS or third-party solutions. Ask yourself which question you want to answer or which assumption you want to validate. Then determine how you best go about it, for instance, if you should implement spikes and what the prototypes should focus on. Gather and evaluate the relevant data and use the new insights to make the right decision. Hope this helps!

  5. David McCotter

    I have worked on a lot of projects (60 – £12m) and this is the single biggest source of overrun and overspend i.e. a lack of “focus”.
    Normally a roadmap is a feature race using the product backlog instead of strategic thinking. Anything that can promote this gets my vote!

  6. Dylan

    Hi,

    I found this very helpful. Any insight regarding organizations structured with multiple product owners working on the same massive product?

    Thanks!

    • Roman Pichler

      Hi Dylan, Glad you found the post helpful. I have written about multiple product owners in my post Scaling the Product Owner. Please let me know if this does not answer your questions.

Leave a Reply

Your email address will not be published. Required fields are marked *