Keep it short and specific
A brief does not need to be long. A page describing the problem, the users, and the key features is more useful than a lengthy document full of vague aspirations.
Include the essentials
- The problem and why it matters now
- Who will use the system
- The features you consider essential
- Any systems it must connect to
- Your rough timeline and budget if known
Describe examples, not just categories
Instead of 'we need better reporting', describe the specific reports you produce and who reads them. Concrete examples lead to concrete estimates.
Note your constraints
Existing platforms, brand rules, data-protection requirements, or fixed deadlines all shape what is possible. Better to state them early.