Kpi Tree Dashboard

KPI Tree Dashboard

When to use

Use whenever a set of metrics needs a clear status read, not just raw numbers, and especially when leading indicators (pipeline coverage, usage trends, early funnel metrics) exist but aren't explicitly connected to the lagging outcomes (revenue, retention, margin) they're supposed to predict.

What it does

Scores every metric red, amber, or green against its target using stated threshold bands via a bundled calculator, and specifically checks whether any leading indicator is flagging red or amber while its corresponding lagging outcome still reads green — the exact situation where a dashboard that only shows lagging metrics would miss a problem that's already visible upstream.

Method

1. Classify every metric as leading or lagging. A lagging metric (revenue, churn, margin) tells you what already happened. A leading metric (pipeline coverage, usage frequency, early-stage conversion) predicts what's about to happen — the distinction matters because they need different response times.
2. Set red and amber threshold bands as a percentage of target for every metric, not just a single pass/fail line — a metric at 96% of target reads very differently from one at 60%, and a three-tier status captures that.
3. State explicitly which leading indicators predict which lagging outcomes. This link is what makes the dashboard actually useful for early warning, not just a status report after the fact.
4. Run the bundled calculator (scripts/kpi_rag.py) to get the RAG status for every metric and, critically, the early-warning check: any leading indicator showing red or amber while its predicted lagging outcome still shows green.
5. Treat every early-warning flag as the headline of the dashboard, not a footnote — a green lagging metric with a red leading indicator behind it is more urgent than a metric that's already red, because there's still time to act before the lagging number actually misses.
6. Set thresholds based on what actually matters for the decision, not an arbitrary default — a metric with severe consequences if missed deserves tighter bands than one that's merely nice to hit.
7. Revisit the leading-to-lagging links periodically. If a leading indicator stops actually predicting its lagging outcome (the relationship breaks down as the business changes), the dashboard needs updating, not blind trust in a stale link.

Inputs

• Every tracked metric with its type (leading or lagging), current actual, target, and red/amber threshold percentages
• The stated link from each leading indicator to the lagging outcome it predicts
• Config saved as JSON matching the format documented at the top of scripts/kpi_rag.py

Output format

RAG status table for every metric with percentage of target; explicit early-warning section flagging any leading indicator in red or amber while its predicted lagging outcome is still green.

Example

Revenue shows green at 99% of target, a status that would read as "everything's fine" on its own. Pipeline coverage, the leading indicator that predicts next quarter's revenue, shows red at 70% of target. The early-warning flag surfaces this explicitly: revenue looks fine today, but the leading indicator behind it suggests that's about to change, giving the team a full quarter of lead time to act instead of finding out when revenue itself finally misses.

Common pitfalls

• Building a dashboard of only lagging metrics, which reports what already happened with no early warning of what's coming.
• Setting a single pass/fail threshold instead of red/amber bands, losing the ability to distinguish a near-miss from a serious shortfall.
• Never stating which leading indicators predict which lagging outcomes, so a red leading indicator sits on the dashboard without anyone connecting it to the risk it actually represents.