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.
Post a Comment or Ask a Question
20 Comments
Hi there. I’ve just moved into a product owner role which looks after a variety of internal digital products, e.g. health and safety tool, people and culture tool, finance team tools ie a raft of Enterprise type products. None are go-to-market products. I’m trying to understand how to best prioritise when contrasting one against the other given none generate returns in terms of revenue and are all very different. We work with business stakeholders and digital business partners (in lieu of product managers) so the PO’s operate more like SAFe PO,s in my opinion. Most of the products are mature or developed so most ideas are continuous improvements or similar. Any suggestions or tips for prioritising between really different products like described? Regards Nicholle
Thanks for sharing your question Nicole. Please take a look at my article The Product Portfolio Matrix, which describes a framework for managing a group of products. Additionally, you may find my article Six Types of “Product” Owners helpful, as it covers the role of a product portfolio owner in addition to the (Scrum) product owner. Hope this helps!
Hi Roman,
I find your work very helpful and it helped me a lot to wrap my head around the different artefacts like vision, strategy, roadmap, and backlog. I just recently have done a workshop together with my team to create a product vision board and roadmap for our project. It helped a lot to get a clear view of what has to be done over the next year.
However, I am struggling a bit with the interface between roadmap and backlog. The abstract concept is clear – the roadmap states the goals and high level features of a release and the backlog contains the steps towards the next goal. We are working with Jira to build our backlog and I am not quite sure how I can make the goal and next steps visible inside the backlog so that the team also keeps a clear focus. My first approach was to capture the features of the GO roadmap on a storyboard where I make them goals and then start to define epics underneath them which are milestones on the way to achieve a feature from the roadmap. Since I use the storyboard feature for that I can no longer have a user story / user journey in Jira.
If you could give some more tips how to get a good interface between backlog and roadmap on the practical side, that would be awesome.
Cheers,
Justin
Hi Justin, Thank you for sharing your feedback and question. It’s great to hear that you have found my work helpful. I am not a Jira expert and won’t be able to help you use the tool unfortunately. But I recommend that you use the next product goal on your roadmap and its features to determine the items in the product backlog. Copy the the features into your product backlog. Remove any items that are not required to meet the goal. Ask yourself which additional items are required to meet the goal and add them to the product backlog. Then prioritise the backlog, break down the high-priority items and refine them so that they are ready to be implemented.
Additionally, clearly distinguish between a product goal and a feature. The former describes a benefit or outcome you want to achieve; the latter captures the output that has to be delivered to meet the goal. Finally, if you work with releases that take more than four months to develop, then consider breaking them down into smaller development efforts, which last two to three months each and which are guided by their own product goals.
Hope this helps!
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.
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!
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!
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?
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.
Thanks for your feedback Amitabh, and good luck with separating the two artefacts!
This is very usefull.
Thanks for your feedback, Prasanna.
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?
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!
Hi,
I found this very helpful. Any insight regarding organizations structured with multiple product owners working on the same massive product?
Thanks!
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.