The members area was a spreadsheet
Item seven on the brief was a members area. Logins, a dashboard, gated content, with a paragraph of description underneath it, so somebody had clearly thought about it.
The brief came in this spring with 11 numbered requirements on 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 sends a PDF price list to about 40 trade customers, one email at a time, working down a spreadsheet. It takes most of a morning, and every so often somebody gets missed.
That’s a real problem. It was costing a person a morning a month and occasionally costing the business a customer, and the answer to it is not a members area. Nobody who wrote the brief knew that, because the office manager wasn’t in the room.
Somebody was taking notes
I’ve slowly worked out that a brief isn’t a description of a need. It’s the minutes of a meeting.
Somebody wanted the site to stop looking like 2011. Somebody else wanted the newsletter signup fixed. The person who runs sales wanted something for the trade customers and described it as best they could to a marketing manager who has seen a members area on a competitor’s site. Whoever was taking notes typed it up as a numbered list, 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 the disagreement taken back out. Which means the part I most want, which is why, is the exact part that got edited away to make the document look decisive.
Not on the distribution list
And the people who lost those arguments are usually the ones holding the information, because they’re closer to the work. The office manager knew exactly what the problem was. They’d have told anybody who asked. They just weren’t on the distribution list for a document about the website, because in what sense is the website about them.
That’s the pattern under all of it, and it isn’t anybody’s fault. Briefs get written by the people who own the budget. The problems belong to the people doing the daily work, or to customers who never speak to either group. There’s a gap between those two populations on every project I’ve worked on, and my sense is that it widens roughly in proportion to the size of the company.
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 isn’t wrong. It’s a reasonable reconstruction, in the way that “just a refresh” is a reasonable reconstruction of four years of decisions. It’s several transcription steps away from the thing that’s actually costing money.
Can I see the analytics?
I used to push back on the brief directly, which produces exactly one outcome, which is a client who spent three weeks writing a document now defending it. That isn’t a discovery conversation, it’s a disagreement about whether they did their homework, and I’ve lost it more often than I’ve won it.
So now I don’t argue with any of the items. I ask for three things instead, and they’re deliberately not confrontational.
The analytics, for the same reason I go and read the client’s own browser numbers instead of guessing from blog posts. Not to prove a point with, just to see what people do on the site they already have. Half the time it quietly retires two items on the list. The page everybody is arguing about turns out to get 11 visits a month.
Whatever they get complaints about. The support inbox, the phone, the contact form, the thing somebody at the front desk is tired of explaining. This is the one I’d keep if I could only ask one, and almost nobody volunteers it, because complaints feel like an admission instead of a resource.
And half an hour with whoever does the work. The office manager, the person who updates the site, whoever handles the orders. Framed as so I understand how a normal week goes, which is true, and which is also how you find the morning a month.
None of that contradicts the brief. It sits alongside it, and by the time you’ve done all three the client has usually gotten to the reframing before you do, which is enormously better than getting there first and telling them.
Not a detective
Plenty of briefs are correct, and there’s a version of this where the developer is a detective and the client is a hapless witness who has to be led to the truth. I’ve met people who work like that and they’re exhausting.
A client who says they need an events calendar because they run a couple dozen events a year and are typing each one into a page by hand has diagnosed it fine and doesn’t need me reframing anything. Interrogate every line as a matter of policy and you’re not doing discovery, you’re performing rigor, and people can tell the difference inside of about 10 minutes.
The tell I use is whether an item names a mechanism or an outcome. A mechanism with no outcome attached, so a members area, an app, a chatbot, is worth a gentle pull on the thread. An outcome with a mechanism attached, so stop typing events in by hand, is somebody who has already done the work, and the right response is to go and build it.
Two companies away
And sometimes there’s a wall.
A fair amount 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 companies away and nobody has budgeted for my curiosity. On those jobs you build item seven. It’s fine, and you write your doubts down somewhere they’ll be found later.
I don’t have a good answer for that. It’s a structural thing about how the work gets bought, and one developer being inquisitive doesn’t fix it. I’d still write the doubts down though, because it’s usually about a year before somebody asks why nobody is using the members area. I have already been on the wrong end of that question about my own work. Being able to say here’s the note from March is worth something, mostly to whoever comes after me.
Ask about the complaints
The brief is a genuinely useful document. It tells you what the client thinks, who has been arguing, and roughly what they’ve budgeted. It just isn’t a description of what’s wrong, and it was never meant to be one.
The one I’d keep, if it had to be one, is asking 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 I ask put together.
As for item seven, we’re building it. It was in the estimate before I ever heard the word spreadsheet, the scope is signed. I don’t think the trade customers are going to make accounts. A page with the current price list on it did go up one afternoon as a while-we’re-in-there, so the office manager can send 1 link instead of 40 attachments and swap the PDF out themselves when the prices change. That took an afternoon. It was never on the list, and the only reason it exists is that I happened to be in a meeting about something else.