Innovation metrics that matter

Years ago, as a store manager, I kept a scrap of paper in the back office that had nothing to do with sales. It tracked the things I could actually influence before the doors opened: how many of the promotion lines were ticketed and faced by nine, how many customers we greeted in the first ten seconds, how long the queue got at the front before someone opened a second register. Sales went on the wall like everyone else's. The scrap of paper was the thing I looked at.

An executive on a store visit found it and was not impressed. Sales targets, I was told, should be the only metrics that matter. Everything else was noise. I did not have the language to argue at the time, so I nodded and kept the paper in a drawer. What I was doing, it turns out, has a name. It is called innovation accounting, and it is the practice of measuring the controllable behaviours that drive results rather than only the results themselves.

I would like to make the case for it here, because the same argument that lost me that conversation twenty years ago is now losing retailers a great deal of money on technology pilots.

Activity is easy to measure. Progress is not.

Every retailer knows how to count. We count sales by the hour, by the store, by the square metre. The trouble with innovation is that for most of its life it produces nothing you can count that way. A pilot in eight stores does not move the chain's number. A new process in the DC does not show up in the P&L for a quarter. So one of two things happens. Either the work is judged on a financial metric it cannot yet move, and gets killed for being "unproven", or it is judged on activity, on demos delivered and stores live and vendors signed, and gets kept alive long after it should have been stopped. Both are failures of measurement, not of the idea.

Innovation accounting sits between those two. It asks: what would we need to see, at this stage, to believe this is working? And then it measures that.

How it works

Start with the hypotheses. Every initiative rests on assumptions about customers, about the business and about feasibility. Write them down, granularly, in language shared across the business so the merchandise team and the store team and the technology team are describing the same bet.

Set learning milestones. Not delivery milestones. Learning ones. The checkpoints where an assumption gets validated or falls over. "By the end of week four we will know whether store teams use this without being reminded" is a learning milestone. "Store 12 live by week four" is not.

Track the leading indicators. Input metrics, the ones you can influence: how many customers engaged, what the prototype test showed, what the pilot data said about adoption in the second week rather than the first. These are the scrap of paper. They tell you whether the behaviour that leads to the result is actually happening.

Experiment in stages. Structured phases, with a minimum viable version, a comparison where you can get one, and a clear learning outcome for each stage. Decide the success criteria for the post-deployment period before deployment, when nobody has anything to defend yet.

Count the learning. Hypotheses validated and invalidated. Adoption rates. Support tickets in the first fortnight, which tell you more about readiness than the launch deck did.

Set the parachute points. This is the one I care about most. Predetermined moments, agreed in advance, where the data says continue, pivot or stop. I call them parachute points because you decide where they are before you jump. It is remarkably hard to stop an initiative that a senior person sponsored and a vendor has been paid for, unless the moment to decide was fixed before anyone was emotionally invested. A parachute point makes stopping a normal outcome rather than an admission.

A few things that help

Start with one or two teams rather than the whole business, and let them teach the others. Make it safe to report an experiment that did not work, because the whole system collapses the moment people learn to shade the numbers. Tie every hypothesis to something that matters to the business and its purpose, not just to the pilot's own logic. Use whatever technology you have to collect the data in real time, so reviews are about what happened rather than what people remember. Make sure someone senior owns the process and turns up to the reviews. And include store teams and, where you can, customers in those reviews, because they will tell you things the dashboard cannot.

So now what?

Financial targets remain essential. Nobody is suggesting otherwise. But a business that measures only the outcome is a business that cannot tell the difference between a good idea executed badly, a bad idea executed well, and a good idea that needed six more weeks. Measuring the behaviours underneath the result gives teams direction, gives leaders a reason to stop something early, and gives everyone the psychological safety to work in uncertain territory without pretending it is certain.

The executive who found my scrap of paper retired a long time ago. I have kept the habit. In ReFRAME we call it the Analyse stage, and it is the one most pilots skip on their way to the applause.