How to Write Outcome Definitions Before You Delegate

Outcomes versus instructions

The single biggest difference between a task that gets handed over cleanly and one that keeps bouncing back is whether the founder described a result or a set of steps. Instructions tell someone what to do; outcomes tell them what 'done well' looks like when they get there. Both have a place, but most small-business founders default to instructions because that's what's in their head — the sequence of actions they'd personally take — rather than the standard they're actually holding the work to.

The trouble with instructions alone is that they don't transfer judgement. If you hand someone a script for replying to customer emails, they can follow the script, but they can't tell whether following it actually solved the customer's problem, because nobody told them what 'solved' means. An outcome definition — 'the customer's issue is genuinely resolved and they don't need to write back about the same thing' — gives them something to check their own work against, which is what lets you stop checking it for them.

This matters more as a task becomes less routine. For purely mechanical work, instructions are often enough. For anything involving a judgement call — how to handle an annoyed customer, how to prioritise two urgent requests, how to write copy in your voice — an outcome definition is what actually lets someone act without asking you first.

What a good outcome definition looks like

A workable outcome definition has three qualities: it's stated as an end state, not an action; it's specific enough to be checked; and it uses language the person doing the work will actually recognise while they're doing it, not abstract phrases that sound good in a strategy document but mean nothing at nine in the morning with a queue of emails.

Compare 'improve customer service' with 'every customer email gets a reply within four working hours, in our tone of voice, with the actual issue fixed rather than just acknowledged'. The first is a direction; the second is a test someone can run on their own work before they send it. The second version also tells you, the founder, exactly what to check at review time, which saves you from vague, unfalsifiable feedback like 'this doesn't feel quite right' that helps nobody improve.

• State it as a result: 'the report is accurate and delivered by 5pm Friday', not 'do the weekly report'
• Make it checkable: something a reasonable person could look at and say yes or no to, not a feeling
• Use their language: the words they'll actually use while doing the task, not management shorthand
• Include the standard, not just the task: 'accurate' needs defining too — accurate compared to what, checked how
• Keep it to one or two sentences — if it needs a paragraph, you're describing steps again

Writing outcomes with the person, not for them

Where possible, draft the outcome definition together with the person who'll be doing the work, particularly the first time you hand something over to them. Ask them to describe, in their own words, what they think 'done well' would look like, then compare that against your own version. The gaps between the two are exactly where misunderstandings will surface later if you don't close them now.

This collaborative step also does something less obvious: it gives the person a stake in the definition rather than a definition imposed on them, which tends to produce more genuine ownership than a document handed down unilaterally. It takes an extra ten minutes at the start and routinely saves far more than that in avoided rework.

Common mistakes in outcome definitions

The most common failure is writing an outcome that's actually a feeling rather than a checkable result — 'make sure clients are happy' sounds like an outcome but gives no way to know whether it's been achieved. A close second is writing an outcome so broad it covers everything and specifies nothing, which is really just an instruction to 'do a good job' dressed up in outcome language.

Another frequent mistake is defining the outcome once and never revisiting it. The first version you write, before anyone has actually attempted the task, is rarely quite right — it usually misses an edge case or uses a standard that turns out to be ambiguous in practice. Treat the first outcome definition as a draft, and update it after the first review conversation based on what actually came up.

A useful test: could the person doing the task mark their own homework using only the outcome definition you gave them, with no further input from you? If not, it isn't finished yet.

When instructions are still the right tool

None of this means instructions are bad. For genuinely mechanical, compliance-driven or safety-critical steps — how to process a refund in the till system, how to lock up the premises, how to record a supplier invoice — a precise sequence of steps is exactly right, and adding vague outcome language on top would only introduce risk. The skill is recognising which parts of a task are mechanical and which involve judgement, and writing each part in the form that suits it.

Many real tasks are a mix: a fixed procedure wrapped around a judgement call. Customer email handling might have a fixed step (log the ticket in the system) and a judgement call (decide the right tone and resolution for this particular customer). Write the fixed part as an instruction and the judgement part as an outcome, rather than forcing the whole task into one format.

Using outcome definitions at review time

The payoff of a clear outcome definition shows up most at the review point, not at handover. Instead of a vague conversation about whether the work 'felt right', you and the person doing it can look at the same sentence you agreed at the start and assess the work against it together. This turns feedback into something specific and improvable rather than a matter of taste, which is a large part of what makes review conversations feel fair rather than arbitrary.

If a review consistently surfaces disagreement about whether the outcome was met, that's usually a sign the definition itself needs sharpening, not that the person is underperforming. Treat repeated ambiguity at review time as feedback on your brief, and update the outcome definition before the next cycle.