When defining success metrics is worth the effort

The version of this that works is simpler than the version most people imagine. Defining success metrics is not free, and pretending otherwise leads to bad decisions.

The projects that go badly are rarely the ones with the hardest technical problems. The version that survives contact with a real deadline is the simple one.

When it is worth it

Agree the numbers before the work starts. It is worth being explicit about, because assumptions differ quietly. Write the reasoning down alongside the decision, because the reasoning is what changes first.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. There is a version of this that is over-engineered, and it is worth avoiding.

How to decide

Pick metrics you can actually influence. It is worth being explicit about, because assumptions differ quietly. Doing this properly once is usually cheaper than doing it approximately three times.

How to tell if yours is fine

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Three things worth confirming about defining success metrics before you move on:

• Someone can say what the current setup is without going to look
• Agree the numbers before the work starts — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.