We are sent everything from a paragraph to a 60-page requirements document. The length is not what makes a brief useful. These five things are.
1. The problem, not the feature
"We need a loyalty tab" is a solution. "Our repeat purchase rate drops after the first month" is a problem, and it might have a much cheaper answer. Tell us the second and we can argue usefully about the first.
2. Who it is for, specifically
Not a demographic - a person and a moment. Someone on a commute with one hand free is a different product from someone at a desk with twenty minutes. That single detail changes navigation, session length and often the whole platform decision.
3. What the first release must do, and must not
The second half of that sentence is what most briefs are missing, and it is the half that makes an estimate possible. A list of everything you eventually want is not a scope; a line drawn through it is.
4. The constraints that are real
- A date that is genuinely fixed, and what happens if it slips
- A budget range - a range is enough, and it saves everyone weeks
- Systems you must integrate with
- Anything legal or regulatory that shapes the build
5. What success looks like in numbers
Even a rough target changes what we build. "Ten thousand users in six months" and "fifty enterprise customers" produce completely different architectures at completely different costs.
What you can leave out
Screen designs, a technology preference, and a feature list numbered to three decimal places. If you have them we will read them, but none of them are what we need to give you a straight answer.
