Skip to content
Writing Style Library

Project Brief

A short kickoff document that sets an initiative’s goal, scope, constraints, and success criteria before detailed work begins.

Project Brief

Section titled “Project Brief”

A project brief sets the direction for an initiative before detailed work begins. It covers the goal, the scope, the constraints, the success criteria, and who is involved. The test of a good brief is simple: a stakeholder who has not been in the room should be able to read it once and understand why the work matters, what counts as done, and where the work stops.

The brief is deliberately high-level. It frames the problem and defines the boundaries so that detailed requirements can be written next, by the people the brief mobilizes. A brief that slides into requirements work has already failed at its primary job: a team cannot align on direction while fighting over feature details. The discipline of staying high-level is not a shortcut - it is what makes the brief useful at kickoff and what makes downstream requirements work possible.

Canonical template

Section titled “Canonical template”
# [Project Name] - Project Brief


## Goal
[The single outcome this initiative achieves. One sentence.]


## Background
[Why this problem matters now. What is broken or missing. 2-4 sentences.]


## Scope
### In scope
- [What this initiative covers]


### Out of scope
- [What this initiative explicitly does not cover]


## Constraints
- [Time, budget, technology, or dependency limits the team cannot negotiate]


## Success Criteria
- [How we will know this succeeded. Measurable if possible.]


## Team
- Owner: [Who decides]
- Contributors: [Who does the work]
- Informed: [Who needs to be kept in the loop]

When to use

Section titled “When to use”
  • Aligning a team on direction before requirements work begins
  • Communicating initiative purpose to stakeholders who need context, not detail
  • Establishing scope and constraints at the start of a project
  • Kicking off cross-functional work where roles and boundaries need to be named
  • Getting sign-off on a problem worth solving before anyone specifies the solution

When not to use

Section titled “When not to use”
  • When the team already has a defined goal and needs feature-level requirements - write a PRD instead
  • When the deliverable is a made decision with context and consequences - write an ADR instead
  • When the audience needs step-by-step instructions or operational detail

Pairs well with

Section titled “Pairs well with”

product-thinker, executive, matter-of-fact, confident, problem-solution

Often confused with

Section titled “Often confused with”

prd: A PRD (Product Requirements Document) is a structured document that defines what a product or feature should do, for whom, and why - it is the contract between a product team and an engineering team, covering problem statement, goals, non-goals, user stories, success metrics, and open questions. A project brief operates one level above: it establishes why the initiative matters and what the boundaries are, so that the PRD can be written well. The brief makes the PRD possible; it does not replace it.

one-pager: A one-pager is defined entirely by its constraint - everything must fit on one page - and makes a single argument or presents a single situation toward one decision-forcing ask. A project brief is identified by its fixed kickoff structure (Goal, Scope, Constraints, Success Criteria, Team) and an alignment purpose, not by length; a brief that fits one page is still a project brief, not a one-pager.

Tells

Section titled “Tells”
  • A single-sentence Goal section that names the initiative outcome, not a cluster of aims
  • An explicit Scope section with both in-scope and out-of-scope items named
  • A Constraints section listing limits the team cannot negotiate away
  • Success Criteria defined before any feature requirements exist
  • A Team section naming owner, contributors, and informed parties
  • Deliberate absence of user stories, feature specs, and implementation detail
  • Short enough for a stakeholder to absorb in one read - typically 200-500 words

Anti-patterns

Section titled “Anti-patterns”
  • Writing user stories, feature specs, or acceptance criteria inside the brief - The brief frames the initiative and defines its boundaries; a PRD is the structured document that defines what a product or feature should do, for whom, and why. The brief makes the PRD possible but does not replace it; mixing in requirements before the team is aligned removes the shared direction that makes requirements work effective.
  • Leaving success criteria vague or omitting them entirely - The brief must define what counts as done before requirements work begins; without success criteria the team cannot judge whether the downstream requirements actually serve the initiative goal.
  • Writing a brief that a stakeholder cannot absorb in one read - The brief exists to create shared direction quickly; if it exceeds 500 words, the initiative may not be well-defined yet or the detail belongs in a downstream document.

Failure modes

Section titled “Failure modes”
  • Over-scopes into a project plan - begins listing tasks, milestones, and timelines until the strategic framing is buried under a schedule - The brief covers goal, scope, constraints, success criteria, and team; project plans carry timelines and task breakdowns. If milestone dates appear in the brief, the document has changed shape.
  • Hedges the Goal section into a cluster of aims because committing to a single outcome is hard - lists A, B, C, and also D, leaving the team with no clear priority to align around - Force the Goal section to a single sentence; if the team cannot agree on one sentence, the initiative is not ready for a brief and naming that disagreement is the work to do first.

Instruction

Section titled “Instruction”
Write as a Project Brief. Cover: Goal (a single sentence naming the initiative outcome, not a
list of aims), Background (why this problem matters now), Scope (explicit in-scope and
out-of-scope lists), Constraints (non-negotiable limits on time, budget, or technology), Success
Criteria (how we will know this succeeded, measurable if possible), and Team (owner,
contributors, informed parties). Stay deliberately high-level - no user stories, no feature
specs, no implementation detail. A stakeholder who has not been in the room should be able to
read the brief once and understand why the work matters, what counts as done, and where the work
stops. Target 200-500 words. The Goal section must be a single sentence.

Template

Section titled “Template”

See the Project Brief template.

Section titled “Related”

Pairs well with

Section titled “Pairs well with”

Product Thinker, Executive, Matter of Fact, Confident, Problem-Solution

Avoid with

Section titled “Avoid with”

Confessional, Reverent, Playful

Often confused with

Section titled “Often confused with”

Product Requirements Document, One-Pager

Examples

Section titled “Examples”

Async-First Standup Trial - Project Brief

Section titled “Async-First Standup Trial - Project Brief”

Goal

Section titled “Goal”

Run a 30-day async standup trial with the full 11-person engineering team to determine whether replacing the synchronous daily standup with structured async posts in #team-standup delivers equitable participation across four timezones and persistent, searchable status records.

Background

Section titled “Background”

The engineering team has grown from 6 to 11 engineers across four timezones over 18 months. The current 9am Pacific standup lands at 9:30pm IST, creating a structural disadvantage for India-based engineers: they averaged 3.2 attendances per week in Q1 compared to 4.6 for US-based engineers. The 14-minute meeting produces an average of 4.2 minutes of content that changes anyone’s behavior; the remainder is status that requires no response and does not persist after the call.

Scope

Section titled “Scope”

In scope

Section titled “In scope”
  • Design and document the async standup process, including the three-field template (Shipped / In progress / Blocked or at risk), the 10am local posting window, and the on-call triage role
  • Run the 30-day trial with all 11 engineers
  • Track participation rate, blocker resolution time, and time recovered across the trial period
  • Collect qualitative feedback at the mid-point and at the Day 30 retro
  • Decide whether to adopt, adjust, or revert based on trial data

Out of scope

Section titled “Out of scope”
  • Tooling changes beyond Slack templates (no standup bots or third-party apps during the trial)
  • Changes to any sprint ceremony other than the daily standup
  • External communication about this change to stakeholders outside the engineering org during the trial

Constraints

Section titled “Constraints”
  • The trial runs for exactly 30 days without mid-cycle process changes, so week-over-week data is comparable
  • No new tooling is approved for this initiative; the format uses Slack only
  • The Thursday working session must fit within the existing 60-minute standup calendar block already held by the team

Success Criteria

Section titled “Success Criteria”
  • On-time post rate reaches or exceeds 90 percent of expected daily posts by week 3
  • India-based engineers post every weekday at a rate matching or exceeding US-based engineers
  • Median time from @mention to first substantive reply is at or below the blocker resolution baseline from the sync standup
  • The team votes at the Day 30 retro to continue, adopt permanently, or make a named adjustment rather than revert

Team

Section titled “Team”
  • Owner: Engineering manager (accountable for the trial design and the adopt/adjust/revert call)
  • Contributors: All 11 engineers (daily posting), on-call engineer rotation (daily triage)
  • Informed: Director of engineering, peer engineering managers