Business value comes from four places. That's it — and most weak business cases are weak not because the arithmetic is wrong but because they've claimed the wrong one, usually the more impressive-sounding one.
Category | Formula | How defensible |
|---|---|---|
Cost reduction | Recurring saving, annualised | Highest — comes off an invoice, no assumptions |
Revenue enablement | Effect size × baseline × conversion assumption | Medium — depends entirely on a number nobody measured |
Risk reduction | Probability × impact | Lowest — the probability is almost always a guess |
Capacity creation | Hours freed × what those hours will do | Zero unless you name the destination |
Pick the category first, then do the arithmetic. Doing it the other way round is how people end up claiming a revenue benefit for a project that only removes cost.
Cost reduction: just say the number
The easiest and most under-used. A recurring bill goes down, you can point at the invoice, and there is no assumption anywhere in the chain.
Two conversions make it land harder. First, annualise it and say it recurs — a monthly saving stated monthly sounds trivial and stated annually sounds material, and only the annual version is comparable to anything else in the room. Second, convert to gross margin points if you can get revenue, because gross margin is a line the board already watches weekly.
And the multiplier is worth stating explicitly. At a 20% net margin, a saved dollar contributes as much to profit as five earned dollars, because the saving arrives whole while revenue arrives net of the cost of earning it. Show the working, name the margin you used, and let the reader check it. For the operations playbook that sits alongside how to calculate the business value of engineering work, see the XenGrowth practice.
Revenue enablement: the assumption is the case
Here the chain always runs through something nobody has measured. Faster checkout improves conversion — by how much? Better onboarding reduces churn — by how much? The engineering is the easy part; the coefficient is the whole argument.
The move that works is to state the sensitivity instead of picking a number and hoping. At a 1% conversion lift this is worth X; at 0.3% it is worth Y; below 0.15% it does not pay for itself. That tells a reader exactly where the uncertainty is and invites them to substitute their own estimate, which converts a fight about your credibility into a conversation about a coefficient. For the the operations side of this angle, see The XenGrowth resource library.
A proposal that names its own break-even assumption is much harder to dismiss than one that presents a single confident figure, because the first one has already conceded the point the sceptic was going to make.
Better still, where the measurement is cheap, propose measuring first. "Two weeks to instrument this and find out" is a proposal almost nobody refuses, and it converts you from someone asking for belief into someone offering evidence.
A worked revenue case
Concretely: suppose checkout takes eleven seconds and you believe you can get it to three. The business has 40,000 checkout attempts a month and an average order value of $80, so the monthly flow through that funnel step is $3.2m at perfect conversion.
The temptation is to reach for a published figure about latency and conversion and apply it. Resist that, because those figures come from other people's funnels with other people's customers, and the variance between studies is larger than most of the effects they report. What you can do instead is bound the problem. If the change lifts completion by one percentage point, that is $32,000 a month. At a quarter of a point it is $8,000. The work costs six engineer-weeks, so the break-even lift is somewhere near a tenth of a percentage point — and now the question in the room is whether an eight-second improvement plausibly moves completion by a tenth of a point, which is a question a commercial team can actually answer from their own experience.
Notice what that reframing did. It replaced a claim they would have to take on trust with a threshold they can judge, and it moved the burden from your credibility to their domain knowledge. It also gives you an honest exit: if the break-even had come out at three percentage points rather than a tenth, the correct conclusion is that the project does not pay, and being the person who says so is worth more than winning the argument.
One more discipline worth adopting for revenue cases specifically. Write down, before you start, what you will measure afterwards and what result would mean you were wrong. Almost nobody does this, which is why so few organisations have any idea whether their last twenty projects worked. It also protects you: a project that missed its estimate but was measured honestly builds more credibility than three that hit unstated targets.
Risk reduction: state the probability out loud
Expected value: probability times impact. The impact is usually straightforward — an outage during peak has a computable cost in a transaction business, a compliance failure has a stated penalty, a data loss has a recovery cost and a churn consequence.
The probability is where these cases fail, and the failure mode is leaving it implicit because naming a number invites disagreement. Leaving it implicit doesn't avoid the disagreement; it just means the reader supplies their own probability, silently, and theirs is lower than yours. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
So write it down with the reasoning attached. "This component has failed twice in eighteen months" or "this dependency goes end-of-life in eleven months" gives an estimate somebody can argue with and improve. And where a genuine maturity date exists, lead with that instead — a deadline is a far stronger argument than a probability, and one is available more often than people check.
Capacity creation: name where the time goes
The weakest of the four, and the one engineers reach for most often. Freed engineering hours are not value in themselves — the salary is being paid either way. The value is whatever those hours produce instead.
Which means an unnamed destination is not a business case. "This saves the team two days a week" prompts the obvious question of what happens with them, and if the answer is vague the proposal reads as a preference for pleasanter work — which it sometimes is. There is a longer treatment of AI search, GEO and discovery in XenGrowth on AI search, GEO and discovery.
Stripe's survey puts roughly 42% of the developer week on technical debt and bad code, so this pool is genuinely large. But note the two traps. Don't double-count by claiming both the time saved and the work it enables as separate benefits. And note DORA's 2025 finding that rising throughput came with rising delivery instability — capacity created is not automatically capacity well spent, and a proposal that acknowledges this is more persuasive than one that assumes freed hours are pure gain.
Two things every case needs, whichever category it is
The first is the counterfactual. Not what happens if we do this, but what happens if we don't — and specifically, whether the problem gets worse, stays flat, or resolves itself. A cost that grows 30% a year is a very different proposition from one that is stable, and a risk with a fixed end-of-life date behaves differently again. Most proposals describe a future with the work and leave the alternative unstated, which quietly assumes the status quo is stable when it usually isn't.
The second is the cost, stated in the same detail as the benefit. Engineer-weeks, what else those weeks would have gone to, and any ongoing operational burden the change introduces. Proposals routinely give a benefit to two significant figures and describe the cost as 'a few sprints', which signals that only one side of the comparison was taken seriously. It also gives you a payback period, which is the single most useful number you can hand someone: a saving of $180,000 a year for six engineer-weeks of work pays back in a couple of months, and that framing survives a meeting where a bare dollar figure does not.
Claim | Problem | Fix |
|---|---|---|
"This will increase revenue" (for a cost project) | Category error — nothing about demand changed | Claim the saving, and state its revenue equivalent |
"Saves the team 20%" | No destination, so no value created | Name what the reclaimed time delivers, and when |
"Prevents a catastrophic outage" | Unstated probability doing all the work | Give the probability with reasoning, or lead with a real deadline |
"$50k saving" from a one-off cleanup | One-off compared against recurring revenue | Say explicitly that it is one-off, or find the recurring part |
A benefit with no cost attached | Reads as advocacy, not analysis | Engineer-weeks, opportunity cost, and a payback period |
The last row is the one I'd fix first in most proposals. A business case with no cost in it is not a business case, and including the cost — along with what you are not doing in order to do this — is what marks the difference between someone advocating and someone deciding.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If how to calculate the business value of engineering work is part of a growth programme rather than a standalone build, XenGrowth's growth engineering practice is the companion reading.
None of this requires a finance background. It requires picking the right category, showing the assumption, and being willing to conclude that a project you wanted to do does not pay for itself.
Four questions to identify where the value comes from. Most weak business cases are weak because they claim the wrong category, not because the arithmetic is wrong — and the wrong category is usually the more impressive-sounding one.
