The brief is the deliverable

Studios talk about process constantly and about briefs almost never, which is odd, because the brief determines more of the outcome than the process does.

A strong brief given to an average team beats a weak brief given to a great one. The second will produce something better looking, aimed at the wrong thing.

What good briefs have in common

They state a decision, not a deliverable

“We need a new website” is a purchase order. “We need prospects to understand what we do before they reach the pricing page” is a brief. The first names an artefact; the second names a change, and leaves room for the possibility that the artefact is not the answer.

They include the constraint that makes it hard

Every interesting project has one: a migration that cannot slip, a regulator, a legacy system, a small team who will own it afterwards, a category convention you cannot ignore without losing trust. Briefs that omit the hard constraint get proposals that ignore it, and the constraint reappears in week six as a change request.

They name who has to be convinced

Work does not get approved by an organisation; it gets approved by people. If a founder, a head of sales and a compliance lead all have to say yes, that is three sets of objections the work has to answer, and knowing it at the start is worth more than another week of exploration.

They are short enough to be read

A brief nobody has finished is not a brief. Length is not rigour — the longest documents we receive are usually the least decided, with every unresolved internal argument preserved in full rather than settled.

What weak briefs look like

They list adjectives. Modern, bold, premium, human. These are moods rather than constraints: every option satisfies them, which means the brief eliminates nothing, and the first review becomes the real briefing session — conducted through work instead of words, at considerably greater expense.

They describe competitors instead of customers. “Something like theirs, but better” inherits someone else's positioning without inheriting any of the reasons for it, including the ones that do not apply to you.

They defer the decision. A brief asking to “explore several directions” is often a brief that could not reach agreement, using exploration to postpone the argument until there is something concrete to have it about. That argument is very much cheaper on paper.

Rewriting the brief with the client

We now spend the first week of most projects rewriting the brief together. It is the least billable and highest-leverage week of the engagement, and it is not a formality: most briefs change substantially, and a few reveal that the project someone asked for is not the project they need.

The method is unremarkable. Restate the request as a decision. Ask what would have to be true for it to work. Ask what has already been tried, and why it did not. Name the constraint nobody has written down. Then get it onto one page and have the people who will approve the work agree that it is right.

Occasionally this ends with us recommending less work than was asked for. That is a good outcome, and a rare one to be paid for — which is roughly why it belongs in the first week rather than the last.

What this buys you

Fewer rounds. Reviews about whether the work answers the brief rather than whether the reviewer likes it, which is the single largest source of drift in creative projects. And a much better chance that what gets built is the thing that mattered rather than the thing that was easiest to specify.

It also changes what the work can be. A brief that names a decision leaves room for a designer to propose something the client had not imagined and can still recognise as an answer. A brief that names a deliverable does not — the best possible outcome is the thing that was already described, executed well.

If you are weighing up a project and are not yet sure the brief is right, that is a good moment to start a conversation rather than a bad one.