Outcome over Output
Measuring and committing to changes in user or business behaviour rather than to the delivery of features.
Output is what is built. Outcome is what changes as a result. A roadmap of features is a list of outputs, and it can be delivered in full while nothing improves.
The shift is in what is committed to. "Ship the new checkout flow in Q3" is an output commitment: it can be met by shipping something that does not work. "Increase checkout completion rate from 68% to 75%" is an outcome commitment, and it admits that the solution is uncertain.
Applied to architecture, this changes the framing of platform work in particular. "Migrate to Kubernetes" is an output. "Reduce deployment lead time from three days to two hours" is an outcome, and it leaves open the possibility that the migration is not the cheapest route to it.
Three consequences worth naming:
It requires measurement before starting, since an outcome commitment with no baseline is unfalsifiable.
It admits the possibility of failure, which is why organisations resist it — an output can always be declared delivered.
It permits the work to stop early when the outcome is achieved by less than was planned, which is a significant source of saved effort and is unavailable in an output model.