Project brief template
Ask your agent to draft the brief at kickoff, share one link, and let stakeholders comment on the exact line — before anyone builds anything.
A project brief answers the question everyone asks at kickoff but nobody writes down: "What are we actually doing, and why?" The writing takes five minutes with an agent. The part that kills most briefs is what happens after — feedback in email, a comment on the wrong version, a revision nobody saw. Share the Drafty link and the reactions land in one place, on the exact line they're about.
Generate it with your agent
Paste this into Claude, Cursor, or any agent:
See it on a real one
What goes in a project brief
Six sections. If it runs past a page, it's a project plan — not a brief.
- Background — why the project exists. The business or user problem, and the context a new stakeholder would need to understand it. Two or three sentences.
- Goal — one sentence stating what's true when the project is done. Not a list of five goals; one. If you have five, pick the one that matters most.
- Scope — what's in, and explicitly what's out. The out-of-scope list is often more useful than the in-scope one: it closes the "can we also add…" conversation before it starts.
- Deliverables — the tangible outputs. Not "improve the onboarding flow" — "a revised onboarding flow, a new email sequence, and updated in-app tooltips."
- Timeline — key milestones with dates, not a Gantt chart. Three to five rows: kickoff, first review, final delivery.
- Stakeholders — a name against each role. Ambiguous ownership is the most common reason projects stall after the brief.
Project brief vs. project charter vs. PRD
The most common confusion is which doc to reach for. A rough rule:
- Project brief — one page, written at kickoff, for any project type. Gets everyone aligned before work starts. The right starting point.
- Project charter — longer, more formal, often required for enterprise approval gates. Contains everything in a brief plus a budget breakdown, risk register, and sign-off fields.
- PRD — scoped to a product or feature. Goes deeper on user stories, success metrics, and engineering scope. Write a brief first; the PRD follows once the brief is approved.
Most makers and PMs can skip the charter entirely and go straight from brief to execution.
When to write a project brief (and when to skip it)
Write one when more than two people need to agree on direction before work starts, or when the cost of starting wrong is high. A client project, a cross-team initiative, a new product line — all need a brief.
Skip it for a quick spike, a fix you can describe in a sentence, or solo work where you're the only stakeholder. For those, a one-pager is faster.
The brief is most useful before anyone has strong opinions about the approach. Written after work starts, it tends to describe what's already decided — and misses the alignment it was supposed to create.
FAQ
How long should a project brief be? One page is the target; two is the ceiling. A brief that needs five pages is usually a project plan with the wrong name. The constraint is the point — if you can't describe the project in a page, the scope isn't clear yet.
Who writes a project brief? The person kicking off the project: a PM, a maker, a consultant, or an agency account lead. The best briefs have early input from the people doing the work — they'll catch scope that looks reasonable in a doc but isn't feasible in practice.
What's the difference between a project brief and a creative brief? A project brief covers any project type — goal, scope, deliverables, timeline, owners. A creative brief goes deeper on brand direction, tone, audience insights, and messaging for creative work like a campaign or a rebrand. Start with a project brief; add creative-specific sections if the work needs them.
What's the difference between a project brief and a project charter? A charter is the formal, enterprise-grade version: longer, more detailed, usually requires executive sign-off. A brief is lighter and faster — the right tool for most teams. If your organization has an approval gate that requires a charter, the brief is still worth writing first.
Can a project brief change after kickoff? Yes, but changes need to be visible. The problem with a brief that lives in a Google Doc is that edits happen silently and stakeholders don't know which version they're looking at. When the brief lives on a shared link, revisions stay on the same URL — and your agent can ship updates in place.
What's the most common mistake in a project brief? Scope that sounds specific but isn't. "Redesign the website" is not a deliverable. "A new homepage, pricing page, and contact form — desktop only, no CMS migration" is. The more precisely you describe what's out, the fewer surprises you get mid-project.