The National Quantum Computing Centre set a target of a 100+ qubit NISQ-era machine by 2025, set out three critical milestones towards it, and then wrote into the same technology roadmap that the plan will be reviewed over time so that promising new platforms and technologies can be brought into the programme as they evolve. The target is the line everyone repeats. The review point is the line that changed the practice.
Technology roadmap development is now the work of building a document that stays useful after the first forecast fails, which it will, while still telling a funded team what to build next. Everything below depends on that shift.
Two confusions that spoil a roadmap before it is drawn
IEEE defines technology roadmaps as documents that "stimulate an industry-wide dialogue to address the many facets and challenges of the development and implementation of an emerging technology", and its guide frames them as peer-reviewed, published and addressed to a whole sector. A product roadmap is proprietary and competitive, produced for one firm's customers and its own delivery teams. Place both in one document and the reader cannot tell whether a line commits to a market or to a platform.
The second confusion lies between a roadmap and a project plan. ProductPlan's worked examples draw the boundary at that level: every roadmap initiative stays at the strategic level, and the tasks beneath it belong to project management. A line that reads "migrate the billing database by June" is a Gantt chart with a grander title.
Why roadmap development is an alignment exercise
IfM Engage, the consultancy arm of the University of Cambridge's Institute for Manufacturing, states that the main reason for developing a technology roadmap is to align the outputs of technology development with the strategic needs of the organisation, defined by the functionality and performance the business needs from its products, services and systems. The same guidance adds that a roadmap earns the word strategic only when it is facilitated well enough to address six key strategic questions, and reports that IfM Engage has worked with more than 300 organisations on that basis.
That reframes the work. The decision in front of a board is which capabilities the business needs, and which of those technology can deliver at a cost the business will fund. The RNLI case on the same page shows the method in use: roadmapping brought key stakeholders together to explore unmanned aerial vehicles for search and rescue, and what came out was a shared view of capability, which is the point of the exercise.
Interfaces and standards come before the plan
The UK government's Technology and Innovation Roadmap for the border, published by the Cabinet Office in August 2021 as part of the 2025 UK Border Strategy, shows the order that now works in public. It opens with a first point of contact, the Border Innovation Hub, then with target use cases defined in partnership with industry, then with the standards the private sector can build against, and only then with the internal change government has to make in order to consume the results.
Each step makes the next one possible, and each is set out so that an outside vendor can act on it. The standards committed to, border data security and interoperability, rest on the Open Standards Principles and are aligned with international partners wherever possible. The internal change covers an API-driven approach to interoperability, legislation, training for front-line officers and sandbox testing programmes run jointly with industry.
Company roadmaps tend to break at the join this public document handles well. The destination gets set out and the interfaces stay unstated, so no vendor, no internal team and no incoming executive can move without a further round of discussion.
Seven steps, in the order they have to be taken
- Write down the four decisions the roadmap must inform over the coming year, before opening a template. If those four cannot be stated, the output will be a wall chart with a time axis.
- Record the current state as capabilities. Atlassian's guidance places the current-state assessment early and asks for a systems inventory alongside a capability audit; the inventory goes stale within a quarter, the capability audit lasts.
- Fix the interfaces and standards that will not move for the life of the roadmap. With API contracts, data schemas and security standards pinned, everything else can change around them.
- Give every line an owner and a review interval. IEEE refreshes its roadmaps yearly, with a more serious revision every two years, and a company can borrow that rhythm at a smaller scale.
- Separate the commitment horizon from the ambition horizon. The commitment horizon takes in only what is funded and owned; the ambition horizon can take in everything else without pretending to be a plan.
- Price each line in decisions taken and decisions deferred. "Defer the warehouse migration to Q3" is a real roadmap outcome. "Modernise data" is not a line anyone can fund.
- Set the trigger for a rewrite alongside the review interval. Atlassian's guidance is explicit that a good roadmap gets revisited, refined and partly rewritten as conditions change, which means the rewrite trigger has to be agreed while everyone still agrees on it.
Every line on a roadmap gets five fields, and a sixth has yet to be needed:
capability: event streaming for order events
owner: head of platform
commitment_horizon: Q3 this year
standard_lock: schema registry, retention policy, PII handling
next_review: 2027-01-15
The form of a line matters more than the tool that draws it. A spreadsheet with these five fields does more work than a polished visual with two of them missing.
Five roadmap types, measured against the same attributes
The labels overlap far more in vendor material than in practice. What separates the types is audience, horizon, the unit of a line, the trigger for a review and the way each one fails.
Industry technology roadmap: the audience is a whole sector, including vendors, universities and funders; the horizon runs five to ten years; a line records a technical challenge with its dependencies; review comes from a committee cycle; and the failure mode is drift into advocacy for the incumbents who wrote it.
Enterprise technology portfolio roadmap: the audience is the executive team and the finance function; the horizon is a year to eighteen months, the range ProductPlan reports for enterprise IT roadmaps; a line records an investment with an owner and a business outcome; review comes from a budget cycle or a change in the operating plan; and the failure mode is spend presented as strategy.
Architecture or platform roadmap: the audience is engineering leadership and the teams building on the platform; the horizon is two to four quarters; a line records a component, an interface contract or a migration stage, covering the API, user interface, storage and third-party integrations that ProductPlan's examples set out; review comes from a completed dependency or a failed load test; and the failure mode is a project plan wearing architecture vocabulary.
Lifecycle and retirement roadmap: the audience is whoever pays the run cost and owns the audit finding; the horizon is three to five years, longer than most people want to look; a line records a system, the point at which vendor support ends and the cost of staying put; review comes from an end-of-support announcement or a failed penetration test; and the failure mode is a retirement that keeps being deferred until the risk decides the schedule for you.
Emerging technology roadmap: the audience is a small group of engineers plus whoever controls the innovation budget; the horizon is one to three years; a line records an experiment with a stated success measure and a decision point; review comes from a completed experiment; and the failure mode is a pilot that nobody is allowed to kill and nobody is allowed to fund.
How a fractional CTO changes the work
The engagement is measured on the decisions taken while a fractional CTO is inside the business, and the roadmap is the record they leave behind. That changes what a client should ask for in the first month.
- A mandate that sets out which decisions the fractional CTO may take alone and which come back to the board. Without it, the work becomes advice.
- A current-state capability audit, done in the first fortnight, in a form the finance function can read.
- A standard lock: the API contracts, data schemas and security positions that will not move for the life of the plan.
- One review trigger, agreed while everyone still agrees on it.
The fee question is settled by the same logic. A day rate pays for attendance. A mandate pays for decisions. Where a company cannot state four decisions the roadmap has to inform, no rate is low enough to make the engagement worthwhile, and that test belongs before the contract, while the terms are still open.
What the client keeps matters as much as what gets produced. The five fields per line, the standard lock, the review trigger and the decision record all stay in the company's own systems, readable by an incoming engineer or an incoming finance director. A roadmap that leaves with the consultant leaves the company where it started.
Four tests a roadmap has to pass
- Funding. Every line on the commitment horizon has an owner and a budget line. A line with neither belongs on the ambition horizon, and moving it there costs nothing.
- Standards. State the interfaces that will not move this year. If nothing can be pinned down, the work ahead is discovery, and the document should say so.
- Trigger. State what would cause a rewrite. A plan with no trigger is a plan nobody has agreed to change, and it will be abandoned the first time reality moves.
- Handover. Hand the document to an engineer who has never seen it and watch for a week. If they can act, the roadmap is working. If each line prompts a question, the interfaces were left unstated.
Little of this needs a platform. The NQCC roadmap, the Cabinet Office roadmap and a thirty-person product company's plan all do the same job: they set a direction, pin the parts that cannot move, and state when the plan will be looked at again. What has changed in practice is that the last of those three is now the part that decides whether the other two still work. The Centre put its review commitment in the same paragraph as its target, and that is the pattern worth copying.