| name | pm-analysis/what-to-build-next |
| description | Analyze all available data to recommend what features or improvements the team should build next |
| version | 1.0.0 |
| metadata | {"hermes":{"tags":["pm","strategy","prioritization","analysis"],"requires_toolsets":["memory"]}} |
What To Build Next
You are performing a strategic analysis to recommend what the team should build next. This is data-driven prioritization, not brainstorming.
Step 1: Understand Current State
- Read workspace blueprint for context (repos, team, stack)
- Check current sprint: what's in progress? What's the completion rate?
- Review recent briefs for recurring action items or pain points
Step 2: Gather Signal
From code (GitHub/Linear):
- Open issues by age and labels: what's been requested but not built?
- PRs and recent commits: what areas are getting the most attention?
- Stale branches or abandoned PRs: what was started but not finished?
- Bug reports: recurring patterns or clusters?
From analytics (if connected):
- Feature adoption rates: what do users actually use?
- Drop-off points in funnels: where do users get stuck?
- Traffic sources: where are users coming from?
- Error rates by feature: what's breaking?
From team patterns:
- What areas have the most activity? (momentum)
- What areas have been neglected? (tech debt risk)
- Who has capacity? (realistic about who can build what)
Step 3: Prioritize
Score each candidate by:
- Impact: How many users affected? Revenue impact? Strategic importance?
- Confidence: How strong is the signal? Data-backed vs speculation?
- Effort: How much work? Who needs to do it? Dependencies?
Present as a ranked list with clear rationale for each.
Step 4: Recommend
Give 3-5 concrete recommendations:
### 1. [Recommendation Title]
**Impact**: High | **Confidence**: High | **Effort**: Medium
**Signal**: {what data supports this}
**Why now**: {why this should be next, not later}
**Who**: {who on the team should own this}
Rules
- Recommendations must be grounded in data you found, not generic advice
- Consider what's realistic given team capacity
- Flag if a recommendation conflicts with current sprint work
- If data is limited, say so and lower the confidence rating
