Why we always say no to the first brief

What clients ask for and what they actually need are rarely the same thing.

3 min read

Why we always say no to the first brief

When a new client comes to us, they usually arrive with a brief. It might be detailed or it might be a paragraph. Either way, we don't start building from it.

Not because the brief is wrong — usually it's thoughtful. But because the brief describes a solution, and we need to understand the problem first.

The brief is already an answer

By the time someone writes a brief, they've already done a lot of thinking. They've identified a pain point, formed a hypothesis about how AI could solve it, and written down what they want built.

The problem is that this thinking happens in isolation, without the benefit of knowing what AI assistants can and can't actually do in production. So the brief tends to describe something either too narrow or too broad.

In both cases, starting from the brief sets the project up for disappointment.

What we do instead

We read the brief, set it aside, and start asking questions about the workflow underneath it.

What does the team do today, manually? Where does time go? What information do they consult before making a decision? What happens when something falls through the cracks?

These questions usually reveal a different problem than the one in the brief — one that's either simpler to solve or more interesting to solve than what the client originally described.

We then share what we're hearing and check whether it resonates. In most cases, the client says some version of "yes, that's actually more like what we meant."

Why clients appreciate this

The instinct to accept a brief and start building feels responsive, feels like progress. But clients don't want progress on the wrong thing.

What they want is confidence that someone actually understood their problem before starting to solve it. Pushing back on the brief, asking hard questions, and reframing the scope when necessary is how we earn that confidence.

It also makes our own work better. Building to a well-understood problem is faster and cleaner than building to an underspecified brief and discovering the gaps mid-project.

So yes — we say no to the first brief. And then we help clients write a better one.