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