Technology Roadmaps: A Template for Engineering Leaders
By Sebastiaan Jansen · · 6 min read
A technology roadmap is a sequenced view of the technical bets an engineering organization will fund over the next few quarters, tied to outcomes the business can recognize. It doesn't list every ticket, and its dates aren't promises. It shows which platforms, risks, and capabilities you fund now, which you prepare next, and which you leave for later. Leaders usually get asked for one when a board, a CTO, or a product peer wants to know whether the team only ships features or also pays for the work that keeps shipping possible.
What a technology roadmap is for
People outside engineering want to know the outcome, the order, and how long it will take.
A product roadmap sequences customer-facing outcomes, and the two should agree. If product plans self-serve billing in Q3 and payments can't support usage-based pricing until Q4, one of them is wrong. Say so early, while you can still move a theme or cut scope.
A project roadmap covers one effort, with its milestones, owners, and dependencies. This document covers the whole portfolio, and projects hang off it.
Tech roadmap vs engineering roadmap
A "tech roadmap" and an "engineering roadmap" are the same document read by two audiences. Leadership reads the themes, the horizons, and the bet. Managers read owners, capacity, exit criteria, and the tickets that show a theme is real. Publish one and derive the other from it.
What to put on it
Themes and bets go on the page. Tasks stay in the tracker.
- Theme: a name a non-engineer can repeat. "Cut p95 checkout latency under 300ms" is better than "Kafka migration phase 2."
- Outcome: latency, incident rate, lead time, cost per request, or a capability product can sell.
- Horizon: now, next, or later. The now-next-later roadmap holds up when date pressure is already bending the plan.
- Capacity: a rough share of a team's time, such as 20% of platform for one cycle.
- Owner: one person accountable for the narrative.
- Dependency: the product theme, vendor, or team that can block you.
- Exit criteria: two or three checks that tell you when to stop.
Leave off tool choices that are still being argued, and anything you can't tie to a customer, a risk, or a cost.
Horizons that stay honest
| Horizon | Window | What belongs here | What does not |
|---|---|---|---|
| Now | This quarter or the next two cycles | Funded work with an owner and exit criteria | Ideas that still need a spike |
| Next | The following quarter | Shaped work you expect to start if Now holds | Promises to customers |
| Later | Two to four quarters out | Direction and options you are watching | Staffing plans and dates |
Now should be full, Next should be reversible, and Later should be thin. If all three carry the same detail, you have a wish list. An agile roadmap keeps the far horizon coarse so you can update it when evidence arrives.
A template you can copy
Use one row per theme. Six to ten rows is healthy; past that, you're tracking projects.
Theme: Outcome: Horizon: Now / Next / Later Capacity: percent of which team, for how long Owner: Depends on: Exit criteria: Explicitly not doing:
The "not doing" line keeps the page from absorbing every request that comes in after the review. A new idea either replaces a row or waits. Review monthly against something you can demo, like cycle time, incident count, or a milestone. DORA's software delivery metrics describe how you ship, but they won't choose what you build.
Technology roadmap example
This technology roadmap example is made up. Northline is a B2B payments API with about 40 engineers. Product wants usage-based pricing later this year, on-call is noisy, and finance and product both query one Postgres replica.
Now (this quarter)
1. Isolate billing from the request path. About 30% of payments for one quarter. Owner: billing tech lead. Exit: a pricing change ships behind a config flag, and checkout p95 doesn't regress. Not doing: an invoicing UI rewrite.
2. Page only on customer-visible failures. About 15% of platform. Owner: SRE manager. Exit: a written alert standard, and the ten noisiest alerts fixed or deleted. Not doing: a new observability vendor.
3. Read replica for finance queries. One engineer for six weeks. Owner: data engineer. Exit: finance queries hit the replica, and month-end primary CPU looks like a weekday. Not doing: a warehouse migration.
Next (following quarter)
4. Usage events good enough for pricing. About 25% of payments, plus a product manager. Depends on theme 1 and on which meters are billable. Exit: one pilot customer reconciled to the ledger for a week.
5. Replace the shared staging database. About 20% of platform. Exit: each squad can reset its staging data in under an hour.
Later (direction only)
6. Multi-region reads. European customers stop waiting on a US-only primary. No date until themes 1 and 3 land. Not doing: multi-region writes until billing is split.
Payments stays at 30% because features still have to ship. If product wants usage pricing generally available in the same quarter as theme 4, write that collision into the review notes. A strategic roadmap sits above this one and names the bets: usage-based pricing and fewer severe incidents. This sequence is how those bets become something the team can build.
How to build one in half a day
- List work you're already doing. Cluster last quarter's meaningful changes.
- Add risks that aren't projects yet. A bus factor of one, a region you can't fail out of, a compliance date. Name the cost of delay or leave it off.
- Score two axes. Impact if it lands, and regret if you wait two quarters. Anything high on both goes to Now.
- Assign capacity before quarters. Above about 40% of a team's time, cut a theme or slip it to Next.
- Write "not doing" before the review. A no is easier to accept in the draft than in the meeting.
- Publish where the work lives. Link each Now theme to its epics.
Keep the page in the tracker you already use. Falrow does that with a roadmap counted from tickets, so a theme moves when its work moves. Jira, Linear, or a spreadsheet also works if someone owns the updates. The hard part is refusing a row you can't staff. A Jira roadmap shows the hierarchy you configure, but it can't tell you whether that hierarchy is honest.
Capacity is the constraint you skip
Product work and technical work can't both run at full speed. Hold a fixed share of each cycle for Now themes and give product the rest.
Otherwise, unfinished themes slide forward at rollover, product work doesn't shrink, and Now turns into a pile. If a theme stays, something else leaves or its exit criteria shrink. Falrow's cycles support a reviewed rollover, so leftover work gets carried forward on purpose.
How to keep it alive
A roadmap you edit once a year ends up as a poster on the wall. Thirty minutes a month covers three questions: which Now theme met its exit criteria, which Next theme is ready and what leaves to make room, and what new request arrived that you are not adding.
If the answers call for a new strategy, hold that meeting separately. The monthly check only asks whether the sequence still fits the capacity you have. Share one page with product and the people who fund you. When asked for a date you don't have, say "Later, unstaffed, after billing is split." Replace a bet that turns out wrong. If a plan never loses a theme, nobody is updating it.
FAQ
What is a technology roadmap?
A sequenced plan of the technical themes an engineering organization will fund over the next few quarters. Each theme has an outcome, an owner, a capacity share, and a horizon: now, next, or later. Tickets stay with the teams.
How is it different from a product roadmap?
A product roadmap sequences what the customer gets and why they care. The technical plan sequences the platforms, risks, and capabilities those outcomes depend on. When the timing disagrees, fix one before you publish either.
How far ahead should it look?
Be specific for one quarter and directional for the two to four quarters after that. Keep Later thin, and revise it when evidence changes the bet.
Who owns it?
One engineering leader owns the page: the CTO, the VP of engineering, or the head of platform. Squad leads own the themes they fund. Product and finance review it, but they shouldn't rewrite exit criteria on their own.