Why bad briefs lead to bad builds (and how to write a good one)

Quick answer: good briefs lead with the outcome (what business problem is being solved and what success looks like), describe the constraints (budget, timeline, must-haves, dealbreakers), and explicitly leave the solution open for the development team to recommend. Bad briefs invert this — they prescribe features and technologies up-front, lock in the wrong solution before discovery, and tie the team’s hands. The structure matters more than the polish.

The single biggest predictor of how a software project goes is the brief. Not the budget, not the agency’s skill, not the platform. The brief.

We see this consistently. The projects that go smoothly start from briefs that surface the actual problem. The projects that drift, miss scope, or end in disappointment usually started from briefs that were either too prescriptive in the wrong places or too vague where it mattered most.

Here’s the difference.

The PMI’s Project Management Body of Knowledge treats requirements gathering as the project’s most leveraged hours; a bad brief is the symptom of skipping that work, not a cause of failure on its own.

What a bad brief looks like

The patterns we see most often:

1. The feature list with no outcome. “We need a customer portal with login, dashboard, billing history, ticket submission, document downloads, calendar integration, and live chat.”

What’s missing: why. What problem does this solve? What does success look like? Which features are must-haves and which are nice-to-haves? Without this, the build proceeds on a list of features that may or may not address the actual need.

2. The technology specification. “We need a custom application built in React with a Node backend, deployed on AWS, integrated with Salesforce.”

What’s missing: whether the technology choice is right. Often it isn’t. By specifying the stack, the brief commits to it before anyone has tested whether simpler alternatives (a SaaS tool, a different stack, no system at all) would solve the actual problem more cheaply.

3. The wishlist with no priorities. “We need to do A, B, C, D, E, F, G, H, and ideally also I and J.”

What’s missing: which of these is most valuable. Without explicit prioritisation, every feature gets weighted equally during the build. The lower-value 80% absorbs the budget and time that should have gone to the higher-value 20%.

4. The assumed solution. “We need a mobile app for our customers.”

What’s missing: whether a mobile app is the right answer. A mobile-friendly website might solve the same problem at a fraction of the cost. Maybe an SMS workflow would be even simpler. The brief has assumed the solution before exploring the problem.

5. The mismatched stakeholders. A brief written by one stakeholder, signed off by leadership, with no input from the operational team that’ll use the system. The build proceeds; the operational team meets the result and discovers it doesn’t fit how they actually work.

What a good brief looks like

A brief that produces good builds tends to include:

1. The problem, in plain language. What’s the business problem this is solving? What happens today, and what’s wrong with that? Quantified where possible (“customers wait 4 days for a response, target is 4 hours”) rather than qualitative (“customers are frustrated”).

2. The success criteria. How will you know the project succeeded? What’s measurable? What’s qualitative? What’s the minimum viable definition of success vs. the ideal outcome?

3. The audience and stakeholders. Who will use the resulting system? Who decides what gets built? Who needs to be consulted? Who needs to be informed? When?

4. Hard constraints. Budget ceiling. Timeline. Must-have features that can’t be cut. Dealbreakers that would kill the project. Compliance requirements. Existing systems that must be preserved or integrated with.

5. Open questions. Things you genuinely don’t know yet. The brief should surface these honestly rather than papering over them.

6. Things deliberately excluded. What’s explicitly not in scope. This is often the most useful section of a brief — it’s how scope creep is prevented before it starts.

7. The solution space, but not the solution. “We’re considering a custom build vs SaaS vs upgrading our existing platform — we’re open to recommendations.” Or, if you’ve made a decision: “We’ve decided to build custom because [reasons], and want recommendations on how.” Either is fine; what doesn’t work is silently committing to a solution and writing the brief as if it were inevitable.

Why this structure works

The structural reason: a problem-led brief lets the development team genuinely engage with the problem and recommend the right solution. A solution-led brief reduces the team to implementing what was specified, even when they can see it’s wrong.

The honest consequence: when the team can see a better answer than what the brief specifies, they have two choices: implement the brief (with internal grumbling) or push back and risk the engagement. Both are bad outcomes. Good briefs avoid the situation entirely.

A brief template that works

For a custom software project, a brief that produces good outcomes typically covers:

1. The problem
   - What's the business situation today?
   - What's wrong with it?
   - What does it cost to leave it unfixed?

2. The desired outcome
   - What does success look like in measurable terms?
   - Who benefits from the change?
   - When does this need to be in place?

3. Audience and stakeholders
   - Who will use the result day-to-day?
   - Who decides what gets built?
   - Who else needs to be in the loop?

4. Constraints
   - Budget ceiling and how that's been determined
   - Timeline and what's driving it
   - Must-haves and dealbreakers
   - Compliance, regulatory, or contractual constraints
   - Existing systems that must be preserved or integrated with

5. Solution space
   - Have you decided on an approach? If so, why?
   - If not, what options have you considered?
   - What are you specifically not interested in?

6. Out of scope
   - What you've decided is not part of this project
   - Things that might come later but aren't now

7. Open questions
   - Things you genuinely don't yet know
   - Things you'd like the development team to investigate

Total length: typically 5–15 pages. Less for smaller projects, more for complex ones. The polish doesn’t matter; the structure does.

Why most clients struggle to write good briefs

The honest reasons:

• Briefs are usually written by people who haven’t done many. A new client writes one or two software briefs in their career. Templates help, but practice is what produces sharp briefs.
• The team writing the brief isn’t the team that’ll use the system. Marketing writes the brief; operations meets the result.
• It’s easier to specify features than to articulate outcomes. Features feel concrete; outcomes feel vague. The opposite is structurally true (outcomes are durable; features are fashionable).
• Stakeholders haven’t aligned. The brief is written by one stakeholder before others have weighed in. The misalignment surfaces during the build.

The fix isn’t to write better briefs in isolation. It’s to treat brief-writing as a structured collaboration with the development team — or to fold it into a discovery phase that produces the brief as one of its outputs.

What a good agency does with a bad brief

A serious agency doesn’t just implement a bad brief. They:

• Push back on what they can see is wrong (politely, with reasoning)
• Ask the questions the brief should have answered
• Propose a discovery phase to surface what the brief left ambiguous
• Refuse projects where the brief is structurally so wrong that even good execution would produce a bad result

The signal we look for in a prospective client: how do they react when we challenge the brief? The good clients are usually relieved — the brief was written under pressure, they know it has gaps, and they appreciate the engagement. The clients who treat the brief as untouchable are usually the ones whose projects later go sideways.

We push back on briefs as a matter of course. It’s the cheapest moment to course-correct.

Common questions

What makes a good software project brief? A brief that leads with the business problem and desired outcome (not features), articulates measurable success criteria, specifies hard constraints (budget, timeline, dealbreakers), maps stakeholders explicitly, and leaves the solution space genuinely open for the development team to recommend.

Why do software projects fail? Most often, because the brief was wrong — either too prescriptive (committing to features or technologies before discovery), too vague (no measurable success criteria), or written without the stakeholders who’ll actually use the result. Bad briefs produce bad builds reliably; the technology choices and team skill matter much less than people assume.

Should I include features or just outcomes in a brief? Outcomes first, features as illustrative examples. “We need to reduce response time from 4 days to 4 hours” is the outcome. “We’re thinking about a customer portal with self-service ticketing” is one possible solution. The brief should leave room for the development team to propose alternatives.

How long should a software project brief be? For a serious mid-size project: 5–15 pages. Smaller projects can use shorter briefs; larger ones may need more. The right length is the one that surfaces the genuine constraints and leaves the solution space honestly open. Polish doesn’t matter; structure does.

Who should write the brief? The person closest to the business problem, in collaboration with the people who’ll use the resulting system, with input from leadership on constraints. Often the structure is best produced through a workshop rather than written in isolation. For larger projects, the brief is usually an output of a discovery phase, not an input to it.

If you’re scoping a project and want help structuring a brief that won’t produce regret in three months, start a project and we’ll work through it with you — before any pricing conversations.