Tokens Up, P&L Flat: You Made Execution Cheap. Now Make the Bet Count.

By
Peter Nichol
-

The cost of a build collapsed. The cost of a wrong bet didn’t. The gap between those two numbers is where your AI returns went.

Enterprises are burning through tokens, shipping faster than ever, and still not seeing it in the P&L. The bottleneck moved. Execution used to be the expensive part of delivery, so teams planned carefully before they built. AI made building cheap, and the planning habits built for the old economics collapsed with it. Coordination is now the constraint, and most organizations are skipping it. This is a model for teams that have already made execution fast and want to know where the next gain is.

1. The conclusion that was half right

For forty years, execution was the expensive part of building anything. A real build took months, tied up the scarcest people in the company, and could not be undone cheaply. Every method we use, from PMBOK and stage gates to sprints and backlogs, was designed to protect that build. Then AI collapsed the build from months to days, and teams drew the obvious conclusion: if building is cheap, planning is waste. Skip it and ship.

That conclusion is half right. The wrong half is costing more than anyone is measuring.

Figure 1. The three-state model. Read the second row first. The cost of a build collapsed between State 1 and State 2. The cost of a wrong bet did not, but teams assumed it had. Bar lengths are illustrative.

2. Planning was always doing two jobs

Here is the part nobody separated because nobody had to. Traditional planning did two distinct things at once.

The first job was de-risking the build. How, by whom, in what order, at what cost. This was the loud job. It had the Gantt charts, the estimates, the resource plans, the architecture reviews, and a PMO to run it. When a build cost nine months and twelve engineers, this job earned its keep.

The second job was selecting the bet. What to build, why, what it was worth, and compared to what else. This job was quiet. It rode inside the business case and the prioritization meeting, and it never had its own staff.

When the build got cheap, the first job became unnecessary. Nobody should be estimating and sequencing a two-day build. Dropping it was correct. But the two jobs had always lived in the same meeting and the same document, so when the first went out the door, the second went with it. Teams stopped de-risking the build and, without noticing, stopped choosing what to build.

Figure 2. Planning had two jobs, and teams dropped both. De-risking the build was the loud job and it is now unnecessary. Selecting the bet was the quiet job and it is now larger than it has ever been, because there is so much more to select from.

3. The inference that broke

Lay the old logic out as a syllogism and the error is easy to see.

The old inference

  1. Building is expensive.
  2. Being wrong means a wasted build.
  3. So being wrong is expensive.
  4. So spend heavily on coordination before you build.

Valid when 1 is true. Produced PMI, stage gates, and agile.

The new inference

  1. Building is cheap.
  2. Being wrong means a wasted build.
  3. So being wrong is cheap.
  4. So coordination is waste. Skip it and build.

Step 2 is the error. A wasted build was never the whole cost of being wrong.

The second line was never true. A wasted build was never the whole cost of being wrong. It was simply so large that it hid everything else. The real cost of a wrong bet has three parts: the build you wasted, the product you now own, and the right bet you did not make because your attention went to this one.

AI took the first part to near zero and left the other two alone. Worse, it raised them. Ownership cost scales with the number of products in production, and opportunity cost scales with the number of options competing for the same judgment. When a build costs an afternoon and nothing is choosing between options, the natural behavior is to build every option. Pilots multiply. Each one that reaches users needs an owner, a run budget, a security review, data contracts, and support. The portfolio fills with products nobody chose on purpose.

Figure 3. The two costs came apart. Until 2023 the cost of a build and the cost of a wrong bet tracked each other closely enough to be treated as one number. From 2023 the build line fell and the wrong-bet line did not, and the mix of a wrong bet shifted from build to ownership and opportunity. Values are illustrative, not measured.

That is the financial signature enterprises are reporting. They bought execution speed and got it. What they did not get is the thing speed was supposed to multiply: a well-chosen bet.

4. Price the bet against ownership, not the build

The correct re-run of the logic goes like this. Building is cheap. Being wrong means owning a product that should not exist and missing the one that should. So being wrong is still expensive, and the expense now sits in ownership and opportunity instead of execution. Therefore, spend the time cheap execution gave back on choosing the bet, and use cheap execution inside that choice as evidence.

Coordination does not disappear. It moves from protecting the build to protecting the portfolio. That is the coordination flip.

In practice this means two kinds of build with different rules. Build-to-decide is cheap, plural, time-boxed, and thrown away by rule. It exists to settle a selection argument in two days and never reaches users. Build-to-ship is singular, production-grade, and gated by a work-in-progress limit on ownership, not on building. Every shipped bet carries a named owner, a run budget, a named outcome, and a kill date set before the build starts.

Figure 4. Maximum-value execution. Two kinds of build, with different rules. Build-to-decide is cheap, plural, and thrown away. Build-to-ship is singular, production-grade, and gated by a WIP limit. Everything blue is where the constraint lives now.

Think of the return on any AI initiative as four terms: the probability the bet is right, the value if it is right, the cost to build, and the cost to own. Execution patterns improved exactly one of those, and a team that has mastered reusable patterns has already driven it near the floor. The other three are coordination terms, and they are almost untouched.

Figure 5. Four terms, one of them finished. Cost avoided and hours avoided are the cost-to-build term, and a team that has mastered its patterns has driven it near the floor. The other three terms are coordination terms. Bar fills are illustrative.

5. Six questions before anything ships

This is the whole of the planning that survives. It fits on one page and takes an afternoon.

  1. What number does this move?
  2. What is it worth if it works?
  3. What else did we consider, and why was it rejected?
  4. What will it cost to own for three years?
  5. What would make us kill it, and when?
  6. Who decided, and against what criteria?

A team that can answer all six has done the coordination the old method did, in a tenth of the time, without an estimate or a Gantt chart in sight. A team that cannot will still ship on time. It will just ship something that cannot return what was intended, and then report hours saved on it.

The constraint moved from the build to the judgment. The organizations that see AI in the P&L will be the ones that moved their process with it.