The Brief Is the Work

Most projects that go wrong were already wrong at the brief. Not because the client withheld something, but because nobody pushed past the first version of the problem. A brief written in an hour produces months of expensive guessing. A brief written properly turns the rest of the engagement into execution.

The first problem is never the real one

Clients arrive with a solution already in mind. We need a new logo. We need the site refreshed. Those are hypotheses, not problems. The useful question is what changed to make this feel urgent now. A stalled sales cycle, a new competitor, an investor conversation, a product that outgrew its packaging. The answer reframes the work almost every time.

Constraints belong at the start

Budget, timeline, internal politics, the one stakeholder who will veto anything green. Teams treat these as awkward details to surface later. They are actually the shape of the solution. Knowing that a small in-house team will maintain the system changes what we should design in week one, not week ten.

Write it down, then read it back

A brief is not agreed until the client hears their own situation described in words they did not supply and recognises it. If they correct you, the brief just got better. If they hesitate, something is unresolved. That moment of reading back is worth more than any workshop exercise.

Define what success looks like

Not adjectives. Outcomes. More qualified inbound. Shorter sales conversations. A team that stops arguing about slide templates. When success is specific, every later decision has a test to pass, and taste arguments end early.

Say what is out of scope

An unwritten boundary is not a boundary. Naming what the project does not include protects the work more than any change-request clause. It also signals that you have thought about the whole picture, which is usually why the boundary is accepted without friction.

How we do it at Monaro

We treat the brief as a deliverable with its own review. We interview the people who will live with the result, not only the person who signed. We write a one-page document covering the real problem, the constraints, the measures of success, and the explicit exclusions, and we do not start designing until it is signed. Projects that begin this way finish faster and argue less.