Technology Roadmapping

Origin

Roadmapping comes from industrial practice: Motorola used the approach from the late 1970s onwards to align technology and product planning across business units, documented in Willyard/McClees, “Motorola's Technology Roadmap Process” (Research Management, 1987). It became a transferable method through the Cambridge group around Robert Phaal: with T-Plan: The Fast Start to Technology Roadmapping (University of Cambridge, 2001), Phaal/Farrukh/Probert published a workshop-based procedure that made the architecture of market, product and technology layers the standard.

Typical use

Roadmapping is used in strategic R&D planning, for alignment between strategy, product management and development, and to prepare investment and portfolio decisions. Its real value lies less in the document than in the process: the functions involved must make their assumptions about market demand, product generations and technology maturity explicit and test them against each other. As a timeline instrument, roadmapping complements S-curve analysis, which judges the maturity of the technologies entered.

Procedure

1. Define the architecture

   First, fix the time horizon, granularity and layers — at the core market (drivers, customer requirements), product (generations, milestones) and technology (capabilities, maturity levels). The architecture determines which questions the roadmap can answer at all.

2. Populate the layers

   Each layer is filled with dated entries: expected market events and regulatory deadlines at the top, planned product generations in the middle, available and required technologies below. Sources are market analyses, expert estimates and development plans.

3. Link entries and identify gaps

   The entries are connected across layers: which technology carries which product, which product serves which market need? This exposes gaps — required technologies without a development path — and mismatches in timing, such as product deadlines ahead of technology maturity.

4. Maintain and connect to decisions

   A roadmap is not a one-off result but a living document with a fixed review rhythm. At each update, assumptions are checked against what has actually happened, and the consequences are carried into budget and portfolio decisions.

Limits and typical mistakes

Roadmapping's greatest weakness is its extrapolation logic: a roadmap is built from what the organisation knows and plans today, and extends that known world into the future. Technologies with neither internal champions nor budget simply never appear. Added to this is false precision — dated bars suggest a certainty that neither market forecasts nor technology estimates can deliver; the roadmap is then read as a commitment rather than a scaffold of assumptions. A third mistake is political use: whoever treats entries as resource claims negotiates instead of analysing. And finally, any roadmap without a binding maintenance process becomes obsolete faster than it was created.

Relation to the Innovator's Dilemma