How Do You Know if Your Brief Is Actually Buildable?

A brief that reads well is not the same as a brief that builds well. The two things feel similar from the inside, which is exactly why the gap between them causes so much damage. A document can be coherent, well-structured, and genuinely exciting to read, and still leave a development team with nowhere solid to stand. The language feels clear until someone has to make a decision based on it, and then it isn't clear at all.

We see this pattern regularly. A client arrives with a brief they feel confident about. They've spent time on it. It describes the product they want, the audience they're targeting, and the problem they're trying to solve. On paper, it looks ready. But when we start asking specific questions, the answers are in the client's head, and sometimes only partially formed even there.

The brief reads as finished long before the thinking behind it actually is.

The result isn't just frustration during handover. Gaps in a brief become scope creep, rework, and budget overruns during build. According to Geneca's survey on software project failure, up to 77% of respondents reported not knowing how to tell when their project is "done", and fewer than 20% felt their requirements were genuinely aligned with the business. That starts in the brief. A brief that hasn't answered the hard questions doesn't become clearer over time. It becomes more expensive.

This article walks through the gaps we find most often, why they appear, and what you can do before handover to catch them yourself.

Why Briefs That Read Well Still Build Badly

A well-written brief creates a feeling of completeness. Sentences flow. The vision is compelling. The audience feels defined. Nobody reading it would immediately flag a problem, because the problems are in what the document doesn't say, not in what it does.

The issue is that briefs are typically written from the perspective of the person commissioning the work. That person knows a great deal about the domain, the users, and the intended experience. So when they write "simple onboarding" or "intuitive navigation", those phrases carry a lot of unstated meaning. To them, the phrase is a shorthand for something specific. To a designer or developer reading it cold, it's a blank space dressed up as an instruction.

Specificity is the gap. Phrases like "users should feel confident" or "the flow should be seamless" describe a desired outcome without describing what would produce it. They don't tell anyone what to build. They describe how the client will feel if it works, which is a very different thing.

This isn't a problem of effort or intelligence. Briefs are written at a particular stage of thinking, often before the hard questions have been properly confronted. The writer knows the product well enough to describe it in broad strokes, but hasn't yet been forced to answer the specific questions a builder will need to ask. Those questions surface later, during build, and at that point answering them costs far more than it would have done at the start.

The User Intent Gap

One of the first questions we ask about any product is what the user is actually trying to do, and how they're currently doing it without the product. This isn't an abstract research question. It determines whether the product has a reason to exist at all, and it shapes every decision about how the product should behave.

Briefs regularly describe the user in demographic terms. Age, income bracket, lifestyle. These details aren't useless, but they don't tell you what the user wants to accomplish in a specific moment, or what's getting in the way. A brief that describes a "25-34 year old professional" has not described a user intent. It's described a person. Those aren't the same thing.

We worked with a pre-launch founder in the football industry who arrived with a colour-coded spreadsheet mapping out competitor products, with the aim of merging several of them into one. The brief, in effect, was the spreadsheet. It described features in detail. What it didn't describe was why a user would choose an all-in-one product over the specialised apps they were already using, or whether consolidation would make individual features weaker rather than more useful. When we started asking those questions, the founder became deflated. But those questions weren't obstacles to the project. They were the project. A brief built on feature lists without a clear account of user intent is a plan for building something, not a plan for building the right thing.

Before handover, write down the single action your primary user takes in their first session. If you can't describe it in one sentence, the intent hasn't been resolved yet.

The Success Criteria Gap

A brief should answer a question that most briefs leave open: how will you know it worked? Success criteria are often absent entirely, or present only in the vaguest terms. "High engagement", "strong retention", "positive user feedback" are wishes. Criteria are measurable, time-bound, and specific enough that two people can agree whether they've been met.

We worked with a pre-investment client whose investor conversations had covered technology, marketing, and market size in detail, but had never touched on how the product would feel to use, or what user retention targets looked like. The silence was read as approval. What it actually indicated was that investors hadn't yet grasped the emotional dimension of the product, and so the right questions hadn't been asked. We had to go back and build out that picture rather than accepting the absence of challenge as confirmation.

Success criteria that no one disputes are usually the ones that no one has tested.

This matters for briefs because undefined success criteria create two problems during build. First, the team doesn't know what they're optimising for, so decisions get made on instinct or internal preference rather than on what will actually serve the product's goals. Second, there's no shared basis for evaluating whether a feature or a flow is good enough, which means every review becomes a negotiation rather than an assessment.

Concrete success criteria also protect against scope creep. When "done" has a clear definition, it becomes much harder to justify adding features because they might improve something that hasn't been measured.

Define at least one measurable outcome for each major feature in the brief. If a feature doesn't connect to a measurable outcome, question whether it belongs in the first version.

The Behavioural Triggers Gap

Most briefs describe what the product should do. Far fewer describe why a user would do it. The distinction matters enormously in practice, because the gap between a user knowing a feature exists and a user actually choosing to engage with it is where products lose people.

A brief might specify that users can set weekly goals, track their progress, and review their history. These are features. What the brief rarely addresses is what prompts a user to set a goal in the first place, what makes them return to check their progress rather than forgetting the product exists, and what happens psychologically when they miss a target. Each of those moments requires a design decision, and if the brief hasn't thought through the behavioural triggers, those decisions get made during build without the context they need.

Every feature in a product should earn its place by either helping users reach their goals or removing friction that stands in their way. That's a useful test to apply to each item in a brief. Does this feature have a clear trigger that makes a user want to use it? Does it help them at the right moment, or does it ask something of them when they're not ready? Does the notification strategy support the user or create pressure they didn't ask for?

These questions don't require a psychologist to answer. They require someone in the room during the brief stage who is thinking from the user's perspective, not the product's perspective. The brief should capture that thinking, not leave it to be resolved during design.

The Failure States Gap

Briefs describe the happy path. The user opens the product, completes the flow, gets the value, returns. This is understandable. The brief is a document of intent, and intent is optimistic by nature. But a product that only has a plan for things going right is a product that hasn't been fully designed yet.

Failure states are the moments when something doesn't go as planned. A user misunderstands an instruction. An action doesn't produce the expected result. A user loses progress and doesn't know how to recover it. These moments happen constantly in real products, and how the product handles them determines whether the user gives it another chance or abandons it entirely.

On a dating app project focused on verified profiles and preventing bots, the client chose to skip discovery for the messaging component and focus the brief entirely on the onboarding process. The failure state they hadn't planned for was what happened when users who had passed rigorous verification then encountered a messaging feature that allowed automated and fake messages. The onboarding and the messaging were completely misaligned. Fixing that misalignment meant rewriting the entire messaging section, which cost approximately £15,000 in additional budget and two months of extra work. The failure state wasn't exotic or hard to predict. It was a direct consequence of only designing the parts of the product that felt exciting to the client.

A brief that has thought through failure states will include guidance on error messaging, recovery flows, and the emotional tone the product should take when things go wrong. It doesn't need to anticipate every edge case. It does need to make clear that the product should feel trustworthy under pressure, and to describe what that looks like.

How Scope Creep Starts in the Brief

Scope creep is often described as a problem that emerges during build, driven by changing minds and new ideas. That's true, but it usually has an earlier cause. Scope creep most often starts in a brief that hasn't been specific enough about what's in and what's out. Ambiguity isn't neutral. It creates space, and space gets filled.

A brief that says "users should be able to manage their profile" has not defined scope. It's opened a conversation that will run through every design review and every sprint. Does profile management include privacy settings? Notification preferences? Account deletion? Connected accounts? Each of those is a decision, and without guidance from the brief, each one becomes a negotiation during build.

We ran a project on a grassroots football club app where the client wanted to replicate several different apps into one product. We advised a limited feature set for launch, with a plan to iterate based on what users actually engaged with. The client wouldn't act on that advice. The scope kept expanding, the budget kept rising, and the product never reached market because the complexity became unmanageable. The two co-founders were, in Simon's words, "very, very strong willed, both of them contributing to the overall constant push to add more things." The brief had never resolved what the product was at its core, so everything felt equally necessary.

A buildable brief defines boundaries as clearly as it defines content. It names what's in scope, and it names what's out of scope for the first version. Both lists are necessary. A brief without an out-of-scope list is an invitation for everything to gradually become in scope.

1. Write a named list of features included in version one.
2. Write a separate named list of features explicitly deferred to a later version.
3. Agree both lists with all decision-makers before handover.
4. Treat any addition to list one as a scope change that requires a formal decision.

What Happens When Discovery Is Skipped

Discovery is the stage where the brief gets tested against reality. It's where assumptions are checked, user behaviour is observed, and the product's core logic is stress-tested before any build begins. Skipping it doesn't remove the uncertainty it would have resolved, and a sound app planning and strategy process is precisely what catches that uncertainty early. It just moves the resolution point to a later, more expensive stage.

The dating app example is a precise illustration of this. Discovery was done thoroughly for the onboarding flow, which was the part the client cared most about. It was skipped for messaging, which felt less central to the product's identity. But messaging was deeply interconnected with onboarding. The entire point of verified onboarding was to create a trustworthy environment, and a messaging feature built without discovery undermined that environment completely. The product contradicted itself, and the cost of resolving that contradiction was £15,000 and two months of time. Nielsen Norman Group has found that investing in discovery reduces the risk of project failure by up to 75%. Partial discovery, as this case shows, doesn't produce partial risk reduction. The components of a product affect each other, and discovery needs to cover all of them.

Skipping discovery is rarely a decision to skip it entirely. More often it's a series of smaller decisions to focus on the exciting parts and trust that the rest will figure itself out. It doesn't. The parts that don't get discovery attention become the parts that require the most rework.

Map the dependencies between every major feature in your brief before handover. If a feature touches another feature, both need discovery coverage. Gaps in one create problems in the other.

How to Audit Your Own Brief Before Handover

An audit doesn't require an external reviewer, though one helps. It requires reading the brief as though you have no prior knowledge of the product and no access to the thinking behind it. The question to ask at every point is whether the instruction is specific enough for someone who has never been in the room to make a correct decision based on it.

These are the questions we use to test whether a brief is ready:

The purpose of this audit isn't to make the brief longer. A brief that answers all of these questions concisely is better than one that answers them at length. The goal is to close the gaps before they reach a development team, where closing them costs significantly more time and money than closing them now.

When a client comes to us without this clarity, we don't begin build work. We ask questions, work through the gaps together, and return to the brief before anything else happens. That process protects the client's budget as much as the product's quality.

Conclusion

A brief is a promise about what will be built. The gap between what a brief implies and what it actually specifies is where budgets go, where timelines slip, and where products end up misaligned with the users they were designed for. The grassroots football app that never reached market, the dating app messaging section that cost £15,000 to rewrite, the football industry founder whose feature list had no user intent behind it: each of those outcomes had an earlier cause, and the earlier cause was a brief that hadn't been properly tested.

The good news is that most of these gaps can be found before handover. They don't require extensive research or specialist tools. They require someone willing to ask specific questions and sit with the discomfort of not yet having specific answers. That discomfort at the brief stage is productive. The same discomfort during build, with a team waiting on decisions, is expensive.

Briefs that build well are more honest about what's been resolved and what hasn't, regardless of length or detail. That honesty is what makes them useful.

If you're preparing to hand over a brief and you're not sure it's ready, let's talk about your project before build begins.

Frequently Asked Questions