Productivity

I've been reading about what The Economist is calling "America's productivity miracle." The short version: U.S. labor productivity has been growing at roughly 2% a year for the past five years, about double what it was doing in the 2010s. At that same time, these productivity gains have basically defied expert predictions.

Interestingly, this is not an AI story: the acceleration in productivity started before LLMs were meaningfully deployed.

But it did get me thinking about my own productivity, especially in light of AI, which has us all feeling more productive.

Here's the definition I keep coming back to: output divided by input. Economic value created per unit of labor. That's the macro version. It's actually a pretty clean definition.

The problem is how we apply it at the individual level. We almost always measure the wrong numerator.

Output, which is drastically increasing thanks to AI, is easy to measure because it's immediate and I control it entirely. I can ship a feature. I can't make the market want it. I can run a test. I can't make it win. Outcomes are delayed, they're subject to things outside my control, and they're genuinely hard to attribute. So we default to output — because at least we own it. The problem is that the thing that's harder to measure is almost always the thing worth measuring.

When I think about my engineering team, the intuitive measure is lines of code. Features shipped. Velocity. That's output in the most literal sense. And by that measure, AI makes everyone wildly more productive. Code gets written faster. More features ship. The numerator grows.

But that's not the right numerator. The right numerator is outcomes. Does the feature drive revenue? Does it reduce churn? Does it help a customer capture margin they were leaving behind? Those are the things that actually matter. Lines of code and features shipped are vanity metrics — measurable, they feel like progress, and they're almost entirely in my control, which is exactly why they're so seductive and so misleading.

Or you could think about it in testing and experimentation terms. The question I hear a lot is: how many tests should we be running? Ten a month? One a week? That's an output question. It's also a bad question. Twenty poorly conceived tests are less valuable than one test that isolates a real variable and gives you something you can act on. The outcome — incremental revenue driven, margin captured — is what matters. The test count is just a way to feel busy.

The trap is this: when you start using AI to generate more output, you can do more work to get the same outcome, and call that productive. More tokens spent, more features in the queue — same revenue growth at the end of the quarter. That is, by any honest definition, less productive; the numerator didn't move.

I think a lot of teams are in this trap right now and don't know it. The feeling of productivity is very real. The dashboards look good. Everyone is busy. But if you're measuring yourself by what you shipped rather than what actually moved, you might be running faster to stay in the same place. The right question isn't "am I doing more?" — it's "is what I'm doing actually moving the number I care about?"