Technical Roadmaps

Scope

Covers

Turning “technical work” (architecture, platform, reliability, tech debt) into a written strategy + roadmap that stakeholders can critique and improve.
Applying Richard Rumelt’s strategy frame (Diagnosis → Guiding policy → Coherent actions) to engineering planning.
Producing a roadmap that is executable (owners, milestones, dependencies, risks, metrics), not a vague wishlist.
Aligning a technical roadmap with product/business constraints (quarters, launches, compliance/security, capacity).

When to use

“Create a technical/engineering/architecture roadmap for the next 2–4 quarters.”
“We need a written technical strategy and a roadmap we can review with leadership.”
“We have many tech-debt/platform initiatives; turn them into a prioritized plan with dependencies and milestones.”
“Our tech roadmap keeps being misunderstood—write it down so we can debug alignment.”

When NOT to use

The problem/outcome is unclear (use problem-definition first).
You need to choose which product bets matter most (use prioritizing-roadmap or ai-product-strategy).
You only need delivery dates, milestone tracking, and RAG governance (use managing-timelines).
You need a deep platform strategy / ecosystem design (use platform-strategy).

Inputs

Minimum required

Audience + decision: who this roadmap is for (Eng leadership, Execs, Product) and what decisions it must enable.
Time horizon + format: e.g., 6 months / 12 months; Now-Next-Later vs quarterly.
Current-state diagnosis inputs: top pain points, reliability/latency/cost signals, incident themes, scaling constraints, key architectural bottlenecks.
Constraints: capacity assumptions, compliance/security requirements, platform constraints, non-negotiables.
Candidate initiatives: known platform/architecture/tech-debt items (even a rough list).

Missing-info strategy

Ask up to 5 questions from references/INTAKE.md.
If answers aren’t available, proceed with explicit assumptions and list them under Open questions.

Outputs (deliverables)

Produce a Technical Roadmap Pack in Markdown (in-chat; or as files if the user requests):

Technical Strategy (Rumelt): Diagnosis → Guiding policy → Coherent actions (template: references/TEMPLATES.md)
Roadmap table (Now/Next/Later or quarters) with owners, dependencies, milestones, confidence, and metrics
Initiative briefs for the top 3–6 roadmap items (1 page each)
Dependency + risk register (top cross-team deps, key risks, mitigations)
Alignment + governance plan (review cadence, update rules, decision owners, comms template)
Risks / Open questions / Next steps (always included)

Expanded guidance: references/WORKFLOW.md

Workflow (7 steps)

1) Intake + audience alignment

Inputs: User request; references/INTAKE.md.
Actions: Confirm the audience, horizon, and roadmap “shape” (quarters vs Now/Next/Later). Identify the decision the roadmap must enable (funding, sequencing, headcount, trade-offs).
Outputs: Intake summary + explicit assumptions + open questions list (if any).
Checks: You can state: “This roadmap is for <audience> to decide <decision> over <horizon> using <format>.”

2) Write the strategy (Rumelt: Diagnosis → Guiding policy → Coherent actions)

Inputs: Current-state signals; constraints; product/business context.
Actions: Draft a written strategy using the Rumelt structure. Keep it concrete: name the constraints and trade-offs.
Outputs: Technical Strategy section using references/TEMPLATES.md.
Checks: A reader can answer: “What’s the problem?”, “What’s our approach?”, “What actions are we taking (and not taking)?”

3) Build the initiative inventory (candidate “coherent actions”)

Inputs: Candidate initiative list; strategy; incidents/metrics; architecture notes.
Actions: Normalize initiatives into a table (theme, outcome, why now, dependencies, effort, risk). Merge duplicates; split overly broad items.
Outputs: Initiative inventory (draft roadmap backlog).
Checks: Each item has an outcome + a “why now” tied back to the Diagnosis/Guiding policy.

4) Prioritize + sequence (make trade-offs explicit)

Inputs: Inventory; constraints; dependencies; capacity assumptions.
Actions: Prioritize based on: (a) alignment to strategy, (b) risk reduction, (c) enabling product work, (d) cost/effort, (e) dependency criticality. Sequence via dependencies and “first unlocks.”
Outputs: Ranked list + sequencing rationale + explicit non-goals/cut list.
Checks: You can justify the top 3 items in 1–2 sentences each, including what you deprioritized.

5) Convert into a roadmap (quarters or Now/Next/Later) with execution detail

Inputs: Ranked list; sequencing; calendar constraints.
Actions: Create the roadmap table with owners, milestones, dependencies, confidence, and success metrics. Add “decision gates” where uncertainty is high.
Outputs: Roadmap table + milestone highlights.
Checks: A team could start execution without guessing owners/dependencies; high-uncertainty items have a gate (spike/RFC/prototype).

6) Draft initiative briefs + alignment plan

Inputs: Roadmap; top items; stakeholder map.
Actions: Write 1-page briefs for the top 3–6 items and a comms/governance plan (review cadence, update rules, decision owners).
Outputs: Initiative briefs + alignment/governance section (templates in references/TEMPLATES.md).
Checks: Stakeholders know when/how the roadmap will change and what inputs trigger a refresh.

7) Quality gate + finalize

Inputs: Full draft pack.
Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Ensure Risks / Open questions / Next steps are present with owners and dates where possible.
Outputs: Final Technical Roadmap Pack.
Checks: The pack is “debuggable”: written, coherent, measurable, and reviewable.

Quality gate (required)

Use references/CHECKLISTS.md and references/RUBRIC.md.
Always include: Risks, Open questions, Next steps.

Examples

Example 1 (platform scaling): “We’re seeing reliability issues and slow delivery. Create a 2-quarter technical roadmap and strategy we can review with leadership.”
Expected: a Rumelt-structured strategy plus a sequenced roadmap with owners, dependencies, milestones, and metrics.

Example 2 (architecture modernization): “We need an architecture roadmap to migrate off a legacy monolith while still shipping product features.”
Expected: explicit trade-offs, dependency-aware sequencing, decision gates, and a governance cadence to keep alignment.

Boundary example: “Write a detailed project plan with dates for every task for the next 6 months.”
Response: use managing-timelines for delivery planning; this skill is for strategy → roadmap (themes/initiatives/milestones), not task-level scheduling.