Most product work slows down long before the first line of code — in the gap between a business problem everyone feels and a direction a team can actually build toward. A good brief closes that gap in a page, not a deck.
Start with the problem, not the solution
The most common failure of a brief is that it describes a feature instead of a problem. "Add a dashboard" is an answer to a question no one has written down yet. Begin by stating who is stuck, what they are trying to accomplish, and what it currently costs them to work around it.
When the problem is written plainly, disagreements surface early — while they are cheap. That is the point. A brief is not there to sound finished; it is there to make the real decision visible before the team commits weeks to it.
Name the decision the brief is asking for
Every brief exists to unblock a specific decision: build or don't, this shape or that one, now or next quarter. State that decision at the top so the reader knows what they are being asked to weigh in on, and what is out of scope.
A brief that asks for everything gets nothing. One that asks for a single, clear yes is easy to move on.
Bound it with constraints and a first slice
Constraints are not the enemy of ambition — they are what make ambition buildable. Note the hard limits (time, systems it must live inside, data it can and cannot touch) and then describe the smallest version that would still teach you something real.
The first slice is the most honest part of a brief. If you cannot describe a version small enough to ship in weeks, the direction is not yet clear enough to start.
