Brief

Pattern

A reusable solution you can apply to your work.

A brief is a short, frame-setting document that names what you’re building, who it’s for, what matters most, and what would count as success, before any spec or plan exists.

“If you can’t describe what you are doing as a process, you don’t know what you’re doing.” — W. Edwards Deming

Understand This First

Application – the brief names which application (or feature) it’s for.
Problem – a brief starts with the problem, not the solution.

This is a strategic pattern, and it sits upstream of almost every other decision artifact in the book. Before anyone writes a Specification, a Design Doc, or the Acceptance Criteria that will check the result, someone has to answer a smaller and more awkward question: what are we doing, and why is it worth doing? That answer, written down, is the brief.

In a pre-agent workflow, the brief was often implicit. A senior engineer, a PM, and a designer shared enough context that a fifteen-minute hallway conversation could serve as the frame, and the spec was where things got written down for real. With an AI agent in the loop, that implicit layer collapses. The agent has no shared context, no intuition about what you actually care about, and no inhibition about shipping the wrong thing quickly. The brief is what you use to make intent explicit before the agent starts producing artifacts.

Problem

How do you align a human team, or a human and an agent, on what you’re actually trying to accomplish, before anyone writes a single specification or line of code?

Jumping straight to the spec is tempting, because specs feel like progress. But a spec answers how at a level of detail that only makes sense once you’ve agreed on what and why. Skip the brief and you get specs for the wrong thing, built beautifully. Conflate the brief with the spec and you lose the cheap, fast alignment document that lets you change direction before the commitments get expensive.

Forces

Briefs must be short enough that stakeholders actually read them, but specific enough to rule out obvious misunderstandings.
The brief should name what matters most, but “most” is a ranking, which means saying some things matter less, which is politically uncomfortable.
A brief has to be stable enough to build against, but the act of trying to build will reveal that parts of it were wrong.
An agent will run with whatever brief you give it, including a bad one, so ambiguity that a human teammate would flag becomes silent error with an agent.

Solution

Write a short document, short enough to read in one sitting, that answers six questions before any spec or plan exists:

What is the product, feature, or change? One or two sentences naming the thing.
What problem does it solve? The user-visible pain or opportunity, not the technical itch.
Who is it for? A specific audience, named specifically. Not “users,” but who, exactly.
What matters most? A ranking, not a list. Speed over polish, or polish over speed. Reliability ahead of feature breadth, or the reverse. If you will not say which side of the tradeoff wins when the two collide, the brief has not done its job.
What constraints exist? The non-negotiables: platforms, deadlines, compliance, cost envelopes, compatibility.
What would count as success? How you’ll know it worked, in a form you could check.

A brief deliberately does not resolve implementation detail. That’s the spec’s job. A brief that has already chosen the database, the framework, and the API shape is a brief that has skipped its own review gate, and usually one that’s locked in the first idea someone thought of.

The load-bearing item is the fourth one. What matters most is the tie-breaker the agent will reach for every time it hits a tradeoff the spec doesn’t resolve. “Speed over polish for this version” tells the agent (and the human reviewer) that a fast, rough checkout flow beats an elegant one that ships a week later. Without a ranking, every tradeoff rolls back up to the human, which defeats a large part of what agents are supposed to do for you.

Keep the brief in the repository, alongside the spec it will eventually spawn. A one-page BRIEF.md that the agent reads at the start of every session, and that you revise as you learn, is worth more than a ten-page document that lives in someone’s Google Drive.

How It Plays Out

A solo founder wants to add a local MCP server to their desktop app so external agents can drive key functions. Before touching a spec, she writes a brief:

Add a local MCP server to the app so external agent tools can control key app functions securely over localhost. It’s for power users who already run Claude Code or Cursor and want to script the app from those environments. Priority: it must be easy for nontechnical users to enable (one toggle, no config files), and it must work reliably on macOS and Windows. Constraints: localhost only, no network exposure, no new dependencies on paid services. Success: a user can toggle the server on, connect from Claude Code, and run the three core functions from there without reading documentation.

That paragraph is enough to point an agent at the right spec. The agent can now ask the right clarifying questions: which three core functions? what authentication model for localhost? what does “toggle on” look like in the existing settings UI? None of those are in the brief, and they shouldn’t be; they belong in the spec. But all three are grounded by something in the brief, so the spec’s answers are traceable back to the original intent.

Contrast that with a team whose entire brief is “add MCP support.” The agent has no audience in mind. It cannot tell whether the target is a power user who lives inside Claude Code or the occasional customer who just wants the feature visible in a release note. It has no way to rank speed against security when those pull in opposite directions, and no success definition to stop at once the work is enough. So it guesses, confidently, and produces four hundred lines of code that solve the wrong problem competently. Every clarification after that point is a rollback of work already done, not a refinement of work about to happen.

Tip

When you hand an agent a brief, tell it the brief is a brief. Say: “This is an alignment document, not a spec. Before you propose any implementation, tell me what questions you’d need answered to write the spec, and which parts of the brief you think are ambiguous.” That single instruction turns the agent from an impatient implementer into a useful editor of your own intent.

Consequences

A good brief raises the floor on every downstream artifact. The spec gets written against a shared understanding of audience and priority. The design doc knows which tradeoffs it’s allowed to resolve and which roll back up to the human. The acceptance criteria have a success definition to anchor to. The agent has a document it can re-read at the top of every session to remember what it’s actually doing.

The cost is discipline. Writing “what matters most” is uncomfortable because it forces you to say some things matter less, and the thing that matters less is often somebody’s pet concern. Briefs that try to please everyone rank nothing, which leaves the agent exactly as adrift as if you’d written no brief at all.

Briefs also go stale. The audience shifts, the constraints relax, the success definition turns out to be the wrong one. A brief that was right at the start of the month can be wrong by the end of the quarter. Treat the brief as a living document during active work and archive it (don’t delete it) once the feature stabilizes, so the reasoning behind the spec remains traceable.

The biggest failure mode is letting the agent expand the brief into a spec without a human review gate. A good agent will helpfully offer to “flesh this out” and produce a ten-page document that looks authoritative and hasn’t been reviewed by anyone. That document will then be treated as the brief by everyone downstream, including later agent sessions, and the original intent will be lost. Keep the human in the loop at the brief-to-spec boundary, even when you trust the agent for everything after that.

Upstream of: Specification – a spec is the brief, expanded into the detail a builder needs.
Upstream of: Requirement – requirements make the brief’s “what it must do” concrete and testable.
Upstream of: Design Doc – the design doc translates the brief’s intent into a technical plan.
Upstream of: Acceptance Criteria – acceptance criteria make the brief’s success definition checkable.
Upstream of: Architecture Decision Record – ADRs record the decisions the brief couldn’t resolve in advance.
Uses: Problem – every brief names a problem.
Uses: User – every brief names an audience.
Uses: Value Proposition – every brief names why the thing is worth doing.
Uses: Constraint – the brief’s constraints section lists the non-negotiables.
Enables: Bounded Autonomy – bounded autonomy needs a tie-breaker; the brief’s “what matters most” provides one.
Enables: Approval Policy – approval gates are easier to draw when the brief has already separated what matters from what doesn’t.
Enables: Plan Mode – plan mode produces better plans when it has a brief to plan against, not a bare prompt.
Enables: Spec-Driven Development – SDD workflows start from a brief, even when they don’t name it.
Enables: Research, Plan, Implement – the research step is cheaper when the brief has already narrowed what’s worth researching.
Contrasts with: Vibe Coding – vibe coding is what happens when you skip the brief and let the agent infer intent from the conversation.
Refined by: Judgment – writing a good brief is itself a judgment act.
Refined by: Taste – the brief is where taste decisions get pinned down in language before code makes them permanent.

Sources

Ryan Singer codified the modern short-form product brief as the pitch in Shape Up: Stop Running in Circles and Ship Work That Matters (Basecamp, 2019). The six-questions framing and the emphasis on ranking priorities rather than listing them owes a direct debt to his treatment.
Colin Bryar and Bill Carr described Amazon’s PR/FAQ and six-pager conventions in Working Backwards: Insights, Stories, and Secrets from Inside Amazon (St. Martin’s Press, 2021). Both are brief-shaped artifacts that force a team to articulate the customer-facing outcome before any engineering work starts.
Marty Cagan’s product brief format in Inspired: How to Create Tech Products Customers Love (Wiley, 2nd ed. 2017) established the modern PM habit of writing a short audience-and-value document before kicking off a spec cycle.
The idea of the brief as a frame-setting document has deep roots in design and advertising practice, where the creative brief has long been the short document that aligns a client, a strategist, and a creative team before anyone produces comps.

Keyboard shortcuts