Most advice on writing an AI project brief treats it as a documentation exercise: list the problem, state your success criteria, describe your data, set a scope boundary. That advice is correct, and it's also missing something. The harder truth is that the act of writing the brief is a diagnostic. How easily you can answer its questions tells you more about whether you're actually ready to start an AI project than the finished document does.
Here's what that looks like in practice, and how to use the struggle itself as useful information instead of just pushing through it.
Some Questions Are Easy. Pay Attention to the Ones That Aren't
Every brief eventually asks you to describe the problem, name who's affected, and say what better looks like. For most teams, those questions are easy — maybe even too easy, because the answers have been repeated in hallway conversations for months. The questions that stall people are different: Who owns this system once it's built? What happens if the AI gets something wrong in front of a customer? Which team's workflow has to change, and have they agreed to that yet?
When one of those harder questions produces a shrug instead of an answer, that's not a brief-writing problem. That's a project-readiness problem wearing a brief-writing costume. The fix isn't a better sentence — it's a conversation with the people who can actually answer it, before a single hour of build time gets spent.
Write It With the People Who'll Disagree About It
A brief drafted alone by one person, even a thoughtful one, tends to read smoothly because it only has to satisfy one point of view. The moment you put it in front of the people who'll actually use the thing — the team whose workflow changes, the person who inherits support tickets when it misbehaves, whoever signs off on budget — disagreements surface. Someone thinks the scope is too narrow. Someone else didn't know this was happening at all.
That friction feels like a delay. It's actually the brief doing its job early instead of late. Every one of those disagreements was going to surface eventually — the only choice is whether it happens on a shared doc before a contract is signed, or three weeks into a build when it's expensive to unwind.
Run a Pre-Mortem Before You Run a Requirements List
Most briefs are forward-looking: here's what we want, here's what success means. A smaller number also ask a backward-looking question that turns out to be more revealing — imagine this project failed. Not "underperformed," failed outright. Why? Write down the two or three most plausible answers.
Common ones: the data turned out messier than anyone admitted at kickoff, the team that was supposed to adopt the new workflow quietly kept using the old one, or the thing technically worked but nobody trusted its output enough to act on it. None of those are technology failures. They're failures a brief can catch in advance, if you're willing to ask the uncomfortable version of the question instead of only the hopeful one.
Treat the First Draft as a Draft, Not a Commitment
Because the brief is doing diagnostic work, it should change as you learn things — including things a consulting partner notices that you didn't. A good partner reads your brief and comes back with follow-up questions that reshape it: a scope line that was drawn in the wrong place, a success metric that's actually two different goals wearing one label, a data assumption that doesn't hold up under a second look. That back-and-forth isn't a sign the first draft was bad. It's the brief working as intended — a shared starting point that gets sharper through use, rather than a document that has to be perfect before anyone's allowed to start.
If you find yourself with a brief that reads fine on paper but still makes you uneasy, trust the unease. It's usually pointing at a real gap — in scope, in ownership, or in how ready your team actually is to change how they work. That's worth sorting out before kickoff, not during it.
If you're in the middle of drafting one and keep hitting questions you can't answer yet, that's a normal place to be — and a reasonable moment to book a short call and think it through out loud, or reach out through our contact page if a call isn't the right first step.