Output, Outcome and Value

Sixty percent more proposals. Four percent more value.

Both numbers describe the same sales team in the same quarter, after the same AI rollout. The first is what the dashboard showed. The second is what the company actually got. The gap between them is plain arithmetic, and almost every AI business case gets it wrong in the same way.

Here is the mistake in one sentence. When AI makes a unit of work cheaper, a team produces more units, and the extra ones are the units that weren't worth producing before. Counting output values every unit at the average, so it overstates the gain, sometimes by more than ten times. Between the work produced and the value received, every step loses something, and the reports that stop at the first step assume those losses are zero.

Three levels

It helps to name the three things people blur together.

Output is what the work produces: drafts, proposals, pull requests, tickets closed. An outcome is a change someone can see because of it: a deal won, a feature in use, a customer whose problem stayed solved. Value is what that change is worth to someone, after subtracting what it cost and what it pushed aside.

The vocabulary comes from program evaluation, where funders learned long ago that counting classes taught says little about whether a job-training program got anyone a job. AI work needs the same discipline, because AI lowers the cost of output more than anything else, and output is what its dashboards count by default.

Scroll sideways to see the whole figure

The important column in that figure is who controls each level. Output is controlled by the team and the tool: if an account executive drafts a proposal in an hour and a half instead of four, the proposals exist and can be counted by Friday. Outcomes depend on the rest of the system: whether there were buyers, whether legal approved the terms in time, whether the pricing desk kept up. Value depends on people outside the team entirely: what customers want, what competitors do, what the organization gave up. The further down the chain, the less the team controls and the longer the signal takes.

That's why reports stop at output. It's free (the tool's telemetry produces it), fast, clearly caused by the tool, and owned by whoever runs the program. Every one of those reasons is sensible. The trouble starts when "60 percent more proposals" becomes "a 60 percent productivity gain" in the next meeting and a dollar figure in the budget after that.

The extra units are the cheap ones

Here is the mechanism, and it's the part most business cases miss.

A team that was already choosing sensibly spends its limited time on the work most worth doing. It sends proposals to the prospects most likely to buy, and skips the ones that rarely do. Now AI cuts the cost of a proposal. The team keeps sending what it sent before, and adds the proposals that weren't worth the effort at the old cost.

Those added units are, almost by definition, the ones whose value was below the old cost. Economists distinguish the average value of all units from the marginal value of the next one, and the difference is the whole story here. An output metric prices every unit at the average. The units AI adds are the marginal ones.

An output metric prices every unit at the average. The units AI adds are the marginal ones.

One sales team, followed all the way down

Take a business-software company with 20 account executives. The numbers are illustrative, chosen to be round. In a typical quarter the team sends 500 proposals and wins 20 percent of them: 100 deals at an average of $50,000, or $5 million of new revenue. The same people manage existing accounts, which bring $1 million of expansion revenue a quarter. At a 60 percent gross margin, the team's work produces $3.6 million of gross profit.

The company deploys an AI assistant that drafts proposals and answers the technical questionnaires attached to them. Next quarter the team sends 800 proposals, 60 percent more. A business case that assumed deals grow with proposals books 60 more deals, worth $1.8 million of gross profit.

About $144,000, or 8 percent of the claim. Net value rises 4 percent. Here's where the rest went.

Scroll sideways to see the whole figure

From proposals to live decisions. Of the 300 extra proposals, 100 are second and third versions sent to prospects already evaluating the company: a revised scope, a version for another stakeholder. When drafting is cheap, revising is cheap, and every revision counts as a proposal without creating a new chance to win. The other 200 go to prospects the team used to skip.

From decisions to deals. The 500 core proposals keep winning at 20 percent. The 200 new ones win at 5 percent, because they went to companies that are a poor fit, have no budget this year, or wanted a quote to keep their current supplier honest. Ten new deals. Output rose 60 percent, decisions 40 percent, deals 10 percent. Cheaper proposals didn't create more buyers. They reached further down a list the team had already ranked.

From deals to gross profit. The new customers are smaller and needed discounts, so the ten deals average $40,000. Gross profit rises from $3.6 million to $3.84 million, or 6.7 percent.

From gross profit to net value. Three subtractions bring it to 4 percent. Eight of the new deals were sold on commitments the AI-drafted proposals described more generously than delivery could support, and fixing the scope cost $5,000 each, paid by the delivery team and invisible on the sales dashboard. The hours spent qualifying and pricing 200 more prospects came out of account management, and expansion revenue fell by $80,000. The tool and its administration cost $8,000.

Put it per proposal. Before the tool, an average proposal was worth 0.2 deals and $6,000 of gross profit. Each extra proposal was worth a thirtieth of a deal and $800, or $480 after the losses. Valuing those extra 300 at the old average is what turned $144,000 into $1.8 million.

And notice how fragile the result is. If the low-fit prospects had converted at 10 percent instead of 5, net value would have risen almost 10 percent. At zero, it would have fallen about 1.6 percent, because the displaced work and the tool cost stay with no new deals to pay for them. The conversion rate of the marginal unit decides the sign of the result, and no AI dashboard reports it.

Four leaks

The example contains the four losses that recur in every function.

Waiting. Output that reaches a step without spare capacity sits there: more pull requests for the same reviewers, more memos for the same monthly committee (Where the Saved Time Goes).

Missing demand. Some output only becomes an outcome if someone on the other side wants it. More proposals need more buyers. And if every vendor in a market sends 60 percent more proposals, buyers read each one less carefully and win rates fall for everyone, which each company will blame on bad luck.

Rework. Output that looks finished and isn't moves its cost to whoever receives it. Researchers named the AI version workslop. In the example it's the scope fixes, paid from another department's budget.

Displacement. Every hour has an opportunity cost, the value of what the person would otherwise have done. Time spent producing more output wasn't spent on account management, mentoring or the second look at a risky contract, and that work usually goes unmeasured.

A fifth loss comes after value exists: competitors adopt the same tools and prices fall, and vendors price toward the savings they enable. Even a correct value figure overstates what the company keeps (Who Receives the Gain?).

Why the people doing the work can't see it

The obvious reply is that people using the tool would notice if their extra output wasn't becoming results. Often they don't, because output is what they see and outcomes happen elsewhere, later.

The cleanest demonstration is a 2025 randomized trial by METR, a research group that measures AI capabilities. Sixteen experienced open-source developers worked on real issues in projects they knew well, with AI tools allowed on some tasks and not others. They expected AI to make them 24 percent faster, and afterward believed it had made them about 20 percent faster. Measured, they took 19 percent longer. They experienced output: code appearing quickly on screen. The trial measured something closer to an outcome: time to a change ready for review. The two pointed in opposite directions. It was one setting, with early-2025 tools and experts in familiar code, and later tools may well do better. But the lesson about measurement holds.

The person producing the output is the one least placed to see whether it became an outcome.

Team-level data shows the same split. Google's 2024 DORA survey of software teams found AI adoption associated with better documentation, code quality and review speed, measures close to output, while delivery stability, a measure of what reaches production and stays there, got worse. In 2025, telemetry from more than 10,000 developers, collected by the engineering-analytics firm Faros AI, showed high-adoption teams merging 98 percent more pull requests, with no significant link between adoption and improvement at the company level.

Count each benefit once

Hours saved is the most common way to express AI value, and it's usually an intermediate. Time becomes value only when it's redeployed: fewer hours bought, more work someone pays for, a faster answer that keeps a customer.

The sales team's business case listed the drafting time saved, 1,250 hours a quarter worth $93,750, next to the extra gross profit. But those hours were the input that produced the extra proposals. Adding both counts the quarter's work twice. Three rules prevent this. Count each benefit at the last level where it can be measured. Treat a mechanism and its result as one line: faster response and higher retention are often the same value seen twice, so report retention and give response time as the reason. And price a risk reduction at its expected cost, only for the part the AI actually removes.

When counting output is fine

Output is a fair stand-in for value under two conditions: the steps downstream have room for the extra units, and the extra units are worth about as much as the average ones. Both hold for a backlog of committed demand, such as insurance claims already filed and owed a decision, or documents already scheduled for translation. There, more units per week is the outcome.

Everywhere else, the honest objection deserves its weight. Output metrics are fast, cheap and under the team's control, and manufacturing ran for a century on units per shift. True, and it names the condition: a proxy works while the ratio connecting it to the result stays stable. Factories could trust units per shift because orders and prices fixed what each unit was worth. An AI tool is a shock to exactly that ratio. It lowers the cost of a unit, so the mix shifts toward marginal units. It changes how the unit is made, so quality can drift. It pushes more volume downstream, so waiting changes. The proxy is least reliable precisely when an AI program is being evaluated, because the program is what's changing the ratio.

What I'd do

Measure the joint, for the extra units. Outcomes per unit of output, value per outcome, and which activities fell, sampled monthly. It's the number programs skip, and it carries the most information. In the example, following thirty extra proposals to their result would have shown the 5 percent win rate within a quarter.

Manage by output inside the team, report value outside it. Fast feedback matters for the people doing the work. The budget needs value, with the ratios that connect the two, measured against a baseline recorded before rollout and ideally a comparison group (Measuring AI Impact Without Fooling Yourself).

Write the business case backward. Start from value and ask what must be true upstream. Who wants what, in their own terms? What is the next outcome worth, not the average one? What constrains it today: qualified buyers, legal review, pricing approval? Size the tool against that constraint, and name what will be displaced and who absorbs the errors.

Run backward, the sales case looks different. Qualified buyers limited wins, a ceiling visible before any proposal was drafted. And one percentage point of win rate on the 500 core proposals is worth five deals and $150,000 of gross profit, more than the entire net gain from 300 extra proposals. An assistant that makes each proposal better, tailored to the buyer and quicker on the technical questions that stall deals, may create more value than one that makes proposals more numerous. Whether it does is an empirical question. The backward case is what turns it into one.

Start from what someone will pay for, and size the tool against the constraint in front of it.

Check yourself

Why does counting output overstate the gain from AI?

The units AI adds are the marginal ones, the work that wasn't worth doing at the old cost. An output metric values them at the average of all units.

In the sales example, why did 300 extra proposals produce only ten new deals?

A third were revisions to prospects already evaluating, and the rest went to poor-fit prospects who won at 5 percent. Cheaper proposals reached further down a list the team had already ranked.

Why is the person using the tool the worst placed to see the shortfall?

They see output appearing on screen, while outcomes happen elsewhere and later. The METR developers expected to be faster and felt it, yet took 19 percent longer.