Ideate, Plan & Deliver method guide

Roadmap / Impact Grid

Roadmap / Impact Grid creates a layered, time-based strategic narrative across markets, products, technology, capabilities, initiatives and resources.

Beginner-friendly guide · 6 min read

What Roadmap / Impact Grid does

Roadmap / Impact Grid creates a layered, time-based strategic narrative across markets, products, technology, capabilities, initiatives and resources.

The IfM Engage guide defines a strategic roadmap as a structured, forward-looking diagram that sets out an integrated view of the way forward. It represents pathways from the current position towards future aspiration and value, together with the enablers and barriers encountered along the way.

A roadmap combines multiple system perspectives across time. In industrial settings, this commonly means reading business and market needs together with products or services and the resources or technologies that enable them. Read vertically to test alignment at a point in time. Read horizontally to understand how each perspective develops. Follow links between layers to understand the strategic logic.

A roadmap is not a static forecast. Its value lies in supporting strategic navigation, decisions, plans, budgets, collaboration and communication as events unfold and knowledge improves. InnovationFlow adds ownership, status, resources, history and lineage to help maintain that living record.

The Impact Grid is a complementary InnovationFlow view of the same items. It helps teams compare candidates before or alongside sequencing, but it does not replace the layered, time-based roadmap.

The IfM Engage introductory guide defines a strategic roadmap as a structured, forward-looking diagram that integrates the pathways towards value, including enablers and barriers. It emphasises connected commercial and technical perspectives, purposeful customisation, stakeholder participation, periodic refresh and communication through a time-based strategic narrative. The roadmap is a navigation aid, not a static forecast or a project schedule.[1][2][3][4][5]

Method schematicSee the strategy as a layered roadmap

Time runs from left to right. Read vertically for alignment, horizontally for development, and follow the links to see how market needs, offers, capabilities and resources form one strategic narrative.

Vertical: alignment nowHorizontal: development over timeLinks: response and enabler logic

InnovationFlow explanatory schematic, synthesised from the method sources[1][2][3][4][5].

Understand the method

The parts in plain language

1

Purpose and strategic questions

Start with the decision context and intended benefit. The IfM guide highlights six universal questions that a roadmap may need to answer: why, what, how, when, who and where. The emphasis and structure should fit the purpose.[1][2][3][4][5]

Illustrative example

A technology roadmap may focus on how technical capability will deliver the product and service performance required by future market needs.

2

Time, layers and sub-layers

Choose a horizon and system perspectives that match the question. A common architecture connects business or market, product or service, and resource or technology layers, but the template should be customised.[1][2][3][4][5]

Illustrative example

Market drivers sit above service offers, data capability and delivery resources over a five-year horizon.

3

Links and strategic narrative

Connect items when one responds to, enables, constrains or depends on another. Each layer has a time-based narrative, while cross-layer links explain the overall pathway towards value.[1][2][3][4][5]

Illustrative example

An interoperability capability enables a multi-vendor service offer that responds to customer demand for mixed-equipment coverage.

4

People, process and communication

Roadmap owners, functional experts, facilitators and other stakeholders contribute different knowledge. The roadmap provides a common reference point for building confidence, consensus and a story that can be communicated more widely.[1][2][3][4][5]

Illustrative example

Commercial, engineering, operations and customer representatives validate the same pathway before budget decisions are made.

5

Resources, refresh and governance

Add owners, status, FTE, budget, constraints, evidence and review triggers. Refresh frequency should reflect the rate of change and the business processes the roadmap serves.[1][2][3][4][5]

Illustrative example

A new regulation triggers an early review, while the normal cadence remains aligned with annual strategy and budgeting.

When to use it

  • When analysis and options need to converge into a coherent strategic direction across time.
  • When market needs, offers, technology, capability, resources and dependencies must be discussed together.
  • When multiple functions or organisations need a shared picture for decisions, budgets and collaboration.

A practical workflow

  1. 1

    Clarify the application context, purpose, expected benefits, constraints and roadmap owner.

  2. 2

    Design the roadmap template around the relevant layers, sub-layers, questions and timeframes.

  3. 3

    Design a proportionate roadmapping process using evidence collection, analysis, consultation, workshops and supporting tools.

  4. 4

    Identify and involve the stakeholders who own, contribute to, use or are affected by the roadmap.

  5. 5

    Populate the roadmap with accepted items, links, rationale, dates, ownership, status and evidence.

  6. 6

    Validate and use the roadmap, testing alignment, dependencies and timing against FTE and budget constraints.

  7. 7

    Refresh the roadmap as events unfold, then reflect on and improve the wider roadmapping process.

Fictional worked example

Example: a connected-service roadmap

This example is illustrative rather than a reported case. A manufacturer sequences an industrial service from evidence to scale.

Why

Observation:Customers need mixed-equipment coverage and new reporting requirements take effect in two years.

Implication:The top layer establishes the market pull, timing and desired outcome.

What

Observation:Two integration pilots lead to a standard multi-site service and later portfolio rollout.

Implication:Product and service items respond to the needs above them.

How

Observation:A common data standard, platform capability and operating model enable each offer.

Implication:Cross-layer links make the technical and organisational logic visible.

Constraint

Observation:The same engineering team supports two programmes and the budget cap is reached mid-horizon.

Implication:Use the resource view to shift timing, change scope or make the trade-off explicit.

From analysis to decision

How to interpret the result

  • 1Check vertical alignment: can every major product, service or initiative be connected to a credible need or aim and to the enablers required to deliver it?
  • 2Check horizontal coherence: does each layer tell a plausible story from the current position through near-, medium- and long-term development?
  • 3Use links to expose response, contribution, dependency and constraint logic, not to decorate the map.
  • 4Do not judge success by whether the roadmap predicted the future exactly. Judge whether each iteration improves confidence, consensus, decisions and action.
  • 5Keep the strategic level readable. Detailed project plans can sit beneath the roadmap rather than overwhelming it.
  • 6Review status, assumptions, rationale, resources and external triggers on an agreed cadence, and occasionally revisit the structure itself.

The interpretation guidance is an InnovationFlow synthesis of[1][2][3][4][5].

What a useful output looks like

A layered, time-based and resource-aware strategic or technology roadmap.
A shared strategic narrative linking why, what, how, when, who and where.
Traceable commitments, dependencies, status, assumptions and change history.

Common pitfalls

  • Do not reduce the roadmap to a Gantt chart or judge it by forecast accuracy alone.
  • Avoid excessive detail that makes the strategic picture hard to read and expensive to maintain.
  • Software can support efficiency and communication, but it does not replace purpose, facilitation, participation and judgement.
  • Customise the structure and process to the decision context rather than copying a generic template.

References and method basis

  1. [1]IfM Engage, University of Cambridge (2022). An Introductory Guide to Strategic and Technology Roadmaps. Institute for Manufacturing, Department of Engineering, University of Cambridge. Source ↗Originating institution
  2. [2]Kerr, C. and Phaal, R. (2021). Roadmapping and Roadmaps: Definition and Underpinning Concepts. Strategic Technology Management. Source ↗Peer-reviewed research
  3. [3]Phaal, R. and Muller, G. (2009). An architectural framework for roadmapping: Towards visual strategy. Technological Forecasting and Social Change, 76(1), 39–49. Source ↗Peer-reviewed research
  4. [4]Phaal, R., Farrukh, C.J.P. and Probert, D.R. (2007). Strategic Roadmapping: A Workshop-based Approach for Identifying and Exploring Strategic Issues and Opportunities. Engineering Management Journal, 19(1), 3–12. Source ↗Peer-reviewed research
  5. [5]Phaal, R., Farrukh, C.J.P. and Probert, D.R. (2001). T-Plan: The fast start to Technology Roadmapping - planning your route to success. Institute for Manufacturing, University of Cambridge. Source ↗Original method source

This guide synthesises the named sources into practical questions for strategy and innovation work. It does not claim that using a tool by itself produces a successful decision.

Practitioner support

Talk to an experienced practitioner

Ask about roadmapping, facilitation or applying a method in your organisation. Your question goes directly to the InnovationFlow team.

Sent securely to hello@innovationflow.app.