Outcome-based delivery: how it works and when it fits

Most software projects are organised around one of two questions: how much of the team's time are we using, or have we built everything on the list? Both are reasonable questions. Neither tells you whether the business got what it needed.

Outcome-based delivery starts from a third question: what result must this work produce, and how will we know it has? This post explains how that differs in practice, how to choose an outcome that can be measured, and when the model fits.

Three ways to organise the work

It helps to compare the models as ways of working rather than as commercial arrangements.

• Time and materials. The team works through a backlog and the client steers week by week. It is flexible and suits work where nobody can know the scope in advance. The weakness is that progress tends to be described as activity: tickets closed, features shipped, sprints completed.
• Fixed scope. The scope is agreed up front and delivered to a deadline. It suits well-understood work with stable requirements. The weakness is that learning during the project becomes a change request, so the team is pushed to deliver the original list even after it is clear part of it will not help.
• Outcome-based. The result and its measure are agreed up front, and the scope is chosen and re-chosen to move that measure. It suits work where the goal is clear but the route to it is not.

These are not exclusive. A project can run on time and materials and still plan and report against an outcome. The difference is what the team is held to and what everyone looks at when deciding what to do next.

Pick an outcome you can measure

An outcome is a change in the world, not a thing that gets built. "Launch a self-service onboarding flow" is output. "New customers start using the product without a call from support" is an outcome. The flow is one way to get there.

A good outcome for this model has a few properties:

• It matters to the business in its own terms. Someone outside the engineering team would care if it moved.
• It can be measured with data you have or can collect. If the number cannot be produced, the outcome cannot be managed.
• The team can influence it directly. "Revenue grows" is too far from the work; too many other things move it. "Trial users reach their first report" is close enough to steer.
• It has a baseline and a time frame. Record where the measure stands before work starts, and agree when you will judge it.

Write it down in one or two plain sentences, with the measure, its data source and how often it will be read. If that statement takes a page, the outcome is not yet clear enough.

Leading and lagging indicators

The outcome that matters most is often slow to show. Retention, renewals and process times can take months to move, and by then the team has made many decisions without feedback. That is a lagging indicator.

A leading indicator moves earlier and predicts the lagging one. If the goal is better retention, a leading indicator might be the share of new accounts that complete setup in their first week, or how often a core feature is used. The team can see those change within days of a release.

Use both:

• The lagging indicator is the one the outcome is judged on.
• One or two leading indicators guide week-to-week decisions.
• Check from time to time that the leading indicators still predict the lagging one. If setup completion rises and retention does not, the team is optimising the wrong thing.

Guard against measures that are easy to game. If the leading indicator is sign-ups, a louder button will raise it without helping anyone. Pair each measure with a counterweight, such as sign-ups alongside activation, so that improving one at the expense of the other shows up.

How planning changes

In a feature-driven plan, the question for each item is whether it is on the list. In an outcome-driven plan, the question is how directly it moves the measure and how confident we are that it will.

That changes a few habits:

• Work is ordered by expected effect, with the most direct route first. Items that do not connect to the outcome need a separate reason to be there, such as security or maintenance.
• Bets are stated as bets. Each significant piece of work carries a short note: what we expect it to do to the measure and how we will check.
• Small releases come first. The sooner something reaches users, the sooner the indicators say whether it worked.
• Stopping is a normal result. If an approach does not move the measure, the plan changes. That is the model working, not failing.

Engineering quality still matters. A team chasing a number can be tempted to cut corners, so keep the usual standards (tests, reviews, monitoring) outside the negotiation.

How reporting changes

A report under this model leads with the measure: where it stood at the start, where it stands now, and what the team believes caused the change. The list of what was built comes second, as the explanation.

A useful report answers four things:

1. How the lagging and leading indicators have moved since the last report.
2. What was released, and what effect each release appears to have had.
3. What did not work, and what the team is doing instead.
4. What the team plans next and why it expects that to help.

Be honest about attribution. Other things move metrics too: a marketing campaign, a seasonal dip, a competitor's launch. Note them beside the numbers rather than claiming or disowning every change.

When it fits, and when it does not

Outcome-based delivery fits when the goal is clear and measurable but the route is uncertain: improving a conversion flow, cutting the time a process takes, raising adoption of a product. It also fits when stakeholders are tired of hearing about activity and want to talk about results.

It fits less well in some situations:

• When the work is the output. A regulatory change, a platform migration or a contractual integration has to be done whatever the metrics say. Fixed scope is often the honest model.
• When nothing can be measured yet. A product with no users has no baseline. Early work may need to focus on getting to a point where outcomes can be observed.
• When the outcome is too far from the work. If the team cannot influence the measure within the time frame, it will either be demoralised or start gaming the numbers.
• When the client cannot share the data. The model depends on both sides looking at the same numbers.

In our own outcome-based work, the outcome and its measure are agreed in writing before work starts, and the plan changes when the measure says it should.

Where to start

Pick one piece of work where the goal is clear but the route is not. Write the outcome in plain terms, choose one lagging and one or two leading indicators, and record their baseline. Plan the first small release against them and report the next time on the numbers first and the features second.

After a few cycles the conversation changes. Instead of asking whether the team is busy, everyone is asking whether the work is helping, which was the point from the beginning.