Metrics dashboard

Skill phuryn/pm-skills/pm-product-discovery/skills/metrics-dashboard

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.From its SKILL.md

Install

npx -y skills add phuryn/pm-skills --skill metrics-dashboard

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

5.6 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most monitoring observability skills give in ~1.2k tokens

Counted across 530 of the 532 authors here whose files we hold, read 2026-09-06

Use structured JSON loggingin 40 of 530, across 36 files
Link every alert to a runbookin 29 of 530, across 27 files
Attach correlation IDs to every log linein 19 of 530, across 16 files
Alert on symptoms rather than causesin 19 of 530, across 17 files
Use OpenTelemetry for distributed tracingin 15 of 530, across 14 files
Alert on symptoms users feelin 15 of 530, across 13 files
Implement health check endpointsin 14 of 530, across 10 files
Inspect existing dashboards firstin 12 of 530, across 4 files
Build the minimum useful boardin 12 of 530, across 4 files
Start from operator questionsin 12 of 530, across 4 files
Propagate trace context across boundariesin 11 of 530, across 10 files
Include trace id in all log entriesin 10 of 530, across 9 files

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.