Everyone needs a map to get to where they’re going. Roadmaps are an essential strategic planning tool. It is a method to help coordinate ways, means, and ends in terms of time. The approach I favor, for most strategic efforts, is a diagram where there’s a single visionary end, and extending out is the concentric planning cycle to get there. Then converging on that visionary end are channels defining a broad aspect of the program (e.g., technology, consumer engagement, etc.).
Roadmaps are continually updated as new information arrives, and is presented to focus discussions, and record decisions. This usually means a product or program manager jots notes on one through a quarter, and periodically the leadership team meets to revise and update. It is also used as the supporting documentation to communicate program needs and priorities during budgetary cycles. The people making investment decisions are more likely to fund efforts that can clearly explain both immediate and long-term benefits through a plan.
From experience, here are my Do’s and Don’ts in creating a roadmap –
Do – be inclusive. As the adage goes, plans are nothing, planning is everything. The roadmap discussion doesn’t need to be exclusive to any one person, activity, or level. By involving a larger audience you build consensus, you discover what you don’t know (or more importantly – what is not knowable), and you have the means to communicate the big story for others to create their smaller stories.
Do – use other methods to prioritize what should or shouldn’t be on a roadmap. Use SWOT, Cost-Benefit analysis, empathy maps, business modeling, and other tools where needed. Each is a tool of discovery.
Do – glob things into an identifiable initiative. Use a strong action word as a label with a byline to summarize its meaning. Each item on a roadmap tells its own story with a list of items that make it possible. Identify dependencies, risks, and timing.
Do – study outside the corporate bubble. Include and share data, trends, statistics, and figures on your industry and its unique economy. You and your team need to know about competitors (Red), and the ecosystem (White).
Do – tell a story. Use Think Red, Think White, Think Blue gaming to create a visual narrative of the roadmap. Strategies are sold through stories.
Do – listen to contributors and ensure the scope of items have purpose. Defend minority opinions with huge impacts, and remove items that don’t align to the ends. The final decision is always by hierarchy, and that decision must be well informed.
Do – have a single person accountable for managing the roadmap. That person identifies the roles of what is needed to execute as an on-going task (e.g., typically a rotating position held by the team’s thought-leaders and part of mentoring future thought-leaders).
Don’t – think of roadmapping as a stand-alone artifact to be updated annually as a solitary task.
Don’t – limit the roadmap to senior staff or key architects. It’s not an exclusive activity and should communicate the strategy to all levels.
Don’t – let the person leading the roadmap be the sole person creating it. A behavior that’ll kill the purpose of a roadmap is where the lead holds numerous meetings and makes frequent requests for information, then hides away for a month or two to generate the roadmap. The lead should collect the past roadmap (If any), and use the meetings to create the roadmap.
Don’t – be overly inclusive. Too many cooks will ruin a stew. Divide the creation of the roadmap vertically and horizontally to have manageable inputs.
Don’t – have separate roadmaps by activity. A solid technology roadmap is tied to a business roadmap, and vice versa. Each activity may formulate their aspect of the roadmap, but it always comes together as one in the end.