Program Roadmap

The hardest thing about a program roadmap isn't building it. It's keeping it at the right altitude — detailed enough to say something, coarse enough that five teams can each see themselves in it without it becoming a merged backlog. This template is calibrated for that: five teams, one of them nested three deep, coordinated across roughly eight and a half months.

Who this program roadmap template is for

This is a program manager's or engineering director's chart. It assumes you coordinate several teams who work mostly independently but ship toward shared dates, and that you're regularly asked some version of "what is everyone working on and when does it land?"

The audience is usually leadership or a cross-functional group — people who need to understand sequencing and commitments but who will never open a ticket tracker. If your audience is the teams themselves, they're better served by their own plans; this is the view that sits above those.

What goes on a program roadmap?

Five top-level lanes, one of them nested three deep.

Platform splits into Core Services — itself split into Auth and Billing — and Developer Experience. Auth runs a service overhaul into an SSO rollout; Billing runs a platform migration that starts once the auth work is done. Developer Experience runs a CLI revamp into a CI/CD overhaul and a docs site.

Growth splits into Acquisition (onboarding redesign, then a referral program and paid acquisition experiments running in parallel) and Retention (a lifecycle email revamp, a churn model, and a loyalty relaunch).

Data runs an event pipeline rebuild into self-serve dashboards and forecasting models, with a data governance rollout alongside.

Security runs vendor security reviews into an identity overhaul, penetration testing, and SOC 2 readiness — the longest single commitment on the chart.

Mobile runs iOS and Android rebuilds in parallel, alongside a push notification revamp, converging on an app store relaunch.

Nine milestones sit across the program — a kickoff, six delivery dates spread through the back two-thirds, a ribbon-only mid-program review, and a close-out.

How long should roadmap items be?

Across the whole template, Platform's work spans about fourteen weeks, Growth's about twenty-four, Data's about twenty-eight, Security's about thirty-six, and Mobile's about sixteen. The staggered finishes are deliberate — roadmaps where every lane ends neatly on the same date are describing a fiscal calendar, not a plan.

Individual bars run from about three and a half weeks (a docs site) to thirteen weeks (the iOS and Android rebuilds).

Shorter than that and it's a task, not a roadmap item — it'll finish before the roadmap is next reviewed, so it only ever appears as already-done. Longer than about four months and it's a placeholder: nobody can tell whether a sixteen-week bar is on track at week six.

The auth overhaul is currently the one number worth calling out directly: it's tracking a week behind its baseline, which is the kind of variance a program roadmap should surface rather than quietly absorb.

How dependencies work on this roadmap

Eighteen links. Eleven are finish-to-start and mostly run within a single team's own lane: the auth overhaul feeds both SSO rollout and billing migration; the CLI revamp feeds the CI/CD overhaul; the event pipeline feeds dashboards, which feed forecasting; the identity overhaul feeds penetration testing, which feeds SOC 2 readiness.

Five links are start-to-start, mostly keeping a successor tied to when its predecessor begins rather than a separately-tracked date — the docs site to the CI/CD overhaul, paid acquisition experiments to onboarding, the data governance rollout to the pipeline rebuild, the identity overhaul to the vendor reviews that precede it, and the app store relaunch to the Android rebuild.

One link crosses into genuinely cross-team territory and is worth naming directly: the push notification revamp is finish-to-finish with the iOS rebuild — both close on exactly the same day, so mobile push doesn't ship on a separately-guessed schedule.

The other cross-team link is start-to-finish: the churn prediction model's completion is gated by when the billing migration starts, not by billing finishing. The model depends on events the new billing platform emits, so it can't be called done until that migration is genuinely underway.

Every other link stays inside its own team's lane on purpose — most cross-team arrows on roadmaps are wishes rather than binding constraints, and drawing them anyway makes every slip in one lane visually cascade into others that were never actually blocked.

What to change for your own program

Common mistakes on program roadmaps

Too many lanes. Eight teams on one chart produces something nobody reads. Split by audience instead — leadership rarely needs the same roadmap as the engineering org.

Roadmap items sized like tasks. A two-week bar on an eight-month chart is visual noise.

Drawing every cross-team dependency. It makes the roadmap look fragile and turns every review into a discussion of arrows rather than outcomes.

Milestones with no owner. Every milestone on this chart should be something a specific person will be asked about. If nobody owns it, it's decoration.

Never letting it move. A roadmap that's been correct for two quarters hasn't been maintained. Drag the bars, keep the baseline, and let the comparison do the talking.

Sharing the roadmap

Program roadmaps are read far more often than they're edited, usually as a slide or a PDF attached to a monthly update. Export a PNG for the deck and a PDF for the record, and re-export after each monthly pass. Everyone who needs to read it does so without an account, which is what keeps it in circulation rather than in a tool only you open.