Building a Technology Roadmap: A Template for Non-Technical Owners

A technology roadmap is not a Gantt chart, and the ones that look like Gantt charts are usually wrong within a quarter.

A useful roadmap is a sequence of decisions, with the reasoning attached, that tells you what you are doing now, what you are deliberately not doing yet, and what would have to change for that to move. It fits on one page and a non-technical owner can write it.

Why the usual version fails

The document most businesses receive as a roadmap is a list of projects with dates. It fails for three reasons.

It commits to dates for work nobody has scoped. Month nine's project has not been specified, so its date is fiction, and everyone knows it.

It does not say why the order is what it is. When circumstances change, nobody can tell which parts of the plan still hold, so the whole thing is abandoned rather than adjusted.

It has no "not now" section. So every new idea competes with the plan on equal terms, and the plan loses.

The five sections

1. What the business is trying to do

Three to five sentences of business outcome, not technology. "Grow the trade side to 40 per cent of revenue." "Survive the founder stepping back in three years." "Stop losing a day a week to quoting."

Everything below has to connect to one of these. Anything that does not is the first thing to cut.

2. What is true now

An honest paragraph on the current state. What works, what is fragile, what depends on one person, what is out of support. The one-week audit in modernising a legacy business produces exactly this.

This section is what makes the roadmap credible to anyone reading it later.

3. Now, next, later

Three columns, and the definitions matter.

Now: in progress or starting this quarter. Scoped, costed, owned by a named person. Three items maximum. Most roadmaps fail here by listing nine.

Next: the following two quarters. Named, roughly sized, deliberately not scoped in detail yet.

Later: agreed direction, no commitment. This is where most of the list lives, and having somewhere legitimate for it is what stops the "now" column swelling.

For each item, one line on why it is where it is.

4. Deliberately not doing

The section that makes a roadmap useful rather than decorative.

List the things that have been proposed and declined, with the reason. "Not replacing the accounts system: it works, nothing else depends on changing it, and connecting it costs a fifth as much." "Not building a customer portal: three clients asked, twenty did not, revisit if it reaches ten."

This stops the same conversation recurring every quarter, and it gives you a written answer for the supplier who raises it again.

5. What would change our mind

For each major item in "later" and each entry in "not doing", the trigger. "If two more clients ask." "If the supplier announces end of support." "If we pass thirty staff."

Triggers convert a roadmap from a plan you abandon into a document you consult.

The template

TECHNOLOGY ROADMAP
[Business]        [Date]        Owner: [name]        Review: [quarterly date]

WHAT WE ARE TRYING TO DO
1.
2.
3.

WHERE WE ARE NOW
[One honest paragraph: what works, what is fragile, what depends on
one person, what is out of support.]

NOW (this quarter, max 3)
| What | Why it is first | Cost | Owner | Done when |

NEXT (following two quarters)
| What | Why | Rough size |

LATER (direction, no commitment)
| What | Why it matters eventually |

DELIBERATELY NOT DOING
| What | Why not | What would change our mind |

DEPENDENCIES AND RISKS
[Anything where one person, one supplier or one system is a [single point](/blog/technology-handover-test)
of failure.]

How to fill it in

Do the "now" column last. Start with the business objectives, then the honest current state, then what you are not doing. By the time you reach "now", the three items usually choose themselves.

Cost the "now" items and nothing else. Costing "later" items is guessing, and a guessed number becomes a budget in somebody's mind.

Put a date on the review, not on the items. Quarterly. The review is where things move between columns.

Get one technical person to read it, whether that is a supplier, a contractor or a fractional CTO. Not to write it. To tell you where the sequence is wrong, which is a different and more useful contribution. See ten questions to ask a development agency..

The most common sequencing error

Building something new before fixing what it depends on.

A customer portal built on top of data nobody has checked, or a reporting tool built on a process nobody has documented, inherits every problem underneath it and adds a layer that makes them harder to see. If an item in "now" depends on data or a process that is in "later", the order is wrong.

Key Takeaways

• A roadmap is a sequence of decisions with reasoning attached, not a list of projects with dates. Dates for unscoped work are fiction.
• Five sections: objectives, honest current state, now/next/later, deliberately not doing, and what would change your mind.
• Three items maximum in "now". Roadmaps fail by listing nine and delivering two.
• The "deliberately not doing" section is what makes it useful. It stops the same conversation recurring and gives you an answer for the persistent supplier.
• Fill in "now" last. Once the objectives, the current state and the exclusions are written, the three items choose themselves.

Frequently Asked Questions

How far ahead should a roadmap look?

Twelve to eighteen months of named items, with direction beyond that. Anything more specific than eighteen months in a small business is decoration, because the business will change more than the technology will.

Who should own it?

Whoever makes the spending decisions, usually the owner or managing director. Technical input improves it; technical ownership turns it into a technology plan rather than a business one, and those get deprioritised the moment trading gets difficult.

How often should it change?

Review quarterly, and expect one or two items to move each time. If nothing ever moves, it is not being consulted. If everything moves every quarter, the "now" column is too long or the objectives are unclear.

Do we need a fractional CTO to write one?

No, and a good one will tell you that. The document should come from the business. Where external help genuinely earns its fee is in reviewing the sequence, sizing the items and telling you which of the things you plan to buy you do not need. See what a fractional CTO costs in the UK.

---

Want someone to review your sequencing rather than write your plan for you? Talk to Halo Technology Lab. Our strategy and scoping service includes a roadmap review, and we will happily tell you which items to drop.