AI projects succeed or stall on one question asked before any tool is chosen: what problem are we trying to solve? This article shows how to spot a vague brief, gives a one-line formula for turning an intention into a workable problem statement, and sets out four questions that test whether a problem is worth solving.
Key takeaways
- AI project success depends on defining the problem before choosing a tool, because AI amplifies whatever problem it is given, including a vague one.
- Use the formula “How could we [action] in order to [outcome] while [constraint]?” to turn an intention into a brief with trade-offs in the open.
- A problem worth solving occurs at an observable moment, happens often, costs something measurable and affects more than one person.
- McKinsey found organisations that redesign workflows before selecting tools are twice as likely to report significant financial returns from AI.
There’s a pattern that comes up in almost every early-stage AI conversation we have with organisations. By the time we’re in the room, a tool has usually been identified. Sometimes a licence has already been purchased. The thing that hasn’t been defined yet is the problem.
This tends to be the real source of difficulty. AI amplifies the problem it’s given. A precise, well-scoped brief produces something genuinely useful. A vague one produces output that looks plausible, gets presented in a demo, and then quietly gets shelved three months later because nobody can connect it to anything that actually matters in the business.
The question that determines whether an AI project succeeds is the one that should come first, before any tool discussion: what problem are we actually trying to solve?
What a false good problem looks like
There’s a category of brief that sounds reasonable but isn’t specific enough to build anything on. “We want to use AI to improve our processes.” “We want to automate repetitive tasks.” “We want to be more data-driven.” These feel like problem statements — they carry real frustration, they reference genuine business pressure, and they’re written by intelligent people who care about improving how their organisations work.
The gap is that they describe a direction, not a problem. They tell you where someone wants to go without identifying what’s broken, who it affects, or what it costs the business today.
The research reflects how widespread this is. A Gallup survey from late 2024 found that only 15% of US employees report their workplace has communicated a clear AI strategy. MIT’s GenAI Divide study found that AI success consistently comes when organisations tackle one specific pain point at a time rather than pursuing broad, unfocused rollouts. And Gartner predicts that 30% of generative AI projects will be abandoned after proof of concept, with unclear business value cited as a primary cause.
The system contributes to this. Tool vendors don’t ask for a problem definition before selling a licence. The pressure to “do something with AI” arrives faster than the organisational clarity needed to do it well. Managers aren’t getting this wrong because the step that matters most has been largely removed from the buying process.
The formula that changes the question
The methodology we use to move from a vague intention to a workable brief comes from our AI in Practice workbook, and it’s built around one prompt:
“How could we [action] in order to [outcome] while [constraint]?”
The structure is simple by design. Each clause does specific work. The action names what needs to change. The outcome connects it to a measurable result. The constraint, the “while”, is where most of the value lives, because it forces the trade-off into the open before anyone has touched a tool.
The difference between a weak brief and a strong one becomes clear quickly. A weak brief sounds like: “How could we use AI to improve our procurement process?” It has a direction. It names a function. There is nothing in it that tells you what’s broken, what success looks like, or what the solution has to work within.
A strong brief sounds like: “How could we guide vendors through the onboarding request process, in order to reduce first-time-right errors and shorten lead times, while working within our existing SharePoint infrastructure and without requiring vendors to install new software?”
That second brief is, in essence, the problem definition behind Harry, the AI-powered procurement assistant we built for HEINEKEN. The original process was fragmented across complex Excel forms with no validation, driven by requestors who were often unaware of the steps involved, producing low first-time-right rates and delayed deliveries. The problem was real, observable, and expensive. The constraint, working within existing infrastructure, shaped the entire technical direction. Harry didn’t emerge from a technology conversation. It emerged from a problem that had been defined precisely enough to build something against.
The “while” clause is what most vague briefs are missing. Without a stated constraint, any solution is technically valid, which means no solution can be properly evaluated. With one, the scope becomes real.
The full methodology, with worked examples across different business functions, is in Chapter 5 of the AI in Practice workbook, free to download and built for managers working through this before any vendor conversation begins.
The four questions worth asking before going further
Once a brief exists in the formula structure, there’s a quick check worth running before taking it further. These are the questions that tell you whether the problem is real enough to build on.
- Is it linked to an observable situation in daily operations?
Something that actually happens, not something that might happen or could theoretically be improved. If you can’t point to a specific moment in the working week when this problem shows up, the brief needs more grounding.
- Does it happen often enough to justify the investment?
A problem that surfaces twice a year is a different kind of problem from one that creates friction every day. Frequency is a proxy for impact, and impact is what makes a business case.
- Does it cost something measurable?
Time, money, energy, or quality. If the cost is hard to articulate, the return will be equally hard to demonstrate, and equally hard to defend when someone asks whether the project was worth it.
- Does it affect more than one person?
Problems that live in a single person’s workflow tend to produce solutions that die when that person leaves or changes role. Broader impact means broader ownership, which matters for adoption as much as for the build.
When the answer to any of these is unclear, the brief needs more work. That’s useful information. It’s faster and cheaper to find it now than six months into a build.
McKinsey’s State of AI research confirms the underlying principle: organisations that redesign workflows before selecting tools are twice as likely to report significant financial returns from AI. The sequence matters as much as the solution.
The work we did with Crisis Cognition illustrates how a well-formed constraint shapes a project from the start. The problem was clear: field teams lose decision support when connectivity fails, and in crisis response, that’s not a minor inconvenience. The constraint, “while operating without internet access, on low-power hardware, without requiring technical setup in the field”, shaped every technical decision that followed. It was the definition that made the project specific enough to build.
What happens when the problem is right
A well-defined problem makes the tool conversation significantly simpler. The requirements are already embedded in the brief. The success criteria exist before the build begins. The people who need to use the solution have contributed to defining it, which changes how they receive it.
It also occasionally reveals that AI is not the right answer — that a process redesign, a better workflow, or a different kind of investment would create more value. We tell clients this when we see it. It’s not a comfortable thing to say early in a relationship, but it tends to build more trust than any demo.
Where to take this from here
Problem definition is the first thing we work through with every organisation we partner with. It regularly changes the direction of a project. Occasionally it changes the project entirely.
The formula and the four questions above are drawn from our AI in Practice workbook, which maps this process with guided prompts for managers working through it with their teams. It’s free to download.
If you’d like to work through problem definition with your team before any tool decision is made, our AI strategists can help you get from a vague intention to a scoped, ready-to-run use case. Get in touch to find out how we work.
Frequently asked questions
Why do AI proofs of concept fail?
AI proofs of concept often fail because the business value was never defined. Gartner predicted 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, with unclear business value a primary cause. A specific problem statement with a measurable outcome gives every proof of concept a clear pass or fail.
How do you write an AI project brief?
Write an AI project brief around one problem, not one tool. State the action, the measurable outcome and the constraint, using the formula “How could we [action] in order to [outcome] while [constraint]?”. For HEINEKEN’s procurement assistant Harry, the constraint of working within existing SharePoint infrastructure shaped the technical direction.
What makes a good AI use case?
A good AI use case starts from a specific, recurring problem with a measurable cost. MIT’s GenAI Divide research found success comes when organisations tackle one pain point at a time rather than pursuing broad rollouts. The best AI use cases also affect several people, which builds ownership and adoption.
How do you know if AI is the right solution?
Define the problem first, then check whether AI is the best response. A clear problem statement sometimes shows that process redesign or a different investment would add more value than AI. When AI is the right solution, the requirements and success criteria are already in place before tool selection starts.
Who should define the problem for an AI project?
The people who experience the problem should help define it, alongside the business owner and the delivery team. People involved in defining an AI problem are more likely to accept the solution, which improves adoption. WeAreBrain works through problem definition as the first step with every partner, and it often changes a project’s direction.
