Metrics exist to steer, not to decorate. Scaleflow’s stance is blunt: hate flying blind without metrics, and hate flying blind with too many. Both leave you unable to make the next decision.
Enough signal to steer
Pick the smallest set of numbers that would actually change your mind. Skip the vanity metrics — the ones that only ever go up and never trigger a decision. More dashboards rarely mean more clarity; they mean more noise to argue about.
Lead and lag, close to the customer
Measure success with a mix of lead and lag metrics, kept as close as possible to the customer problem the initiative exists to solve.
- Lead metrics move first and tell you whether the work is landing — adoption, activation, time saved.
- Lag metrics confirm the outcome later, once the effect has had time to show.
Avoid making revenue the primary metric. Revenue is downstream of almost everything and moves too slowly and too noisily to steer a week’s work. Measure the customer behaviour that revenue depends on instead.
Gold, Silver, Bronze
For each metric, define three achievement levels in advance:
- Gold — the outcome that would make this a clear win.
- Silver — solid, worth shipping, short of the dream.
- Bronze — the floor; below this the bet didn’t pay off.
Naming the tiers up front kills the after-the-fact debate about whether a result was “good enough.”
An initiative to speed up a slow report sets its lead metric as median report-load time and its lag metric as weekly active users of the report. Gold: load time under two seconds and active users up 20%. Silver: under four seconds and a measurable lift. Bronze: under four seconds with no drop. When the work ships and load time lands at three seconds with flat usage, the team doesn’t argue — that’s a Silver-on-speed, Bronze-on-usage result, and the gap between them becomes the next UncertaintyUncertaintyWhat the team does not yet know — sized and tracked deliberately rather than hidden inside estimates.: why didn’t faster reports pull more people in?
Metrics in the Initiative Document
Success metrics live in the Initiative DocumentInitiative DocumentThe PR/FAQ-shaped document where an initiative's context lives — customer, solution, plan, business case, and success metrics. from day one, so every Product Demo and Board Meeting can check the work against the metrics it was supposed to move. The Delivery & Data Meeting does this systematically across initiatives: review the basic product metrics, hold past deliveries up against the metrics they were meant to move, and preview upcoming deliveries with their expected impact. A delivery that didn’t move its metric is a lesson, not a failure to hide.
The vague-metrics anti-pattern
How this maps to OKRs
If your organisation runs on OKRs, the translation is direct:
- The Initiative title is your Objective. OKRs want the Objective to be somewhat inspirational, so name the initiative accordingly — not “Reporting v2” but “Reports people actually trust.”
- The Success Metrics are your Key Results — the Gold / Silver / Bronze numbers you already defined.
- The text in the Initiative Document gives the OKR its context, so the numbers never float free of the reason they matter.
You don’t run a separate OKR process on top of the method. The Initiative Document already contains an OKR; you just read it as one.