Diagnose why your product's shipping velocity is declining

Description

Your team grew from 5 to 15 engineers but you're shipping fewer features per quarter than before. Standups feel pointless, PRs sit in review for days, and sprint commitments keep slipping. This runs a structured velocity diagnosis to find the real bottlenecks — process, architecture, or people.

Diagnose the root causes of declining shipping velocity for {{product_name}} and recommend specific fixes.

## Context
- Product: {{product_name}}
- Team size: {{team_size}} engineers (was {{previous_team_size}} at time of peak velocity)
- Sprint length: {{sprint_length}}
- Average story points completed per sprint (last 6 sprints): {{velocity_numbers}}
- Deploy frequency: {{deploy_frequency}}
- Average PR review time: {{pr_review_time}}
- Number of active projects/streams: {{active_projects}}

## Step 1: Symptom Inventory
Rate each symptom (0 = not an issue, 5 = critical bottleneck):
1. PRs sit in review for >24 hours
2. Sprint commitments are missed >40% of the time
3. Meetings consume >25% of each engineer's week
4. Unclear requirements cause mid-sprint scope changes
5. Deployment pipeline takes >30 minutes
6. Engineers context-switch between multiple projects daily
7. New engineers take >3 months to ship independently
8. Technical debt forces workarounds on most features
9. Dependencies between teams cause blocking delays
10. On-call or incident response disrupts planned work

## Step 2: Root Cause Analysis
Group the top-scoring symptoms into root causes:
- **Process bloat**: Too many approvals, ceremonies, or handoffs
- **Architecture friction**: Monolith, shared codebase, flaky tests, slow CI
- **Coordination overhead**: Too many people touching the same surface area
- **Scope creep**: Requirements changing faster than the team can absorb
- **Skill/knowledge gaps**: New hires underperforming or too few senior engineers

For each root cause:
1. What evidence supports this diagnosis?
2. When did this become a problem? (timeline)
3. What has been tried before? Why didn't it work?

## Step 3: Intervention Design
For each confirmed root cause, propose a specific intervention:
1. Target: which symptom does this fix?
2. Action: what exactly changes? (be specific — not "improve process" but "replace 3 weekly syncs with async Slack updates")
3. Owner: who drives this change?
4. Timeline: when will we see impact?
5. Success metric: how do we know it worked?

## Step 4: Quick Wins vs. Structural Fixes
Separate interventions into:
- **Quick wins** (implement this week, impact within 2 sprints): list 3
- **Medium-term** (implement this month, impact within 1 quarter): list 3
- **Structural** (requires investment, impact within 2 quarters): list 2

## Step 5: Tracking Dashboard
Design a velocity health dashboard with:
- Deploy frequency (weekly trend)
- Cycle time (PR open → merged → deployed)
- Sprint commitment accuracy (committed vs. completed)
- Engineering time allocation (features vs. debt vs. meetings vs. support)

Customize This Prompt