The Product Roadmap Agility Checklist

I see many versions of product roadmaps in my work. Unfortunately very few pass this agility test. Does your product roadmap pass the Product Roadmap Agility checklist?

Download the checklist here.

Let’s walk through the rationale behind these checklist items.

Items on the product roadmap represent value

Items on a product roadmap can take on many names. “Epic”, “Initiative”, “Big bet” – it depends on the language you have chosen to use. What is less practiced is that items on the roadmap should represent pieces of value. For example, “build a bicycle” is a representation of a solution. What represents value is “freedom to move around”. Check that your items on the roadmap translate to value in the eyes of the customer or the market. This enables you to see (and challenge) if you are indeed creating value and not just building bells and whistles that no one really cares about.

External stakeholders can see what value they will be getting and roughly when

As an external stakeholder or customer, I should be able to see the value you intend to deliver and roughly when, without needing to walk through all the intricate details of how you do it. I should be able to treat our development unit as a black box but still understand what value I can expect and roughly when.

Note, you don’t need to disclose all items in a product roadmap to external parties. You choose which to communicate and when. For example, you might want to expose only a subset of the roadmap to avoid expectation gaps. How much you choose to disclose generally depends on the maturity of the stakeholder, their integrity and ability to handle the information with care, and the trust you have in each other.

Employees can see the sequence which best realizes that value

As an employee, I should have visibility to (the current best understanding of) the sequence that realizes that value (see image above). This helps me do a very early check to see if this is feasible in the desired time range and to see the dependencies across organizational boundaries.

The product roadmap is validated towards capacity and skill

Focus is essential to achieve success.

If your product roadmap overpromises compared to real capacity, you can be sure corners will be cut during implementation. Corners will be cut, technical debt will build up and your engineers will repeatedly experience the feeling that “we never get to do anything well around here”.
Sometimes capacity is mistaken to be the same thing as a budget. They are not the same! Why? A budget represents money, but does not take into consideration ramp up time, cost of task switching, bottlenecks to name a few. When you validate your roadmap towards capacity, you validate it towards the capacity of Agile teams that you really have. For longer time horizons, you are allowed to build the capacity that will get the job done. This allows you to take into account ramp up time. This is important because failure to adapt capacity ahead of time will lead to the “meh” effect – your products are released but they always lack that ‘oomph’ because you had to prioritize away the innovative stuff!

Here’s the good news: Validating your product roadmap towards capacity is a fairly straight forward exercise (the trick is to avoid getting bogged down by details). For each time period (increment), calculate the gap between the estimated capacity to keep the value flowing, and what you actually have. The hard but essential part is making the tradeoffs necessary when a gap exists. (A small trick I use: For product roadmap items, I often size them using the currency of the number of team sprints. This represents a decent tradeoff between analysis and decision speed – “should we invest more in this?” at a very early stage).

Contains options that enable Agility

An Agile product roadmap builds in options that can be traded away to exploit late learnings and opportunities. As a product manager, you enable business agility by building in options into your product roadmap.

The balance between Business epics and Technical enablers is healthy

A product roadmap should strike a sustainable balance between business initiatives and technical investments, which should speed up future business initiatives. A product roadmap represents a handshake of this balance, such that it can be reflected from the top to team level.

Mitigates our bottleneck

Every system has a bottleneck. It is also likely to move over time. Your job is to make sure you optimize value through it.

Optimizes the value of the company

After you mitigated your constraints and your key risk, it’s important to take a step back and ask yourself, “Does this optimize the value of our company?” It’s easy to lose track of this perspective and get distracted by a thousand details.

We are capable of forecasting “when can we deliver?”

Ever been told that Agile companies can’t estimate deliveries? That’s (pardon my French) bullocks. What is true is that we need to handle uncertainty cleverly. And this is what Agile is all about! Any Agile company should be able to forecast a delivery date. One key is to estimate and communicate the uncertainty of the delivery using a confidence range, often expressed as a time range. The confidence should illustrate the range between an optimistic outcome and a conservative outcome. Another side benefit is that this introduces the healthy habit of quantifying risk (and calibrating your ability to do so).

The product roadmap is updated frequently and drives tradeoff decisions

A product roadmap is a living entity. If it isn’t updated towards reality regularly, it risks becoming a paper artifact. The proof that it isn’t is whether it drives tradeoff decisions. Make sure you update your roadmap using a fixed and frequent rhythm. The world changes and your roadmap should always reflect reality. Which rhythm you pick is up to you as long as the product roadmap allows you to stay ahead of the game.

That’s it! Give this checklist a try at your next product roadmap planning session.