A project brief is cheap insurance against an expensive mistake: building the wrong thing, correctly, for six weeks. It's the document that forces alignment before the work starts, when changing direction costs a conversation instead of a sprint. Skip it and you'll discover the disagreements you avoided naming — in the review, in front of the client, at the worst possible time.
The brief exists to answer one question: are we agreed?
A brief's job isn't to be comprehensive; it's to surface the assumptions people are quietly holding differently. The value isn't in the document — it's in the moment someone reads "success means X" and says "wait, I thought it meant Y." That disagreement was always there. The brief just makes it happen in week zero for the price of a comment, instead of in week six for the price of a rebuild.
The five things a brief must pin down
Everything else is optional; these five are not:
- The problem — what's actually wrong today, in one or two sentences, before any mention of solution. If you can't state the problem crisply, you're not ready to solve it.
- Success criteria — how you'll know it worked. Concrete and checkable, not "improve the experience." If it can't be verified, it can't be aimed at.
- Scope — and explicitly, non-scope. What you're not doing is often more valuable than what you are, because unspoken exclusions are where scope creep breeds.
- Constraints — deadline, budget, the things that can't move. These shape every downstream decision, so surface them now.
- Owner and stakeholders — who decides, who's consulted, who just needs to know. Ambiguity here is how projects acquire three chefs and no cook.
Ruthless on length
A brief that runs long stops being read, which defeats its entire purpose. Aim for one page — two at the absolute most. The discipline of fitting it on a page is doing real work: it forces you to distill the project to its load-bearing decisions and cut the reassuring padding. If you're struggling to compress the prose without losing meaning, running the draft through an editing tool like Wrivio and reviewing its cuts is a fast way to find the words that were carrying no weight — while you keep final say over anything that shifts the meaning.
Circulate it, then freeze it
A brief written and filed is worthless; a brief written and agreed is the whole point. Send it to every stakeholder, collect the disagreements, resolve them, and then lock it. The lock matters: a brief that keeps quietly changing is no anchor at all. Once frozen, distribute it in a form that stays put — a PDF of the final version arrives on every screen looking identical and can't be silently edited out from under the team's shared understanding.
Reopen it only on purpose
Projects change, and sometimes the brief genuinely needs to. But "the brief changed" should be an event — a decision someone makes deliberately, communicates, and re-circulates — not a drift that happens in hallway conversations while the document sits stale. When the brief and the actual work diverge, that gap is a signal to stop and re-align, which is exactly the expensive surprise the brief was written to prevent in the first place.
