Jevons Paradox and the Wrong Kind of Productivity

The Jevons Paradox

In 1865, English economist William Stanley Jevons noticed something interesting about coal consumption. Steam engines were becoming more efficient, so you might reasonably expect industry to use less coal. Instead, coal consumption increased. More efficient engines made steam power economical for more applications, which created more demand for coal.

This became known as the Jevons paradox: when technology makes a resource more efficient and therefore cheaper to use, we often consume more of it, not less.

Jevons paradox came up recently in a discussion about artificial intelligence, and it applies directly to what is about to happen in product management.

The Productivity Illusion

Most conversations about AI productivity assume we’ll use AI to do the same work with less effort. If writing requirements takes four hours today and AI reduces that to one hour, we’ve saved three hours. If creating a prototype takes a week and AI reduces that to a day, we’ve saved four days. The productivity calculations look fantastic.

But that’s probably not what we’ll do with the savings.

AI is dramatically reducing the cost of producing almost everything associated with product management. Requirements, user stories, research summaries, competitive analyses, prototypes, code, tests, marketing content, presentations—all of these are becoming faster and cheaper to produce. If AI allows us to produce software twice as efficiently, most organizations won’t decide to produce the same amount of software with half the people or half the effort. They’ll produce more.

And that’s where the worry starts.

Producing more isn’t the problem. Producing more without making better decisions is. AI is very good at reducing the cost of execution, but reducing the cost of execution doesn’t necessarily improve the decision about what should be executed. AI can help write an excellent requirement, but it cannot establish that the requirement deserves to exist. It can create a prototype in minutes without establishing that anyone needs what’s being prototyped. It can produce working code astonishingly quickly without determining whether solving this problem is a better investment than solving another one.

With AI, you can build the wrong product faster than ever.

What Scarcity Was Doing for Us

For decades, software organizations have been trying to solve the same basic problem: How do we build more stuff faster? We adopted Agile, DevOps, cloud computing, low-code and no-code tools, and now AI. And we’ve actually gotten extraordinarily good at producing software.

But customers never asked us to become good at producing software. They wanted us to solve their problems.

That’s an important distinction because we may discover that scarcity was doing more work for us than we realized. Imagine that an organization has 100 ideas for improving its product but enough capacity to pursue only five. That’s frustrating, but it forces a decision. Someone has to determine which five deserve investment.

That’s where product management should come in. Which problems are worth solving? Which customers actually have those problems? How dissatisfied are they? What evidence do we have? What alternatives are customers using today? How does this opportunity support our strategy? And perhaps the most difficult question of all: What should we stop doing?

When we could afford to pursue only five ideas, scarcity forced us to choose.

Now imagine that AI changes the economics enough that we can pursue 30 (or 70!) of those 100 ideas. Have we improved the product? Or have we simply relaxed the constraint that forced us to prioritize?

Many organizations will choose the latter. Instead of getting better at determining which investments deserve resources, they’ll simply invest in more things. The backlog doesn’t get smaller because developers become more productive. We just pull more items from it.

When Abundance Becomes the Problem

This is where Jevons paradox becomes particularly interesting for product leaders. If the cost of execution falls dramatically, execution will no longer be the primary constraint.

Despite amazing productivity improvements in engineering, customer attention doesn’t increase tenfold. Market demand doesn’t increase tenfold. The number of meaningful customer problems doesn’t increase tenfold. And our ability to launch, sell, support, maintain, and eventually retire everything we build certainly doesn’t increase tenfold.

In fact, we could easily create the opposite problem. Production gets cheaper while complexity gets more expensive.

And some of that complexity gets dumped directly onto the customer.

Alas, more isn’t necessarily better.

Think about the headache-remedy aisle at the grocery store. You don’t find one product for a headache. You find dozens (or hundreds!) of products, formulations, brands, strengths, combinations, package sizes, and claims. Unless you happen to know what acetaminophen, ibuprofen, naproxen, and aspirin do differently, what exactly are you supposed to buy? Sometimes you give up and ask the pharmacist.

Books aren’t much better. An online bookstore can offer virtually every book currently in print, plus millions that aren’t. That’s an extraordinary achievement in distribution. It doesn’t answer the question, “What should I read next?” For that, we still turn to reviewers, friends, librarians, bestseller lists, and recommendations.

More choice sounds wonderful until you’re the person who has to choose.

We need pharmacists, designers, reviewers, and other experts partly because production and distribution have made abundance possible. Their value isn’t in giving us even more options. Their value is in applying judgment to the options that already exist.

The Job of Deciding What Not to Build

Today, product management plays a similar curation role.

A product manager shouldn’t merely be the person who feeds more possibilities into the development organization. Part of the job is deciding what not to offer. Which products deserve to exist? Which capabilities belong in this product? Which features improve the experience, and which merely add confusion? When does another configuration give the customer valuable flexibility, and when are we simply shifting a decision we should have made onto the customer?

Software has a peculiar tendency to regard optionality as inherently good. If some customers want A and others want B, we’ll support both. If somebody might want to configure something differently, we’ll add a preference. If one prospect requests a capability, we’ll squeeze it into the backlog.

After all, another feature can’t hurt.

Except it can.

Every choice has a cost. Customers have to understand it. Salespeople have to explain it. Marketing has to position it. Customer success has to support it. Engineering has to maintain it. Product management has to decide what happens to it next.

Making something inexpensive to build doesn’t make it inexpensive to own. And making something possible for the customer doesn’t necessarily make the product better.

This is why judgment becomes more important as execution becomes cheaper. If AI allows us to build almost anything, the valuable question is no longer “Can we build it?” It becomes “Sure we can build it, but should we?”

As execution becomes abundant, judgment becomes scarce. Instead of asking how much more we can produce, product leaders should be asking what to do when production is no longer the constraint.

Output Jevons vs. Learning Jevons

This is also where we can create a different understanding of Jevons paradox.

Suppose we spend the AI productivity dividend not on more output but on more learning.

The obvious version of Jevons in product development goes something like this: AI makes production cheaper, so we create more requirements, more code, more features, and ultimately more products.

Call that Output Jevons.

What about Learning Jevons?

AI makes investigation cheaper, so we gather and process more customer evidence, explore more hypotheses, run more experiments, challenge more assumptions, and make better decisions before committing resources.

There are already wonderful applications for AI here. Use it to summarize customer interviews and identify patterns across dozens or hundreds of conversations. Ask it to find contradictions in what customers are telling you. Use it to analyze win/loss information, examine competitors, explore alternatives, test assumptions, and identify gaps in what you know.

But there is an important qualification. AI should amplify evidence, not manufacture it.

A beautifully generated market analysis isn’t customer evidence. A synthetic persona isn’t customer evidence. Asking an AI what customers probably want isn’t customer evidence. We still have to go into the market and learn from actual customers, prospects, and buyers.

Customer conversations are the product manager’s superpower. AI doesn’t diminish that superpower. It makes it more valuable. If you can use AI to process more conversations, compare what you’ve heard across customers, expose contradictions, and identify questions you should have asked but didn’t, then the economics of customer learning have improved dramatically.

Good. Let’s invoke Jevons there.

Let’s have more conversations because we can process them more efficiently. Let’s explore more hypotheses because experiments are cheaper. Let’s investigate more alternatives before deciding which one deserves investment. Let’s use our new productivity to increase the amount of evidence behind our decisions instead of merely increasing the amount of stuff those decisions produce.

Yes, AI will make product organizations more productive. But “productive” is one of those dangerous business words that sounds more precise than it actually is. We should always finish the sentence: More productive at what?

If AI gives us a tenfold productivity improvement, the interesting question isn’t how we can produce ten times as much. The question is what we want ten times more of. We don’t want ten times the requirements, the user stories, or the features. We want ten times the learning.

When AI makes output cheap, product management is the discipline that decides which output deserves to exist.