The Product Roadmap and the Product Backlog

Published on 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 the nexts, 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.

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 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.

Product Goal to Scope the Product Backlog


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.

Keeping the product roadmap and product backlog in synch

Post a Comment or Ask a Question

16 Comments

  • Iuliia says:

    Hi Roman,
    thank you for your materials. They all are very useful and concise.
    I have many requests from the stakeholders, users, and the development team for my product. Where do you advise to collect all these stories?
    I have this question because you advise focusing at the backlog on the tactical work for one quarter. But a lot of these requests are for long planning.
    Now I collect them at the backlog, but I understand that it is not easy to work with such a backlog.

    • Roman Pichler says:

      Hi Iuliia,

      Thanks for your feedback and sharing your question. As long as your product experiences a fair amount of change, I would recommend that you add the requests to the product roadmap, assuming that they are a. in line with the overall product strategy and b. related to a roadmap goal/outcome/benefit.

      If a. does not apply, I would discard the request, unless you decide to change the product strategy. If there is no roadmap goal that the request supports, then either rework your roadmap and introduce an new goal or amend an existing one or discard the request. Note that as long as your product experiences bigger changes, it is beneficial to have a concise product backlog that is easy to adjust.

      But when your product has matured and become stable, then you can work with a longer and more detailed product backlog. In this case, you could consider adding feature requests that affect future product releases or versions to the backlog. But I would still recommend ensuring that any request is in line with the product strategy and helps create value for the users or the business.

      Hope this helps!

  • Lucia Tonda says:

    Hello Roman! I have a question: We are 12 teams working on differents digital products and vinculated between them. Do you recommend some practices like “PO Sync” or “roadmap sync”? I read about the product roadmap portfolio (it was very useful) but I need some tool that helps me to sync with PO. Sorry for my English, I am from Argentina. Thanks for sharing your knowledge!

    • Roman Pichler says:

      Hi Lucia,

      Thank you for sharing your question. While I am not sure that I fully understand your challenge, there are three things that might help you: First, organise around products and have a stable group of product people looking after and one or more stable dev teams developing each product.

      Secondly, if your products are related, for example, they are licensed or released together, then establish a portfolio management process where you regularly identify and manage dependencies between the products. This may involve creating a product portfolio strategy and/or product portfolio roadmap.

      Thirdly, create a community of practice for the product people. Come together on a regular basis and share how you carry out your work and solve challenges. Review common standards; enhance existing ones and create new standards, for instance, which product portfolio roadmap format should be used.

      Does this help?

  • AMITABH KISHORE says:

    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.

  • Prasanna says:

    This is very usefull.

  • Jay Jay says:

    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 !

    • 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?

    • 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?

  • Ayang says:

    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.

    • 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!

  • 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!

  • Dylan says:

    Hi,

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

    Thanks!

2 Trackbacks

  • Iuliia says:

    Hi Roman,
    thank you for your materials. They all are very useful and concise.
    I have many requests from the stakeholders, users, and the development team for my product. Where do you advise to collect all these stories?
    I have this question because you advise focusing at the backlog on the tactical work for one quarter. But a lot of these requests are for long planning.
    Now I collect them at the backlog, but I understand that it is not easy to work with such a backlog.

    • Roman Pichler says:

      Hi Iuliia,

      Thanks for your feedback and sharing your question. As long as your product experiences a fair amount of change, I would recommend that you add the requests to the product roadmap, assuming that they are a. in line with the overall product strategy and b. related to a roadmap goal/outcome/benefit.

      If a. does not apply, I would discard the request, unless you decide to change the product strategy. If there is no roadmap goal that the request supports, then either rework your roadmap and introduce an new goal or amend an existing one or discard the request. Note that as long as your product experiences bigger changes, it is beneficial to have a concise product backlog that is easy to adjust.

      But when your product has matured and become stable, then you can work with a longer and more detailed product backlog. In this case, you could consider adding feature requests that affect future product releases or versions to the backlog. But I would still recommend ensuring that any request is in line with the product strategy and helps create value for the users or the business.

      Hope this helps!

  • Lucia Tonda says:

    Hello Roman! I have a question: We are 12 teams working on differents digital products and vinculated between them. Do you recommend some practices like “PO Sync” or “roadmap sync”? I read about the product roadmap portfolio (it was very useful) but I need some tool that helps me to sync with PO. Sorry for my English, I am from Argentina. Thanks for sharing your knowledge!

    • Roman Pichler says:

      Hi Lucia,

      Thank you for sharing your question. While I am not sure that I fully understand your challenge, there are three things that might help you: First, organise around products and have a stable group of product people looking after and one or more stable dev teams developing each product.

      Secondly, if your products are related, for example, they are licensed or released together, then establish a portfolio management process where you regularly identify and manage dependencies between the products. This may involve creating a product portfolio strategy and/or product portfolio roadmap.

      Thirdly, create a community of practice for the product people. Come together on a regular basis and share how you carry out your work and solve challenges. Review common standards; enhance existing ones and create new standards, for instance, which product portfolio roadmap format should be used.

      Does this help?

  • AMITABH KISHORE says:

    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.

  • Prasanna says:

    This is very usefull.

  • Jay Jay says:

    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 !

    • 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?

    • 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?

  • Ayang says:

    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.

    • 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!

  • 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!

  • Dylan says:

    Hi,

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

    Thanks!

  • […] Roman Pichler erklärt in seinem Blog das Zusammenspiel zwischen Product-Backlog und Product-Roadmap. […]

Leave a Reply

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