Most project frustration traces back to a vague brief. Here's how to write one that actually sets a project up to succeed, rather than setting up disagreement later.
Describe the Problem, Not Just the Deliverable
A brief that says "we need a new website" gives far less to work with than one that explains what's actually wrong with the current situation. The problem statement shapes better solutions than a feature list does, because it gives the team building the solution room to propose an approach you might not have considered, rather than just executing a predetermined spec.
Be Honest About Constraints Upfront
Budget range, timeline flexibility, and internal approval processes are all things worth stating clearly from the start — withholding them doesn't protect your negotiating position, it just produces proposals that don't fit. A vendor proposing a solution without knowing your real budget range is essentially guessing, and the resulting mismatch wastes both sides' time.
Include Examples of What You Don't Want, Not Just What You Do
Negative examples — competitor sites or past experiences you specifically want to avoid — often communicate more clearly than aspirational references alone. Saying "not like this" about a specific example is often more precise and actionable than trying to describe an abstract aesthetic or approach in words alone.
Define What Success Looks Like, Concretely
"We'll know it worked if X" is one of the most useful sentences you can put in a brief, and one of the rarest. Whether that's a specific business metric, a qualitative outcome, or a concrete milestone, having it stated explicitly gives everyone involved a shared target rather than relying on subjective, after-the-fact judgment of whether the project succeeded.
If you're putting together a brief for a real project, we're happy to help shape it. About digitally scaled
A Brief Is a Starting Point, Not a Contract
A good brief invites clarifying questions rather than trying to anticipate every possible detail upfront. If a vendor reads your brief and has no questions at all, that's sometimes a sign they're not engaging deeply enough with the specifics of your situation, rather than a sign your brief was unusually thorough.
What to Include About Your Internal Approval Process
A brief that explains who needs to sign off on major decisions, and roughly how long that typically takes, helps a vendor build a realistic timeline and set expectations with their own team. Vendors surprised by a lengthy, multi-stakeholder approval process partway through a project often end up building in schedule buffer reactively, after a delay has already happened, rather than planning for it from the start.
This is one of the most commonly omitted pieces of a brief, even though it directly affects how realistic any proposed timeline can actually be.
A Simple Structure for Organizing a Brief
A clear brief doesn't need to be long — it needs to cover a few specific things in order: the problem you're solving, who it affects, what constraints you're working within, what success looks like, and any examples of what you do or don't want. Organizing a brief around these five elements, even briefly, tends to produce a more useful document than a longer, less structured one covering the same ground in a less organized way.
What Happens When a Brief Is Too Prescriptive
Some briefs go too far in the opposite direction — specifying exact solutions, colors, or technical approaches rather than the underlying problem and goals. This can inadvertently prevent a vendor from proposing a better approach they'd otherwise have suggested, since they're being asked to execute a predetermined spec rather than genuinely solve a problem. A useful brief states goals and constraints clearly while leaving room for the vendor's expertise to shape the actual solution.
Reviewing a Brief Before Sending It
Before sending a brief to any prospective vendor, it's worth reading it as if you were a stranger with no context on your business. Does the problem statement make sense without additional explanation? Are the constraints specific enough to be useful? A brief that requires a follow-up call just to clarify basic facts wastes time that a clearer initial document would have saved for everyone involved.
How a Good Brief Evolves Through the Sales Conversation
A brief doesn't need to be perfect on the first draft — the best ones often get refined through a genuine back-and-forth conversation with a prospective vendor, where their clarifying questions surface gaps you hadn't considered. Treating the initial brief as a strong starting point rather than a final, locked document keeps that refinement process productive.
Common Brief Mistakes That Undermine an Otherwise Good Process
Sending an identical brief to multiple vendors without any tailoring sometimes produces proposals that don't account for real differences in how each vendor might approach your specific situation. Similarly, an unrealistic timeline stated as fixed, without acknowledging real flexibility, can push vendors toward proposals that quietly cut corners just to appear to meet the stated deadline.
How to Brief for an Ongoing Relationship Versus a One-Time Project
A brief for an ongoing partnership benefits from covering longer-term goals and how success will be measured over time, not just the immediate deliverable. This context helps a prospective long-term partner understand whether they're a good fit for where you're headed, not just what you need right now.
What to Do When You Genuinely Don't Know Your Own Requirements Yet
It's reasonable to bring a vendor in for a paid discovery engagement specifically to help define requirements, rather than trying to write a full brief for something you haven't yet figured out. Being upfront that you need help defining the problem, not just executing a solution, sets an honest, productive starting point.
Red Flags in How a Vendor Responds to Your Brief
A vendor that proposes a solution without asking any clarifying questions, regardless of how detailed your brief was, may not be engaging deeply with your specific situation. Conversely, thoughtful clarifying questions that reference specifics from your brief are a good sign of genuine engagement worth valuing in vendor selection.
Key Takeaways
- A clear problem statement gives room for better solutions than a rigid feature list handed down as a spec.
- Honest constraints — budget, timeline, approval process — upfront produce proposals that actually fit your situation.
- Specific negative examples often communicate preferences more precisely than aspirational, abstract references.
- A concrete definition of success gives everyone a shared, objective target rather than subjective after-the-fact judgment.
Frequently Asked Questions
Is it risky to share our actual budget with a vendor?
Generally no — sharing a realistic range produces proposals that actually fit, while withholding it more often produces mismatched proposals than it protects any real negotiating advantage.
How detailed should a brief be for a smaller project?
Even a short brief benefits from covering the problem, constraints, and success criteria — detail should scale with project complexity, but those core elements matter regardless of size.
What if we don't yet know exactly what we want?
That's fine to say directly — a good brief can describe the problem and desired outcome even without a fully formed solution in mind, and a good partner will help shape the approach.
Should we include our internal approval process in the brief?
Yes — explaining who needs to sign off and roughly how long that takes helps a vendor build a realistic timeline rather than being surprised by delays later.
What's a simple way to structure a brief if we're not sure where to start?
Organizing it around five elements — the problem, who it affects, your constraints, what success looks like, and examples — produces a clear, useful document even if kept brief.
Can a brief be too detailed or prescriptive?
Yes — specifying an exact solution rather than the underlying problem can prevent a vendor from proposing a better approach based on their own expertise.
How should we review a brief before sending it?
Read it as a stranger with no context would, checking whether the problem and constraints are clear without requiring a follow-up call just to understand the basics.
Should the brief stay exactly the same throughout the vendor selection process?
No — the best briefs get refined through genuine conversation with prospective vendors, whose clarifying questions often surface gaps worth addressing.
What common mistakes undermine an otherwise good briefing process?
Sending an identical, untailored brief to every vendor and stating an unrealistic fixed timeline without acknowledging flexibility are both common, avoidable mistakes.
How should a brief differ for an ongoing relationship versus a one-time project?
It benefits from covering longer-term goals and how success will be measured over time, helping a prospective partner understand fit beyond the immediate deliverable.
What if we don't know our own requirements well enough to write a brief?
A paid discovery engagement specifically to define requirements is a reasonable approach, and being upfront about needing that help sets an honest starting point.
Is it helpful to include past examples of work we've liked from any source?
Yes — references don't need to come from a direct competitor; examples from any source that capture a quality or approach you want help communicate intent clearly.
