Why do businesses use roadmaps?

A roadmap is a plan or strategy intended to achieve a particular goal. In the Product world, a roadmap is an artifact that, theoretically, fulfills two business needs: identify the things that generate the most value for the business and commit to dates when they will be delivered.

Both business needs are legitimate, and producing a roadmap usually gives “that manager” a sense of security due to the fact that the business has identified what to work on and when to deliver it. As always, saying that something will happen helps very little to ensure this will really happen and “that manager” will end up empty handed more often than he should.

Grandma’s recipe for the perfect roadmap

The perfect recipe for a roadmap requires the following steps:

• Identify a cross-functional team including the smartest people in your company
• Set up a long series of meetings, or even better a workshop
• Pressure people into deciding what to design and how long it will take
• Sprinkle a bit of tight deadlines and financial constraints

The cross-functional team will likely produce something like this:

I almost forgot the last step of grandma’s recipe for the perfect roadmap: throw it in the bin.

Why roadmaps don’t work

Roadmaps are the wrong answer to two reasonable business needs for this fundamental reason: they try to determine outcomes (what to build and when) at a time where uncertainty, hence risk, is at its maximum. The starting uncertainty is usually non-negligible due to the complexity of the product, the cross-functional nature of the team, dependencies on supply chain and many other factors. Roadmaps try to predict the rate at which uncertainty will be reduced and extrapolate a completion date based on many assumptions. Little surprise that they often don’t work.

After a roadmap has been produced and the engineering team starts working, three scenarios are possible (here I’m purposefully ignoring the fantastical scenario where all predictions were accurate as the likelihood is next to zero):

• The team realizes that uncertainty can only be reduced at a lower rate than expected and the delivery date slips
• The team realizes that the initial solution isn’t going to work and needs start again from the beginning
• The team realizes that the initial solution isn’t going to work and there isn’t a viable alternative

When the delivery date slips

The first scenario is where the roadmap predicts that uncertainty will be reduced at a certain rate at the beginning of the project (A) and the expected delivery is interpreted as a commitment. During execution, the team reviews the project plan and typically realize that the initial prediction was too optimistic (B). At this point there is still too much uncertainty to accurately predict a new delivery date. Nevertheless, the team is pressured (either explicitly or culturally) into making a new commitment. When uncertainty reaches a certain value (C), the team can re-evaluate the project plan, accurately commit and execute.

There are two problems with this scenario: the business had to delay the product delivery, and it committed and missed delivering on two occasions (but could have been more!). The positive aspect here is that the team has somehow managed to deliver.

When a different solution is needed

In the second scenario, the same assumptions as the first are made on the ability of the team to reduce uncertainty at a certain rate (A). However, in this case, the initial solution turns out to be wrong and uncertainty (or risk) cannot be reduced further (B). This forces the team back to the drawing board (C) and from here the same path is followed as in the first example.

This scenario adds the following to the previous problems: the business had to delay the product delivery even further, and the product that is delivered to the customer is different to the one that was promised when the roadmap was defined. The positive thing about this scenario is that the team has still been able to produce a product that meets the customer needs.

When no solution is going to work

The third scenario is the worst one. It starts with the same assumptions as the previous scenarios (A), but the team is unable to drive the level of uncertainty of this, or any other, solution down to an acceptable level (B).

The team has to face two choices: abandon the project (good luck if your business has already committed to a customer) or bring the project to conclusion accepting a high level of uncertainty (or risk) that will keep haunting the company for the next several years. In this case it’s also worth noting that due to the level of residual uncertainty, it will be extremely difficult to predict a delivery date.

Do discovery and delivery instead

Now that we have analysed what happens when the team tries to follow an unrealistic roadmap, let’s take a look at the alternative. In this scenario, the team accepts that until the uncertainty is too high, it doesn’t make sense to pretend a delivery date can be predicted (A). What the team does instead is to focus on burning uncertainty (and risk) as fast as possible, until an acceptable level is reached (B). At this point, the time to delivery can be predicted with accuracy, similar to what happens in scenarios one and two.

This approach clearly splits the development into two phases:

• Discovery (A-B): where the team is focused on reducing uncertainty and finding solutions to problems
• Delivery (B-C): where the team takes care of the necessary things to get into production

Using this approach requires honesty to ourselves, our teams and our customers: commitments are made when chances of delivering are high and success will be likely. At the same time, this method puts a lot of responsibility in the hands of the team to complete the discovery phase and reach the commitment point as soon as possible.

It is also important to note that the absence of an early commitment date, however fictional and inaccurate, can be perceived as a bit of a gamble,especially by “that manager”. The real secret is in the cultural shift that needs to happen to truly empower (and trust) the engineering teams.

---

From the library