Here’s a test for the last brief you wrote. Count the questions you got after you sent it.

Not the polite “love this!” replies. The real ones. “Who is this actually for?” “Can we say it’s the fastest?” “Is the landing page in scope?” “What does done look like?”

Some questions are just questions. “Can you send the logo files?” is fine. But questions about audience, claims, or scope are bug reports. The brief shipped, and its users couldn’t do their job with it.

A brief isn’t paperwork that proves you thought about the campaign. It’s a product. It has users, it has one job, and it either works for those users or it doesn’t. Too many briefs are built for a different customer: the person who approves them.

Here’s what that looks like on the page.

Before and after: the same launch brief

Before and after: a competent brief vs one people can work from

This is an illustrative brief for a made-up invoicing tool launching automatic payment reminders to its existing customers. Not a real client. It’s a lifecycle launch, so there’s no sales team in the loop: just an email, the product, and the people who’ll build them.

Before (written for the approver):

Objective: Drive adoption of Auto-Reminders among existing customers.
Audience: SMB owners and finance admins, 10–50 employees, on the Growth plan.
Key message: Auto-Reminders takes the awkward follow-up out of getting paid.
Tone: Confident, warm, a little cheeky.
Deliverables: Launch email, in-app banner, 3 social posts, landing page.
Timeline: Live by Oct 30.

There’s nothing lazy here. The audience is specific. The message is decent. There’s a date. You’d approve it in a minute.

Now read it as the person who has to make the work. Can the email say customers get paid faster? Is the landing page for existing customers or for new prospects, and does it need pricing? Cheeky about what, exactly? What do the social posts do for people who are already customers? Who decides if the banner copy changes?

The brief doesn’t say. So the answers will come from a call, a Slack thread, or a guess.

After (written for the people who use it):

The job: Get existing Growth-plan customers who send 20+ invoices a month to turn on Auto-Reminders. This launch is about adoption. New-customer awareness is not the goal.
Who, in what situation: The owner or finance admin who chases late invoices by hand every Friday and dreads writing the “just following up” email.
The one thing to land: You stop being the person who has to ask for the money.
Why they’d believe it: Reminders go out from the invoice itself on a schedule you set, and you can preview exactly what will be sent before you turn it on. (Only claim what product can demo on launch day.)
Tone: Warm, and a little cheeky about the chore of chasing payment. Never cheeky about the people who pay late. They’re still our customers’ customers.
Don’t say: Don’t quantify how much faster customers get paid; we don’t have evidence yet. No “AI.”
In scope: Launch email, in-app banner, help article. Not in scope: social posts, landing page.
Timeline: Live by Oct 30. Help article goes live first so the email and banner can link to it.
Success signal: Auto-Reminder activations among eligible customers within 14 days.
Quality bar: After reading the email, a customer can explain what changes in their Friday workflow.
Decisions: Copy and design calls are the team’s. Claims and scope come back to me.

The second version isn’t the first one with the blanks filled in. It’s the same launch after someone made the hard calls:

  • Social and the landing page are cut. These are existing customers. They’ll see the banner and the email. A landing page and social posts would mostly reach people who can’t turn the feature on yet. The help article replaces them, because people who click want to know how, not why.
  • A claim is ruled out. “Takes the awkward follow-up out of getting paid” is one edit away from “get paid faster,” with a number attached. Nobody has evidence for that yet, so the writer hears it now, not after the email is in review.
  • The audience is a situation, not a segment. “10–50 employees” doesn’t help a writer. “Chases invoices by hand every Friday” does.
  • Cheeky gets a boundary. The team knows exactly where the joke lands, and where it doesn’t.
  • Success is split in two. The activation number tells you whether the launch worked. The quality bar tells the writer what the email has to do, and they can check that before it ships.
  • Decisions have owners. The team knows what they can change without asking.

It’s longer, but it’s not padded. The approver can still see the strategy. Now everyone else can act on it too.

Who actually uses a brief

Ask who a brief is for and you’ll usually hear “the creative team.” That’s one user. There are more.

Primary users work from the brief directly:

  • The designer or writer who has to make something good from it, often without you in the room.
  • The agency or freelancer who doesn’t know your history, your politics, or what was decided in last month’s meeting.
  • The channel and media people, like the lifecycle or email owner, the social lead, or whoever plans paid, who need to know what’s in scope before they plan anything.

Downstream readers don’t make the work, but they live with it:

  • Sales and CS, who will get the questions once the campaign is live. (If you don’t have a sales team, that’s support.)

And two more:

  • The approver, who wants to know the work is on strategy.
  • You, six weeks from now, trying to remember why you said no to the bold option.

Only one of those people reads the brief to sign it off. The rest read it to make decisions. When a brief is written for the approver, it reads well and works badly. It’s full of things that are easy to agree with and light on the things people need to choose.

The one job a brief has

A brief has one job: help people make sound decisions without you in the room.

Aligning stakeholders still matters. It’s how you get to a brief worth writing. But alignment is an input, not the finish line. A room full of people who agree on the strategy can still produce three different landing pages.

So here’s the spec. If the designer can pick between two headline directions, the writer knows which claim is off-limits, and the agency knows whether the landing page is theirs, all without pinging you, the brief worked.

If those calls still route through you, the brief is a cover page, and you’re the real product.

What a brief that fails its users looks like

You’ve seen these:

  • The clarifying call is the real brief. Everyone nods at the doc, then the useful stuff gets said out loud and never written down.
  • The Slack thread is longer than the brief.
  • Round one comes back “not quite.” Nobody can say why, because the brief never said what “right” was.
  • Three people give three answers to “who’s this for?” All of them technically match the doc.
  • The brief got written after the work started, to describe what was already happening.

None of this means people didn’t read it. It means the brief didn’t answer what they needed to know.

What each line needs to do

Before you send any brief, run the 5-question preflight. It’s a solo check that takes two minutes. Does it name one job? One thing to land? At least one thing that’s ruled out? What “right” looks like? Who decides what? Any “no” points to a row in this table.

Brief field What it usually says What the people using it actually need
Objective “Drive adoption” or “drive awareness” The one behaviour change this work is for, and what it’s not for
Audience A segment or a firmographic The situation they’re in when this matters to them
Key message A generic stack of benefits One thing to land, in words a customer might repeat
Tone A few adjectives Where the tone applies, and where it stops
Proof Often missing What we can actually show, and what we can’t claim yet
Don’t say Logo and legal line, if anything Claims, words, and angles that are off-limits
Deliverables A list of assets What’s in scope and what isn’t
Success signal “Engagement” The behaviour you’ll measure to know it worked
Quality bar Never written What a reader should understand after one read, so round one can hit it
Decisions Never written Which calls are theirs and which come back to you

If your brief template is mandated, by a client, a parent company, or a team you can’t overrule, you don’t need to fight it. Just add three rows to the bottom: Don’t say, Not in scope, and Decisions. They do more work per word than anything else in a brief.

The playback test

The preflight checks the doc. The playback test checks whether it works for an actual user.

Before kickoff, give the brief to one person who will work from it. Let them read it. Then ask them to play it back to you in 60 seconds: who it’s for, the one thing to land, what’s out of scope. Then ask what they’d make first.

That last question does a lot. If the designer on the Auto-Reminders launch says “the landing page,” the scope didn’t land. If the writer starts with “get paid faster,” the Don’t say line didn’t either.

If their playback doesn’t match what you meant, fix the doc, not the person.

Where this goes wrong

“Treat it like a product” can turn into a different mistake:

  • The 12-page brief. Thorough isn’t usable. If the user has to hunt for the one thing to land, it’s buried.
  • The brief as insurance. Written so you can point at it when things go sideways. It’s written for blame, not for the people doing the work.
  • The brief nobody’s allowed to question. A product with users gets feedback. If people can’t push back on the brief before work starts, they’ll push back on the work after.

What to do next

  1. Open the last brief you sent and list the questions you got after it went out. Each one may reveal a missing line.
  2. Run the 5-question preflight on your next brief before you send it.
  3. Book ten minutes with one person who’ll work from it and run the playback test before kickoff. Ask what they’d make first.

You’ll still have kickoff calls. They’ll just stop being where the brief actually gets written.