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 is a strategic product-planning tool that shows how the product is likely to grow across several major releases. This creates a continuity of purpose, facilitates stakeholder collaboration, helps acquire funding, and makes it easier to coordinate the development and launch of different products.

I prefer to work with a goal-oriented product roadmap that clearly states the benefits provided by each major release, particularly in an agile, dynamic environment. You can download my GO product roadmap template from romanpichler/tools/product-roadmap where more roadmapping information is available.

TheGORoadmapTemplate

The product backlog contains the outstanding work necessary to create a product including epics and user stories, workflow diagrams and storyboards, 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. The following diagram summarises the main differences of the two roadmap and the backlog.

RoadmapvsBacklog

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.

To successfully employ both tools, you have to decide if your product backlog should be derived from your product roadmap or the other way round. Let’s have a look at the two options and discuss when they are appropriate.


Option 1: Derive the Backlog from the Roadmap (Top-down)

Your first option is to derive your product backlog from your roadmap. This assumes that you have a product roadmap available and that the roadmap provides you with a helpful input for your backlog such as a product or release goal and some features.

RoadmapToBacklog

If you choose this option then I recommend that you focus your product backlog on the next product version or the major release, as the following picture illustrates.

BacklogDerivedFromRoadmap

This shifts the longer-term planning work to the roadmap and it results in a concise, short product backlog, which is comparatively easy to create and to update or “to groom”.


Option 2: Derive the Roadmap from the Backlog (Bottom-up)

Your second option is to derive the product roadmap from your product backlog. This assumes two things: First, you have a fairly long product backlog whose items cover more than the next release. Second, the backlog is stable enough to serve as an input for the roadmap.

BacklogToRoadmap

To employ this option, look through your backlog and identify common themes. Group the themes and assign them to major releases. If you use my GO product roadmap then you should also consider the benefit (or goal) of providing each release and you should state the appropriate metrics to determine if the benefit is realised. The picture below illustrates this approach.

ThemesBenefitsToCreateRoadmap

While your product backlog might still cover the same timeframe as the newly created product roadmap, the latter provides you with a high-level view of the likely growth of your product. This makes it easier to collaborate with the stakeholders including marketing, sales, service, and other business groups.


Top-down or Bottom-up?

To select the right option for creating your product roadmap and your product backlog, take a look at the lifecycle stage of your product. If your product is still changing significantly as you are, for instance, developing a brand-new one or you have recently launched the first version, I recommend that you first create your product roadmap and then derive your product backlog from it. In other words, as long as you have not achieved product-market fit and your product does not yet satisfy the customer and users needs well, you should employ a top-down approach.

RoadmapBacklogBeforePMF

If your product is stable and you have achieved product-market fit, you can consider using your backlog to create the roadmap.

RoadmapBacklogAfterPMF

Bear in mind though that markets can unexpectedly change and cause products to loose their market fit. I therefore recommend applying the top-down approach as the default or norm. In doubt, derive your product backlog from the product roadmap.


Roadmap and Backlog Ownership

As the product owner or product manager, you should lead the strategic and the tactical product decisions. You should therefore be responsible for the product roadmap and the product backlog. In an agile context characterised by uncertainty and unexpected change, the strategic product decision do not only influence the tactical ones, but the product details can significantly impact the product strategy. Customer feedback on a product increment can, for instance, cause a strategy change (pivot), which is likely to invalidate the product roadmap.

But you should not be the only person working with the roadmap and the backlog. The development team and the stakeholders, as the following picture illustrates.

RoadmapBacklogOwnership

Use the roadmap as the primary tool to achieve stakeholder alignment, to agree on the overall product direction, and the go-to-market strategy (that is, when which features are released). Use the backlog to decide on the product details including the user interaction, the product functionality, and the visual design. The conversations with marketing, sales, service, and the other business groups about the product direction and the product goals should therefore happen in the context of the product roadmap rather than the product backlog.


Learn More

You can learn more about working effectively with an agile product roadmap by attending my Agile Product Strategy and Roadmap training course and by reading my book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age.

Participating in my Certified Scrum Product Owner training course will help you improve your product backlog practices.

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

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

RSS Feed

Tags related to this post:


14 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 *