How to Write a Business Outcome Before Requirements
Write a measurable business outcome before requirements using a practical four-part method, worked example and clear limitations.
A useful outcome states whose situation must change, what observable change matters, by when, and how success will be judged—without prescribing a product.
The ACTS outcome statement
Build the statement in four passes. Treat every number as a proposal until its owner and evidence are confirmed.
- 01
Audience
Name the people, team or process experiencing the problem. Avoid a vague subject such as ‘the business’. Different groups can need different outcomes.
- 02
Change
Describe the observable change in work or results. Use a neutral verb such as reduce, shorten, increase or prevent; do not name a feature.
- 03
Time boundary
Choose when the change should be visible and separate the implementation date from the outcome date.
- 04
Success evidence
Specify a baseline, target and evidence owner. If the baseline is unknown, record that unknown instead of inventing precision.
Example: service request handoffs
Weak: ‘Implement a ticketing platform.’ Stronger: ‘By the end of Q2, regional service coordinators can route routine requests to an accountable owner within one working day, measured from accepted request to assigned owner.’ The team must still validate the baseline, exclusions and whether one day is operationally realistic.
What this method cannot guarantee
- An outcome is not a complete business case; cost, risk and strategic fit still need separate evaluation.
- A target can create harmful incentives if it measures speed while ignoring quality or workload.
- The method supports judgement; it does not transfer accountability from the people approving the decision.