We read a lot of briefs. Some arrive as polished decks with market research and competitor analysis and a clear articulation of the problem. Some arrive as a paragraph in an email. Some arrive as a phone call where the client talks for forty minutes and we take notes.
The format doesn't predict the quality of the work. The honesty does.
The question behind the question
Every brief contains a stated problem and an unstated one. The stated problem is what the client thinks they need. The unstated problem is what they actually need. Our job, in the early stages of any engagement, is to find the gap between them.
A client asks for a new website. The unstated problem is that their sales team can't explain what the company does in a single sentence. A client asks for a brand refresh. The unstated problem is that they've been trying to serve two incompatible audiences for three years and the brand is trying to do the same. A client asks for a mobile app. The unstated problem is that their core workflow is broken and they're hoping technology will paper over it.
The best briefs we've received have one thing in common: they are honest about what the client doesn't know.
What a good brief contains
A good brief contains a clear articulation of the problem, not the solution. 'We need a new website' is a solution. 'Our conversion rate from trial to paid is 3% and we believe the onboarding experience is a significant factor' is a problem. The former constrains the work before it starts. The latter opens it up.
A good brief contains an honest account of the constraints. Budget, timeline, internal politics, technical debt, stakeholder dynamics. We would rather know about the constraint upfront than discover it three months in. Constraints are not obstacles. They are the shape of the problem.
A good brief contains a definition of success that is specific enough to be falsifiable. Not 'we want to improve the brand perception' but 'we want to be considered alongside the top three players in our category by enterprise procurement teams within eighteen months.' The former is a direction. The latter is a destination.
What we do with a bad brief
A bad brief is not a reason to decline the work. It is a reason to do more work before the work starts. We call this the brief-back: a document we write in response to the brief that reflects our understanding of the problem, the constraints, and the success criteria — and, crucially, where we think the brief is wrong.
The brief-back is a test. If the client responds well to being challenged — if they engage with the questions and revise their thinking — the engagement will go well. If they respond defensively — if they insist the brief is correct and we should just execute it — we have learned something important about how the relationship will work.
The brief we write ourselves
The most important brief we write is the one we write for ourselves at the start of every engagement. It is not a document we share with the client. It is a document we use internally to align on what we believe the real problem is, what success looks like, and what we are willing to do to achieve it.
This internal brief is updated as the engagement progresses. When we learn something that changes our understanding of the problem, we update the brief. When a constraint shifts, we update the brief. The brief is not a contract. It is a living document of our best current understanding.
A brief is not a specification. It is an invitation to think together. The clients who understand this — who come to us with problems rather than solutions, with honesty rather than polish — are the ones we do our best work with. Not because they make our job easier. Because they make it more interesting.