The brief is the deliverable

A brief that says we need a new website is not a brief. It is a purchase order with adjectives. It has already made the largest decision in the project, usually in a meeting where nobody present had talked to a customer that month, and everything downstream is now optimisation of a choice that was never examined.

The briefs that produce good work have three parts and none of them is a solution. First, a description of the situation specific enough to be wrong: not our brand feels dated but booksellers cannot tell our six imprints are one publisher. Second, what would count as better, stated in terms someone outside the project could verify. Third, the constraints that are real, as opposed to the ones that are habits.

That third part is where most of the value is, and it is the part clients find hardest, because separating a real constraint from an inherited one requires admitting which is which. We cannot change the fare structure is sometimes a legal fact and sometimes a sentence someone said in 2016. Half of our first six weeks on any project is spent sorting that pile.

We now write the brief ourselves, as a deliverable, at the end of a short paid phase, and we do not start the main work until the client has signed something they helped write. It reads as an inversion of the normal order and it is. The client has the knowledge and we have the practice at asking; expecting them to produce the artefact alone is expecting them to do the part they hired us for.

The test we use: could this brief be answered in more than one way? If only one solution satisfies it, the brief is a specification and the interesting decision has already been made without you.