Technology Roadmap Example: A Now, Next, Later Plan for a Platform Team

Technology roadmaps tend to fail in one of two ways. Some are Gantt charts with dates nobody believes, redrawn every quarter. Others are a backlog export with a title on top. Neither tells the teams that depend on you what is happening now, what comes next and what you have not decided yet.

Platform teams have it harder than most. Their deadlines are often set by someone else, such as the end of support for a Kubernetes or PostgreSQL version. Their customers are other engineering teams, each with a request. And their work is full of long migrations that stay almost done for months.

This post builds a technology roadmap for a platform team in the Now, Next, Later format, explains where the format comes from and why it suits technology work, and covers how to run it so it stays honest.

Why Now, Next, Later

The format comes from ProdPad. In The Birth of the Modern Roadmap, co-founder Janna Bastow describes how, near the end of 2012, her co-founder Simon Cast sketched three columns on a napkin: Current, Near term and Future. The columns were time horizons, and the idea behind them was certainty: work in the first column is clear and close, work in the last is fuzzy in scope. They built it into ProdPad as the Now-Next-Later roadmap.

The columns are about certainty, not calendar quarters. An item moves left when you know enough to commit to it, not when a quarter ends.

What makes a technology roadmap different

External deadlines. Software you run has a support window, and the window sets your order of work. The Kubernetes project maintains the three most recent minor releases, and each gets about a year of patch support. Upgrades are therefore a recurring roadmap item, not a one-off project, and skipping minor versions is not supported for kubeadm clusters, so going from 1.35 to 1.37 means two upgrades. PostgreSQL supports each major version for five years; after that, a final minor release ships and the version is end-of-life.

Internal customers. Stream-aligned teams plan around what the platform will deliver. They need to know what is committed and what is not, which is exactly what the columns say.

Long tails. A migration that is 90 percent done still has a database or a service left on the old version. Show progress as what is left to move, not as a date.

Dependencies. Platform work often builds on other platform work. A service template that includes tracing cannot ship before tracing works.

Write outcomes, not projects

Write each item as the result you want, so that anyone can tell when it is done:

Add the measure to the item's description: services exporting traces, clusters on a supported version, databases still on version 15.

The example: a platform team's roadmap

The example is dated October 2026, so the deadlines are the real ones from the Kubernetes and PostgreSQL release pages.

• Now. Traces everywhere, the OpenTelemetry rollout, is about a third done and at risk because the team needs another engineer. Kubernetes 1.37 is in progress: Kubernetes 1.35 reaches end of life on February 28, 2027, which falls in the Next window, so the upgrade has to happen now.
• Next. Golden path, a service template with CI/CD, tracing and dashboards built in, waits for tracing. Off PostgreSQL 15 is a major upgrade to version 18 with pg_upgrade, ahead of the version 15 end of life on November 11, 2027.
• Later. Two problems to explore: making cloud cost visible per team, and making checkout survive a region outage. Neither has an owner or a solution yet.

How to read it:

• Columns are certainty, not quarters. Left to right, the work goes from committed to likely to not yet decided.
• Each card is an outcome with an owner, a status and a progress bar. Later items have no owner yet; they are problems, not plans.
• The dependency badge shows that tracing blocks the golden path, because the template ships with tracing turned on.
• Milestones are external deadlines, placed in the column where they fall. Kubernetes 1.35 support ends during Next, so its upgrade is in Now. PostgreSQL 15 support ends in Later, so its upgrade starts in Next and leaves time for the long tail.
• The status badge explains the risk: tracing needs staffing.

How to run it

• Review it on a fixed rhythm, such as every two weeks, with the leads of the teams you serve. Move items only at the review, so the roadmap does not change under people's feet.
• Keep Now small. Put in it only what the team is staffed to work on. If something new enters Now, something else leaves.
• Promote from Later to Next only when shaped: a problem statement, a measure of done, an owner and a rough size.
• Use dates only for external deadlines. Internal estimates belong in the item's description as ranges, not on the roadmap as promises.
• Show finished items once, at the next review, then archive them. The roadmap is about what is ahead.
• Link items to the details: the design doc, the migration tracker, the architecture diagram. The CI/CD pipeline diagram and the Kubernetes architecture diagram posts show what those pictures can look like.

Common mistakes

• A feature list with dates. It hides uncertainty until a date slips, and then everyone learns about it at once.
• Everything in Now. If ten items are in progress, none of them is.
• No owners. An item without an owner in Now or Next is a wish.
• Hidden dependencies. If one item needs another, draw it. Otherwise the second item starts and stalls.
• Upgrades that appear only when urgent. Put every support window you depend on on the roadmap as a milestone the day you adopt the version.
• A roadmap nobody looks at. Keep it where people already work, and embed it in your docs instead of pasting a screenshot that goes out of date.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram, or start from the Now / Next / Later roadmap template.
2. From the Roadmap pack, add three Quarter frames and name them Now, Next and Later.
3. Add an Epic for each outcome and set its title, owner, status and progress.
4. Add a Milestone for each external deadline, with its date, in the column where it falls.
5. Add a Dependency badge between two epics where one blocks the other, and connect them with dashed edges.
6. Add a Status badge for a risk, and a Core Note with the rules for each column.

The example uses 13 diagram nodes, within the Free plan.

FAQ

What is the difference between a technology roadmap and a product roadmap? A product roadmap is about what customers get. A technology roadmap is about the capabilities, upgrades and migrations that make it possible, and its customers are usually other engineering teams. The format can be the same.

Should a technology roadmap have dates? Only where a date is real: an end of support, a contract or a regulation. Everything else goes into columns of certainty.

How far ahead should Later go? There is no fixed horizon. Later holds problems, so keep it short enough that every item is still worth discussing at the next review.

How do I show progress on a long migration? Count what is left to move, such as clusters, services or databases, and update the number at each review. A percentage without a count hides the long tail.

Who should see the platform roadmap? Everyone who depends on the platform. Share it with the teams you serve and review it with their leads, so they can plan around what is committed.

Start free — one seat, no credit card.