A brief is not paperwork. It is the thing that stops you building the wrong product confidently for three weeks. The goal is not a long document, it is a short one that makes the next decisions obvious.
Decide what it is in one line
If you cannot say what the thing is in a single plain sentence, the build will wander. Write that line first. Everything else in the brief either supports it or gets cut.
Name the job, not the feature
Describe who it is for and the specific job they would hire it to do, in their words. “Students who find making flashcards tedious” is a job. “An AI flashcard platform” is a feature looking for a reason. The job is what tells you whether a feature belongs.
Scope is mostly what you leave out
The most useful line in any brief is the out-of-scope list. A short must-have list for version one, and an explicit list of what you are deliberately not doing yet, is what keeps a first version shippable. Cutting is the work.
Write down what you are guessing
You will not know everything yet, and that is fine. Make a sensible assumption, then write it down as an assumption rather than burying it as a fact. The open questions you can see are the ones you can resolve.
Example shape
Common mistakes
- Writing a PRD nobody reads. If it is long, it is not a brief.
- No out-of-scope list, so v1 quietly grows until it never ships.
- Generic filler. Cut any sentence that would be true of any project.