<!-- last-reviewed: 2026-06-01 · owner: Product (Product Manager) -->

SOP-070 — Roadmap maintenance

SOP · owner: Product (Product Manager). Layer: SOP/Runbook (docs/canon.md). Keeps docs/product/roadmap.md — the living, time-horizon summary of the backlog — honest and current. Links to canon; does not restate it.

Interface Contract

• Inputs: prioritised backlog ← from self (SOP-068) · trigger: backlog ready
• Inputs: accepted concept brief ← from <Innovation Director / CPTO> · trigger: gate package ready
• Outputs: updated roadmap → to Project Manager · trigger: backlog ready
• Outputs: approved roadmap version → to Archivist · trigger: artifact approved
• Outputs: docs/product/roadmap.md Index row change → to Documentarian · trigger: document changed
• Handoff trigger (in): a major prioritisation decision, a gate approval (Ideate→Plan / Plan→Build), or a Principal directive changes what is coming and why
• Handoff trigger (out): the roadmap reflects the current priority order and accepted briefs; the Project Manager has the current view to sequence against
• Definition of Done before handoff:
  • [ ] every roadmap item traces to a backlog item (SOP-068) — no roadmap-only scope
  • [ ] horizons are honest (no committed dates the backlog/evidence does not support)
  • [ ] major shifts since last version carry their CPTO sign-off reference
  • [ ] deferred / dropped items are shown as such with a one-line reason (not silently removed)
  • [ ] approved version handed to Archivist; canon Index row reflected via Documentarian
  • [ ] learnings captured to docs/knowledge/ if any (SOP-024)

Trigger status: backlog ready is now registered (docs/handoff-triggers.md, Wave-2 block); the Ideate→Plan concept handoff uses the canonical gate package ready (concept brief accepted was folded into it). artifact approved / document changed already existed. The Project Manager edge is pending (role not yet an Interface-Contract identity — §3.1.1 R3).

Purpose

Keep one honest, current, time-horizon view of what the product is doing next and why — the external-facing summary of the backlog — so the CPTO, Project Manager, and any stakeholder reads the same truth. The roadmap is a view over the backlog, not a second source.

When to use

• After a major prioritisation decision (a re-ordering with CPTO sign-off, SOP-068).
• After a gate approval (Ideate→Plan or Plan→Build) that admits new scope.
• After a Principal directive that changes direction.
• Not after every grooming tweak — the roadmap tracks material movement, not churn.

Flow

flowchart LR
  A["Trigger: major shift /<br/>gate approval / directive"] --> B["Reconcile roadmap<br/>against current backlog (SOP-068)"]
  B --> C["Update horizons + 'why'<br/>(honest dates only)"]
  C --> D["Show deferred/dropped<br/>with one-line reason"]
  D --> E["Hand to PMO 'backlog ready'<br/>+ Archivist 'artifact approved'"]
  E --> F["Canon Index row<br/>→ Documentarian 'document changed'"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  class A,B,C,D,E,F s

Text fallback: a material trigger fires → reconcile the roadmap against the current prioritised backlog (every roadmap item must trace to a backlog item) → update the horizons and the “why”, using only dates the evidence supports → show deferred/dropped items with a one-line reason (never silently remove) → hand the updated roadmap to the Project Manager (backlog ready) and the approved version to the Archivist (artifact approved) → reflect any canon Index row change via the Documentarian (document changed).

Steps

1. Confirm the trigger is material. A grooming tweak is not a roadmap event; a priority re-order, gate approval, or directive is.
2. Reconcile against the backlog. Open docs/product/backlog.md; ensure every roadmap entry maps to a real, prioritised backlog item. No roadmap-only scope — the roadmap never invents items the backlog does not hold.
3. Update horizons. Place items into honest time horizons (e.g. Now / Next / Later). Do not assert committed dates the backlog and evidence cannot support — delivery dates are the Project Manager’s to commit, not the roadmap’s to promise.
4. Carry the “why”. Each horizon item states why it is where it is (the RICE-driven priority, the gate that admitted it, the directive behind it).
5. Show movement honestly. Items deferred or dropped since the last version stay visible with a one-line reason — silent removal hides the decision.
6. Reference sign-off. For any major shift, link the CPTO sign-off that approved it (SOP-068 step 6).
7. Hand off. Give the Project Manager the current view (backlog ready); hand the approved version to the Archivist (artifact approved); route the canon Index row to the Documentarian (document changed).

Roadmap format (docs/product/roadmap.md)

Roles / approvers

• Product Manager — owns and maintains the roadmap.
• CPTO — approves major priority shifts the roadmap reflects (reporting line).
• Project Manager (PMO) — consumes the roadmap to sequence delivery; owns dates and milestones (the roadmap shows horizons, not commitments).
• Documentarian — receives the canon Index row when the roadmap is added/moved.
• Archivist — preserves each approved roadmap version.

Guardrails

• The roadmap is a view, not a source — every item traces to the backlog (SOP-068).
• No committed dates the evidence does not support — delivery sequencing and milestone commitment belong to the Project Manager (charter boundary 4).
• No silent removals — deferred/dropped items keep a visible reason.
• Major shifts carry CPTO sign-off before the roadmap publishes them.
• Personal information is PA-only.

See also: docs/units/product/charter.md · SOP-068 (backlog) · SOP-069 (acceptance criteria) · docs/methodology.md (phase gates) · interface-contract-spec.md · docs/handoff-triggers.md.