How to Build a Roadmap that Works

“Set your direction, decide how you are going to get there and invest in sustaining yourself.”

This is a statement I have heard one of my mentors use numerous times when presenting transformation roadmaps to executive leadership. As simple as the above statement sounds, it always got a positive response. I didn’t pay much attention to it for the longest time as it seemed too obvious. With time, however, I learned the value of simplicity. It helped bring people together. Let’s come back to this later.

Over the last 15 years, I have had the chance of working on a few transformation programs of varying degrees—front office, middle-to-back office, and lately, front-to-back transformations (in vogue these days). I have always found roadmaps interesting. On the one hand, most of them look good, so a lot of people end up paying attention to them. On the other hand, they are generally of limited value. Did I say that out loud?

Here are some common roadmap issues I have heard people mention:

• They are stale: they make sense at the beginning of the program, and then we end up creating lower fidelity project plans but never bother to update the roadmap.
• They are theoretical: a lot of them look pretty but are not well thought out. Milestones might make sense at a high level, but when you look under the hood, you realize that there are many unknowns.
• They can’t be used for execution: I get this a lot, and I agree to an extent. It’s not a project plan or a sprint plan. I am not sure if that is an issue, though.

There’s more, but I think we get the drift here—a lot of us feel roadmaps could be better.

Before we rush to reform them, I think there is value in understanding the purpose of a roadmap in 2022 (we’re almost there). Do we even need them in the first place? There is a growing share of commentary in product management circles claiming that roadmaps are dead. There is an argument to be made for that. A stale and theoretical document is of no use to anyone, roadmap or otherwise. That said, the purpose of a roadmap is to show what you need to get done when going from point A to point B, with the understanding that there will be detours, pitstops, and worries about gas mileage along the way. I feel that a roadmap is an essential document to know if you are still headed in the right direction–especially because of the detours (read: changing risks, dependencies, and milestones on a project plan).

Here is how I have found roadmaps being used effectively by organizations:

Aligning on a shared vision

• While we can debate the relevance of a roadmap during execution, there is usually no argument on the value of a roadmap before you start executing. It helps teams bring out risks early in the process and helps as a mechanism to get aligned on a shared vision through budget, priorities, and executive decisions.
• For this to work, the roadmap must be constructed transparently and updated if a team brings up valid risks and dependencies.

Cross-functional communication during execution

• At a front-to-back transformation program for a multi-asset family office, I saw most of their in-house and vendor tools get updated over two years. An overall program roadmap was a vital tool in aligning milestones and integration points between each vendor. Each team had their low fidelity plan to execute, but the roadmap told them what was coming next and what’s moved out (and things change all the time).
• For this to work, the roadmap must be updated at a predictable frequency so that teams can anticipate and consume the changes in an organized manner.

Resist making feature promises

• This can be a bit counterintuitive as teams naturally align with features. After all, that’s what they are working on. The exact details of features are not well understood initially and keep changing throughout the program. Making feature promises and not being able to keep them leads to confusion among internal and external customers.
• For this to work, the roadmap’s focus must be aligned to outcomes (ideally aligned to the organization’s overall business strategy), and features can be part of project plans.

Framework trumps format

• I hate to say this because I love templates (as all consultants do) but the format of the roadmap doesn’t matter. The roadmap needs to be simple so that people consume the essentials quickly. What is more important is the framework used to facilitate the roadmap sessions to consider all required inputs.
• For this work, it can be just bullets points and doesn’t have to be the usual color-coded swim lanes forced over a timeline.

I wanted to come back to the simplicity of the quote I mentioned initially. The simplicity of the roadmap shouldn’t be misunderstood for lack of details. There shouldn’t be obvious gaps that will lead readers to think it is half-baked. If the roadmap was constructed in a transparent manner through working sessions, there should be supplementary information available for people to read and understand the context behind the decisions (e.g., objectives, assumptions, meeting notes, vendor timelines, etc.). And in the remote-working Agile world we live in today, strategy can’t be set in stone. Strategy and execution inform each other, and the roadmap (a visual for strategy) needs to be updated like a live document.