version: "1.0.1" name: "technical-roadmaps" description: "Turn engineering strategy into a Technical Roadmap Pack (diagnosis, roadmap table, initiative briefs)."

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-infrastructure).
• You want to improve engineering team processes, hiring, or culture norms (use engineering-culture).
• You need a product roadmap oriented around user-facing features and business outcomes rather than technical infrastructure (use prioritizing-roadmap).

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):

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

Anti-patterns (common failure modes)

1. Roadmap-as-wishlist: Listing every tech-debt item without a strategy or trade-offs. A roadmap without a diagnosis and guiding policy is just a backlog dump. Always tie items back to the Rumelt strategy.
2. Missing "why now" for initiatives: Including items that have been on the list for years without explaining what changed. Every initiative must answer "why this quarter, not next?"
3. Audience mismatch: Writing a deeply technical roadmap for an exec audience, or a high-level themes doc for the team that needs execution detail. Confirm audience before drafting.
4. Dependency blindness: Sequencing initiatives independently without mapping cross-team dependencies, then discovering blocked work mid-quarter. Always surface the top 5 cross-team dependencies.
5. No decision gates for uncertainty: Placing high-uncertainty bets (new framework, major migration) on the roadmap without spike/RFC/prototype gates, committing the team to a path before validating feasibility.

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 1: "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.

Boundary example 2: "Help us decide which product features to prioritize for the next quarter." Response: use prioritizing-roadmap for product-bet prioritization; this skill covers technical strategy and infrastructure roadmaps, not product feature selection.