How to build a technology roadmap (with a template)

What a technology roadmap is for

A product roadmap says what customers will get. A technology roadmap says what engineering will do to get there and to keep the system healthy while it does. In a small company they should be the same document, with technical work visible next to the features it enables.

The roadmap’s job is to make trade-offs explicit. Every quarter you have a fixed amount of engineering time. Spending a month on a database migration means a month less on features. If that trade-off isn’t written down and agreed, it gets made silently, usually in favor of features, until the debt stops the features.

Step 1: start from business goals

Before listing any work, write down three to five business outcomes for the next two to four quarters. Not features. Outcomes: “move upmarket to customers with 500+ seats”, “cut churn in the first 90 days”, “pass a SOC 2 audit”, “survive 10x traffic from the partnership launch.”

Each outcome implies engineering work, and some of it isn’t features. Moving upmarket might need SSO, audit logs and tenant isolation. Surviving 10x traffic might need caching and database work. This is how platform work gets onto the roadmap legitimately: tied to an outcome the business already wants.

Step 2: inventory the technical work

Next, list what engineering knows needs doing, whether or not anyone has asked for it. Sources worth mining:

• Incident history. What broke in the last six months, and what would stop it breaking again.
• Hotspots in the code. Files that change often and cause bugs. Your Git log shows them.
• End-of-life dates for your language, framework, database and OS versions. Upgrades that are cheap now get expensive later.
• Developer friction. Ask the team what slows them down. Slow CI, flaky tests and painful local setup belong on the roadmap.
• Security and compliance gaps that a customer, auditor or acquirer will ask about.

For each item, write one sentence on the cost of not doing it. “Rails 6 is out of security support; every month we wait adds risk and makes the upgrade bigger” is a case. “The code is messy” isn’t. My guide to reducing technical debt covers how to frame debt in business terms.

Step 3: decide the capacity split

Rather than fighting over every item, agree a split of engineering capacity up front. A common starting point for a growing SaaS is roughly 70% product features, 20% technical debt and platform, 10% unplanned work and experiments. Adjust it to your situation: a team drowning in incidents might need 40% on platform for a quarter; a pre-product-market-fit team might go 90% features.

The split is a negotiation you have once a quarter instead of every sprint. It also protects technical work from being cut first whenever a deadline looms.

Step 4: rank, don’t schedule

Rank all items within each bucket. One list, no ties. The ranking forces the real conversation: is the SSO work more important than the billing rebuild?

Then organize the ranked items into three horizons rather than precise dates:

• Now (this quarter): committed, scoped, estimated as ranges. High confidence.
• Next (next quarter): likely, roughly scoped. Medium confidence.
• Later (beyond that): intentions, not commitments. Low confidence.

Now/Next/Later is more honest than a Gantt chart. It shows what you’re sure of and what you aren’t. For the “Now” column, use ranges rather than single dates; I’ve written up the techniques in software estimation.

Step 5: review it with the business, then publish it

Walk the roadmap through with the CEO, product and sales before calling it final. The goal is agreement on the trade-offs, not approval of each line. Then put it somewhere everyone can see it: a single page in your wiki, linked from the engineering channel.

Update it monthly. Mark what shipped, what moved and why. A roadmap that is quietly out of date is worse than none, because people keep making decisions based on it.

Technology roadmap template

Copy this structure into a single document. Keep it to two pages; if it’s longer, nobody will read it.

1. Header: owner, last updated date, review cadence.
2. Business outcomes (3–5): each with a measurable target and a target quarter.
3. Capacity split: percentage for features, debt and platform, and unplanned work, with one sentence on why.
4. Now (this quarter): ranked items. For each: name, outcome it serves, owner, estimate range, confidence, status.
5. Next (next quarter): ranked items with outcome served and a rough size (S/M/L).
6. Later: a short list of intentions with outcome served.
7. Technical health items: each with the cost of not doing it, linked to an outcome or a risk.
8. Risks and dependencies: hiring, vendor deadlines, end-of-life dates, things outside engineering’s control.
9. Explicitly not doing: items considered and deferred, with the reason. This section prevents the same debate every month.
10. Change log: what moved since the last version and why.

Common roadmap mistakes

• Dates on everything. Commit dates only for the current quarter, and as ranges.
• No technical work visible. If it isn’t on the roadmap it will be cut, and then you’ll lose a quarter to an emergency upgrade.
• Too many priorities. If everything is ranked first, nothing is. Five big items a quarter is plenty for a team of ten.
• Written once, never updated. Set a monthly review in the calendar before you publish.
• Big-bang platform projects. Prefer incremental work that ships value every few weeks. A rewrite on the roadmap is a warning sign; see rewrite vs refactor.

When to get outside help

If you’re a founder without a technical leader, or your engineering lead is too deep in delivery to step back, building the first version of a technology roadmap is a good use of outside time. An experienced person can audit the codebase, interview the team and turn it into a ranked plan in a couple of weeks. That’s what my technology roadmap consulting covers, and it’s often the first piece of work in a fractional CTO engagement.

Related

• A technical roadmap your team can actually execute
• Fractional CTO services for growth-stage SaaS
• Software estimation that survives contact with reality
• Reducing technical debt without stopping feature work
• Building without a technical cofounder