The brief and the problem are usually different things

“We want AI to support our clinicians.”

That was the brief, more or less word for word. It’s a good example because there’s nothing wrong with it. The clinicians were busy. They were spending time on admin they’d rather not do. AI could clearly help.

Most AI briefs I see look like this. They describe a solution, not a problem. “We need a chatbot for enquiries.” “We want an agent for onboarding.” Either might be right. The people writing them aren’t guessing, either. They know the business far better than I do.

But a brief is written from where the pain is felt. And the place you feel it is often a few steps away from where it starts.

Think about how a problem travels through a business. Something goes slightly wrong early on, a detail entered badly or a step skipped. Nobody notices, because the work keeps moving. The cost turns up later and somewhere else, as rework, chasing, a complaint, a write-off. By the time someone writes a brief, they’re describing the symptom from the spot where it hurts.

That’s what happened here. When we followed the work, the costly problem sat mostly unobserved in the back office. Invoices were being invalidated by small things, an incorrect billing code or a minor handling error. They circled back through the process, piled up as aged debt, and a lot of it was eventually written off. Nobody had written a brief about payment codes. It wasn’t anyone’s headline problem. It was worth $1.5M a year.

So I don’t start with the brief. I start with the work.

In practice, that means picking one real item and following it from start to finish. An invoice, a referral, a customer request. I watch where it sits waiting for someone to approve it. I watch where the same details get typed into a second system by hand. I ask what happens when it goes wrong, and who finds out. Those three places, the waiting, the double handling and the quiet failure, are where the value tends to sit.

It’s slower than taking the brief at face value. It’s also much cheaper than building the wrong thing well.

There’s some outside support for this. A study of AI projects that failed found the most common root cause was that nobody had clearly defined the problem to be solved or how to measure it (RAND, 2024). I’d add one caution about the wider research. Most of what gets published on why AI fails comes from firms that sell the fix, so it tends to find the fix is the answer. The question of whether teams picked the wrong problem in the first place barely gets asked.

When the location is right, two things usually happen. The build gets smaller, because you’re aiming at one chain of work rather than a whole department. And the result gets easier to measure, because the back office already counts things like days to get paid and debt written off.

The brief still matters. It tells me what people are feeling, and that’s worth knowing. It just isn’t the map.

I believe most AI briefs are right about the pain and wrong about where it lives. Finding that gap is most of the job.