product-health-analysis
About product-health-analysis
A skill that turns product metrics into a health report describing what is working, what needs investigation, and suggested actions. It compares performance with targets and prior periods across acquisition, activation, engagement, and retention.
Key features
- 01Analysis across four product metric layers
- 02Current, prior-period, and target comparisons
- 03Flags metrics more than 10% off target
- 04Correlates metric movements
- 05Suggests investigation steps and actions
Use cases
- 01Reviewing monthly product health
- 02Investigating a retention decline
- 03Comparing feature-area metrics with targets
- 04Sharing metric findings with non-data stakeholders
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/product-health-analysisin Claude Code to confirm it loaded.
Details
From the project READMEProduct Health Analysis Skill
Transform raw metrics data into a clear health narrative — what's working, what's not, and what needs immediate attention.
Required Inputs
Ask the user for these if not provided:
- Metrics data (current values for key metrics — even rough numbers work)
- Targets or benchmarks (OKR targets, historical baselines, or industry benchmarks)
- Period (week / month / quarter being analysed)
- Product area or segment (are we looking at the whole product or a specific feature?)
Metrics Framework
Analyse across four layers:
- Acquisition — new users, source quality, CAC trends
- Activation — time to first value, onboarding completion rates
- Engagement — DAU/MAU, feature adoption, session depth
- Retention — D1/D7/D30 retention, churn rate, resurrection rate
Process
- For each metric, compare: current period vs. previous period, current vs. target
- Flag anything more than 10% off target as requiring investigation
- Look for correlations — does a drop in activation explain a retention dip 2 weeks later?
- Write a plain-English health summary (no jargon) suitable for sharing with non-data stakeholders
- Recommend top 3 areas for immediate investigation with suggested diagnostic steps
- Validate — Confirm every flagged metric has a plausible root cause hypothesis, not just a raw number, and every recommended action has a specific owner or team
Output Structure
Product Health Report — [Period]
Overall Health: 🟢 On Track / 🟡 Watch / 🔴 Action Required
| Metric | Current | Target | vs. Last Period | Status |
|---|---|---|---|---|
| [metric] | [value] | [target] | [+/-%] | [🟢/🟡/🔴] |
Key Observations: [3-5 bullet observations written in plain English]
Areas Requiring Investigation:
- [Metric + hypothesis + suggested diagnostic]
- [Metric + hypothesis + suggested diagnostic]
- [Metric + hypothesis + suggested diagnostic]
Recommended Actions: [Specific next steps with owners and timelines]
Quality Checks
- Every metric includes both a target and a trend (not just a snapshot)
- At least one correlation is drawn between metrics (e.g., activation → retention)
- Every flagged metric has a root cause hypothesis, not just "it dropped"
- Observations are written for a non-technical stakeholder (no raw query language or data jargon)
- Overall health rating is justified with specific evidence
Anti-Patterns
- Do not report a single aggregate metric without segment breakdowns — averages hide opposing trends
- Do not flag a metric as healthy just because it is above the target — check if the target itself is meaningful
- Do not list metric movements without root cause hypotheses — observations without explanations are not analysis
- Do not mix product health metrics with business KPIs without explaining the relationship between them
- Do not omit recommended actions — a health report that only describes problems without prioritised next steps is incomplete