Skip to content
Product Lifecycle Templates

KPI Dashboard

beta  ·  Family governance-docs  ·  Phase undefined  ·  Sizes lean, full  ·  ~1,750 tokens

The defined set of key performance indicators an organization watches to know whether it is making progress toward its objectives, plus the specification of how each is measured, targeted, owned, and reviewed. A standing governance instrument and a platform-agnostic dashboard definition (not a live BI tool) that survives Goodhart’s Law and the vanity-metric trap by keeping metrics actionable, precisely defined, owned, and reviewed on a cadence.

Fast reference for using the kpi-dashboard bundle. For the full reasoning, history, and sources, read kpi-dashboard_companion.md.

First, the scope: this bundle is a document that defines a dashboard - which metrics matter, how each is measured, targeted, owned, and reviewed. It is platform-agnostic and precedes the build in Tableau, Looker, Power BI, or Amplitude. It is not the live tool.

When to use

Section titled “When to use”
  • You need to agree, in writing, on the few metrics that show whether an objective is being met - and exactly how each is calculated.
  • Metrics are disputed across teams (“our number says X, yours says Y”) and you need locked definitions.
  • Someone other than the author will build the live dashboard, and needs a spec to build from.
  • You want a standing monitoring instrument for progress toward objectives, reviewed on a cadence.

When NOT to use

Section titled “When NOT to use”
  • You are choosing objectives, not monitoring them. That is OKRs (the objective and its key results). The dashboard monitors the KPIs; it does not set the direction. Use both, in sequence.
  • You want a periodic snapshot against targets, not live monitoring. That is a scorecard. A dashboard monitors current state; a scorecard compares actual to target at a point in time.
  • You are reporting project status. That is a status report (completion against a plan), not an ongoing performance monitor.
  • You have no objective to measure against. A dashboard with no objective above it is a pile of numbers. Name the objective first, or you are collecting vanity metrics.

Dashboard, OKRs, scorecard, or risk register? (the question people actually have)

Section titled “Dashboard, OKRs, scorecard, or risk register? (the question people actually have)”
KPI dashboard OKRs Scorecard Risk register
Answers “How are we doing, live?” “Where are we going, by when?” “Above or below target, this period?” “What could stop us?”
Direction Monitors progress Sets direction Compares to target Tracks threats
Cadence Continuous Quarterly Periodic snapshot Weekly-to-quarterly
In this family this bundle (strategy-docs) (a dashboard variant) risk-register

The dashboard and the risk register are governance siblings: the dashboard tracks progress toward objectives, the register tracks threats to them. Read them together - a green dashboard beside an unreviewed register is a program performing today while accumulating exposure for tomorrow.

Pick a variant

Section titled “Pick a variant”
  • Lean (default): Purpose and Audience, KPIs, Review and Ownership. Enough for one team to agree what it watches and act on it.
  • Full: adds Metric Definitions (formula, inclusions/exclusions, owner and data steward), Layout and Thresholds (RAG bands and escalation), and Data Sources and Refresh. Use it when the dashboard feeds governance, when teams must agree what a metric means, or when someone else builds it on a BI platform.

Grow lean into full by adding sections; never reorder the shared three. The scaling signal is stakes and audience, not the number of charts.

Quality rubric (self-grade)

Section titled “Quality rubric (self-grade)”
  • The dashboard names the objective it monitors and the audience it serves.
  • Every row is a KPI (a metric paired with an objective and a target), not a bare metric.
  • Metrics are actionable: for each, “if it moved, we would do X.” No vanity numbers.
  • The list is short (under ten; 5-9 on any one view), not thirty metrics of noise.
  • Each KPI is marked leading or lagging, and headline lagging targets are paired with leading indicators.
  • Every KPI has one named owner.
  • There is a stated review cadence and the last-reviewed date is current.
  • (Full) Each KPI has a locked definition with inclusions/exclusions, formula, grain, and a data steward distinct from the owner.
  • (Full) RAG thresholds are defined numerically, with an escalation rule when a metric is red.
  • (Full) Each metric names an automated source of record; nothing critical is entered by hand.
  • The dashboard is read beside the risk register, and an all-green dashboard is treated with suspicion.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. The vanity dashboard. Numbers that go up and to the right but guide no decision. Fix: keep only metrics that change what you do.
  2. The gamed metric (Goodhart). A KPI that became a target and is now optimized directly, decoupled from the outcome. Fix: pair lagging targets with leading indicators; watch for the metric improving while the outcome does not.
  3. The ambiguous metric. No locked definition, so every team has its own number and reviews argue about data. Fix: define inclusions/exclusions, formula, grain, and source.
  4. Dashboard bloat. Thirty metrics on one view. Fix: a three-tier hierarchy (headline / supporting / drill-down).
  5. The orphaned metric. No owner, so no one can act when it moves. Fix: one named owner per KPI, distinct from the data steward.
  6. The all-green dashboard. Every metric green, because the targets are soft or the risks are tracked nowhere. Fix: honest targets, and read it beside the risk register.

No paired skill (yet)

Section titled “No paired skill (yet)”

There is no deliver-kpi-dashboard or govern-kpi-dashboard skill in the product-on-purpose org today, so this bundle’s pairs_with is empty. Until one exists, this template is filled by hand.

The artifacts

Section titled “The artifacts”

kpi-dashboard_template-lean.md · ~1,750 tokens

---
title: "{{dashboard_name}} KPI Dashboard"
monitors: "{{objective_or_program}}"
audience: "{{audience_tier}}"
dashboard_owner: "{{dashboard_owner}}"
last_reviewed: "{{date}}"
review_cadence: "{{cadence}}"
status: "{{status}}"
doc_type: kpi-dashboard
size: lean
source_template: kpi-dashboard
source_template_version: 0.1.0
---


<!--
LEAN KPI DASHBOARD SPECIFICATION. The smallest real dashboard spec: what objective it monitors and for whom,
the KPIs themselves (each a metric paired with an objective and target), and the cadence that keeps it alive.
Use it for one team to agree on what it watches and act on it. To grow it into a governance-grade spec (see
kpi-dashboard_template-full.md), ADD sections; never rename or reorder the ones below, because the full
variant is a strict superset of this one.


THIS IS A DASHBOARD DEFINITION, NOT A LIVE TOOL. It specifies which metrics matter, how each is measured, the
target, the owner, and the cadence - platform-agnostic. It precedes and outlives the build in Tableau,
Looker, Power BI, or Amplitude. Write the definition first: if a metric's meaning is unclear, it is useless.
See kpi-dashboard_companion.md section 1.


A KPI IS NOT JUST ANY METRIC. A metric becomes a KPI when it is paired with a specific business objective and
a target. Keep the list short (fewer than ten). Prefer ACTIONABLE metrics - ones that change what you do -
over VANITY metrics that feel good but guide no decision. See kpi-dashboard_companion.md sections 3 and 6.


BEWARE GOODHART'S LAW. "When a measure becomes a target, it ceases to be a good measure." A KPI under
target-pressure gets gamed. Pair headline (lagging) targets with leading indicators, and treat an all-green
dashboard with suspicion, not relief. See kpi-dashboard_companion.md section 6.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a companion pointer), guiding
   questions to ASK, a GOOD and a WEAK example, and the TRAP to avoid. Tables add PRIORITY and ROW HINT.
2. Replace each {{placeholder}}. Give every KPI a target and one named owner.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. Never finished, but before you share it: self-grade against kpi-dashboard_guide.md, then DELETE every HTML
   comment.
-->


# {{dashboard_name}} KPI Dashboard


## Purpose and Audience


<!-- WHAT  What objective this dashboard monitors, who reads it (audience tier), and the review cadence. One
           short block.
     WHY   The audience determines everything downstream: an executive dashboard is 3-5 headline metrics, an
           operational one is dozens refreshed in minutes, an analytical one is for data-literate users. Name
           the objective the metrics serve, or the dashboard is a pile of numbers. Deep dive:
           kpi-dashboard_companion.md section 3 (Purpose and Audience).
     ASK   What objective or program does this monitor? Who is the audience (executive / operational /
           analytical)? How often is it reviewed, and by whom?
     GOOD  "Monitors progress toward the Reporting Platform Modernization program's value goal (cut Time to
           Insight 30% by Q3). Audience: the program steering group (strategic). Reviewed monthly; owned by
           the program manager."
     WEAK  "A dashboard of our metrics." (no objective, no audience, no cadence; nothing to judge the metrics
           against)
     TRAP  Building for "everyone." A dashboard that serves executives and analysts at once serves neither;
           pick the audience and design for it. -->


{{purpose_and_audience}}


## KPIs


<!-- WHAT  The key performance indicators, one row each: name, a one-line definition, the target, the current
           value, the trend, whether it is leading or lagging, and the owner.
     WHY   This is the dashboard. A KPI is a metric paired with an objective and a target - not every metric
           qualifies. SMART (specific, measurable, achievable, relevant, time-bound) is the quality bar. Mark
           leading vs lagging: leading indicators can be acted on; lagging ones only confirm the past. Deep
           dive: kpi-dashboard_companion.md section 3 (KPIs).
     ASK   For each KPI: what is measured (in one line)? What is the target, and by when? What is the current
           value and trend? Is it leading (predictive, actionable) or lagging (confirms past)? Who owns it?
     PRIORITY  Keep it short (under ten; 5-9 is what the eye holds). Order by importance, headline metrics
           first. Owner is one named person. Every KPI has a target - a metric with no target is not a KPI.
     ROW HINT  A good row is a SMART, actionable metric with a target and an owner. A weak row is a vanity
           number (goes up, guides no decision) or a metric with no target.
     GOOD  | Time to Insight | Median minutes from opening a report to acting | -30% vs baseline by Q3 | -18% | improving | leading | Priya Nair |
     WEAK  | Page views | Total report page views | (no target, no objective; a vanity metric) | 2.1M | up | | |
     TRAP  Vanity metrics and metric bloat. Ask of every row: "if this moved, what would we do differently?"
           If the answer is nothing, it does not belong. Thirty metrics is not a dashboard; it is noise. -->


| KPI | Definition (one line) | Target | Current | Trend | Lead/Lag | Owner |
|---|---|---|---|---|---|---|
| {{kpi_name}} | {{definition}} | {{target}} | {{current}} | {{trend}} | {{lead_lag}} | {{owner}} |


## Review and Ownership


<!-- WHAT  How often the dashboard is reviewed, who owns it, and what happens when a metric turns red. A few
           lines.
     WHY   A dashboard is an instrument for a review meeting; the meeting is where value is created or lost.
           An exception-driven review (discuss what moved, not every green metric) plus a clear escalation
           when a metric goes red is what keeps the dashboard a decision tool, not wallpaper. Deep dive:
           kpi-dashboard_companion.md section 3 (Review and Ownership).
     ASK   How often is the dashboard reviewed, and by whom? Is the review exception-driven (focus on what
           changed)? Who owns the dashboard overall? What action triggers when a KPI turns red?
     GOOD  "Reviewed monthly by the steering group, exception-driven (owners speak only to metrics off-target
           or off-trend). The program manager owns the dashboard; each KPI has a named owner. A red KPI gets
           a root-cause and an action item at the review. Last reviewed 2026-07-20."
     WEAK  "Reviewed periodically." (no cadence, no owner, no escalation; the dashboard becomes wallpaper)
     TRAP  A review where every metric is green and everyone nods. The most dangerous dashboard is the one
           that is all green; either the targets are too soft or the risks are tracked nowhere. Read it
           beside the risk register. -->


{{review_and_ownership}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 6 sections across 1 format(s), methodology methodology-agnostic, typically owned by PM / Data Analyst.