Roadmapping

Kerr and Phaal define a roadmap as a “structured visual chronology of strategic intent” and roadmapping as the application of a temporal-spatial structured strategic lens. The wording matters. Chronology makes time explicit; structure separates different kinds of strategic knowledge; visual form makes relationships inspectable; and intent distinguishes a roadmap from a neutral forecast. The roadmap is the artefact. Roadmapping is the process of organising evidence, perspectives and choices through that lens. [1]

The method grew from industrial practice rather than from a single academic theory. Its history includes early work in aerospace, energy and electronics, followed by influential applications at Motorola, BP, Philips and sector-level organisations. Modern roadmapping retained a common idea from those varied roots: connect a view of the future to the products, systems, technologies and actions required to respond. [2]

That is why a product release plan, project schedule or list of technology bets may be useful without being a complete strategic roadmap. They show one slice. Roadmapping becomes distinctive when it connects several perspectives and makes the logic between them visible over time.

A widely used architecture places time on the horizontal axis and strategic perspectives in layers. The upper layers ask why action is needed: trends, drivers, stakeholder needs and desired value. Middle layers ask what should change: products, services, systems or measurable outcomes. Lower layers ask how: technology, capability, partnerships, projects and resources. The explicit timeline supplies the when. [3][5]

This is a thinking structure, not a mandatory four-row template. A public-policy roadmap, a business transformation roadmap and a product-technology roadmap will use different language and levels of detail. The test is whether the chosen layers represent the perspectives required for the decision at hand.

The finished visual helps people communicate a strategic narrative. The process used to create it does something different: it exposes conflicting assumptions, helps commercial and technical participants develop a shared vocabulary, and forces gaps to become discussable. Workshop-based approaches are therefore not merely efficient ways to populate a diagram. Participation is part of the mechanism through which alignment is built. [4]

Phaal, Chaskel and colleagues describe roadmap canvases as a way to organise dialogue, learning, consensus-building, decisions and action. They also stress that reference processes should guide rather than prescribe. Participants may start with the future state, the present problem or the pathway, provided the pieces are eventually synthesised into a coherent narrative with uncertainties and knowledge gaps visible. [5]

For practitioners, this means facilitation quality matters. Invite people who hold different parts of the evidence, separate idea generation from prioritisation, record disagreements rather than smoothing them away, and end by naming decisions, owners and unresolved questions.

Roadmapping is especially useful when several functions or organisations must coordinate over time; when market, policy, product and technology change at different speeds; when there are several plausible pathways; or when a portfolio needs a shared rationale. It can support product and service strategy, research planning, transformation, sector coordination, capability building and mission-led innovation. [1][3]

It is less useful when the decision is already narrow and operational, when no meaningful stakeholder group can supply evidence, or when leaders want a picture that legitimises a fixed answer. Roadmapping does not remove uncertainty and should not manufacture consensus. It should show where confidence is low and where evidence must be improved. Agile roadmapping research treats gaps and uneven evidence on the canvas as diagnostic signals, not blemishes to hide. [6]

Start by defining the decision, scope, horizon and participants. Agree the layer language before generating large amounts of content. Populate the current state and future intent, then explore pathways between them. Connect important items across layers, surface gaps and alternatives, and prioritise a small number of issues for deeper work. Finish with next actions and a review mechanism. T-Plan packages this logic into a fast-start process while explicitly covering customisation and keeping the roadmap alive. [7]