Planning and Roadmap: Now / Next / Later

The roadmap is the artifact that turns the kickoff into a quarterly plan, and the artifact most projects fake. The fake version is a Gantt chart with confident dates that nobody believes. This chapter shows the honest version - Now / Next / Later with confidence levels - and how to communicate it without losing stakeholder trust.

When does a written roadmap actually pay back?

Three signals.

Project longer than one quarter. Below a quarter, the kickoff doc plus a sprint plan is enough. Above a quarter, the team and stakeholders need a horizon view.

Cross-team dependencies. When Team A's work depends on Team B's API, both teams need to see the timeline shape. The roadmap is where dependencies surface before they bite.

External communication required. Sales wants to commit to customers, marketing wants to plan launches, leadership wants to forecast hiring. Each is reading the roadmap differently; one artifact serves all three.

If the project is one team, one quarter, internal-only, you can skip the formal roadmap and use the kickoff doc as the plan.

What is the cost of vague or absent roadmap?

Three failure modes.

Stakeholder surprise. Sales sold a feature for January; team planned to ship it in March. The mismatch surfaces at the quarterly review.

Team overload. Without visibility, leadership keeps adding items to the team's plate. Capacity calculation is impossible without a written plan.

Hiring lag. A new engineer needs a quarter to ramp up. If the roadmap shows growth coming in 2 quarters, hiring starts now. Without a roadmap, hiring starts when the pain hits.

What does the minimal roadmap look like?

# Roadmap — {{ Team / Product }}, updated 2026-06-10

## Now (Q3 2026 — committed, 90% confidence)
- Refund flow end-to-end (Sponsor: VP CS) — owner: Bob — 6 weeks
- Postgres 16 upgrade (Sponsor: Infra) — owner: Carol — 4 weeks
- API rate-limit dashboard (Sponsor: VP Eng) — owner: Alice — 3 weeks

## Next (Q4 2026 — planned, 70% confidence)
- Subscription billing (depends on refund flow shipping)
- Multi-currency support (depends on FX provider selection)
- Mobile checkout flow (depends on web checkout patterns landing)

## Later (Q1 2027 onward — intent, 30% confidence on specifics)
- B2B contract billing
- Self-service refund (after refund flow stabilises)
- Analytics: revenue dashboards

Three details. The "depends on" notes are explicit so promotion from Next to Now requires those dependencies to be done. The sponsor name surfaces who is accountable for each item. The confidence percentages frame stakeholder expectations.

What does the dependency Gantt look like?

For in-quarter coordination across 3 teams:

gantt
    title Q3 2026 — Refund Initiative
    dateFormat YYYY-MM-DD
    section Backend
    Refund API endpoint           :a1, 2026-07-01, 14d
    Stripe integration            :a2, after a1, 7d
    Audit logging                 :a3, after a1, 5d
    section Frontend
    Refund button on order page   :b1, 2026-07-08, 5d
    Refund history view           :b2, after b1, 7d
    section Comms
    Refund email template         :c1, 2026-07-15, 3d
    Customer support runbook      :c2, after c1, 5d
    section Launch
    QA + UAT                      :d1, after a2 b2 c2, 7d
    Go-live                       :milestone, after d1, 0d

The Gantt is in-quarter only. Anything beyond stays in Now/Next/Later. Mermaid renders this directly in the detail view, so the roadmap can live in markdown next to the kickoff doc.

What does roadmap look like at multi-team scale?

flowchart TB
    OrgRoadmap[Org roadmap<br/>themes, 1 page] --> TeamA[Team A roadmap<br/>Now/Next/Later]
    OrgRoadmap --> TeamB[Team B roadmap<br/>Now/Next/Later]
    OrgRoadmap --> TeamC[Team C roadmap<br/>Now/Next/Later]
    TeamA --> SprintA[Sprint backlog]
    TeamB --> SprintB[Sprint backlog]
    TeamC --> SprintC[Sprint backlog]

The org roadmap is one page of themes ("performance Q3", "billing Q4"). Each team's roadmap derives Now/Next/Later from those themes. Sprint backlogs derive from team roadmaps. Three layers, each summarising the one below.

What failure modes does the roadmap introduce?

• Roadmap as commitment. Stakeholders treat Later items as promises. Mitigation: label confidence next to every entry; reaffirm in every monthly update that Later is intent, not contract.
• Promotion theatre. Items move from Later to Next without capacity check. The Now bucket overfills. Mitigation: when promoting, check the destination capacity; demote something else if necessary.
• Update skipped. Roadmap created at quarter start, ignored until next quarter. Mitigation: monthly review on calendar with the same attendees as project review.
• Gantt false precision. Dates set to specific days that have no basis. Mitigation: use week boundaries (week of July 8) not exact days, until the work is committed.

When is a roadmap overkill?

Two cases.

Pure exploration team. Research-heavy work where the next six weeks shape what the next six months look like. The roadmap is meaningless; the retrospective is the artifact that matters.

Reactive ops team. Platform / SRE / support teams whose work arrives unpredictably. They use Kanban; roadmap level is org-wide themes, not their daily work.

The roadmap earns its update cost when there is enough planned work to make ordering decisions worthwhile.

Where should you go from here?

Next chapter: sprint execution - the weekly cadence inside the roadmap quarter. After that, launch and handover covers what happens at the end of the Now bucket.