How to Brief a Team Without Writing a Novel

A product manager I worked with for two years had a rule: if a brief needed a table of contents, it had already failed. He was not being flippant. He had watched three separate launches slip because the one decision that mattered, the actual ask, was buried in paragraph nine of a document nobody finished reading.

Most briefs are not too short. They are too long in the wrong places and too short in the one place that counts. A brief that opens with market context, moves through goals, drifts into background, and only then states what it wants from the reader is optimized for the writer's thinking process, not the reader's attention span.

Why length feels like thoroughness

Writing a long brief is easier than writing a short one, which is exactly why so many people do it. Compressing a decision down to its essentials takes a second pass that most schedules do not allow for. The first draft comes out as a record of the thinking, not a summary of the conclusion, and it goes out the door that way because the deadline for sending it arrived before the deadline for editing it.

There is also a quieter reason. A long brief reads as diligence. It signals that the writer did the research, considered the angles, and covered themselves against the question nobody wants asked in the follow up meeting: did you think about this? Short briefs feel exposed by comparison, because there is nowhere to hide an unexamined assumption.

The one thing a brief actually has to do

A brief has exactly one job: get the reader to the right decision or the right action with the least amount of interpretation required. Everything else, context, rationale, alternatives considered, is in service of that job, not a job in itself. If a paragraph does not change what the reader does next, it belongs in an appendix or a linked document, not in the body.

I ask writers to try a version of a simple test before sending anything longer than half a page: could someone act correctly on this after reading only the first three sentences? If the answer is no, the ask is not at the top, and the reader is being asked to earn the information that should have been given to them first.

Where generic advice about briefs goes wrong

The common advice is to use a template with fixed headings, such as background, objective, scope, and success metrics. Templates help people who forget sections, but they also encourage writers to fill every section whether or not it has anything to say. A background section with nothing new in it still gets three sentences, because the heading demands them, and those three sentences are exactly what a busy reader skips past on the way to something that matters.

I have stopped recommending fixed templates for anything shorter than a full project charter. For a normal task brief, a better structure is: the ask, the constraint that makes it non-obvious, and the deadline. Three lines. If someone genuinely needs background to act correctly, that background earns its place. If they do not, it is decoration, and decoration is what gets a brief skimmed instead of read.

A brief that actually got used

The clearest brief I have seen in the last two years was four sentences long, sent by a design lead to an outside contractor. It named the deliverable, named the one constraint that mattered (a file format the contractor's usual tools did not export cleanly), stated the deadline, and linked to a folder for anything else the contractor might want. No goals section, no background on the client. The contractor delivered on time with zero clarifying questions, which is a rarer outcome than it should be.

Compare that to a brief I reviewed for a client last spring, six pages long, with a goals section that repeated the objective in three different phrasings because three different stakeholders had each added their preferred wording during review. Nobody removed the redundancy because removing someone's sentence felt like removing their input. The brief went out at six pages, and the team that received it asked four clarifying questions in the first hour, each one answerable by something already in the document, just not findable in it.

None of this means cutting research or care out of the process that produces a brief. It means separating that process from the document itself. Do the thinking in a notes file, in a call, in a whiteboard session, wherever it needs to happen. Then write the brief as if you already know the answer and are handing it to someone in a hurry, because that is usually exactly who receives it.

The habit that changes this fastest is writing the ask first, before anything else, even in the draft. Most writers put it last because that is the order they arrived at it themselves. Moving it to the top forces every other sentence to justify its presence against a reader who already knows what you want and is deciding whether to keep reading. For more on what happens after the brief lands, see why the status updates that follow often get skipped for the same reason briefs do, and how the fix carries over almost unchanged. It also connects to the wider question of how teams brief and follow up without losing the thread between one document and the next.

Try it on the next brief you write, whatever the length. Draft the ask as a single sentence before you write anything else, then build outward only as far as the reader actually needs. If a section does not change what happens next, cut it, or move it below a line marked optional reading. Most briefs get shorter by half this way, and the half that survives is the half anyone actually used.