Start with what should change
A useful brief begins with the business or customer situation, not a feature list. Explain what people are trying to accomplish, what they use today, and why the current path is no longer good enough.
You do not need to know the solution. A short account of the problem gives us more room to find the right product shape than a long list of screens copied from another tool.
- Who experiences the problem
- What they do today
- Where time, trust, or revenue is lost
- What a meaningfully better result would make possible
Share the constraints early
Budget range, timing, required systems, decision makers, security needs, and immovable events help us shape a realistic first release. Constraints do not weaken a brief. They make the recommendation useful.
- Target date and why it matters
- Known systems and data sources
- People who approve product, technical, or legal decisions
- Anything that must remain unchanged
Bring the material you already have
Existing screenshots, spreadsheets, call notes, analytics, support tickets, process documents, and examples of current work are often more useful than a polished presentation. Sensitive material can wait until a secure sharing method and appropriate agreement are in place.
Was this not the answer?