Build multi-quarter technical roadmaps aligned with business goals, clearly showing strategic investments, trade-offs, and dependencies. Use when planning longer-term technical direction, communicating with stakeholders, or aligning engineering capacity with business priorities.
From technical-planningnpx claudepluginhub sethdford/claude-skills --plugin tech-lead-planningThis skill is limited to using the following tools:
examples/example-output.mdtemplate.mdProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Calculates TAM/SAM/SOM using top-down, bottom-up, and value theory methodologies for market sizing, revenue estimation, and startup validation.
Develop a 3-12 month technical vision that translates business strategy into engineering work, making trade-offs visible and enabling cross-functional alignment.
You are helping create a technical roadmap that guides engineering work for the next quarter or year. A good roadmap explains not just what you're building, but why it matters to the business and what you're not doing (the trade-offs).
Technical roadmaps fail when they're either too detailed (become outdated) or too vague (don't provide direction). The best roadmaps are strategic narratives, not feature lists.
Before building the roadmap, gather:
From Product:
From Engineering:
From Leadership:
Group work into themes that tell a story:
Example themes:
Each theme should be ~20-30% of engineering capacity.
For each theme, list 2-3 major initiatives:
| Theme | Initiative | Expected Impact | Risk | Effort (weeks) |
|---|---|---|---|---|
| Stability | Migrate from Elasticsearch to managed OpenSearch | 30% reduction in on-call pages | Medium (new tool) | 6 |
| Stability | Add distributed tracing (APM) | 50% faster incident diagnosis | Low | 4 |
| Scale | Refactor user-service monolith | Handle 10x growth; improve MTTR | High (complex refactor) | 12 |
| Scale | Build caching layer (Redis) | 40% reduction in DB queries | Medium | 3 |
| DX | Improve CI/CD (reduce deploy time from 20m to 5m) | Faster iteration; unblock product team | Low | 5 |
Break into 3-month cycles with clear outcomes:
Q1 (Jan-Mar): Foundation
Q2 (Apr-Jun): Scale
Q3 (Jul-Sep): Hardening
Write a 1-2 page strategy document:
# Engineering Roadmap: 2024
## Strategic Context
Our product is scaling; we've reached 5M daily active users. Our infrastructure
is maxing out:
- Database at 85% capacity
- On-call pages up 40% YoY
- Deploy time is 20 min (slowing product iteration)
To support 10M users and reduce operational burden, we need to invest in:
1. Observability (reduce MTTD/MTTR)
2. Scale (database sharding, caching)
3. Developer velocity (faster deploys, better tooling)
## Q1-Q2 Priorities (50% of capacity)
**Theme: Observability (Q1)**
- Deploy APM (New Relic / DataDog)
- Migrate to managed Elasticsearch (OpenSearch)
- Standardize logging across services
- Expected outcome: 30% reduction in on-call pages; incident diagnosis 2x faster
**Theme: Scale (Q2)**
- Refactor user-service monolith for sharding
- Implement Redis caching layer
- Database sharding plan & POC
- Expected outcome: Ready for 10M users; database queries reduced 40%
## Q3 Priority (30% of capacity)
**Theme: Compliance**
- SOC2 audit preparation
- Implement RBAC
- Encrypt sensitive data at rest
- Expected outcome: SOC2 Type II certification
## Technical Debt (20% of capacity)
- Test flakiness (E2E tests failing 10% of runs)
- CI/CD optimization (deploy time 20m → 5m target)
- Library updates (many dependencies out of date)
## What We're NOT Doing (and why)
- API rate limiting (low demand; competitive advantage is features, not APIs)
- Multi-region deployment (business prioritizes single-region until 2025)
- Event sourcing migration (complex; not critical until we need audit trails)
These could be revisited in 2025 based on business direction.
## Dependencies & Risks
- APM deployment depends on vendor onboarding (4-week lead time; start immediately)
- Sharding depends on cache layer stability (Q1 must complete)
- Compliance audit scheduled for Q3; prep work begins Q2
Map which teams depend on which work:
| Initiative | Owning Team | Depends On | Unblocks |
|---|---|---|---|
| APM deployment | Platform | (none) | Product (faster deployments) |
| Cache layer | Backend | APM (observability) | Scaling work, API team |
| Sharding | Backend | Cache layer | Scaling to 10M users |
| RBAC | Security | (none) | Compliance, Product |
Define conditions that would trigger roadmap changes:
Roadmap is reviewed quarterly; major changes require stakeholder approval.
A roadmap document (shared with engineering and stakeholders):
# 2024 Engineering Roadmap
## High-Level Strategy
[1-2 paragraph context and goals]
## Q1-Q4 Themes & Initiatives
[Table or narrative showing what, why, expected impact]
## Quarterly Breakdown
- **Q1 Focus**: [3-5 key outcomes]
- **Q2 Focus**: [3-5 key outcomes]
- **Q3 Focus**: [3-5 key outcomes]
- **Q4 Focus**: [3-5 key outcomes]
## Technical Debt Allocation
[20-30% of capacity reserved for debt paydown]
## Trade-Offs & What We're NOT Doing
[Explicitly list major initiatives deferred and why]
## Dependencies & Risks
[Cross-team dependencies, technical risks, mitigation]
## Success Metrics
[How do we know the roadmap is working?]
## Reassessment Gates
[Conditions that would trigger roadmap changes]
Engineering Roadmap: FinTech Payment Platform (2024)
Our payment platform processes $2B annually across 10K SMB customers. We're experiencing:
To maintain growth and compliance, engineering will focus on: reliability (reduce incidents), compliance (PCI-DSS v4 + KYC), and speed (T+1 settlement).
Q1 (Jan-Mar): Reliability & Observability
Q2 (Apr-Jun): Compliance
Q3 (Jul-Sep): Speed
Q4 (Oct-Dec): Scale & Hardening
When building roadmaps and facing uncertainty:
Description: Roadmap listed as firm promises; business commits to customers; engineering fails to deliver.
Guard: Frame as "plans if no blocking risks emerge." Roadmaps are bets, not guarantees. Revisit quarterly.
Description: Roadmap 100% feature work; technical debt accumulates; velocity drops to zero.
Guard: Reserve 20-30% for debt paydown explicitly. Show it as line item in roadmap.
Description: Roadmap doesn't explain why Feature X was chosen over Feature Y.
Guard: "Alternatives Considered" section showing trade-offs between competing options.
Description: Roadmap assumes team size that won't happen (no hiring plan).
Guard: Cross-check roadmap against headcount forecast. If mismatch, either reduce scope or increase hiring.
Description: Roadmap updated constantly; becomes useless as planning tool.
Guard: Quarterly review only. Mid-quarter changes require escalation to leadership.
Before sharing the roadmap: