Outcomes over output: a working definition

Peter Drucker said there is surely nothing quite so useless as doing with great efficiency what should not be done at all. I've watched a lot of software organizations spend a lot of money proving him right.

Here's the uncomfortable industry math. In 2019, the product-analytics firm Pendo analyzed feature usage across a large sample of software products and found that about 80% of features are rarely or never used. Argue the number down if you like; the shape of the finding survives. A very large share of what software teams build makes no difference to anyone. All of it counted as output. All of it landed in somebody's velocity chart. Sprint reviews celebrated it. And none of it mattered.

That's the gap our seventh commitment lives in. Success is the problem solved, not the feature count.

Goodhart's law eats your dashboard

The moment a measure becomes a target, it stops being a good measure. That is Goodhart's law, and software is its natural habitat. Target velocity, and story points inflate. Target ticket throughput, and tickets get smaller. Target lines of code and, God help you, you will get lines of code. None of this requires bad actors. It requires ordinary people responding sensibly to what leadership decided to count. Every one of those metrics measures motion, and a team can score brilliantly on all of them while its users' actual problem sits exactly where it was two quarters ago.

I've sat in the meeting where a delivery org presents a superb velocity trend in the same week the customer-satisfaction numbers fall off a cliff. Nobody in that room was lying. They were measuring output, and output was fine. It's the business that wasn't.

Numbers a CFO will sign

The fix is not to stop measuring. It's to measure things that resist theater. We hold ourselves to DORA-style delivery measures: cycle time, deployment frequency, defect-escape rate. Part of why we like them is that they hold up in a board review. The subtler reason is that they keep each other honest. Deployment frequency alone can be gamed by shipping confetti; paired with defect-escape it can't, because speed purchased with recklessness shows up immediately in the stability column. The research behind those metrics found that teams scoring well on speed and stability together are building real capability rather than performing it.

Then there's the layer that matters more, the one the delivery numbers stand in for: what did users and customers actually get? We tie engagement success to that question in writing, before the work starts. Not "did we ship the roadmap." Did cycle time fall, did the error rate drop, did the thing you hired us to fix get fixed.

The blunt question

Two practices put teeth in this, and both are mildly uncomfortable, which is how you know they're real.

First: our quarterly reviews of what we've built ask one blunt question: did this matter? Sometimes the honest answer is no, and the right move is to sunset the thing rather than keep paying its maintenance tax out of sentiment. Killing your own output on purpose is the clearest signal a team can send about what it's actually optimizing. Teams that can never sunset anything have also told you what they're optimizing.

Second: demos put real users on real work. A demo driven by the builder, on a happy path, with rehearsed data is a slide narrative with extra steps. It exists to make output look like an outcome. Put an actual user on their actual task and the software tells the truth about itself in about ninety seconds. It's the cheapest honest metric we know, so we've made it a habit.

Why this ordering

I keep Sigao pointed at the outcome instead of the hours because the alternative quietly corrupts everything downstream: what gets staffed, what gets celebrated, what a "good quarter" means. Output is what the work costs. Outcomes are what the work is for. A firm that confuses the two will be very busy, fully billable, and useless. What we ship is the measure, not what we put in. If what we shipped didn't move your numbers or your people, I don't want credit for it.

Sources

• Pendo, The 2019 Feature Adoption Report, 2019.
• DORA, "DORA's software delivery metrics: the four keys": the research archive lives at dora.dev/research.