Briefs, not tickets

A useful brief records the problem, the customer evidence behind it, and what is in and out of scope.

Without that, engineers fill the gap themselves. They guess the intent, invent the edge cases, and build the general version because the specific one felt arbitrary. That guessing is where scope grows.

What an implementation brief carries

• A verdict. Build, reject, or reduce — with the sentence that settles it.
• The evidence. The conversations, quotes and accounts behind the claim, attached rather than summarised.
• Developer scope. The surfaces that change, the behaviour before and after, and the decisions already made so nobody re-opens them mid-branch.
• Explicit non-goals. The tempting adjacent work that is deliberately not in this change.

Why the non-goals matter most

Most overbuilt features were never requested. They were inferred from a vague ticket by a careful engineer who did not want to ship something half-done. Writing the boundary down is not bureaucracy — it is permission to build the small version confidently.

A brief takes twenty minutes longer to produce than a ticket. It removes the three conversations, the rework, and the feature nobody uses.