Why AI Improves Everything Except Your P&L

TL;DR

Apply AI to a part of your business that was never limiting your results and that part really does improve. Nobody is lying about the productivity. But your costs go up and your sales don’t, because a business can only produce as much as its narrowest step allows. That’s the mechanism behind the 95% of companies reporting no measurable P&L impact from AI. Here’s what a constraint is, why almost nobody’s AI investment is aimed at one, and a test you can run in a minute.

---

A company rolls out AI coding tools to its engineers. Six months later the team is measurably faster. Tickets close quicker, the release notes are longer, and everyone involved can feel the difference. It’s real. Then the year closes and revenue is flat while the software budget is up.

I’ve now heard that story told many times, in one form or another, by people running very different businesses. What strikes me is that the people describing it, including some who are extremely well informed about AI, describe it as a puzzle. The usual explanations are that the productivity gains must have been an illusion, or that the technology needs more time.

It isn’t a puzzle, and more time won’t help. Only correcting the mistake will. The mistake has a name, it’s about forty years old, and it has almost nothing to do with AI.

What a constraint is

A business is a series of steps that turn effort into money. You find prospects, you win the work, you do the work, you deliver it, you get paid. The steps never have equal capacity. One of them can handle less than all the others, and everything you sell has to pass through it, so that step sets the pace of the whole business no matter how fast anything else runs. It’s called the constraint, sometimes the bottleneck. Every other step is a non-constraint, and by definition every non-constraint has spare capacity.

Think of a four-lane highway that narrows to one lane for a mile. Traffic through that mile determines when everybody gets home. Widening the other three lanes doesn’t get a single car home sooner, and it might even make the backup worse.

The constraint can be almost anything, and where it sits changes what you should do about it:

• A resource inside the business. One machine, one licensed specialist, one senior person who has to review or approve everything. Work piles up in front of them and everything downstream waits.
• The market itself. There aren’t enough orders. Your people and equipment could handle more work than is coming in, so demand is what limits you. This is extremely common in small businesses and it’s the case most owners are least willing to name out loud.
• A policy. A rule about how work gets released, a pricing decision, an approval nobody questions, a segment you decided years ago you don’t serve. No machine is limiting you; a decision is.

That’s the whole idea. What’s difficult, and I’ll come back to this, is knowing which one is yours.

The accounting

The man who worked all this out was Eliyahu Goldratt,¹ and the most readable account is his 1984 business novel The Goal.² His method rests on three measurements with ordinary-sounding names and unusual definitions. The definitions are the entire point, so read them slowly.

• Throughput (T) is the rate at which the business generates money through sales. Note those last two words. Finished work you haven’t sold is not Throughput. Neither is code shipped, tickets closed, documents drafted, or units produced. If nobody paid you, T did not move.
• Inventory or Investment (I) is all the money tied up in things the business owns and intends to turn into sales. Equipment, materials, work in progress.
• Operating Expense (OE) is all the money the business pays out to turn I into T. Salaries, rent, software subscriptions, electricity.

Everyday language collapses all three into “revenue” and “costs.” When someone says a change improved throughput, they usually mean the work moved faster. Goldratt’s T doesn’t move until a customer pays. The gap between those two meanings is where a great deal of money goes missing.

Net profit is T minus OE. Every improvement a business makes has to show up in one of the three measurements or it didn’t happen, whatever else it did to your dashboards.

Now run an AI deployment through it. OE goes up on day one: subscriptions, tokens, integration work, and the hours your people redirect into learning the tools. That part is certain and it arrives on schedule. T goes up only if the thing you improved was limiting sales. If it wasn’t, T doesn’t move at all, and T minus OE is now a smaller number than before you started.

The result is predictable.

Capacity is not throughput

There’s a line in The Goal I’ve been quoting to clients for years. An hour lost at a bottleneck is an hour lost for the entire system. An hour saved at a non-bottleneck is a mirage.

What AI reliably buys today is capacity. More work per hour at whatever step you point it at. Capacity turns into Throughput at the constraint and nowhere else. Everywhere else it accumulates as spare capacity added to a step that already had spare capacity.

Here’s the part that gets skipped. When you apply AI to a non-constraint, you improve that step in isolation, and in isolation it genuinely is better. Faster, cheaper, more consistent. Measure it on its own and the result holds up. But no step of a business is used in isolation. It’s used as part of a system, and a system’s output is set by its constraint, not by the average condition of its parts. Goldratt said it as plainly as it can be said: the sum of the local optima is not the optimum of the system.

So you can improve every part of a business and improve the business not at all. That’s arithmetic. Flow through the constraint didn’t change, so nothing sold that wasn’t already going to sell.

That’s the forty-year-old mistake from the opening, and its name is local optimization: improving the parts and expecting the system to follow.

If your engineering team isn’t the reason you can’t sell more today, making it 30% faster produces more of something that wasn’t scarce. That’s not an argument against improving your product. A better product may well drive sales next year. It’s an argument about which changes move money now, and about how genuinely hard it is to tell those two kinds of change apart.

The engineers aren’t wrong to be pleased, either. They improved what they were asked to improve and they’re measured on it. Goldratt saw this one coming too: “Tell me how you measure me, and I will tell you how I will behave.”³ AI has made acting on the wrong measurement cheaper and faster than ever before.

Why nearly everyone lands on a non-constraint

Most businesses don’t know where their constraint is. This is the big one, and it isn’t a failure of intelligence. Nobody sits down on a Tuesday and identifies their constraint, because nothing in ordinary business life prompts the question. You can’t aim at a target you haven’t named, so AI adoption gets decided department by department, by whoever is enthusiastic, which will find the constraint only by luck.

Most businesses also underestimate how much it matters. If you think of the constraint as one problem among many, you’ll fix it eventually, in turn, alongside everything else. But it isn’t one problem among many. It’s the only place where improvement converts into money. Getting the priority wrong is as costly as getting the location wrong.

AI is best at the work that’s easiest to see. Writing, coding, summarizing, drafting, transcribing, answering. These are visible activities with obvious before-and-after. Constraints are frequently somewhere less photogenic: one overloaded person, a decision sitting in a queue, a market that doesn’t understand what you sell. The tools get pointed where the demonstrations are.

Improvements you can watch are more satisfying than improvements you can bank. Something that took a day now takes an hour, and you can see it happen. That feeling is honest, and it’s a poor guide to where money is made.

The evidence

MIT’s NANDA lab published The GenAI Divide: State of AI in Business 2025, which found that 95% of organizations are getting zero measurable P&L impact from generative AI. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs and unclear business value. Goldman Sachs published a research note titled, without irony, “Gen AI: Too Much Spend, Too Little Benefit?” Menlo Ventures counted $37 billion in enterprise AI investment in 2025, triple the year before.

Look at what those surveys measure. They check the T side and ask whether it moved. The OE side was never in doubt; it moved the day the invoices started. So “no measurable P&L impact” is the charitable reading. If the accounting above is right, then for most of that 95% net profit went down, by something like the size of the AI budget.

One honest exception. If AI spend replaces other operating expense, OE can fall even when T stays flat, and that’s a legitimate win. I’ve had several of those myself, including replacing a stack of SaaS subscriptions with tools I built. It’s a real result, it’s a much smaller prize than the one most of that $37 billion was chasing, and it isn’t what went in the business case.

The clearest example I can give you is my own

I can’t open another company’s books, so here are mine.

My last contract ended in January 2025 and I went full-time on AI. The productivity was real: I’ve been writing software for over thirty years and I built faster in the following eighteen months than in any comparable stretch of my career. I replaced our accounting stack, did my own taxes with a coding agent, and shipped tools I wouldn’t have attempted alone. I stand by what I wrote at the time, that at 66 I’m more capable than I was five years ago because these tools multiply experience and judgment.

Here’s the accounting anyway. My OE went up by $400 to $600 a month, every month, starting immediately. My T stayed flat. My constraint was demand, and every hour of new capacity I bought went into production instead. I got very fast at producing software for customers I did not have.

And the subscriptions are the small number. The large one is eighteen months of contracting income I didn’t earn while I was busy being productive. That’s the true cost of aiming at a non-constraint: not what you pay for the capacity, but what the constraint doesn’t produce while you’re improving something else.

I’ve been Jonah-certified⁴ since I trained under Goldratt, and I still had to watch this happen in my own numbers before I named it. That’s the part I’d ask you to take seriously. Knowing the rule doesn’t protect you, because the pull toward the visible improvement is stronger than the rule.

What aiming at the constraint looks like

The useful question isn’t whether to use AI. It’s what your constraint is, and then what AI can do about that specific thing. The answers get concrete fast.

If the constraint is a physical resource, the goal is to keep it loaded and never idle. In a cath lab that sits dark three-quarters of the week, the AI that matters is whatever fills the schedule and shortens turnaround between cases, not whatever drafts the department’s emails. Same logic in a print shop where the graphic artist was doing every job twice: AI at the pre-flight step raises the constraint’s output. AI at the press does nothing, because the press was never the problem.

If the constraint is a decision queue, and it often is, the target is the time between “we have the information” and “we made the call.” AI that turns a pile of inputs into something decision-ready moves T. AI that produces more beautiful analysis to sit in the same queue moves OE.

If the constraint is demand, which is where a lot of small businesses actually live, then code generation is beside the point no matter how good it gets. The work is finding and articulating a problem someone will pay to have solved, and saying it in language your market recognizes. AI can help with that. It’s just not what most people are pointing it at.

The general rule is Goldratt’s. Raise the constraint’s output, or protect it from sitting idle.⁵ Everything else is optional, and most AI budgets today are funding the optional part.

Finding it is the hard part

I’d like to tell you that naming your constraint is a Tuesday afternoon exercise. In practice most businesses get it wrong on the first several tries, for reasons that are structural rather than careless.

People point at the loudest pain, and the loudest pain is usually downstream of the constraint rather than at it. The team drowning in rework is often drowning because something upstream feeds it badly. The team that looks idle is often being starved by the actual bottleneck. Both are symptoms, and both are more visible than the cause.

Local measurements hide it too. When every department is hitting its own numbers and the business still isn’t growing, the measurements are working exactly as designed and telling you nothing about the system.

And when the constraint is a policy, it’s close to invisible from the inside, because policies feel like facts about the world rather than choices somebody made.

The harder problem: knowing whether a change will help

Finding the constraint answers today’s question. The harder problem shows up every week afterward, when somebody proposes a change and you have to decide whether to make it.

Nearly every proposal is local. Buy this tool, restructure that team, adopt this AI, automate that step. Each arrives with a local benefit that is usually genuine. The only question that matters is what it does to flow through the constraint, and there are three possible answers:

• It increases flow through the constraint. Do it.
• It does nothing to flow through the constraint. Optional at best, and it costs OE.
• It reduces flow through the constraint. This is the one nobody expects.

That third case is real, and it’s the oldest failure mode in the book. Half of The Goal is about it. Speed up a step that feeds the constraint and you can flood it with work in the wrong order, or in batches too large, or with defects that the constraint then has to put its scarce hours into fixing. An AI-accelerated engineering team shipping more features can quietly consume more of the one senior reviewer who was the actual constraint, and output goes down. Everybody involved did something locally sensible.

Predicting which of the three you’re looking at is genuinely difficult. The information you’d need is spread across departments that each measure themselves locally, and the effect you’re predicting is a system effect that none of those local measurements can see. Without a method for answering it, you’re guessing, and the odds are poor.

That’s the part I’d sell you if you asked: not the one-time finding, but a repeatable way to answer “should we do this?” before the money is committed.

The test

Until then, here’s one you can run yourself in a minute. If you doubled your AI budget tomorrow, which line moves: T or OE?

OE moves the day you swipe the card. T moves only if what you improved was the constraint, or if the improvement takes more out of OE elsewhere than it adds. If you can’t say which step in your business is the constraint, that’s your finding, and it’s the first thing to fix.

Where I could be wrong

Lag. “Give it time” is the standard defense of these numbers, and it deserves less weight than it first appears to. The constraint is the one place where improvement converts into money immediately; aim an effective effort there and results tend to show up in weeks, not quarters. A long delay is itself evidence the effort landed somewhere else. I’ll grant that a large enterprise rolls anything out slowly, so some real effects are still in the pipe. Not many, on this argument.

Constraints relocate. Break one and it moves. Some companies did aim well, and their constraint is now downstream, often in the human review of AI output. My claim is a snapshot of where most businesses are today, not a law.

Some businesses genuinely are capacity-constrained. A shop with a full pipeline where delivery is the limit is a different case. There, buying capacity is buying Throughput, and this argument doesn’t apply. I’d still ask how full that pipeline looks a year out.

Diffuse gains are hard to measure and still real. Suppose AI takes an hour a week off forty people, none of them the constraint. The surveys will find nothing, yet something did change, and what it’s worth depends on the payroll. If those are hourly workers, OE falls a little, and that’s the exception named above. If they’re salaried, nothing changes until the freed time becomes something: capacity nobody needed, or, eventually, one hire you don’t make. Real, small, slow, and invisible to a survey. I hold this one loosely.

And I should be precise about what I’ve seen myself. The constraint work is thirty years of my career and the case studies I’ve linked here are real. The AI-specific claim in this post is different: it comes from the published data, from many conversations, and from one set of books I can open completely, which are my own. I haven’t yet sat inside a company and watched an AI budget miss its constraint in real time.

So if you have the story I don’t, from either side of it, tell me. The AI budget that missed its constraint, or the one that hit it and moved the P&L. That second case is the one worth studying, and I’d rather learn where the boundary is than defend the claim.

Writing this clarified what I should be doing with my own time. Finding where a business is actually constrained, and then working out what AI can and can’t do about that specific thing, is the work I’m best equipped for and it’s what I’m now doing deliberately. If you’re not sure which line your AI budget is moving, that’s usually a short conversation and a useful one either way. Reach me at john@common-sense.com.

Notes

Sources

• The GenAI Divide: State of AI in Business 2025 (MIT NANDA)
• Fortune: MIT report: 95% of generative AI pilots at companies are failing
• Gartner: Over 40% of Agentic AI Projects Will Be Canceled by End of 2027
• Goldman Sachs: Gen AI: Too Much Spend, Too Little Benefit?
• Menlo Ventures: 2025 The State of Generative AI in the Enterprise
• Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement

Footnotes

1. Eliyahu M. Goldratt (1947–2011) was an Israeli physicist who turned to manufacturing and management, and developed the Theory of Constraints: the idea that every system has one limiting factor at a time, and that improving anything else produces no gain for the system as a whole. ↩

2. The Goal: A Process of Ongoing Improvement (Goldratt and Jeff Cox, 1984) is a novel about a plant manager with three months to save his factory. It has sold millions of copies and is still assigned in MBA and operations programs forty years later. It is the most readable introduction to all of this, and no background is required. ↩

3. A line Goldratt used for decades in lectures and workshops, usually quoted as “Tell me how you measure me, and I will tell you how I will behave. If you measure me in an illogical way, do not complain about illogical behavior.” ↩

4. “Jonah” is the name of the mentor character in The Goal, and it became the name of Goldratt’s certification for practitioners trained to apply the method. I trained under Goldratt directly. ↩

5. In the full method these are two of the five focusing steps: identify the constraint, exploit it (get everything you can from what you already have), subordinate everything else to that decision, elevate it (add capacity), and then repeat, being careful not to let inertia become the new constraint. ↩