YAML
---
name: strategic-roadmapping
description: Creates quarterly strategic roadmaps with dependency mapping and resource allocation. Use when planning product releases, project timelines, or organizational initiatives across multiple quarters.
---

Strategic Roadmapping

Q1 2024 Strategic Roadmap Template:

OBJECTIVES:
• Primary: [Key strategic goal]
• Secondary: [Supporting goals]

INITIATIVES:
Initiative A (Jan-Mar)
├─ Resources: 3 engineers, 1 designer, $50K
├─ Dependencies: API completion (Dec)
└─ Deliverables: MVP, user testing

Initiative B (Feb-Apr) 
├─ Resources: 2 PMs, 4 engineers
├─ Dependencies: Initiative A milestone 2
└─ Deliverables: Integration, launch prep

CRITICAL PATH: Initiative A → Initiative B → Q2 Launch

Progress:

• Gather inputs - Collect business objectives, constraints, team capacity
• Map dependencies - Identify blocking relationships between initiatives
• Allocate resources - Assign people, budget, and time across quarters
• Define milestones - Set quarterly checkpoints with success criteria
• Validate feasibility - Review with stakeholders for capacity and priority alignment
• Create timeline - Build visual roadmap showing parallel workstreams
• Plan reviews - Schedule monthly progress checks and quarterly pivots

Example 1: Input: "Need roadmap for new mobile app launch with backend API, iOS/Android apps, and marketing campaign"

Output:

Q1: Foundation (Jan-Mar)
├─ Backend API (5 engineers, Jan-Feb)
├─ iOS Development (3 engineers, Feb-Mar) [depends: API v1]
└─ Android Development (3 engineers, Feb-Mar) [depends: API v1]

Q2: Integration & Testing (Apr-Jun)  
├─ Platform Integration (4 engineers, Apr-May)
├─ Beta Testing Program (1 PM, May-Jun)
└─ Marketing Asset Creation (2 designers, Apr-Jun)

Q3: Launch (Jul-Sep)
├─ App Store Approval (May submission)
├─ Marketing Campaign (3 marketers, Jul-Aug) 
└─ Customer Support Setup (2 support, Jun-Jul)

Critical Dependencies: API completion blocks mobile dev, beta results gate launch decision

Example 2: Input: "Planning enterprise software migration across 4 business units over 18 months"

Output:

Q1-Q2: Discovery & Pilot
├─ Business Unit A (pilot) - 2 engineers, 1 analyst
├─ Requirements gathering - All units stakeholder interviews
└─ Migration tooling development - 4 engineers

Q3-Q4: Phase 1 Rollout  
├─ Business Unit B migration - 3 engineers (depends: pilot success)
├─ Business Unit C migration - 3 engineers (parallel to B)
└─ Support infrastructure - 2 DevOps engineers

Q5-Q6: Phase 2 Completion
├─ Business Unit D migration - 2 engineers  
├─ Legacy system decommission - 1 engineer
└─ Training & documentation - 1 technical writer

Resource allocation: 8 engineers total, staggered deployment
Risk mitigation: 4-week buffer between phases for issue resolution

• Start with outcomes - Define what success looks like before planning how to get there
• Buffer for unknowns - Add 20% time buffer for unexpected dependencies or scope changes
• Align resource reality - Don't plan more work than your teams can realistically deliver
• Make dependencies explicit - Clearly show what blocks what to identify critical path
• Plan monthly reviews - Quarterly planning needs monthly course corrections
• Communicate up and down - Share roadmaps with both executives and implementation teams

• Over-optimistic timelines - Teams consistently underestimate integration and testing time
• Hidden dependencies - Failing to map external team dependencies or vendor deliverables
• Resource double-booking - Assuming key people can work on multiple critical path items
• Scope creep tolerance - Not protecting roadmap from "small additional requests" that accumulate
• Waterfall thinking - Planning as if all requirements are known upfront instead of iterating
• Ignoring team velocity - Using ideal estimates instead of historical delivery data