跳到主要内容
知仓学习社ZHICANG

product-health-analysis

Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a …

不碰外部(只输出文字)无严重或高危命中mohitagw15856/pm-claude-skills

它会碰到什么

扫了多少1 个文本文件,5 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

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

| Metric | Current | Target | vs. Last Period | Status |

|--------|---------|--------|-----------------|--------|

| [metric] | [value] | [target] | [+/-%] | [🟢/🟡/🔴] |

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]

Scoring Rubric (0–40)

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

| Dimension | 0 | 5 | 10 |

|---|---|---|---|

| Target & trend discipline | Metrics shown as bare snapshots; no targets or period-over-period comparison | Most metrics have targets and trends, but some RAG statuses don't follow from the numbers or targets are accepted uncritically | Every metric has target, trend, and a status that follows from both — and at least one target is itself challenged if it's no longer meaningful |

| Root cause depth | Movements listed without explanation ("activation dropped 27pts") | Flagged metrics have hypotheses, but they're generic ("onboarding friction") with no diagnostic to confirm them | Every flagged metric has a specific, falsifiable hypothesis plus a named diagnostic step, and at least one cross-metric correlation (e.g. activation → retention lag) is drawn |

| Segment honesty | Only blended aggregates reported; opposing segment trends invisible | Some segment cuts shown, but the headline observations still lean on averages that hide divergence | Every material aggregate is decomposed where segments diverge, and the divergence itself is surfaced as a finding, not a footnote |

| Verdict & actionability | No overall rating, or a rating asserted without evidence; actions missing or ownerless | Overall RAG present and roughly justified; actions exist but some lack owners, dates, or a link to a flagged metric | Overall rating argued from specific evidence (including against the good news), and every action has a named owner, a date, and traces to an investigation or observation |

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

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。

同名技能的其他版本

有 4 个不同仓库或目录里都有叫 product-health-analysis 的技能。它们内容并不相同,别混用: