{ "schema": "https://ai-atoms.com/schemas/skill-v1.json", "type": "skill", "id": "skill/metrics-review", "version": "1.0.0", "name": "metrics-review", "description": "Review and analyze product metrics with trend analysis and actionable insights. Use when running a weekly, monthly, or quarterly metrics review, investigating a sudden spike or drop, comparing performance against targets, or turning raw numbers into a scorecard with recommended actions.", "system_prompt_fragment": "# Metrics Review\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).\n\nReview and analyze product metrics, identify trends, and surface actionable insights.\n\n## Usage\n\n```\n/metrics-review $ARGUMENTS\n```\n\n## Workflow\n\n### 1. Gather Metrics Data\n\nIf **~~product analytics** is connected:\n- Pull key product metrics for the relevant time period\n- Get comparison data (previous period, same period last year, targets)\n- Pull segment breakdowns if available\n\nIf no analytics tool is connected, ask the user to provide:\n- The metrics and their values (paste a table, screenshot, or describe)\n- Comparison data (previous period, targets)\n- Any context on recent changes (launches, incidents, seasonality)\n\nAsk the user:\n- What time period to review? (last week, last month, last quarter)\n- What metrics to focus on? Or should we review the full product metrics suite?\n- Are there specific targets or goals to compare against?\n- Any known events that might explain changes (launches, outages, marketing campaigns, seasonality)?\n\n### 2. Organize the Metrics\n\nStructure the review using a metrics hierarchy: North Star metric at the top, L1 health indicators (acquisition, activation, engagement, retention, revenue, satisfaction), and L2 diagnostic metrics for drill-down. See **Product Metrics Hierarchy** below for full definitions.\n\nIf the user has not defined their metrics hierarchy, help them identify their North Star and key L1 metrics before proceeding.\n\n### 3. Analyze Trends\n\nFor each key metric:\n- **Current value**: What is the metric today?\n- **Trend**: Up, down, or flat compared to previous period? Over what timeframe?\n- **vs Target**: How does it compare to the goal or target?\n- **Rate of change**: Is the trend accelerating or decelerating?\n- **Anomalies**: Any sudden changes, spikes, or drops?\n\nIdentify correlations:\n- Do changes in one metric correlate with changes in another?\n- Are there leading indicators that predict lagging metric changes?\n- Do segment breakdowns reveal that an aggregate trend is driven by a specific cohort?\n\n### 4. Generate the Review\n\n#### Summary\n2-3 sentences: overall product health, most notable changes, key callout.\n\n#### Metric Scorecard\nTable format for quick scanning:\n\n| Metric | Current | Previous | Change | Target | Status |\n|--------|---------|----------|--------|--------|--------|\n| [Metric] | [Value] | [Value] | [+/- %] | [Target] | [On track / At risk / Miss] |\n\n#### Trend Analysis\nFor each metric worth discussing:\n- What happened and how significant is the change\n- Why it likely happened (attribution based on known events, correlated metrics, segment analysis)\n- Whether this is a one-time event or a sustained trend\n\n#### Bright Spots\nWhat is going well:\n- Metrics beating targets\n- Positive trends to sustain\n- Segments or features showing strong performance\n\n#### Areas of Concern\nWhat needs attention:\n- Metrics missing targets or trending negatively\n- Early warning signals before they become problems\n- Metrics where we lack visibility or understanding\n\n#### Recommended Actions\nSpecific next steps based on the analysis:\n- Investigations to run (dig deeper into a concerning trend)\n- Experiments to launch (test hypotheses about what could improve a metric)\n- Investments to make (double down on what is working)\n- Alerts to set (monitor a metric more closely)\n\n#### Context and Caveats\n- Known data quality issues\n- Events that affect comparability (outages, holidays, launches)\n- Metrics we should be tracking but are not yet\n\n### 5. Follow Up\n\nAfter generating the review:\n- Ask if any metric needs deeper investigation\n- Offer to create a dashboard spec for ongoing monitoring\n- Offer to draft experiment proposals for areas of concern\n- Offer to set up a metrics review template for recurring use\n\n## Product Metrics Hierarchy\n\n### North Star Metric\nThe single metric that best captures the core value your product delivers to users. It should be:\n\n- **Value-aligned**: Moves when users get more value from the product\n- **Leading**: Predicts long-term business success (revenue, retention)\n- **Actionable**: The product team can influence it through their work\n- **Understandable**: Everyone in the company can understand what it means and why it matters\n\n**Examples by product type**:\n- Collaboration tool: Weekly active teams with 3+ members contributing\n- Marketplace: Weekly transactions completed\n- SaaS platform: Weekly active users completing core workflow\n- Content platform: Weekly engaged reading/viewing time\n- Developer tool: Weekly deployments using the tool\n\n### L1 Metrics (Health Indicators)\nThe 5-7 metrics that together paint a complete picture of product health. These map to the key stages of the user lifecycle:\n\n**Acquisition**: Are new users finding the product?\n- New signups or trial starts (volume and trend)\n- Signup conversion rate (visitors to signups)\n- Channel mix (where are new users coming from)\n- Cost per acquisition (for paid channels)\n\n**Activation**: Are new users reaching the value moment?\n- Activation rate: % of new users who complete the key action that predicts retention\n- Time to activate: how long from signup to activation\n- Setup completion rate: % who complete onboarding steps\n- First value moment: when users first experience the core product value\n\n**Engagement**: Are active users getting value?\n- DAU / WAU / MAU: active users at different timeframes\n- DAU/MAU ratio (stickiness): what fraction of monthly users come back daily\n- Core action frequency: how often users do the thing that matters most\n- Session depth: how much users do per session\n- Feature adoption: % of users using key features\n\n**Retention**: Are users coming back?\n- D1, D7, D30 retention: % of users who return after 1 day, 7 days, 30 days\n- Cohort retention curves: how retention evolves for each signup cohort\n- Churn rate: % of users or revenue lost per period\n- Resurrection rate: % of churned users who come back\n\n**Monetization**: Is value translating to revenue?\n- Conversion rate: free to paid (for freemium)\n- MRR / ARR: monthly or annual recurring revenue\n- ARPU / ARPA: average revenue per user or account\n- Expansion revenue: revenue growth from existing customers\n- Net revenue retention: revenue retention including expansion and contraction\n\n**Satisfaction**: How do users feel about the product?\n- NPS: Net Promoter Score\n- CSAT: Customer Satisfaction Score\n- Support ticket volume and resolution time\n- App store ratings and review sentiment\n\n### L2 Metrics (Diagnostic)\nDetailed metrics used to investigate changes in L1 metrics:\n\n- Funnel conversion at each step\n- Feature-level usage and adoption\n- Segment-specific breakdowns (by plan, company size, geography, user role)\n- Performance metrics (page load time, error rate, API latency)\n- Content-specific engagement (which features, pages, or content types drive engagement)\n\n## Common Product Metrics\n\n### DAU / WAU / MAU\n**What they measure**: Unique users who perform a qualifying action in a day, week, or month.\n\n**Key decisions**:\n- What counts as \"active\"? A login? A page view? A core action? Define this carefully — different definitions tell different stories.\n- Which timeframe matters most? DAU for daily-use products (messaging, email). WAU for weekly-use products (project management). MAU for less frequent products (tax software, travel booking).\n\n**How to use them**:\n- DAU/MAU ratio (stickiness): values above 0.5 indicate a daily habit. Below 0.2 suggests infrequent usage.\n- Trend matters more than absolute number. Is active usage growing, flat, or declining?\n- Segment by user type. Power users and casual users behave very differently.\n\n### Retention\n**What it measures**: Of users who started in period X, what % are still active in period Y?\n\n**Common retention timeframes**:\n- D1 (next day): Was the first experience good enough to come back?\n- D7 (one week): Did the user establish a habit?\n- D30 (one month): Is the user retained long-term?\n- D90 (three months): Is this a durable user?\n\n**How to use retention**:\n- Plot retention curves by cohort. Look for: initial drop-off (activation problem), steady decline (engagement problem), or flattening (good — you have a stable retained base).\n- Compare cohorts over time. Are newer cohorts retaining better than older ones? That means product improvements are working.\n- Segment retention by activation behavior. Users who completed onboarding vs those who did not. Users who used feature X vs those who did not.\n\n### Conversion\n**What it measures**: % of users who move from one stage to the next.\n\n**Common conversion funnels**:\n- Visitor to signup\n- Signup to activation (key value moment)\n- Free to paid (trial conversion)\n- Trial to paid subscription\n- Monthly to annual plan\n\n**How to use conversion**:\n- Map the full funnel and measure conversion at each step\n- Identify the biggest drop-off points — these are your highest-leverage improvement opportunities\n- Segment conversion by source, plan, user type. Different segments convert very differently.\n- Track conversion over time. Is it improving as you iterate on the experience?\n\n### Activation\n**What it measures**: % of new users who reach the moment where they first experience the product's core value.\n\n**Defining activation**:\n- Look at retained users vs churned users. What actions did retained users take that churned users did not?\n- The activation event should be strongly predictive of long-term retention\n- It should be achievable within the first session or first few days\n- Examples: created first project, invited a teammate, completed first workflow, connected an integration\n\n**How to use activation**:\n- Track activation rate for every signup cohort\n- Measure time to activate — faster is almost always better\n- Build onboarding flows that guide users to the activation moment\n- A/B test activation flows and measure impact on retention, not just activation rate\n\n## Goal Setting Frameworks\n\n### OKRs (Objectives and Key Results)\n\n**Objectives**: Qualitative, aspirational goals that describe what you want to achieve.\n- Inspiring and memorable\n- Time-bound (quarterly or annually)\n- Directional, not metric-specific\n\n**Key Results**: Quantitative measures that tell you if you achieved the objective.\n- Specific and measurable\n- Time-bound with a clear target\n- Outcome-based, not output-based\n- 2-4 Key Results per Objective\n\n**Example**:\n```\nObjective: Make our product indispensable for daily workflows\n\nKey Results:\n- Increase DAU/MAU ratio from 0.35 to 0.50\n- Increase D30 retention for new users from 40% to 55%\n- 3 core workflows with >80% task completion rate\n```\n\n### OKR Best Practices\n- Set OKRs that are ambitious but achievable. 70% completion is the target for stretch OKRs.\n- Key Results should measure outcomes (user behavior, business results), not outputs (features shipped, tasks completed).\n- Do not have too many OKRs. 2-3 objectives with 2-4 KRs each is plenty.\n- OKRs should be uncomfortable. If you are confident you will hit all of them, they are not ambitious enough.\n- Review OKRs at mid-period. Adjust effort allocation if some KRs are clearly off track.\n- Grade OKRs honestly at end of period. 0.0-0.3 = missed, 0.4-0.6 = progress, 0.7-1.0 = achieved.\n\n### Setting Metric Targets\n- **Baseline**: What is the current value? You need a reliable baseline before setting a target.\n- **Benchmark**: What do comparable products achieve? Industry benchmarks provide context.\n- **Trajectory**: What is the current trend? If the metric is already improving at 5% per month, a 6% target is not ambitious.\n- **Effort**: How much investment are you putting behind this? Bigger bets warrant more ambitious targets.\n- **Confidence**: How confident are you in hitting the target? Set a \"commit\" (high confidence) and a \"stretch\" (ambitious).\n\n## Metric Review Cadences\n\n### Weekly Metrics Check\n**Purpose**: Catch issues quickly, monitor experiments, stay in touch with product health.\n**Duration**: 15-30 minutes.\n**Attendees**: Product manager, maybe engineering lead.\n\n**What to review**:\n- North Star metric: current value, week-over-week change\n- Key L1 metrics: any notable movements\n- Active experiments: results and statistical significance\n- Anomalies: any unexpected spikes or drops\n- Alerts: anything that triggered a monitoring alert\n\n**Action**: If something looks off, investigate. Otherwise, note it and move on.\n\n### Monthly Metrics Review\n**Purpose**: Deeper analysis of trends, progress against goals, strategic implications.\n**Duration**: 30-60 minutes.\n**Attendees**: Product team, key stakeholders.\n\n**What to review**:\n- Full L1 metric scorecard with month-over-month trends\n- Progress against quarterly OKR targets\n- Cohort analysis: are newer cohorts performing better?\n- Feature adoption: how are recent launches performing?\n- Segment analysis: any divergence between user segments?\n\n**Action**: Identify 1-3 areas to investigate or invest in. Update priorities if metrics reveal new information.\n\n### Quarterly Business Review\n**Purpose**: Strategic assessment of product performance, goal-setting for next quarter.\n**Duration**: 60-90 minutes.\n**Attendees**: Product, engineering, design, leadership.\n\n**What to review**:\n- OKR scoring for the quarter\n- Trend analysis for all L1 metrics over the quarter\n- Year-over-year comparisons\n- Competitive context: market changes and competitor movements\n- What worked and what did not\n\n**Action**: Set OKRs for next quarter. Adjust product strategy based on what the data shows.\n\n## Dashboard Design Principles\n\n### Effective Product Dashboards\nA good dashboard answers the question \"How is the product doing?\" at a glance.\n\n**Principles**:\n\n1. **Start with the question, not the data**. What decisions does this dashboard support? Design backwards from the decision.\n\n2. **Hierarchy of information**. The most important metric should be the most visually prominent. North Star at the top, L1 metrics next, L2 metrics available on drill-down.\n\n3. **Context over numbers**. A number without context is meaningless. Always show: current value, comparison (previous period, target, benchmark), trend direction.\n\n4. **Fewer metrics, more insight**. A dashboard with 50 metrics helps no one. Focus on 5-10 that matter. Put everything else in a detailed report.\n\n5. **Consistent time periods**. Use the same time period for all metrics on a dashboard. Mixing daily and monthly metrics creates confusion.\n\n6. **Visual status indicators**. Use color to indicate health at a glance:\n - Green: on track or improving\n - Yellow: needs attention or flat\n - Red: off track or declining\n\n7. **Actionability**. Every metric on the dashboard should be something the team can influence. If you cannot act on it, it does not belong on the product dashboard.\n\n### Dashboard Layout\n\n**Top row**: North Star metric with trend line and target.\n\n**Second row**: L1 metrics scorecard — current value, change, target, status for each key metric.\n\n**Third row**: Key funnels or conversion metrics — visual funnel showing drop-off at each stage.\n\n**Fourth row**: Recent experiments and launches — active A/B tests, recent feature launches with early metrics.\n\n**Bottom / drill-down**: L2 metrics, segment breakdowns, and detailed time series for investigation.\n\n### Dashboard Anti-Patterns\n- **Vanity metrics**: Metrics that always go up but do not indicate health (total signups ever, total page views)\n- **Too many metrics**: Dashboards that require scrolling to see. If it does not fit on one screen, cut metrics.\n- **No comparison**: Raw numbers without context (current value with no previous period or target)\n- **Stale dashboards**: Metrics that have not been updated or reviewed in months\n- **Output dashboards**: Measuring team activity (tickets closed, PRs merged) instead of user and business outcomes\n- **One dashboard for all audiences**: Executives, PMs, and engineers need different views. One size does not fit all.\n\n### Alerting\nSet alerts for metrics that require immediate attention:\n\n- **Threshold alerts**: Metric drops below or rises above a critical threshold (error rate > 1%, conversion < 5%)\n- **Trend alerts**: Metric shows sustained decline over multiple days/weeks\n- **Anomaly alerts**: Metric deviates significantly from expected range\n\n**Alert hygiene**:\n- Every alert should be actionable. If you cannot do anything about it, do not alert on it.\n- Review and tune alerts regularly. Too many false positives and people ignore all alerts.\n- Define an owner for each alert. Who responds when it fires?\n- Set appropriate severity levels. Not everything is P0.\n\n## Output Format\n\nUse tables for the scorecard. Use clear status indicators. Keep the summary tight — the reader should get the essential story in 30 seconds.\n\n## Tips\n\n- Start with the \"so what\" — what is the most important thing in this metrics review? Lead with that.\n- Absolute numbers without context are useless. Always show comparisons (vs previous period, vs target, vs benchmark).\n- Be careful about attribution. Correlation is not causation. If a metric moved, acknowledge uncertainty about why.\n- Segment analysis often reveals that an aggregate metric masks important differences. A flat overall number might hide one segment growing and another shrinking.\n- Not all metric movements matter. Small fluctuations are noise. Focus attention on meaningful changes.\n- If a metric is missing its target, do not just report the miss — recommend what to do about it.\n- Metrics reviews should drive decisions. If the review does not lead to at least one action, it was not useful.", "applicable_domains": [ "product", "planning" ], "invocation": [ "/metrics-review", "/metrics-review