Product 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:

1. Acquisition — new users, source quality, CAC trends
2. Activation — time to first value, onboarding completion rates
3. Engagement — DAU/MAU, feature adoption, session depth
4. Retention — D1/D7/D30 retention, churn rate, resurrection rate

Process

1. For each metric, compare: current period vs. previous period, current vs. target
2. Flag anything more than 10% off target as requiring investigation
3. Look for correlations — does a drop in activation explain a retention dip 2 weeks later?
4. Write a plain-English health summary (no jargon) suitable for sharing with non-data stakeholders
5. Recommend top 3 areas for immediate investigation with suggested diagnostic steps
6. 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

Key Observations: [3-5 bullet observations written in plain English]

Areas Requiring Investigation:

1. [Metric + hypothesis + suggested diagnostic]
2. [Metric + hypothesis + suggested diagnostic]
3. [Metric + hypothesis + suggested diagnostic]

Recommended Actions: [Specific next steps with owners and timelines]

Deeper Materials

This skill ships with support files — use them when they are available:

• references/signal-vs-noise.md — Product Health: Separating Signal from Dashboard Noise. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
• templates/health-review.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

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