Check whether a dashboard can be trusted before a decision. — Claude Skill
A Claude Skill for Claude Code by Paweł Huryn — run /metrics-dashboard in Claude·Updated Jun 12, 2026·vphuryn/pm-skills@metrics-dashboard
Reviews dashboard definitions, freshness, filters, owners, source systems, and obvious contradictions so teams know whether the numbers are safe to use.
- Explains whether dashboard numbers are decision-ready, stale, inconsistent, or missing context.
- Checks metric definitions, filters, date ranges, owner, refresh time, source system, and known caveats.
- Separates cosmetic dashboard issues from problems that can change a business decision.
- Returns a trust summary, risks, questions for the owner, and fixes to make before sharing.
A team opens a dashboard in a meeting, notices a number looks odd, and spends the discussion arguing about whether it is trustworthy.
Run /dashboard-audit before the meeting to identify stale data, unclear definitions, risky filters, and questions for the owner.
Who this is for
Review dashboard trust, definitions, source freshness, and blocking issues.
See skills for this roleKnow whether product metrics are safe for launch or roadmap decisions.
See skills for this roleCheck revenue dashboards before forecast, pipeline, or leadership reviews.
See skills for this roleWhat it does
Check whether a dashboard is safe to use in a weekly business review.
Find why numbers look wrong, stale, or inconsistent with another source.
Review definitions, filters, and owners before a new dashboard goes live.
How it works
Share dashboard screenshots, metric definitions, filters, SQL snippets, or exported numbers.
State the decision the dashboard is supposed to support.
The skill checks freshness, definitions, filters, source alignment, and contradictions.
A human confirms the source owner, fixes blocking issues, and decides whether the dashboard can be used.
Input options
Screenshots, exported table, metric definitions, filters, refresh timestamp, or SQL.
Example
Dashboard: Weekly Revenue Overview. Decision: leadership will decide whether Q3 pipeline recovery plan is working. Observed: - Revenue chart says bookings are up 18%. - CRM report says commit forecast is down 9%. - Dashboard last refreshed Friday 18:00. - Filter excludes Enterprise region because of a saved view. - Owner listed: RevOps Analytics, but owner left last month. Need: can we use this dashboard in Monday review?
Do not use as the primary decision source yet. The dashboard may be useful for directional context, but two blocking issues can change the leadership decision.
Enterprise is excluded by a saved filter, and the owner is stale. Because Enterprise can materially change bookings and forecast, the dashboard is not decision-ready.
Friday refresh may be acceptable for Monday review only if weekend CRM changes are not material. Confirm refresh schedule and last successful job.
Who owns this dashboard now? Should Enterprise be included? Are bookings and commit forecast intentionally different metrics?
Reset filter, assign owner, refresh data, and add a note explaining bookings vs commit forecast.
Metrics this improves
Works with
Works anywhere
Paste the notes, exports, screenshots, or summaries you already have. The skill works without a connected system.
Connect the relevant support, analytics, CRM, or data tool when you want fresher source evidence.
Want to use Metrics Dashboard?
Choose how to get started.
Install and run this skill locally on your computer.
Open a terminal on your computer and paste this command:
This downloads the skill with all its files to your computer:
Add -g at the end to make it available in all your projects.
Start Claude Code, then type the command:
Product Metrics Dashboard
Design a comprehensive product metrics dashboard with the right metrics, visualizations, and alert thresholds.
Context
You are designing a metrics dashboard for $ARGUMENTS.
If the user provides files (existing dashboards, analytics data, OKRs, or strategy docs), read them first.
Domain Context
Metrics vs KPIs vs NSM: Metrics = all measurable things. KPIs = a few key quantitative metrics tracked over a longer period. North Star Metric = a single customer-centric KPI that is a leading indicator of business success.
4 criteria for a good metric (Ben Yoskovitz, Lean Analytics): (1) Understandable — creates a common language. (2) Comparative — over time, not a snapshot. (3) Ratio or Rate — more revealing than whole numbers. (4) Behavior-changing — the Golden Rule: "If a metric won't change how you behave, it's a bad metric."
8 metric types: Vanity vs Actionable (only actionable metrics change behavior), Qualitative vs Quantitative (WHAT vs WHY — you need both; never stop talking to customers), Exploratory vs Reporting (explore data to uncover unexpected insights), Lagging vs Leading (leading indicators enable faster learning cycles, e.g. customer complaints predict churn).
5 action steps: (1) Audit metrics against the 4 good-metric criteria. (2) Update dashboards — ensure all key metrics are good ones. (3) Identify vanity metrics — be careful how you use them. (4) Classify leading vs lagging indicators. (5) Pick one problem and dig deep into the data.
For case studies and more detail: Are You Tracking the Right Metrics? by Ben Yoskovitz
Instructions
-
Identify the metrics framework — organize metrics into layers:
North Star Metric: The single metric that best captures core value delivery
Input Metrics (3-5): The levers that drive the North Star
Health Metrics: Guardrails that ensure overall product health
Business Metrics: Revenue, cost, and unit economics
-
For each metric, define:
Metric Definition Data Source Visualization Target Alert Threshold [Name] [Exact calculation: numerator/denominator, time window] [Where the data comes from] [Line chart / Bar / Number / Funnel] [Goal value] [When to trigger an alert] -
Design the dashboard layout:
┌─────────────────────────────────────────────┐ │ NORTH STAR: [Metric] — [Current Value] │ │ Trend: [↑/↓ X% vs last period] │ ├──────────────────┬──────────────────────────┤ │ Input Metric 1 │ Input Metric 2 │ │ [Sparkline] │ [Sparkline] │ ├──────────────────┼──────────────────────────┤ │ Input Metric 3 │ Input Metric 4 │ │ [Sparkline] │ [Sparkline] │ ├──────────────────┴──────────────────────────┤ │ HEALTH: [Latency] [Error Rate] [NPS] │ ├─────────────────────────────────────────────┤ │ BUSINESS: [MRR] [CAC] [LTV] [Churn] │ └─────────────────────────────────────────────┘ -
Set review cadence:
- Daily: Operational health (errors, latency, critical flows)
- Weekly: Input metrics and engagement trends
- Monthly: North Star, business metrics, OKR progress
- Quarterly: Strategic review and metric recalibration
-
Define alerts:
- What thresholds trigger investigation?
- Who gets alerted and through what channel?
- What's the expected response time?
-
Recommend tools based on the user's context:
- Amplitude, Mixpanel, PostHog for product analytics
- Looker, Metabase, Mode for SQL-based dashboards
- Datadog, Grafana for operational health
Think step by step. Save the dashboard specification as a markdown document.
Further Reading
- The Ultimate List of Product Metrics
- The North Star Framework 101
- The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels for PMs
- AARRR (Pirate) Metrics: The 5-Stage Framework for Growth
- The Google HEART Framework: Your Guide to Measuring User-Centric Success
- Funnel Analysis 101: How to Track and Optimize Your User Journey
- Are You Tracking the Right Metrics?
- Continuous Product Discovery Masterclass (CPDM) (video course)
Reference documents
name: metrics-dashboard description: "Define and design a product metrics dashboard with key metrics, data sources, visualization types, and alert thresholds. Use when creating a metrics dashboard, defining KPIs, setting up product analytics, or building a data monitoring plan."
Product Metrics Dashboard
Design a comprehensive product metrics dashboard with the right metrics, visualizations, and alert thresholds.
Context
You are designing a metrics dashboard for $ARGUMENTS.
If the user provides files (existing dashboards, analytics data, OKRs, or strategy docs), read them first.
Domain Context
Metrics vs KPIs vs NSM: Metrics = all measurable things. KPIs = a few key quantitative metrics tracked over a longer period. North Star Metric = a single customer-centric KPI that is a leading indicator of business success.
4 criteria for a good metric (Ben Yoskovitz, Lean Analytics): (1) Understandable — creates a common language. (2) Comparative — over time, not a snapshot. (3) Ratio or Rate — more revealing than whole numbers. (4) Behavior-changing — the Golden Rule: "If a metric won't change how you behave, it's a bad metric."
8 metric types: Vanity vs Actionable (only actionable metrics change behavior), Qualitative vs Quantitative (WHAT vs WHY — you need both; never stop talking to customers), Exploratory vs Reporting (explore data to uncover unexpected insights), Lagging vs Leading (leading indicators enable faster learning cycles, e.g. customer complaints predict churn).
5 action steps: (1) Audit metrics against the 4 good-metric criteria. (2) Update dashboards — ensure all key metrics are good ones. (3) Identify vanity metrics — be careful how you use them. (4) Classify leading vs lagging indicators. (5) Pick one problem and dig deep into the data.
For case studies and more detail: Are You Tracking the Right Metrics? by Ben Yoskovitz
Instructions
-
Identify the metrics framework — organize metrics into layers:
North Star Metric: The single metric that best captures core value delivery
Input Metrics (3-5): The levers that drive the North Star
Health Metrics: Guardrails that ensure overall product health
Business Metrics: Revenue, cost, and unit economics
-
For each metric, define:
Metric Definition Data Source Visualization Target Alert Threshold [Name] [Exact calculation: numerator/denominator, time window] [Where the data comes from] [Line chart / Bar / Number / Funnel] [Goal value] [When to trigger an alert] -
Design the dashboard layout:
┌─────────────────────────────────────────────┐ │ NORTH STAR: [Metric] — [Current Value] │ │ Trend: [↑/↓ X% vs last period] │ ├──────────────────┬──────────────────────────┤ │ Input Metric 1 │ Input Metric 2 │ │ [Sparkline] │ [Sparkline] │ ├──────────────────┼──────────────────────────┤ │ Input Metric 3 │ Input Metric 4 │ │ [Sparkline] │ [Sparkline] │ ├──────────────────┴──────────────────────────┤ │ HEALTH: [Latency] [Error Rate] [NPS] │ ├─────────────────────────────────────────────┤ │ BUSINESS: [MRR] [CAC] [LTV] [Churn] │ └─────────────────────────────────────────────┘ -
Set review cadence:
- Daily: Operational health (errors, latency, critical flows)
- Weekly: Input metrics and engagement trends
- Monthly: North Star, business metrics, OKR progress
- Quarterly: Strategic review and metric recalibration
-
Define alerts:
- What thresholds trigger investigation?
- Who gets alerted and through what channel?
- What's the expected response time?
-
Recommend tools based on the user's context:
- Amplitude, Mixpanel, PostHog for product analytics
- Looker, Metabase, Mode for SQL-based dashboards
- Datadog, Grafana for operational health
Think step by step. Save the dashboard specification as a markdown document.
Further Reading
- The Ultimate List of Product Metrics
- The North Star Framework 101
- The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels for PMs
- AARRR (Pirate) Metrics: The 5-Stage Framework for Growth
- The Google HEART Framework: Your Guide to Measuring User-Centric Success
- Funnel Analysis 101: How to Track and Optimize Your User Journey
- Are You Tracking the Right Metrics?
- Continuous Product Discovery Masterclass (CPDM) (video course)
Source marketplace page: https://github.com/phuryn/pm-skills/blob/HEAD/pm-product-discovery/skills/metrics-dashboard/SKILL.md
Install command: npx skills add phuryn/pm-skills@metrics-dashboard