How to Write a One Page Project Brief for a Small Team (With a Copyable Example)

Quick answer

A one-page project brief works when it answers six questions on a single sheet: what outcome are we chasing, for whom, what is in and out of scope, who owns each deliverable, when is it due, and how will we judge success? If a new teammate can read it once and start working, it is doing its job. If it takes three pages to explain the scope, the scope is the problem, not the document.

This guide walks through a six-step method, a full example for a three-person team launching a seasonal promo page, a copyable template, and a review checklist you can run before anyone starts work.

Why briefs sprawl, and what to cut

Long briefs usually grow for predictable reasons: background research gets pasted in, every stakeholder adds a "nice to have," and nobody is willing to say what is explicitly not happening. The result is a document that is long enough to feel thorough and vague enough to be useless.

The one-page constraint is the fix. It forces three decisions that fuzzy briefs avoid:

• A single measurable outcome instead of a list of aspirations.
• Named owners instead of "the team will handle it."
• Explicit exclusions instead of silent assumptions.

Keep the page to roughly 400–600 words. Anything that is reference material — brand notes, past campaign data, research links — belongs in an appendix or a linked folder, not in the brief itself.

The six-step workflow

Step 1: Write the goal as one sentence with a measurable outcome

Start with a single sentence in this shape: We will [do a thing] so that [audience] [measurable outcome] by [date].

The measurable part is where most briefs fail. "Increase awareness" is not measurable. "Get 300 sign-ups to the promo waitlist by 14 November" is. If you cannot name a number yet, say so honestly and name the person who will set it — for example, "Target to be confirmed by the owner by 10 October." Do not invent a metric to make the sentence look finished.

Step 2: Name the audience and the single problem

Describe one audience segment and one problem they have. Not "small businesses" — "independent coffee shops that run seasonal promotions but have no designer on staff." Then state the problem in the audience's words: "They need a promo page live in a week and have no template."

If two audiences need two different pages, that is a scope signal, not a copywriting problem. Pick one for this brief and note the other as out of scope.

Step 3: List in-scope and out-of-scope items

Write both lists. The out-of-scope list is the most valuable part of the page because it prevents the mid-project "can we also…" conversation from becoming a silent deadline risk.

Be concrete. "No email campaign" is better than "email not included." "No paid ads; organic social only" is better than "limited promotion."

Step 4: Assign one owner per deliverable

Every deliverable gets exactly one name. Shared ownership means no ownership. A useful pattern is a short table:

"Definition of done" is optional but cheap, and it stops the "I thought you meant the draft" conversation.

Step 5: Add a short review checklist

A review checklist is not a project plan. It is the handful of things that must be true before launch. Keep it to five to seven items, each answerable yes or no. For the promo page example: copy matches the offer, form submits and sends a confirmation, page loads on a phone, links resolve, the owner has signed off, and the brief version date is current.

Step 6: Keep it to one page and version it with a date

Put a version line at the top: v1.0 — 7 Nov 2026 — owner: Alex. When scope changes, bump the version and note the change in one line. Do not silently edit the brief; a dated version trail is what lets a small team remember why a deliverable appeared or disappeared.

Copyable example: seasonal promo page for a three-person team

Below is a sample brief you can adapt. It is an illustration, not a record of a real project.

Notice what is missing: no invented conversion benchmarks, no claims about which tools will be used, no promises about results. The target is flagged as needing confirmation, which is more honest than a confident number nobody can trace.

Using an AI assistant to draft the brief

You can draft the structure with an AI document tool and then edit it yourself. In Vife's document creator you can start from a prompt, generate a structured draft, and revise sections in place — useful for turning scattered notes into the six sections above. Treat the output as a first draft: the owners, dates, and metrics must come from your team, not from the model.

A sample prompt you can try:

The [TBC] instruction matters. It gives you a visible list of decisions still to make instead of a polished page full of plausible guesses.

Review checklist before you share the brief

Run these checks on the finished page. They are judgment calls, not automated tests.

• Can a new teammate act from this alone? Hand it to someone outside the project and ask what they would do first. If they hesitate, a section is vague.
• Does every deliverable have exactly one owner? Scan the table for blank or doubled names.
• Are scope boundaries explicit? The out-of-scope list should name at least two things you expect someone to ask for.
• Is every number traceable? Each metric should have a source or a named person who will confirm it.
• Are there tool or performance claims you cannot support? Remove them. A brief does not need to promise speed or results.
• Is it one page, and is the version date current?

Common mistakes

Writing a goal with no number. "Improve engagement" cannot be reviewed at the end. Add a measurable outcome or an explicit TBC with an owner.

Skipping the out-of-scope list. Without it, scope creep is invisible until the deadline slips.

Assigning deliverables to roles instead of people. "Design will handle it" is not an owner.

Pasting in background research. It inflates the page and buries the decisions. Link to it instead.

Editing without versioning. If the brief changes and nobody knows, the team is working from different documents.

Letting an AI draft supply the facts. Generated owners, dates, and metrics look authoritative and are usually wrong. Use AI for structure and wording, then fill in the real details.

FAQ

How long should a one-page brief take to write?

For a small project, aim for 30–45 minutes of drafting plus a short review with the team. The time goes into deciding scope and owners, not into prose.

What if the project is too big for one page?

Split it. A one-page brief per phase or per deliverable group works better than a five-page brief for everything. If you cannot split it, the project likely needs a plan document, not a brief.

Should the brief include a budget?

Only if the budget affects scope decisions. A single line — "Budget: fixed at X, no new spend without owner approval" — is usually enough.

Who should own the brief?

One person, usually whoever is accountable for the outcome. They keep the version date current and decide when a scope change warrants a new version.

Can I reuse the same brief for the next campaign?

Reuse the structure, not the content. Copy the template, reset the version to v1.0, and re-check every owner, date, and metric — the team and the baseline will have changed.

Do I need a separate review checklist?

A short one inside the brief is enough for small projects. Keep it to items that are genuinely pass/fail, and delete items that are really preferences.

The takeaway

The value of a one-page brief is not the page — it is the decisions the page forces: one outcome, one audience, explicit boundaries, named owners, and a review standard. Write it in an afternoon, version it with a date, and let it be the document your team actually opens.