Development Roadmap

Engineering plans have a credibility problem, and it's usually self-inflicted. A roadmap drawn at ticket resolution looks precise and turns out wrong; a roadmap drawn as four featureless quarters looks honest and says nothing. This template sits between the two: four phases nested three deep across about seven months, with the dependencies that genuinely govern a release and nothing else.

Who this development roadmap template is for

This is for an engineering lead, tech lead, or delivery manager who owns a release and has to explain it upward. It assumes a substantial piece of work — a major version, a platform rewrite, a new product surface — with real architecture decisions at the front and a real rollout at the back.

The audience is generally not other engineers. Engineers have the tracker. This is the chart for a product counterpart, an executive sponsor, or a customer-facing team who need to plan around your dates.

What are the phases of a software development roadmap?

Four top-level lanes, one of them three deep, plus docs running alongside.

Discover covers the technical spec, a stakeholder alignment workshop, the architecture review that signs it off, and feasibility spikes. It starts before the chart's zero point, because spec work almost always begins during the tail of the previous release.

Build splits into Core Services (scaffolding, a service mesh, and data migration tooling) and Feature Teams — itself split into Web and Mobile, each running its own feature build into its own follow-up work. This is the longest phase by a wide margin.

Harden splits into QA (a test plan, regression, then load and failover testing) and Security (a security review, then a dependency and license audit). Deliberately separate sub-lanes, for reasons worth defending in any planning meeting.

Ship covers the phased rollout, general release, and the flag cleanup and rollback drill that follow it.

Docs runs as its own top-level lane — API reference, a migration guide, then release notes — so documentation is never the thing quietly slipping behind the code.

How long does each phase take?

Roughly seven months end to end, distributed unevenly on purpose.

Discover runs about five weeks. Build is the longest phase at about sixteen weeks — Core Services alone runs from scaffolding through data migration tooling in about fourteen and a half weeks, while Web and Mobile each run roughly twelve to thirteen weeks of feature work. Harden runs about eight weeks across QA and Security together. Ship runs about five weeks, and Docs runs about nine weeks, mostly overlapping Harden and Ship rather than following them.

The ratio to notice is that hardening and shipping together are still under a fifth of the programme. Teams routinely plan them as a fortnight and then discover that a penetration test has a three-week lead time. Drawing them at honest length is the main reason to use this template rather than a two-phase build-and-launch chart.

Which dependencies govern a release?

Twenty-four links. Thirteen are finish-to-start and form the spine: spec finishes then the workshop starts; the workshop finishes then architecture review starts; review finishes then feasibility starts; feasibility finishes then scaffolding starts, which in turn gates both the web and mobile feature builds.

Nine links are start-to-start, mostly keeping a successor tied to when its predecessor begins rather than a fixed date — the service mesh to scaffolding, the web and mobile test plans to their respective feature builds, the license audit to the security review, and the rollback drill and flag cleanup to general release.

One link is start-to-finish, and it's the one worth naming directly: data migration tooling's completion is gated by when security review starts, not by review finishing. In this build the two dates land on the same day — migration work finishes the moment review begins, because review needs a stable target to assess.

One link is finish-to-finish: load testing's completion is tied to the phased rollout's completion, not gated upfront by a hard buffer signed off weeks in advance — testing stays live against the release candidate for as long as rollout itself is still moving.

The most important structural fact is that hardening sits on the critical path with real but limited parallelism. There's nowhere to absorb a slip in security review without it showing up in the rollout date, which is exactly why it should be visible before anyone proposes compressing it.

What to change for your own release

Common mistakes on engineering roadmaps

Folding hardening into build. It disappears, and then it's discovered at the point where there's no time left for it.

Drawing sprints. Cadence is not structure. A roadmap of a dozen identical two-week bars conveys less than four honest phases.

Equal confidence across the chart. The bars seven months out aren't as firm as the ones next month, and presenting them identically is how roadmaps lose credibility.

No migration or docs work. Both are invisible to stakeholders, both are always required, and both are always underestimated.

Rebuilding rather than dragging. Keep the baseline and move the bars. A release that's visibly slipped for a stated reason is far more trustworthy than one that's been redrawn with no history.

Presenting the release plan

This is a chart that gets attached to planning documents, shown in steering meetings, and forwarded to teams who need to schedule around your dates. Export a PDF at each phase boundary and a PNG whenever the bars move. Recipients read it without needing an account or any knowledge of your tooling, which is what makes it useful outside engineering.