How to define and price a business outcome

Write the business result rather than the feature, then attach a number to it in one line of checkable arithmetic. Volume times unit cost, or volume times conversion times margin. If you cannot write that line, you do not have an outcome yet, you have an intention. Tenhaw publishes the whole method for doing this, worked examples and arithmetic included, free for a team to adopt without hiring anyone. The test is whether someone outside the team could recompute your figure from published or internal numbers and land in the same place.

Measure it as it runs today, not as it is documented. Volume, elapsed time, people involved, and rework. Pull it from the system that already records it rather than from an estimate in a workshop, and pull it before you name a target, because a target set before a baseline is a number chosen to sound achievable. The baseline is also what makes the eventual claim of improvement checkable.

One named person in the business, not the delivery team, and owning it means carrying the number in their own plan. If the outcome is a cost reduction, the owner is whoever holds that cost line and will show it falling. If nobody will put their name against the figure, the value was never believed in the first place, and that is the most useful signal the exercise produces.

Write the query before you commit, not after you ship. Decide now what you will run in six months, against which system, and what result would count as the outcome having landed. Running it is then arithmetic rather than argument. Writing it up front also tends to expose outcomes that cannot be measured at all, which is cheaper to discover before the work than after it. Tenhaw's Globelynx write-up reports delivery lead times falling 60% within six months, a figure that is quotable only because comparable delivery data existed before any improvement was claimed.

Pick the point at which the result would be visible in the business, then plan headroom inside it rather than filling it. An outcome with no horizon never closes, and one with a horizon packed to the edge closes by being quietly redefined. The horizon also forces the split into epics, and if those epics do not sum to the number, the outcome is not funded, whatever the plan says.

Split it so every epic carries a share of the figure, then add them up and check the sum against the outcome. Anything that cannot be given a share is not part of this outcome and belongs somewhere else. That check is the whole point of the split, because it is the moment you find out whether the plan actually delivers the number, or whether it delivers most of it and hopes.

Someone commits to the number or the outcome does not start. The gate is where the owner accepts the figure into their plan, the arithmetic is checked in the open, and the validation query is agreed. Closing works the same way, on a stated reason. Either the query returned the result or it did not, and both are recorded. Outcomes that drift without either are how a roadmap fills with work nobody can defend.

The same arithmetic, on the cost base instead of the revenue line. Volume of the thing you no longer do, times what it costs to do it once. That volume and unit cost have to survive the real exceptions first, which is what a proof of concept is for. Tenhaw built one in two weeks inside a London specialty insurance business, PDFs in and business intelligence out on Azure, over ground the firm had circled for roughly a year. Avoided cost is harder to defend than revenue because nobody sees it arrive, which is why the baseline and the validation query matter more here rather than less. The query has to show the cost line actually falling, not that the process changed.

An outcome is a business result with a price and an owner. An epic is a share of that price with a delivery team behind it. A story is a piece of an epic. Nothing exists that does not trace up to a priced outcome, which is what stops a roadmap filling with work that is justified by the fact somebody asked for it.

Make the trace mandatory in both directions. Every epic points up to an outcome with a number and an owner, and every outcome divides down into epics whose shares add up to it. Tenhaw runs its own engagements on that rule, with a value target on every month and a month that delivers none reported to the client as a failed month rather than absorbed into the plan. Work that cannot make the trip in either direction does not get planned. It is a mechanical test rather than a judgement call, which is what makes it survive contact with a busy quarter.

Price the loss you are avoiding, not the feeling of safety. Regulatory work carries an exposure, a remediation cost and a probability of landing inside the horizon. £4m of exposure at a 30% chance is £1.2m, and legal or finance owns both of those inputs, not you. Platform work is priced through what it unblocks. If a migration is the precondition for £900k of epics that cannot start without it, that is the number, and it validates when those epics validate. What does not work is pricing effort, or pricing away a problem you were never going to have. Tenhaw prices its own platform and guardrail work that way, against a public engineering standard of 72 rules with RFC 2119 severities.

Precise enough that two competent people re-running the arithmetic land within about 20% of each other, and no more precise than that. The number earns its place by forcing assumptions into the open and letting you compare one outcome against another, not by predicting the P&L to the pound. If flexing a single assumption moves the answer by an order of magnitude, that assumption is the real work, so go and reduce the uncertainty before committing rather than averaging it away and hoping.

No. An epic links to exactly one outcome. The moment its value is split across two, neither outcome's arithmetic can be checked and neither owner can be held to a number. If an epic serves two outcomes, decide which one it primarily belongs to, price its full share there, and note the second-order benefit on the other without booking currency against it. If that decision feels impossible, the two outcomes are probably one outcome that has been split for organisational reasons.

Close the outcome as accepted as not realised, with the validation figures attached and a note on which assumption broke: the baseline was wrong, the movement was smaller than expected, or the value per unit did not hold. Tenhaw ends engagements on the same principle, with an exit date agreed at kickoff and 30 days' notice either side. That closure is worth more than a quiet success, because it recalibrates the realisation ratio you use to size headroom on the next outcome. The failure mode to avoid is closing it as unvalidated. That teaches nothing and slowly inflates your calibration until the forecasts stop meaning anything.

About six hours of working time, spread across a few sittings rather than one workshop. Elapsed time is longer on purpose, since you re-run the baseline query a week later and a different number means you had a screenshot rather than a baseline. The sittings are short because each needs different people. Whoever owns the report sits with you for the baseline, finance supplies the margin and lifetime value figures, and the named business owner confirms they will carry the number in their own plan for the year. Tenhaw is founder-led and James Rooney leads every engagement personally, so he sits in those conversations himself. Where no baseline exists at all, instrumenting it becomes the first epic and the outcome waits in Exploring.

Reconstruct the outcome behind the work already in flight, one item at a time, because that is the fastest way to find out what should be cancelled. For each item, write the business result it should produce, then strike out every technology, vendor and screen name and see whether the sentence still means anything. If it does not, somebody priced a solution rather than a result. Then pull the baseline it claims to move and price it in one line of arithmetic. Anything that cannot reach a priced result with a named owner is a candidate to stop, and planning is a cheaper place to stop it than week eleven. Tenhaw starts inherited roadmaps with that reconstruction before proposing new work.

In landing order, with each epic priced on what the one before leaves behind. Two epics both claiming the same lift on the same traffic total £400k on paper and deliver £200k, and adding up the shares will not catch it, because the arithmetic sums perfectly. In the worked checkout example the three epics, guest checkout at £620k, payment failure retry at £510k and address autocomplete at £340k, all move one conversion number, so each carries only the movement it adds on top of its predecessor. Fix the order during planning, because the second epic's share depends on which one lands first.