Framework library · Technology management
Technology roadmap
A technology roadmap lines up four layers on one timeline: what the market will need, which products and services meet it, which technologies those products depend on, and what resources and partners make it possible. Its value is in the links between layers, which show why each investment exists and what slips if it is late.
Use it when
- Technology investment needs to be justified by the products and customers it serves.
- Several teams depend on each other's technology and need to see the sequence.
- You are planning around a dated external event, such as a standard's release or a spectrum auction.
Avoid it when
- You need a delivery plan with tasks and dependencies. Use a project schedule.
- The direction is not decided. A roadmap shows a chosen path. Explore options with scenario planning first.
- Nobody will maintain it. A stale roadmap is worse than none, because people still trust it.
How to run it
Set the horizon and periods
Quarters for two years, or half-years for four. The far end can be coarse.
Start with the market layer
Customer needs, regulation and dated external events. Everything below should trace back to something here.
Add products and services
What will be offered, and when, to meet those needs.
Add the technologies
What each product depends on, with the date it must be ready. Mark milestones such as a standard's freeze.
Add resources and partners
Hiring, suppliers, funding and alliances that the technology layer needs.
Check the links
Any technology with no product above it, or any product with no technology below it, is a gap to resolve.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Drawing only the technology layer, which makes the roadmap an engineering wish list.
- Setting precise dates far into the future. Show uncertainty by widening bars rather than inventing precision.
- Treating a vendor's roadmap as your own. Its dates serve the vendor's sales plan, and when they slip, every product that depends on them slips too.
Where it comes from
Developed at Motorola in the late 1970s and described in Willyard and McClees, "Motorola's technology roadmap process", Research Management, 1987. The layered form used here follows Phaal, Farrukh and Probert, "Technology roadmapping: a planning framework for evolution and revolution", Technological Forecasting and Social Change 71(1-2), 2004. Source.
Use it with
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.