...there is a product Vision for the organization. It is important for the Product Owner to share this vision with the team and the stakeholders. There are many potential paths to business success, and ever-emerging insights from the Product Owner and the developers affect the chosen path through the sequence of Product Increments.

✥       ✥       ✥ 

The Product Owner is confident about a general product direction and might even be confident of the destination. Even so, there are many paths to reach a given market position, level of profitability, market penetration, and other product objectives. Unfortunately, it’s usually impossible to know beforehand the best path to take. The Product Owner has a hunch for which Product Increments are good options for market success. Without foreseeing the experience that comes with a few releases and growing market knowledge, what looks good now may not look good later. And it’s silly to blindly act on every initial hunch, so it’s a good idea to keep options open. Holding too tightly to a false certainty about some exact plan can lead to a death march. So how can Product Owners contemplate and communicate the big picture and overall goals to the teams and stakeholders, and also help maintain the right stuff on the Product Backlog?

When starting to develop a new product, product management often starts with brainstorming important features and ideas for key deliverables. To describe these features and ideas, it is tempting to fully detail how they will work and fully specify the steps needed to make these ideas real while they are fresh in your mind. You may even want to estimate them to specify a Release Plan and fantasize about when you might finish the project. This is often referred to as waterfall development.

It can take a lot of time to understand the Vision and note how strategic business decisions will affect the direction of the product. There is a danger that many details of the Product Owner’s Vision can remain tacit. A good Product Owner may have an agile spirit, knowing that he or she can benefit the enterprise by changing the details of Product Increments when new information emerges. But good Product Owners also have a “plan B” in their back pocket for dealing with some of the challenges and changes they can foresee. These may include some specific feature as an alternative to another, or just multiple different release sequences of the same Product Increments. The best Product Owners make these alternatives visible.

Yet, these options don’t have a proper place on the Product Backlog. The Product Backlog shows one delivery ordering of one set of Product Increments. It must reflect a committed ordering of deliverables by the Product Owner in light of the best current information. However, this information changes Sprint by Sprint and hour by hour. It’s important to have a place to remember the possible directions that the Scrum Team has explored and which are still open to possible deployment—subject to business conditions and other criteria that might change. You want to keep all product direction decisions, all of the “known knowns,” and all “known unknowns” visible to the entire Scrum Team and other stakeholders.

You could track all of these options on one Product Backlog and just move the unlikely PBIs to the bottom. However, that may lose information about the dependencies between PBIs and timing information that is important to the Release Plan. In other words, a Product Backlog is one-dimensional and you would need to add complex annotations to express multiple deployment options; this would leave it less transparent.

As Scrum Teams are working through Sprints (including both Sprint Planning and development), they can often get lost in the details of current and short-term work, leading to local optimization and missing the big picture. It is important to sustain awareness of how current tasks and envisioned features fit into the big picture and to also demarcate important decision points which could lead to new directions and influence the Product Backlog ordering.

Therefore,

Create a Product Roadmap as a focal point to reflect the overall Vision and to drive the Product Backlog. The Roadmap presents options in two dimensions (alternative decision paths in time and sequence), while the Product Backlog depicts ordering in only one dimension (monotonically progressing time). The Product Roadmap outlines alternatives, and the opportunity to collectively make decisions at well-defined decision points: do we go right or left here? The Product Backlog is today’s best guess of the path we will take through the Product Roadmap. The Roadmap may evolve to reflect changes to the business strategy.

A Product Roadmap is a graph with intersection points. To get from A to B in the path, development must fulfill some requirement. To build a Product Roadmap the Product Owner must identify the conditions for meeting the Vision. All stakeholders must contribute in identifying the conditions. Many paths can lead to implementation of the Vision. The Product Roadmap should be a plan for how to follow the road that yields the highest long-term value.

Each step in the Product Roadmap must create value as obtained from the Value Streams. To help the Product Owner order the Product Backlog, he or she may benefit from a value estimate for each link in the Roadmap. Therefore, a good Product Owner annotates the Product Roadmap with available information about cost and value.

The Product Roadmap is based on current known conditions. Things will change. There are always surprises from many sources including competitive analysis, SWOT (strengths, weaknesses, opportunities, threats) analysis, stakeholder expectations, market conditions, projected velocities, and hard market deadlines. The Product Owner owns the Product Roadmap and is responsible for updating it when business conditions change or relevant information becomes available. The Product Backlog should reflect the best-known current path through the Roadmap, and the Product Owner derives the Release Plan from the Product Backlog.

✥       ✥       ✥ 

With an up-to-date Roadmap in hand, the team has guidance to maintain the Product Backlog in successive Sprints. The Scrum Team and all stakeholders have a greater sense of direction and Unity of Purpose (see Unity of Purpose) as well as an understanding of the overall product Vision. Ensure that the Roadmap remains transparent to all stakeholders as an Information Radiator.

The Product Backlog will evolve from the Product Roadmap as the latter offers insight into the consequences of key decisions about the product direction.

Building a Product Roadmap as an explicit artifact might require a non-trivial effort, but the effort may be worthwhile when product delivery options become complex, or just to make tacit backup plans visible. The Product Roadmap also has a benefit of supporting the discussions at all Scrum events, giving important insight into the concrete aspects of the Product Owner Vision.

A Roadmap can never perfectly foresee the future of a changing landscape. Trying to foresee every contingency is futile; keep alternative product directions at the level of strategic, rather than tactical, decisions. The top of the Product Backlog should detail tactical changes prompted by new information.

A Product Backlog is not a Product Roadmap. A Product Roadmap communicates strategic information and makes visible the options that Product Owner has for the product. In contrast to this, the Sprint Backlog contains largely tactical information. The Product Backlog is intermediate to these two, abstracting away options that the Product Owner has currently decided not to roll out.

Any point in the Product Roadmap may list several alternative options, and the Product Owner may choose one or more of them at will, usually on a just-in-time basis. Use Set-Based Design to help qualify candidates for the Product Backlog.

Good Product Roadmaps are as simple as possible. Use simple and flexible technology, such as sticky notes on a board, rather than computerized tools. Use the roadmap to show deployment dependencies and alternatives rather than release plans; use the Product Backlog as a basis for release planning, and limit release planning to the current “plan of record” to avoid confusing stakeholders with too many alternative potential release dates.

Picture credits: Head image Provided by PresenterMedia.com. Middle photo credit: Todd Herman Associates, 2016, https://www.toddherman.com/improve-business/client-roadmap Reconstructed by Mark den Hollander and Esther Vervloed (April 2019)