Outcomes

What question does this solve?

“Outcome” is an attractive word and an ambiguous one. A working application is a result of development work. Spending less time organizing requests is a benefit expected from using that application. The first can contribute to the second without demonstrating it. A contract that says “outcome” without saying which one invites disappointment on both sides.

Definition and role

An Outcome is the intended result. Software delivery and business effect must be distinguished explicitly.

Every use of the term needs to say which result is under discussion. A feature can be available and meet the agreed criteria while its benefit still depends on how it is used, the surrounding process and other conditions beyond the scope of the delivery. The model therefore keeps three references apart:

Reference	Illustrative example	What has to be clarified
Capacity	A professional’s time over a period	Availability, competences, limits, and how the work is directed
Delivery	An application that registers and tracks requests under the agreed conditions	Expected behaviour, constraints, evaluation and conditions of use
Benefit of use	Less time to resolve requests	Metric, context, observation period, and the factors that influence the effect

A delivery can itself be an intermediate artifact, a usable change, or something in between. What matters is that a proposal lets everyone recognize whether a commitment concerns an intermediate artifact, a usable change, or a benefit observed after adoption.

How it works

Delivery is what a Quality Gate can accept

An accepted delivery is established by a Quality Gate against a Stage Contract. That acceptance settles whether the output met the conditions within the scope evaluated. It does not show that the expected business benefit followed.

Business effect needs its own reference

If a commitment includes a business effect, it needs an additional reference of measurement and attribution: which effect will be observed, over what period, and what conditions make it reasonable to attribute it to the delivery. External changes can make that attribution hard. A mechanism for buying software must not turn a technical delivery into an implicit guarantee of business benefit.

Why it changes the economics

Paying for an accepted feature is not the same as making payment conditional on an observed improvement in the business. The second requires the extra reference above, and a condition based on a poorly observable effect can create disputes instead of alignment. See Pricing.

In the running example

The barbershop’s accepted outcome, in the delivery sense, is booking that works under the defined conditions: 30-minute appointments within registered availability, no overlap for the same professional, cancellation freeing the slot. Fewer missed appointments, or less time spent coordinating by hand, are benefits of use. They depend also on the behaviour of the barbershop’s clients and its own practices, and neither the Quality Gate nor the deployment demonstrates them. If payment were tied to fewer missed appointments, that effect would need its own measurement and attribution.

Boundaries and failure modes

The word does not do the work. Using “outcome” without stating its scope can create undue expectations. Renaming a form of charging “outcome-based” without making these conditions explicit does not change how delivery is consumed.

Discovery can be the outcome. An accepted discovery that leads to a decision not to build can be an adequate result of what was bought, not a failure to reach the “real” outcome.

Connected concepts

• Economics overview
• Previous: Unit Economics
• Next: From hours to outcomes, how this distinction changes what is consumed
• Quality Gate, which accepts a delivery, not a business effect
• Glossary