metrics-dashboard

name: metrics-dashboarddescription: >  Design a product metrics dashboard — North Star, input metrics, and  guardrails — that a team actually uses to make decisions. Use when  building dashboard architecture: layers, owners, cadence, and  visualization.license: MIT + Commons Clausemetadata:   version: 1.0.0  author: borghei  category: project-management  domain: product-discovery  updated: 2026-05-27  python-tools: dashboard_designer.py  tech-stack: metrics, dashboard, north-star, hexagonal-metrics  tags:     - metrics    - dashboard    - north-star    - guardrail-metrics    - product-analytics

Metrics Dashboard

A dashboard architecture skill: which metrics go where, at which cadence, for which audience, with which visualization. Focused on producing the ONE artifact a team uses to make decisions — not the 30-chart dashboard nobody opens.

When to use this skill

• New product / feature launch — what to instrument and watch
• Existing dashboard audit — what to cut, add, refactor
• Team-level OKR tracking — operational dashboard for the team
• Exec readouts — board / monthly business review dashboard
• Cross-functional alignment — what does "success" look like?

The 4 dashboard layers

1. North Star — 1 metric that summarizes value delivered
2. Input metrics (3-5) — the drivers of NS
3. Guardrails (3-5) — what we DON'T want to sacrifice (counter-metrics)
4. Operational metrics (4-8 per team) — what we actually act on weekly

A dashboard ≠ all metrics. A dashboard = these 11-22 metrics presented for fast decision-making.

Clarify First

Before designing the dashboard, settle the inputs below. When one is missing or vague and would change the result, ask about it; when it wouldn't, use a sensible default and say which one you used.

• North Star metric: defined or not (it is the root of all 4 layers; if undefined, define it first via north-star-metric).
• Audience: board/exec / functional team / all-hands / IC (sets the max top-level metric count, 5-8 down to 1-3).
• Team structure: which teams act on this (operational metrics are 4-8 per team with named owners).
• Available instrumentation: what data you actually capture (you can't show a metric you don't measure; bounds refresh cadence).

Ask about the two or three inputs that matter most for this request, not the whole list. If the user wants a result straight away, produce it and state your assumptions at the top.

Workflow

Step 1 — Confirm the North Star

Already defined? Use it. Not defined? See project-management/execution/north-star-metric.

A good NS:

• Behavioral or business
• Moves week-over-week
• Hard to game without delivering real value
• One number

Step 2 — Decompose to input metrics

For each NS, identify 3-5 inputs whose combined movement drives it.

Example for NS "Weekly Active Companies × Messages Sent per Company":

• Acquisition rate
• Activation rate (% reaching 50 messages in 14 days)
• Retention rate (W4 cohort)
• Expansion (adds users / channels)

Step 3 — Identify guardrails

What could move the NS up while damaging the underlying value?

Example guardrails:

• Spam rate (if NS = messages, more messages can include spam)
• User-reported complaints
• Power-user churn (vs total churn)
• Support ticket volume
• Latency / error rate

Step 4 — Identify operational metrics per team

The 4-8 metrics each team needs to act weekly:

• Growth team: funnel conversion, channel CAC, signup quality
• Retention team: cohort retention, save-room saves
• Platform team: SLO posture, on-call health, deploy freq
• Trust & safety: spam reports, removed accounts, false-positive rate

Step 5 — Define visualization + cadence per metric

Each metric needs:

• Visualization: line chart / funnel / cohort heatmap / bar
• Comparison: vs prior period / vs target / vs cohort baseline
• Refresh cadence: real-time / hourly / daily / weekly / monthly
• Owner: named team

Step 6 — Run dashboard_designer.py

Audit: too many top-level metrics, no guardrails, vanity metrics, missing owners, missing comparisons.

python3 project-management/discovery/metrics-dashboard/scripts/dashboard_designer.py \
  --input dashboard_spec.json --format markdown

Step 7 — Sunset stale metrics

Quarterly: kill metrics no team looked at. Dashboards rot; pruning is healthy.

Decision frameworks

Top-level metric count

Visualization fit

Avoid pie charts beyond 3 slices. Avoid 3D charts always.

Vanity vs actionable test

For each candidate metric: "If this moved up 10% next week, what would we do?"

• Have answer → actionable; keep
• No answer → vanity; cut

Comparison discipline

Every chart needs a comparison anchor:

• vs prior period (week / month / quarter)
• vs target
• vs cohort baseline
• vs competitor benchmark (rare; usually unreliable)

A chart with no comparison is a number floating in space.

Common engagements

"Build us a dashboard for the new product line"

1. Confirm North Star.
2. Decompose to 3-5 inputs.
3. Identify 3-5 guardrails.
4. Per team: 4-8 operational metrics.
5. Spec viz + cadence + owner per metric.
6. Pilot for 4 weeks; cut what nobody opens.

"Audit our existing dashboard"

1. List every metric currently shown.
2. Tag each: NS / input / guardrail / operational / vanity.
3. Cut all vanity.
4. Cut operational that no team looks at.
5. Add missing guardrails.
6. Limit each audience to its max.

"Help us track an OKR"

1. Map OKR to metric: KR → metric.
2. KR should be the metric.
3. Inputs = what moves the KR.
4. Guardrails = what we won't sacrifice.

Anti-patterns to avoid

• 30+ metrics on one screen. Decision-making dies.
• No guardrails. NS optimization without counter-balance.
• All metrics for all audiences. Exec doesn't need eng team metrics.
• No comparisons. Numbers without context.
• Real-time everything. Most metrics don't need it (and it's expensive).
• No owner per metric. Orphan metrics rot.
• Vanity metrics (page views, signups alone). Not action-driving.
• No cadence on review. Dashboard exists; team doesn't use it.

Scope & Limitations

In Scope:

• Dashboard architecture in four layers: North Star, 3-5 input metrics, 3-5 guardrails and 4-8 operational metrics per team
• Visualization, comparison anchor, refresh cadence and named owner for each metric
• Top-level metric limits by audience and the vanity-versus-actionable test
• A spec audit for too many top-level metrics, missing guardrails, vanity metrics, missing owners and missing comparisons (dashboard_designer.py)
• Audits of existing dashboards and mapping OKRs to metrics

Out of Scope:

• Defining the North Star itself (see project-management/execution/north-star-metric/)
• Building the dashboard in a BI tool or writing its queries (see data-analytics/business-intelligence/)
• Event tracking and instrumentation (see marketing/analytics-tracking/)
• Metric trees, cohort and funnel analysis on real data (see product-team/product-analytics/)

Important Caveats:

• dashboard_designer.py audits a hand-written JSON spec. It reads no live data and does not check that a metric is instrumented.
• Flags such as drives_ns and actionable_test_passed are self-reported in the spec. The tool trusts them.
• Which metrics count as guardrails or vanity, and the targets behind them, stay team judgments.
• Dashboards go stale. The skill expects a quarterly prune, which the tool does not schedule.

References

• references/dashboard-architecture.md — layers, cadence, visualization patterns
• references/dashboard-anti-patterns.md — common failures + fixes

Related skills

• project-management/execution/north-star-metric — define THE one number
• product-team/product-analytics — metric tree + cohort + funnel
• product-team/ab-test-setup — experimentation
• c-level-advisor/chief-data-officer-advisor — platform context