A short guide to defining success metrics

There is no clever trick in this one, just a handful of decisions worth making deliberately. Everything we would tell a client about defining success metrics in the time it takes to drink a coffee.

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Doing this properly once is usually cheaper than doing it approximately three times.

Why this earns attention

Agree the numbers before the work starts. Getting it slightly wrong is survivable. Ignoring it entirely is not. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The practical version

Traffic is not a business outcome. That sounds obvious written down. It is still the thing most often skipped. If it only works because one person remembers to do something, it does not work yet.

Warning signs

Pick metrics you can actually influence. The reasoning matters more than the rule, because the rule has exceptions. Assume whoever inherits this will have half your context and none of your patience.

What this looks like day to day

The projects that go badly are rarely the ones with the hardest technical problems. Three things worth confirming about defining success metrics before you move on:

• Someone can say what the current setup is without going to look
• Traffic is not a business outcome — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.