Elements of Great Roadmaps
Strategic Alignment
Roadmaps need a purpose. For a technical team in a business, this purpose should align with the larger business strategy. Chapter 1 covered the basics of building technical goals that align with business goals. Here, the roadmap begins to show the approach to meeting those goals with:
- Clear Connection to Business Goals: Tech roadmaps should be arranged to connect the technical work to the business goal. Swimlanes, color coding, naming conventions, and other techniques can link a specific item on the roadmap back to the business strategy and goals.
- Focus on Value: Emphasize how each item on the roadmap delivers value, in terms of the business goals the roadmap supports. Connect the “what” in the roadmap to the “why” of the goals.
In general, if a business executive picks up a technical roadmap, they should get a sense of what the technology team will deliver in coming quarters and how this supports the business strategy.
Clarity and Communications
Following on the last bit of that last section, a roadmap should be self-explanatory if it is shared or viewed as part of a larger document or update. If a roadmap needs the owner to explain it each time it’s viewed, the roadmap needs to be improved for clarity.
Creating a clear roadmap is somewhat contextual. “Clear” will be subjective depending upon the technical expertise of the “non-technical” employees, upon the industry, upon how new or innovative things might be, and upon how well defined are the business strategy and goals. What’s clear for a highly technical company working in the software market might be confusing for other companies or industries.
In general, keys to creating a clear roadmap will consider these factors:
- Visual Model: Roadmaps show work done over time, so there are several ways to represent this visually. Timelines, swim lanes, and Kanban boards are all examples. There’s a temptation to pack information into a single diagram, but this is typically a mistake. Roadmaps are high-level, so ensure text is easily readable and there is a legend explaining colors/shapes/etc.
- No Surprises: Roadmaps should summarize the shared understanding of team goals and priorities. If anybody involved with the roadmap doesn’t know or understand one of the items, then the team should regroup to discuss why this happened and how to prevent it in the future.
- Easily Available: The roadmap should be easily found, and the people who manage it should be easy to contact for questions. As updates are released, key people involved should receive an update so they can see progress and review next steps.
The main goal of a roadmap is to communicate a view of the future. If the roadmap is unable to do this, if it confuses people, or if stakeholders do not know it exists then the roadmap owners need to regroup and address these problems as quickly as possible.
Flexibility and Adaptability
Roadmaps are not a contract. They are a prediction. Items that are closer-in-time have higher confidence while things further out (multiple quarters into the future) are often guesstimates, at best.
With this, it is important for the roadmap owner to clearly explain that the roadmap is a forecast of the future. As with any forecast, it is going to change as new information is revealed and business focus evolves. Thus, a roadmap needs to demonstrate that it is a:
- Living Document: Roadmaps are a prediction or forecast. They predict what the technology team will do in the future to support ongoing business strategy and goals.
- Conversation Starter: As people look at the roadmap, it will inspire questions. Questions may focus on how the roadmap supports larger strategies. Questions might reveal the need for additional coordination between internal teams. If a roadmap leads to questions, that’s a good thing!
Thus, roadmaps are as much a conversation starter as they are a proposal for how to allocate resources or set priorities in future months and quarters.
Scope and Focus
A roadmap needs to address the right level of detail. If it is too detailed, it risks becoming overwhelming to a reader or it might cross over into project planning territory. Too little detail and it’s not useful to anybody.
When a roadmap is shared with a larger group, who doesn’t regularly look at the roadmap, the questions the group asks will often indicate if the roadmap is properly scoped. If people say they are confused, there might be too much information and the visualizations or data presentation should be reviewed to simplify things. If people say they aren’t quite clear about the goals, that may mean the roadmap is too vague or high-level.
Roadmaps are never perfect. Welcome the feedback and adjust as needed for audiences. In some situations, there may be a few versions of a roadmap: a highest-level strategic summary, a mid-level priority summary, and a low-level breakdown by team or effort or project. (Note that even the “low-level roadmap” is still a summary when compared to an actual project plan.)
The roadmap should also help a team focus on what will be important in the near future. If the roadmap simply lists a set of goals, that might not help the team understand what is most important or how they can build solutions today that support the goals of next quarter. Roadmaps must incorporate the element of time so that everybody can appropriately work and coordinate.