Living Roadmaps: Plans That Evolve With Your Code

roadmap · birds-eye auth ✓ billing teams api v2 reconciles ↑ live specs + tasks T1 done T2 done T3 running T4 backlog + new scope T6 backlog T7 review

In AI development, plans change daily. A living roadmap reconciles with reality as you ship while keeping the birds-eye view intact. How to build one.

Angela Edmundson··6 min read

Most roadmaps are obituaries. They describe a plan that was true the morning it was written and started decaying the moment work began. By the time anyone looks again, the document and the codebase have nothing to do with each other.

That was tolerable when projects moved at the speed of human typing. It isn't anymore. When an agent can ship a feature between lunch and standup, a roadmap reviewed monthly is fiction within a week. The fix isn't a better planning meeting. It's a roadmap that stays alive.

What a living roadmap is

A living roadmap is a plan that reconciles itself with reality as work happens, while preserving the birds-eye view of where the project is going.

Two halves, both required. The reconciliation keeps it honest: work that shipped is marked done, work that slipped shows as slipped, new scope gets absorbed instead of ignored. The birds-eye view keeps it useful: zooming out still tells you the shape of the project — the themes, the sequence, what's next — not just a flat list of closed tickets.

A dead roadmap has the second half and loses the first; it shows a tidy plan that no longer matches the code. A task tracker has the first half and loses the second; it's accurate but you can't see the forest for the issues. A living roadmap holds both at once.

Why traditional roadmaps break under AI

Traditional roadmaps fail in AI-assisted development because the rate of change outran the cadence of planning.

The old loop was: plan quarterly, review monthly, adjust occasionally. That worked because the work moved slowly enough that a month-old plan was still roughly true. Agents broke that assumption. Scope that used to take two weeks now lands in two days. Three of those in a week and your roadmap is describing a project that no longer exists.

When the plan and the reality diverge, something predictable happens: people stop trusting the roadmap. Once it's wrong twice, nobody checks it. It degrades into a slide deck you update before a stakeholder meeting and ignore the rest of the time. The roadmap stops being a tool you use and becomes a chore you perform.

The instinct is to update it more often. But manual updates at AI speed are a treadmill — you'd spend more time maintaining the map than walking the territory. Faster manual reconciliation isn't the answer. Automatic reconciliation is.

The principle: derive the plan, don't maintain it

The way out is to stop treating the roadmap as a separate document you keep in sync, and start treating it as a view derived from the work itself.

This is the key move. If your roadmap is built from the same artifacts your work actually runs on — your specs and tasks — then completing work is updating the roadmap. There's no second step to forget. The plan reflects reality because it's computed from reality.

Concretely, that means:

  1. One source of truth. The roadmap reads from the same specs and tasks the team builds against, not a parallel document that has to be reconciled by hand.
  2. Status flows up automatically. When a task completes or a spec finishes, the roadmap's view of that initiative changes on its own — no status meeting required.
  3. New work has a home. When scope appears mid-stream (and it always does), it lands as a spec or task that the roadmap absorbs, rather than an off-plan surprise.
  4. The altitude is preserved. Above the task-level churn, the roadmap still groups work into themes and sequence, so zooming out gives you direction, not noise.

The roadmap becomes a lens on the project, not a record you maintain alongside it. That's what makes it living: it can't drift from the code, because it's made of the same material.

Keeping the birds-eye view while everything churns

There's a tension here worth naming. The more accurately a roadmap tracks reality, the more it risks becoming a firehose of task-level detail — accurate but useless for seeing the shape of things.

The resolution is layering. The bottom layer is the live task and spec state — granular, constantly changing. The top layer is a stable structure of themes and milestones that changes slowly even as the work underneath it moves fast. The features you're building this quarter don't churn the way individual tasks do.

So the birds-eye view stays legible precisely because it sits at a different altitude than the reconciliation. You can ship twenty tasks and the high-level roadmap reads the same — "auth is in progress, billing is next" — while the detail underneath reflects every one of those twenty. Reconciliation happens at the bottom; the view lives at the top; both are always current.

How Monday Morning does it

Monday Morning builds the roadmap as a derived view rather than a maintained document. Its features and specs are the real units of work, and the roadmap reads from them — so as specs get built and tasks complete, the roadmap reconciles to match without a manual update.

The birds-eye view shows up where you're already working. The Conductor keeps a roadmap pulse at the top of its panel — a one-line read on where the project stands — and opens the full roadmap board when you want the whole picture. You don't go to a separate tool to check the plan; the current plan is sitting next to the work.

Because the roadmap is computed from project state, the two can't quietly diverge. Finishing a spec moves the roadmap. New scope captured through the Conductor becomes a spec or task the roadmap already accounts for. The high-level shape stays stable while the detail underneath stays honest — living roadmap, both halves intact.

The takeaway

In AI-assisted development, the roadmap problem isn't planning — it's keeping the plan true as the ground shifts under it daily. A static document can't win that race, and updating it faster by hand just turns planning into a treadmill.

The answer is to derive the roadmap from the work instead of maintaining it beside the work. Tie it to your specs and tasks so reconciliation is automatic, and layer a stable theme-level view on top so the birds-eye picture survives the churn. Build it that way and the roadmap stops being an obituary — it becomes the one view that's always true.

Frequently Asked Questions

What is a living roadmap?
A living roadmap is a plan that updates itself as work happens instead of being frozen at the start of a quarter. It reconciles with reality continuously — marking work done, surfacing what slipped, absorbing new scope — while preserving the high-level view of where the project is headed.
Why do traditional roadmaps fail in AI-assisted development?
Because the pace of change outran the cadence of planning. When agents can ship a feature in an afternoon, a roadmap reviewed monthly is stale within days. The plan and the codebase diverge, people stop trusting the roadmap, and it becomes a document nobody reads instead of a guide anybody uses.
How do you keep a roadmap in sync with the actual code?
Tie the roadmap to the same artifacts your work runs on — specs and tasks — so completing work updates the plan automatically rather than through a manual status meeting. The roadmap reads from real project state, so its high-level view is always derived from what actually shipped.
How does Monday Morning keep a roadmap up to date?
Monday Morning derives roadmap status from the specs and tasks that drive the actual work. As specs are built and tasks complete, the roadmap reconciles to match, and the Conductor surfaces a one-line roadmap pulse so the birds-eye view stays current without a manual update step.
#roadmap#project-management#ai-development#planning#spec-driven-development

Keep Reading