Most KPI frameworks fail not because the metrics are wrong, but because they were never designed for the people who need to act on them. Here is the sketch-first discipline that fixes that.
A KPI framework is not a list of metrics. It is a decision-support system. If the executives it was built for cannot tell you, in one sentence, what decision each number informs, the framework has already failed — it just hasn't been retired yet.
We have reviewed dozens of executive scorecards over the years, and the pattern is remarkably consistent. The metrics are technically correct. The pipelines behind them are sound. The dashboard is polished. And six months after launch, leadership has quietly gone back to the spreadsheet the CFO's analyst maintains by hand, because that spreadsheet answers the questions they actually have.
The failure was never in the data. It was in the design process — or more precisely, the absence of one. The framework was assembled by the people who had access to the data, in the shape the data happened to take, and then presented to the people who were supposed to run the business with it. That order of operations is backwards, and reversing it is the single highest-leverage change you can make to your reporting estate.
When a data team builds a scorecard without structured stakeholder input, the result reflects the team's incentives: completeness, accuracy, and defensibility. So the scorecard grows. Every metric that can be calculated gets calculated. Every stakeholder who asks for a number gets a tile. Eighteen months later the 'executive dashboard' has forty-three metrics, four tabs, and no point of view.
Decision-makers have a different incentive: speed to judgment. A COO looking at a Monday morning scorecard wants to know three things — are we on track, where are we not, and what do I need to do about it. A framework that cannot answer those three questions in ninety seconds will be abandoned, no matter how accurate it is. Accuracy is the entry fee. Actionability is the product.
There is a second, quieter failure mode: metrics defined by what the source systems make easy. If the warehouse has clean order data but messy pipeline data, the scorecard skews toward orders — regardless of whether orders or pipeline is the lever leadership actually controls. The framework ends up describing the data estate rather than the business.
Our methodology applies a discipline borrowed from product design: never build the thing before you have sketched the thing. Before a single dbt model is written or a single semantic measure is defined, we run a working session — usually two hours, with the executives who will own the scorecard in the room — and we wireframe it on paper or a whiteboard.
The wireframe is deliberately crude. Boxes, labels, and made-up numbers. That crudeness is the point: nobody hesitates to cross out a box on a whiteboard, but everybody hesitates to ask for a rebuild of a finished dashboard. The cheaper the artifact, the more honest the feedback.
The workshop has a fixed agenda:
This session typically costs a client two hours and saves them a quarter of rework. It is the same sketch-first principle we apply across our methodology: validate the shape of the deliverable with the people who will use it before investing in the engineering behind it.
The right number of top-level KPIs for a leadership scorecard is five to seven. Not because of dashboard real estate, but because of attention. Beyond seven, executives stop reading the page and start scanning it, and a scanned scorecard drives no decisions.
Every metric that makes the cut must pass three tests. It must be tied to a named decision and a named owner — 'revenue' is a fact; 'net revenue retention, owned by the CRO, informing the renewals coverage decision' is a KPI. It must be movable on the cadence it is reviewed — a metric that only changes quarterly does not belong on a weekly page. And it must have a defined threshold for action: the green/amber/red boundaries are agreed in the workshop, not improvised in the meeting.
Everything else — the supporting detail, the diagnostic cuts, the departmental metrics — lives one click down. A good framework is a pyramid: a one-page apex for leadership, drill-down layers for operators. The mistake is flattening the pyramid onto one screen.
Every KPI in the framework gets a definition record before it ships. One page per metric, covering: the business definition in plain English, the calculation logic including filters and exclusions, the source tables and refresh cadence, the owner accountable for the number, the threshold logic, and the known caveats. We write these so that a new executive joining the company could read the record and trust the number without a single meeting.
This sounds bureaucratic. It is the opposite. The most expensive recurring meeting in most companies is the one where two leaders argue about whose revenue number is right. A definition record ends that argument permanently — and when the definition needs to change, it changes in one governed place, with a version history, instead of drifting silently across six dashboards.
A framework launches into a meeting, not into a portal. We anchor every scorecard to a specific recurring forum — the Monday leadership review, the monthly business review — and for the first six weeks, the framework is run side-by-side with whatever it replaces. The old spreadsheet is retired only when the new page has survived six consecutive real reviews without anyone reaching for the old numbers. That is the only adoption metric that matters.
Governance after launch is light but non-negotiable: a quarterly metric review where the leadership team confirms each KPI still maps to a live decision, retires the ones that don't, and admits new candidates through the same decision-first filter they survived in the original workshop. A change process for definitions, with notice to consumers. And a single named owner for the framework as a whole — because a scorecard owned by everyone is maintained by no one.
Run the sketch before you run the pipeline. Two hours with leadership, a whiteboard, and the discipline to start from decisions rather than data will do more for adoption than any amount of engineering polish. Five to seven metrics, each tied to a decision and an owner, each with a written definition and an agreed threshold, anchored to a real meeting and reviewed quarterly — that is the whole framework. It is not complicated. It is just rarely done in that order. If you want an honest read on where your current reporting estate stands, our Data Maturity Assessment takes fifteen minutes and benchmarks exactly these practices — and our free assessments are a low-stakes way to start the conversation.