Outcomes and roadmaps: 36 questions, answered

Question 1

How do you define a business outcome that can actually be priced?

Accepted Answer

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.

Question 2

How do you baseline a process before setting an improvement target?

Accepted Answer

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.

Question 3

Who should own a business outcome, and what does owning it mean?

Accepted Answer

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.

Question 4

How do you validate that a business outcome actually landed?

Accepted Answer

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.

Question 5

How do you set the horizon for an outcome without over-committing?

Accepted Answer

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.

Question 6

How do you break a priced outcome into epics without losing the number?

Accepted Answer

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.

Question 7

What happens at an approval gate for a priced outcome?

Accepted Answer

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.

Question 8

How do you price an outcome when the benefit is avoided cost rather than revenue?

Accepted Answer

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.

Question 9

What is the difference between an outcome, an epic and a story?

Accepted Answer

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.

Question 10

How do you stop a roadmap filling with work that has no business case?

Accepted Answer

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.

Question 11

How do you price work with no revenue line, like compliance, security or platform?

Accepted Answer

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.

Question 12

How precise does the price need to be?

Accepted Answer

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.

Question 13

Can one epic contribute to two outcomes?

Accepted Answer

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.

Question 14

What happens when the value does not land?

Accepted Answer

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.

Question 15

How long does it take to define and price a business outcome?

Accepted Answer

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.

Question 16

We inherited a roadmap nobody can trace to a number. What do we do first?

Accepted Answer

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.

Question 17

Two epics improve the same conversion rate. How do we price them?

Accepted Answer

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.

Question 18

Can we use an industry benchmark to price an outcome?

Accepted Answer

No. A figure lifted from a vendor deck or an industry benchmark comes out of somebody else's business, so it cannot be reconciled to your reporting, and the first monthly validation becomes an argument about the source instead of the result. A number reverse-engineered from a budget already approved fails the same way, because it was built to justify a spend rather than to describe one. Price it from your own data: baseline volume from the system that records it, margin and lifetime value from finance with whose figures they are, and one visible line of arithmetic. Then flex the two assumptions you trust least by a third each and see whether the target still justifies the quarter.

Question 19

What if an outcome needs longer than a quarter?

Accepted Answer

That is normal and the model expects it. Outcomes span quarters; epics do not. Tenhaw plans its own engagements the same way, retainer-shaped and monthly with an exit date agreed at kickoff. Put the epics that move the outcome this quarter on this roadmap with their share of the value, leave the rest of the target unallocated until the next planning round, and carry the remainder forward. The outcome stays open in Working On or Value Monitoring across both quarters and only closes when every epic under it has closed. What you must not do is write one epic spanning both quarters to avoid the split, because that is the single change that makes the whole portfolio unforecastable.

Question 20

How do I set a calibration factor before I have any history?

Accepted Answer

Plan the first quarter at one to one and write on the roadmap that it is uncalibrated. Then record planned value against realised value for every epic, at each monthly outcome validation and again at the close. After two quarters you have a ratio worth using and after four it is stable enough to plan against. The first honest number is usually lower than the team expected, and that conversation is worth more than the arithmetic it changes.

Question 21

Something urgent lands in week five. What do I do with it?

Accepted Answer

Urgent work takes the same route as everything else. Shape it, price it and commit it as an outcome, or attach it to an existing epic if it belongs under one. Then it has to displace something. Find the epic with the lowest planned value per delivery week, move it to the cut list with its pounds attached, re-run the p85 forecast for the reduced set, and publish both changes together. Tenhaw takes that call as delivery lead inside Programme and Delivery Management, which is bought on its own even where another supplier is building. The failure mode is adding the new work without naming what it pushed out, because by the close nobody can separate under-delivery from a quarter that was quietly reloaded.

Question 22

Do the Tech Debt and Bug Budget epics carry a currency value?

Accepted Answer

No. They carry a share of the person-weeks, not a planned contribution to any outcome target. Their return is avoided rework and avoided incidents, which cannot be attributed honestly at planning time without inventing a number, and inventing one there corrupts the calibration data everywhere else. Count them in capacity, report their burn rate monthly, and never let their absence from the value column become the argument for cutting them, which is the exact argument the two fixtures exist to defeat.

Question 23

How do you calculate team capacity for a quarterly plan?

Accepted Answer

Start from the calendar and subtract before you count anything else. Write down the first and last working day, and thirteen calendar weeks gives you sixty-five working days per person. Then subtract public holidays, booked leave, on-call rotations, mandatory training, any release freeze, and the final week of the quarter, because a plan that runs into its last days has no room to close. Multiply what remains by headcount. Nine and a half delivery weeks across six people is 57 person-weeks, not the 78 the calendar implies, and that gap is where most over-committed quarters begin. Do this before opening the backlog, not after you have promised.

Question 24

How much capacity should go to tech debt and bug fixing each quarter?

Accepted Answer

Open with ten per cent each for tech debt and bug fixing, then correct it with last quarter's actuals rather than intentions, so if bug work burned eighteen per cent of capacity, budget eighteen. Tenhaw won that argument at Greggs with delivery data showing tech debt work accelerated timelines, across two squads over six months. Both live as epics created before any feature epic, each with a named owner and a share of the person-weeks. Every bug and debt item found in the quarter links to one of the two, so nothing floats unbucketed, and by week six the burn rate against each budget tells you whether quality is improving or rotting. Resist raiding them mid-quarter; that reflex is what the two fixtures exist to stop.

Question 25

How many outcomes should one team take on in a quarter?

Accepted Answer

Cap it at three or four live outcomes per team. Past that the epics compete for the same people and the quarter ends with four things at eighty per cent done and nothing validated. The cap also forces the right planning conversation. Only outcomes that have been shaped, priced and committed get roadmap space at all, and ideas still being explored wait. For each outcome you do take on, plan against the remaining target, the headline number minus the value already claimed by epics that closed in earlier quarters, because that remainder is what this quarter's epics actually have to cover.

Question 26

Should I forecast each epic separately or the roadmap as a whole?

Accepted Answer

Forecast the whole roadmap as one set. Size the epics, then simulate the entire quarter against your own throughput, sampling completed items weekly from the last eight to twelve weeks, and take p50 and p85 completion dates for the set. Four individually confident epics all landing in the same fortnight is the failure that kills most plans, and only a whole-set simulation exposes it. Forecast them one at a time, add the dates together, and that collision stays hidden. If your history is shorter than eight weeks or the team has changed size, say the forecast is unreliable and re-run it at the end of week three rather than publishing a number you do not believe.

Question 27

The plan does not fit the quarter. Do we trim scope everywhere or drop an epic?

Accepted Answer

Drop whole epics until the p85 forecast for the remaining set lands inside the quarter. A half-built epic delivers none of its planned value, while a deferred one delivers all of it next quarter, so cutting whole epics keeps the arithmetic honest and shaving scope off everything does not. Choose cuts by planned value per delivery week, protect the Tech Debt and Bug Budget epics from the cutting reflex, and publish the cut list with the pounds each deferred epic carried. That list is the part teams skip, and the part that protects them in month three when someone asks why something is missing.

Question 28

What should a published quarterly roadmap show the business?

Accepted Answer

Publish the roadmap where the business actually reads, not only inside the delivery tool. Tenhaw writes and maintains that published version inside Programme and Delivery Management. Show the outcomes with their currency targets, the epics under each with the planned value and the arithmetic visible, gate status for every epic, and the cut list with the pounds each deferred epic carried. Expect four to six weeks of work gated on day one and the rest still in research; a fully gated roadmap usually means the later epics were written thin. Finish by putting the monthly outcome validation dates and the close date in the calendar with named owners, so the quarter has a booked ending as well as a plan.

Question 29

When should we start planning next quarter, and how long does it take?

Accepted Answer

Start two to three weeks before the quarter begins, and budget about two days of focused work for one pass. Do it only once the outcomes you intend to work on are shaped, priced and committed, because a session that also has to invent the outcomes will produce neither them nor a plan. Three things need to be to hand: the delivery tracker holding the quarter's epics, an export of the last eight to twelve weeks of throughput, and a spreadsheet for the whole-set forecast. Plan again mid-quarter, the moment enough has changed that the published forecast is no longer honest.

Question 30

Who needs to be involved in quarterly roadmap planning?

Accepted Answer

Fewer people than most planning events assume. Product and engineering both have to approve every epic that opens the quarter, so both belong in the room rather than being consulted after it. Tenhaw staffs planning with senior people only, no junior rung, and its founder co-designed HSBC Global Payment Solutions' target operating model with selected teams there. Each epic's value arithmetic needs a named person who owns each input, usually whoever runs the system that number is read from. The Tech Debt and Bug Budget epics each need a named owner, set before any feature epic is written. Every cross-team dependency needs an owner and a date. The monthly outcome validation dates and the close date go in the calendar with names against them.

Question 31

What does a quarterly roadmap look like with the numbers filled in?

Accepted Answer

Take a made-up subscription business with one team of six. Public holidays, booked leave, half a week of training, a year-end freeze and the final week for close cut thirteen calendar weeks to 9.5 delivery weeks, so 57 person-weeks, of which 11.4 go to Tech Debt and Bug Budget. The outcome is reducing involuntary churn against a £900k target, with £150k already claimed by epics that closed, leaving a £750k remainder that at 70 per cent realisation needs about £1.07m of planned epic value behind it. Four priced epics total £910k, so a £160k gap gets named in planning, and the p85 lands three weeks late, which puts the smallest epic on the cut list.

Question 32

What should happen when the quarter closes?

Accepted Answer

The close is booked in the calendar during planning, with an owner against it, and the final week of the quarter is kept clear of planned work so there is room to do it properly. Tenhaw applies the same test monthly, and a month that delivers no measurable value is reported to the client as a failed month. At the close you read realised value against planned for every epic, and that reading is what sets the realisation ratio the next roadmap plans against. Outcomes that are not finished stay open and carry forward the remainder, the target minus the value claimed by epics that have closed. The cut list goes into the next planning session with the pounds each deferred epic carried attached.

Question 33

How much of the quarter should be ready to start on day one?

Accepted Answer

Expect four to six weeks of it gated and the rest still in research. An epic does not open the quarter until it has product approval, engineering approval and the gate content its delivery mode requires, which means the research and design behind those first epics happened in the previous quarter. A fully gated roadmap is not the sign of a well-prepared team. It usually means the later epics were written thin, because nobody can honestly specify week eleven's work two weeks before the quarter opens. Gate the front, keep the research running behind it, and gate the rest as it becomes real.

Question 34

How do we tell by week six whether the quarter is off track?

Accepted Answer

Three readings, none of which needs a new report. Tenhaw built that reporting at Globelynx across 16 client deliveries, where lead times fell 60 per cent inside six months. Re-run the whole-set forecast at the end of week three, especially if the throughput history you planned from was short or the team changed size, then compare that p85 date with the one you published. Read the burn rate against the Tech Debt and Bug Budget epics, which is the only quality trend you get without building anything, and which shows whether those budgets are quietly being raided for feature work. And one monthly outcome validation will have run by then, so you hold a real reading of realised against planned rather than a status colour.

Question 35

Can we give the business a twelve-month roadmap?

Accepted Answer

You can show a year of intent, but only the current quarter gets dated epics. Tenhaw's own engagements run monthly on the same footing, stopping on 30 days' notice either side rather than a twelve-month commitment. Outcomes span quarters and carry a currency target; an epic never spans one, and an epic with no single quarter to ship in makes a whole portfolio unforecastable. Beyond the quarter, publish the outcomes with the remainder still to cover, the target minus the value already claimed by epics that closed, alongside the cut list and the pounds each deferred epic carried. That is honest and useful. Dated epics twelve months out are neither, because the forecast behind them samples throughput the team has not generated yet.

Question 36

Does quarterly planning work differently on an AI-native team?

Accepted Answer

Less than people expect. The capacity count, the value arithmetic and the p85 forecast are identical whether a team is AI-augmented or AI-native. Two things change. Gating is the first. An AI-native epic needs product and engineering approval with the key user journeys and the test requirements written on the ticket, in place of the product-approved child story an AI-augmented epic carries, so the research behind those journeys happens in the previous quarter. The second is forecasting. AI-native throughput moves fast enough that twelve weeks of history can flatter or punish you, so use the shortest window covering at least eight completed items and re-run at the end of week three. Tenhaw's own AI-native work runs against an open-source handbook of 72 rules, enforced by an agent rather than remembered.

How to define and price a business outcome