How to Write a Project Brief That Actually Gets Used

Most project briefs are written once and read never. They live in a shared drive, growing stale as the project evolves, referenced only when someone new joins the project and needs context. By then, the brief is so outdated that it creates more confusion than clarity.

This is not a documentation problem. It is a design problem. The typical project brief is designed as a formal document -- comprehensive, detailed, and thorough. But the people who need it want something different: a quick-reference guide they can consult when making decisions, a scope boundary they can point to when requests creep in, and a success definition they can measure against when the project finishes.

A project brief that gets used is not a long document. It is a concise, living artifact that answers the questions people actually ask during a project. This guide covers how to write one.

Why Most Briefs Fail

Briefs fail for predictable reasons, and understanding these reasons helps you design one that succeeds.

Too Long

A ten-page brief is not a brief. It is a specification. The length itself is a barrier to use -- nobody is going to reread ten pages to check whether a feature is in scope. If the answer to a simple question requires reading multiple pages, people will not consult the document. They will guess, ask someone, or make an assumption. The brief becomes a write-only artifact.

Too Vague

The opposite failure mode is a brief so high-level that it does not actually constrain anything. "We will improve the user experience" is a goal, not a scope definition. It does not tell the team what to build, what not to build, or how to know when they are done. A vague brief is worse than no brief because it creates the illusion of alignment while everyone interprets it differently.

Disconnected From Execution

Many briefs describe what the project will accomplish but not how the work will be structured. There is no connection between the brief's objectives and the tasks in the task management system. The brief is a strategic document; the task list is a tactical document; and nobody maintains the link between them.

Written by One Person

Briefs written unilaterally by a project manager or product manager often miss the technical constraints that engineering knows about, the design implications that designers would flag, and the operational considerations that support teams would raise. A brief that does not incorporate diverse perspectives creates alignment on an incomplete picture.

The Five-Section Brief

An effective project brief has five sections. Each section answers a specific question that arises repeatedly during project execution. The total length should be one to two pages -- short enough to read in five minutes and consult in thirty seconds.

Section 1: Context and Problem (Why Are We Doing This?)

This section explains the background and the problem being solved. It should be two to three paragraphs that someone unfamiliar with the project can read to understand why this work matters.

Include:

• The business context (what is happening in the market, with customers, or in the organization that makes this project necessary)
• The specific problem or opportunity being addressed
• The impact of not doing this project (what happens if we do nothing)

Do not include:

• The solution (that comes later)
• Detailed data analysis (link to it if it exists)
• Historical context older than is necessary to understand the current situation

Example: "Our customer onboarding completion rate has declined from 78% to 62% over the past two quarters. Customer support tickets related to onboarding confusion have increased 40%. Customers who do not complete onboarding have a 3x higher churn rate in the first 90 days. The current onboarding flow was designed for a simpler product and has not been updated to reflect the features added in the past year."

This context tells everyone on the project why the work matters, what success looks like in business terms, and what the cost of inaction is.

Section 2: Scope and Deliverables (What Are We Building?)

This section defines the boundaries of the project. It answers two questions: what is included, and what is explicitly excluded.

The exclusion list is as important as the inclusion list. Without explicit exclusions, scope creeps in through well-intentioned suggestions: "While we are redesigning onboarding, should not we also update the settings page?" An explicit exclusion list provides a reference point: "The settings page is out of scope for this project."

Format:

In scope:

• Redesign the five-step onboarding flow for new users
• Add progress indicator and estimated time
• Create skip/save-and-return functionality
• Build onboarding analytics dashboard

Out of scope:

• Changes to the existing user settings page
• Mobile app onboarding (separate project planned for Q3)
• Integration with third-party onboarding tools
• Changes to the pricing or signup page

Deliverables:

| Deliverable | Description | Owner | |---|---|---| | Redesigned onboarding flow | Five-step interactive onboarding with progress tracking | Design + Engineering | | Analytics dashboard | Completion rates, drop-off points, time-to-complete | Engineering | | Documentation | Updated help articles for new onboarding flow | Content |

Section 3: Success Criteria (How Do We Know It Worked?)

This section defines measurable outcomes that determine whether the project succeeded. Without explicit success criteria, the project is never "done" -- there is always another improvement, another feature, another refinement.

Success criteria should be:

• Specific: Not "improve onboarding" but "increase onboarding completion rate"
• Measurable: Include a target number or threshold
• Time-bound: Specify when the measurement will be taken
• Realistic: Based on reasonable expectations, not aspirational fantasy

Example:

| Metric | Current | Target | Measurement Date | |---|---|---|---| | Onboarding completion rate | 62% | 75%+ | 60 days post-launch | | Average onboarding time | 12 minutes | Under 8 minutes | 60 days post-launch | | Onboarding-related support tickets | 45/week | Under 20/week | 30 days post-launch | | 90-day retention for new users | 55% | 65%+ | 90 days post-launch |

These criteria serve multiple purposes. They align the team on what success means. They provide a decision-making framework during execution ("Does this feature help us reach 75% completion?"). And they create accountability after launch ("Did we achieve what we set out to achieve?").

Section 4: Constraints and Dependencies (What Limits Us?)

Every project operates within constraints. Making these explicit prevents surprises during execution.

Timeline constraints: Hard deadlines, launch windows, dependencies on other projects.

Resource constraints: Available team members, budget limits, technology restrictions.

Technical constraints: Platform limitations, integration requirements, performance requirements.

Dependencies: What must be completed before this project can proceed? What does this project block for other teams?

Example:

| Constraint | Detail | |---|---| | Deadline | Must launch before Q2 product update on April 15 | | Team | 2 engineers, 1 designer (part-time), 1 content writer (part-time) | | Technical | Must work with existing authentication system; no new databases | | Dependency | Requires updated branding assets from the design team (due March 1) |

Section 5: Task Breakdown and Timeline (How Will We Execute?)

This section connects the brief to the task management system. It outlines the major phases and milestones, with links to the detailed task breakdown in your project management tool.

Phase structure:

| Phase | Duration | Key Milestone | Status | |---|---|---|---| | Research and Design | 2 weeks | Design mockups approved | Not started | | Development Sprint 1 | 2 weeks | Core flow implemented | Not started | | Development Sprint 2 | 2 weeks | Analytics and edge cases | Not started | | Testing and QA | 1 week | All critical bugs resolved | Not started | | Launch | 1 week | Live for all new users | Not started |

Link to tasks: Each phase should link to the corresponding project or milestone in your task management system. In SettlTM, you would create a project for the onboarding redesign, add milestones matching the phases above, and link from the brief to the project dashboard.

This connection ensures that the brief remains relevant throughout execution. When someone reads the brief and wants to see current status, they follow the link to the live task data rather than relying on the brief's static snapshot.

Writing the Brief: Process

Step 1: Draft Solo (30 minutes)

The project lead writes the first draft. This draft does not need to be perfect -- it needs to be complete enough to provoke useful feedback. Fill in all five sections with your best understanding, marking areas where you are uncertain or need input from others.

Step 2: Circulate for Async Review (2-3 days)

Share the draft with key stakeholders: engineering, design, relevant business stakeholders, and anyone whose input is critical. Ask for specific feedback:

• "Is the scope complete and correct?"
• "Are the success criteria realistic?"
• "Are there constraints I missed?"
• "Does the timeline account for your team's availability?"

Async review is better than a meeting for this purpose. People can review at their own pace, think carefully about their feedback, and provide written comments that create a record.

Step 3: Resolve Conflicts (1 meeting, 30 minutes)

If the async feedback reveals disagreements (different scope expectations, conflicting timeline estimates), hold one brief meeting to resolve them. The goal is not to discuss the entire brief but to address specific points of contention.

Step 4: Finalize and Distribute (15 minutes)

Incorporate feedback, finalize the brief, and share it with everyone involved in the project. Store it in a location that is easy to find -- linked from the project in your task management system, pinned in the project Slack channel, or bookmarked in the team wiki.

Step 5: Keep It Updated (ongoing)

A brief is a living document. When scope changes, update the brief. When success criteria are revised, update the brief. When the timeline shifts, update the brief. Each update should be minor (a sentence here, a row there) because the brief is short. If your brief is so long that updating it is burdensome, it is too long.

Linking the Brief to Task Breakdown

The most powerful feature of a well-designed brief is its connection to the task management system.

From Brief to Tasks

Each deliverable in Section 2 becomes a project or epic in your task manager. Each project is broken down into tasks with estimates, assignees, and due dates. The brief provides the "what and why"; the task breakdown provides the "how and when."

SettlTM's AI-powered task decomposition can accelerate this step. Given a deliverable like "Redesign the five-step onboarding flow," the breakdown agent can suggest subtasks: "Audit current onboarding metrics (2h)," "User interview synthesis (3h)," "Wireframe new flow (4h)," "Stakeholder review meeting (1h)," etc. You review and adjust the suggestions, then have a ready-to-execute task list linked to the brief.

From Tasks Back to Brief

When questions arise during task execution ("Is this feature in scope?" "What is the priority between these two approaches?"), the answer should be findable in the brief. If task-level decisions repeatedly require information that the brief does not contain, the brief needs updating.

This bidirectional link keeps the brief relevant and the tasks aligned with the project's intent.

Brief Templates by Project Type

The five-section structure adapts to different project types with minimal modification.

Feature Development Brief

Focus on: user problem, proposed solution, success metrics, technical constraints. Add: User stories or use cases in the scope section.

Marketing Campaign Brief

Focus on: campaign objective, target audience, channels, success metrics. Add: Brand guidelines and messaging framework in the constraints section.

Process Improvement Brief

Focus on: current process pain points, proposed changes, efficiency targets. Add: Change management considerations in the constraints section.

Research Brief

Focus on: research questions, methodology, expected outputs. Add: Participant recruitment and ethical considerations in constraints.

Key Takeaways

• A project brief that gets used is one to two pages long, answers the five questions people actually ask during a project, and connects directly to the task management system.
• The five sections are: context and problem (why), scope and deliverables (what), success criteria (how we know it worked), constraints and dependencies (what limits us), and task breakdown and timeline (how we execute).
• Explicit out-of-scope lists are as important as in-scope lists for preventing scope creep.
• Measurable success criteria align the team, guide decision-making during execution, and create accountability after launch.
• A living brief that is updated as the project evolves remains useful; a static brief written at kickoff and never updated becomes a historical artifact.

Frequently Asked Questions

How long should a project brief be? One to two pages. If it exceeds two pages, it contains detail that belongs in the task management system or in separate reference documents, not in the brief. The brief is a summary and a decision-making reference, not a comprehensive specification.

Who should write the project brief? The project lead or product manager drafts it, but key stakeholders (engineering, design, business) review and contribute. A brief written without engineering input will miss technical constraints. A brief without design input will miss user experience considerations. The draft is one person's work; the final version is a shared understanding.

What is the difference between a project brief and a PRD? A product requirements document (PRD) is typically more detailed, focusing on specific features, user stories, and acceptance criteria. A project brief is higher-level, focusing on scope boundaries, success criteria, and execution structure. For large projects, both may exist, with the brief providing the overview and the PRD providing the detail. For smaller projects, the brief may be sufficient on its own.

Should the brief include a budget? If budget is a meaningful constraint, yes. If the project uses existing team resources without incremental cost, a budget section is unnecessary. Include budget information when it affects scope decisions: "We have a budget of $5,000 for external design support, which limits us to one round of user testing."

When should the brief be written relative to project start? The brief should be finalized before significant execution begins. A brief written after work has started is a retroactive justification, not a planning tool. Ideally, the brief is drafted during the planning phase, reviewed and finalized before kickoff, and then referenced throughout execution.

Break down project briefs into actionable tasks with SettlTM -- start free at tm.settl.work