The tighter brief that made the work worse

A project starts with a brief that runs forty pages. Every button placement is specified. Every file format is named. Every field on every screen has a rule attached to it. Whoever wrote it did the responsible thing: they anticipated every question a builder might ask and answered it in advance, so nothing would be left to guesswork.

The work comes back. It matches the spec, line for line. And it misses the business point entirely. Nobody can point to a single requirement that was violated, and everybody agrees the thing does not do what it was supposed to do.

The instinct at that point is to conclude the brief was not specific enough. So the next one gets longer: more edge cases named, more fields pinned down, more of the builder's judgment replaced with an explicit rule. The theory is that ambiguity is the enemy, and the fix for ambiguity is always more detail.

The next round comes back matching the new, longer spec exactly. It still misses the point, in a slightly different way. That is the tell. If doubling the detail does not close the gap, the gap was never a detail problem. A forty-page brief can specify every button on a screen and never once say what decision the screen is supposed to help someone make. The builder was never confused about what to build. They were never told why it mattered, so they built the literal words and nothing in the document told them when the literal words and the actual goal came apart.

The fix was not adding a forty-first page. It was removing most of the other forty. We rewrote the brief down to three things: the one decision the finished work has to drive, the specific person it is for, and who has the authority to say yes when it is done. Everything else that used to live in the document, every button placement, every formatting rule, every edge case, got pulled out and treated as a conversation to have with the builder while the work was happening, not a constraint to hand them before it started.

That felt risky at first. A shorter brief looks like less rigor, not more. But a rule written down in a document a builder reads once is weaker than a decision made in a live conversation, next to the actual screen, with both people looking at the same problem. The forty pages were an attempt to compress every future conversation into text ahead of time. Most of those conversations were better held when they were actually needed.

The first draft against the short brief came back usable. Not perfect. Usable, on the first pass, which the forty-page version never once managed. Nobody had specified every button, and somehow every button was still right, because the builder understood the decision it needed to serve and could reason about the parts nobody had written down.

Give a team the destination and the person it is for, and their judgment fills in the footsteps correctly more often than a document can specify them. Give them only the footsteps, and the destination is the one thing that never got written down anywhere they could see.