Most measurement conversations start in the wrong place. Someone asks what we should be tracking, a list gets built, everyone agrees it’s the right list, and then it quietly dies somewhere between the meeting where it was agreed and the month it was supposed to start.
The reason is almost never that the metrics were wrong. It’s that nobody checked whether they could be produced.
So this issue is about the order of operations - the questions that come before metric selection, what makes a data source genuinely usable rather than nominally available, and a distinction that changes how we think about what we’re measuring in the first place.
The four questions ( to be asked in order)
1. What question am I actually trying to answer?
Not which metric sounds useful. What decision is waiting on this.
The test is whether we can name the action that changes depending on the answer. If margin by channel comes back worse than expected, what happens next - do we reprice, do we shift investment, do we renegotiate, do we exit? If nothing changes regardless of the answer, we’re building a number for reassurance rather than for use, and it will be the first thing dropped when the month gets tight.
This question also does quiet work on scope. “How is the business performing” has no answer. “Which channels are eroding faster than we’re replacing them” has a very specific one, and it tells us exactly what data we’re going to need.
2. What data would answer it?
Down to the level of granularity the answer actually requires, which is nearly always lower than anyone assumes in the meeting.
Channel margin sounds like a single number. It isn’t. It only exists if we can get to individual products, at the prices actually paid, with the customers behind them correctly attributed to a channel, and the relevant costs sitting alongside - and then roll all of that back up cleanly. That’s four separate data requirements hiding inside one innocuous-sounding metric.
The rule of thumb: any metric that requires attribution - by channel, by segment, by customer type - is a granularity question wearing a reporting question’s clothes.
3. Does that data exist, is it current, and can I trust it?
These are separate tests and a source can fail any one of them independently.
Current. How fresh is it by the time we’d use it? A source refreshed monthly cannot support a weekly view, and a source updated in arrears cannot support a decision taken in the first week.
Complete. Are all the dimensions actually populated, or is the channel tag present on 80% of records and blank on the rest? Partial attribution produces a number that looks precise and is systematically wrong, which is worse than no number at all.
Reconcilable. Does it tie back to what we already publish? If our new channel view sums to something different from reported revenue, the first meeting will be about the reconciliation rather than the decision. We will lose time and trust, however good the underlying analysis is.
Owned. Is there a person accountable for the source, or does it exist because someone maintains it as an unofficial favour? Unowned sources fail silently, and usually at the worst moment.
4. How does this get built so it survives me being away?
A view only one person can refresh isn’t a measurement system. It’s a dependency.
The practical version of this question is: what happens on the third refresh, when the person who built it is on holiday and the underlying file has changed shape? If the answer involves anyone reverse-engineering anything, the design isn’t finished.
Leading and lagging aren’t a choice
There’s a related question that comes up as soon as the list is agreed: should we be measuring outcomes, or the things that produce them?
The usual framing is that leading indicators are better than lagging ones, because a lagging metric tells us what happened after we can no longer act on it. Sales results close the month, and the month is closed. Leading indicators are the only ones we can still steer.
That’s true as far as it goes, and I think the underlying instinct is right - building a system of consistent behaviour is a better management frame than chasing an outcome number. But the framing hides the part that actually matters:
A leading indicator is a hypothesis about cause.
If the hypothesis is untested, we haven’t built an early warning system. We’ve made activity easier to measure. A team can hit its leading indicator perfectly and produce nothing, if the link between the activity and the outcome was assumed rather than demonstrated.
So they aren’t alternatives. The lagging metric defines what we’re trying to achieve. The leading metric is our bet on what produces it. And the discipline - the part almost nobody does - is periodically checking whether the bet still holds. Most organisations set the pair once and never revisit it, which means the leading indicator carries on being reported long after it stopped predicting anything.
The distinction that matters more: threshold or lead indicator
Here’s where this gets uncomfortable for finance specifically.
Ask an FP&A team what their leading indicator is and the answer is usually some version of delivered on time, right first time. It’s a reasonable answer. It’s measurable, it’s within our control, and it’s the thing that most visibly fails.
But it’s worth being precise about what kind of metric it is.
A threshold is something we clear and then stop optimising. A lead indicator is something we keep pushing. Confusing the two produces a team that polishes punctuality indefinitely - and a mandate to be right first time, every time, taken literally, is a mandate to over-check. Which is how forty minutes gets spent on an immaterial variance that changes nothing.
There’s a sharper problem underneath. On time and error-free is a reporting quality metric. If the thesis is that finance exists to support decisions rather than to produce reports, then optimising the delivery of the artefact rather than its influence builds a team that is reliably punctual and entirely ignored. We’ve all seen that team. Perfect accuracy, perfect timing, nobody reading it.
The thing that actually predicts influence is different: how often finance is in the conversation before the decision is framed, rather than being asked to validate one already made.
I’d hold that as a principle rather than a metric, because I don’t think it can be honestly measured. There are proxies - requests arriving as “help us think about this” versus “check this for me,” being on the invite where options are still open, the lead time between question and decision - but every one of them is soft, and none survives being turned into a target. The moment we incentivise early requests, requests get reclassified.
Which brings this back to where we started
Notice what just happened.
The metric that’s easy to source - on-time delivery, error rate - can be pulled from a calendar and a version history in about ten minutes. The one that actually predicts whether our work matters has no system of record at all.
So teams optimise the first one. Not because anyone decided it was more important, but because it was the one already being tracked.
That’s the argument of this issue arriving from the other end. The four questions exist to stop us committing to metrics we can’t produce. But it’s worth being awake to what that constraint does to us over time - measurement availability shapes priorities more powerfully than importance does, and it does it invisibly.
The practical response isn’t to measure the unmeasurable. It’s to keep the principle explicitly on the table alongside the metrics, so the dashboard doesn’t quietly become the whole definition of the job.