The brief is not the problem

A brief came in last spring with 11 numbered requirements. Item seven was a members area. Logins, a dashboard, gated content, the lot, and it had a paragraph of description under it, so somebody had clearly thought about it.

Six weeks later, in a meeting about something else, I found out what the members area was for. Once a month their office manager emailed a PDF price list to about 40 trade customers, and they were doing it by hand, from a spreadsheet, and it took most of a morning and they sometimes missed someone.

That’s the problem. It’s a real problem, it was costing a person a morning a month and occasionally costing the business a customer, and the solution to it is not a members area. But nobody in the room when the brief was written knew that, because the office manager wasn’t in the room.

A feature list is a record of an argument

The thing I’ve slowly worked out is that a brief isn’t a description of a need. It’s the minutes of a meeting.

Somebody wanted a redesign. Somebody else wanted the newsletter fixed. The person who runs sales wanted something for trade customers and described it as best they could to a marketing manager who has seen a members area on a competitor’s site. Then it all got typed up in a numbered list by whoever was taking notes, and the list went out to three agencies, and now it’s a specification.

Every line on it is a compromise between two people who wanted different things, flattened into a bullet point, with all the disagreement removed. Which means the information you most want, which is why, was the specific part that got edited out to make the document look decisive.

The information you most want is the disagreement, and the disagreement is the specific thing that got edited out to make the document look decisive.

And the people who lost those arguments are usually the ones with the actual information, because they’re closer to the work. The office manager knew exactly what the problem was. They’d have told anyone who asked. They just weren’t on the distribution list for a document about the website, because in what sense is a website about them.

Nobody who wrote it has the problem

That’s the pattern under all of this, and it’s not anyone’s fault.

Briefs are written by the people who own the budget. The problems are experienced by the people who do the daily work, or by customers who never speak to either group. There’s a gap between those two populations on every project I’ve worked on and its width is roughly proportional to the size of the organization.

So the brief describes what the budget-holder has understood, second-hand, filtered through a competitor’s website and a conversation in a corridor. It’s not wrong, exactly. It’s a reasonable reconstruction. It’s just several transcription steps away from the thing that’s actually costing money.

Three things I ask for

I used to push back on the brief directly, which produces exactly one outcome, which is that a client who has spent three weeks writing a document is now defending it. That’s not a discovery conversation, that’s a disagreement about whether they did their homework properly, and I’ve lost it more than I’ve won it.

So now I don’t argue with any of the items. I ask for three things, always, and they’re deliberately not confrontational:

The analytics. Not to be clever with, just to see what people actually do on the current site. Half the time this quietly retires two items on the list, because the page everyone’s arguing about gets 11 visits a month.

Whatever they get complaints about. Support inbox, the phone, the contact form. This is the single highest-yield question I ask and almost nobody volunteers it, because complaints feel like an admission rather than a resource.

Half an hour with whoever does the work. The office manager, the person who updates the site, the one who handles the orders. Framed as “so I understand the day-to-day,” which is true, and which is also how you find the morning-a-month spreadsheet.

None of that contradicts the brief. It sits alongside it, and by the time you’ve done all three, the client usually gets to the reframing before you do, which is enormously better than you getting there first and telling them.

Sometimes the brief is just right

I want to include this because there’s a version of this post that’s insufferable, where the developer is a detective and the client is a hapless witness, and I’ve met people who work like that and they’re exhausting.

Plenty of briefs are correct. A client who says they need an events calendar because they run 40 events a year and are currently typing each one into a page by hand has diagnosed it properly and doesn’t need my help reframing it. If you interrogate every line as a matter of policy you’re not doing discovery, you’re performing rigor, and clients can tell the difference within about ten minutes.

The tell I use is whether the item on the list names a mechanism or an outcome. A mechanism with no outcome attached (“members area,” “an app,” “a chatbot”) is worth a gentle pull on the thread. An outcome with a mechanism attached (“stop typing events in by hand”) is a person who has already done the work.

When you don’t get to ask

And the honest constraint: sometimes there’s a wall.

A fair bit of agency work is subcontracted, and the client on the other side of it is somebody else’s client. You get a spec, a deadline and a Basecamp thread, and the person who could answer any of this is two organizations away and nobody has budgeted for your curiosity. On those jobs you build item seven, and it’s fine, and you write down your doubts somewhere they’ll be found later.

I don’t think there’s a clever answer to that. It’s a structural thing about how work is bought, and one developer being inquisitive doesn’t fix it. But I’d still write the doubts down, because in my experience it’s about a year until someone asks why nobody uses the members area, and being able to say “here’s the note from March” is worth something, mostly to the next person.

Ask about the complaints

The brief is a genuinely useful document. It tells you what the client thinks, who’s been arguing, and roughly what they’ve budgeted. It is not, and was never meant to be, a description of what’s wrong.

If you only take one thing: ask what they get complaints about. It costs nothing, it isn’t a challenge to anybody’s document, and it has changed the shape of more projects for me than every other question put together.