Anatomy of a rejected brief

A brief that ends in "Rejected" is more useful than one that ends in "Approved", because it is the only one anybody will argue with. It has to hold up.

Start with the verdict, not the request

Most decision documents bury the outcome under context. Invert it. The first line is the call. Everything below exists to defend it.

Rejected — solves a workaround problem that disappears when bulk export ships in the current cycle.

That sentence is doing the real work. Not "deprioritised", not "later" — a reason specific enough that someone can disagree with it on the merits.

Attach the evidence, not a summary of the evidence

Paraphrase is where signal dies. Keep the words the customer used, and keep the source attached:

• Sales call, mid-market account: "we end up copying rows into a spreadsheet every Monday morning."
• Support ticket: "is there a way to get everything out at once? doing it one by one."
• Slack, from an account manager: "third time this month someone has asked for this."

Three quotes. One underlying problem. Notice that none of them asked for the feature that was requested — they described the workaround they had already built.

Scope the thing you are actually doing

A rejection is rarely a full stop. It usually redirects. So the brief still ends in acceptance criteria, just for a different piece of work than the one that came in.

That is what makes the document safe to hand to engineering: it does not need a translation meeting.

The test

Six months later, someone asks why you did not build it. If the answer is in the document and still reads as sound, the brief worked. If the answer is "I think we were busy", you never had a decision layer.