# How to Define a Measurable Outcome

Source: https://gravam.com/blog/how-to-define-a-measurable-outcome
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity. How to write one, and the traps.

**A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity.** "Treasury sees group cash intraday without touching a spreadsheet" is an outcome. "Build a cash dashboard" is an activity. The difference matters because teams that commit to activities can complete every task and still fail — the dashboard shipped, and treasury is still rebuilding the position by hand. An outcome tells everyone what success actually looks like, and lets you prove whether you got there.

## Outcome vs output

An **output** is what you produce: a report, a feature, a system. An **outcome** is the change that output is meant to create. They're easy to confuse and expensive to confuse:

|  | Output | Outcome |
| --- | --- | --- |
| **Is** | What you delivered | The result it created |
| **Example** | "The exposure report is live" | "Month-end exposure is right first time, no manual rebuild" |
| **You can** | Tick it done | Verify it mattered |

You can hit every output and miss the outcome. That's the whole reason to define the outcome first.

## What makes an outcome measurable

Three things:

- **Specific** — a concrete end state, not "better" or "improved."
- **Observable** — you can point at something and say whether it's true.
- **Tied to the problem** — it resolves the actual pain, not a proxy for it.

> The test: _how would you know?_ If you can describe how you'd verify the outcome — a number, a behaviour that changed, a thing that no longer happens — it's measurable. If the honest answer is "we'd just kind of feel it's better," it isn't an outcome yet.

## How to write one, from the problem

The outcome falls out of a well-stated [problem](https://gravam.com/blog/problem-statements-vs-solution-requests). Take the problem, describe the world once it's solved, and phrase it as something observable:

- **Problem:** "Treasury rebuilds month-end exposure by hand; it's slow and error-prone."
- **Outcome:** "Month-end exposure by entity is produced automatically and reconciles first time, without a manual rebuild."

Notice the outcome names _no solution_ — not a report, not a system. That's deliberate: it leaves room for the best answer — the same solution-free discipline that keeps [a requirement testable](https://gravam.com/blog/how-to-write-good-requirements-for-finance-systems) — and it's what you'll measure regardless of how you build it.

## Leading, lagging and proxy measures

Some outcomes are directly measurable (a number, a cycle time). Others are harder, and you use a **proxy** — an observable signal that stands in for the real result. That's fine, as long as you're honest that it's a proxy and it genuinely tracks the outcome. What you're avoiding is a _vanity_ measure — something easy to move that doesn't reflect the real change (usage of a feature nobody needed, say).

## An example

- **Vague:** "Improve the cash forecasting process." Not measurable — you can't tell when you're done.
- **Measurable:** "The two-week cash forecast is produced weekly with no manual spreadsheet consolidation, and forecast accuracy at the one-week horizon is tracked and improving." Now everyone knows the target and can verify it.

## What usually goes wrong

- **Activity disguised as outcome.** "Deliver the new module" — that's an output; the outcome is what the module changes.
- **Unmeasurable outcomes.** "Make it better" — no way to know if you succeeded, so scope and success float.
- **Vanity measures.** Optimizing something easy to move that doesn't reflect the real result.
- **No owner for the outcome.** A measurable outcome with [no one accountable for it](https://gravam.com/blog/07-cost-of-unclear-ownership) still slips.

Define the outcome first, make it observable, tie it to the problem — and you've given the work a target everyone can aim at and verify. That's exactly the field [Delivery Sheet](https://gravam.com/products/delivery-sheet) forces next to the problem: what's true when this is done, and how you'll know.

***

_See also [problem statements vs solution requests](https://gravam.com/blog/problem-statements-vs-solution-requests), the [project intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams), and the same discipline applied to an AI redesign: [how to measure ROI from an AI workflow](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow)._

## Questions this article answers

**Q: What is a measurable outcome?**

A measurable outcome states what will be true when the work is done, in a way you can actually verify — a result, not an activity. 'Treasury sees group cash intraday without touching a spreadsheet' is an outcome; 'build a cash dashboard' is an activity. A good outcome is specific, observable, and tied to the problem, so everyone knows what success looks like and can tell whether it was reached.

**Q: What is the difference between an outcome and an output?**

An output is what you produce — a report, a feature, a system. An outcome is the result that output is supposed to create — the change in the world that means the work mattered. 'We delivered the dashboard' is an output; 'treasury no longer rebuilds the position by hand' is the outcome. Teams that measure outputs can complete every task and still fail the outcome.

**Q: How do you write a good outcome statement?**

Start from the problem, describe the desired end state as something observable, and make sure you could tell whether it's true. Avoid naming the solution or the activity. 'Month-end exposure is produced automatically and reconciles first time' is measurable; 'improve the exposure process' is not. If you can't say how you'd verify it, it isn't yet an outcome.