"Output or outcomes?"

Output is easy to measure. Features shipped, tickets closed, code committed.
Outcomes are harder. Did the work actually solve a problem? Did it make someone’s life better? Did it move the business forward?

Teams that optimise for output get good at looking busy. But busyness isn’t the same as progress. You can deliver a mountain of features and still miss the point if nobody asks, “Is this what’s needed?”

Optimising for outcomes shifts the question. It’s less about “how much did we do?” and more about “what difference did it make?” That’s uncomfortable, because outcomes are slower to measure, harder to attribute, and sometimes reveal that our efforts weren’t as effective as we hoped.

But if we only chase output, we risk building faster and faster, in the wrong direction.

Are you counting what your team delivers, or what it changes?

✉️ Enjoying The Messy Middle?​
If this sparked something useful, consider forwarding it to a colleague or friend, it might help them too.

If someone sent this email your way and you’d like to get it direct, you can sign up here.