Problem First. Tools Second.

Watch how most AI projects begin. Someone in the room asks, "How can we use AI here?" It sounds like the right question. It's quietly the wrong one, and the order it puts things in shapes everything that follows. Start with the technology and you end up hunting for somewhere to put it. The tool is fixed; the problem becomes whatever the tool happens to be good at. That's backwards. You've decided on the answer before anyone's agreed on the question. ## What working backwards actually produces When the tool leads, the solutions that come out of it tend to share a family resemblance. They're inelegant, because they've been bent to fit the technology rather than the work. They're brittle, because they solve the version of the problem that suited the demo, not the messy one your team faces on a Tuesday. And they're siloed, because each one was built around a capability rather than a process, so nothing joins up. You can usually spot these projects later. They get used for a fortnight, quietly drift, and become the thing nobody quite wants to admit was a waste of three months. The technology wasn't the issue. The starting point was. Beginning with the tech turns it into a constraint. You're no longer asking what would genuinely fix this; you're asking what this particular tool will allow. That's a smaller question, and it gets you a smaller answer. ## The better order Flip it. You have new tools available — more capable ones than you had a year ago. Good. Now go back to your biggest problems and look at them again, properly, as if you hadn't already half-accepted them as the cost of doing business. The shift sounds subtle. "How can we use AI?" versus "What's the best way to solve the problem in front of us?" Same meeting, almost the same words. But the second question keeps the technology in its place: as one option among several, judged on whether it actually solves the thing. Sometimes the answer is AI. Sometimes it's a better process, a clearer handoff, or removing a step nobody needed. You only find that out if you started with the problem. This is also why the approach lasts. A method built around a specific tool expires when the tool does. A method built around understanding the problem doesn't. It worked before any of this — good teams have always started by asking what they were actually trying to fix — and it'll work with whatever turns up after AI stops being the thing everyone's talking about. You're buying a habit that outlives the hype cycle, not a trick tied to this year's flavour of the month. ## One problem. One bottleneck. Here's where good intentions go wrong. A team accepts that they should start with the problem, then lists fifteen of them and tries to make a dent in all of them at once. Effort spreads thin, nothing moves far enough to notice, and within a quarter the conclusion is "we tried AI and it didn't really land." Pick one problem. The one that costs you the most — in time, money, lost work, or sheer frustration. Then resist the urge to fix the whole of it, because most problems aren't one thing; they're a chain, and only one link is actually holding everything up. That link is the bottleneck. It's the step where work piles up, waits, or gets handed back. Everything upstream of it is running faster than the bottleneck can absorb, so going faster there just grows the queue. Everything downstream is starved, waiting for the bottleneck to release work. Speed up anything that isn't the constraint and you'll feel busy without changing the outcome — which is exactly how teams convince themselves they're making progress while the number that matters refuses to budge. So the discipline is narrow on purpose. One problem, and within it, the one bottleneck. Relieve that, and the whole chain moves. Then you find the next constraint, because there's always a next one — it's just somewhere new. This is far less satisfying than a grand transformation programme and far more likely to actually work. ## How to prepare before you start The quality of any discovery conversation is set before it begins, by how clearly you've thought about your own business. You don't need answers to everything. You do need to have done the thinking, because the gaps are often the most useful part — they tell you where you've been assuming rather than knowing. Worth having straight in your head before you sit down: - **The problem, stated plainly.** Not "we need to be more efficient." Something like "quotes take three days to go out and we lose deals because of it." If you can't say it in a sentence, it isn't defined yet. - **What it actually costs.** Hours, money, missed work, errors, the thing that doesn't get done because this eats the time. A problem you can't size is hard to prioritise and impossible to measure a fix against. - **How the work really flows today.** The honest version, not the tidy one in the process document. Who touches it, in what order, where it waits, where it gets handed back. This is where the bottleneck usually hides. - **Who feels it.** The people doing the work daily will know things the org chart doesn't. They also have to live with whatever you build, so their view of the problem matters more than anyone's. - **What "fixed" looks like.** How you'd know it worked. If the answer is vague, the solution will be too, and you'll never be able to say whether it earned its keep. - **What you've already tried.** What helped, what didn't, and why. This saves everyone from solemnly reinventing something that already failed for a good reason. - **The hard constraints.** Sensitive data, systems that can't change, regulatory lines, decisions already made. Better to name these up front than discover them halfway through a build. Bring that, and the conversation goes somewhere. Skip it and you'll spend the first hour establishing what the problem even is — which is fine, that's part of the work too, but it's an hour you could have used. ## The first question, every time Before the tools, before the budget, before someone's already drafted the press release, there's one question worth sitting with longer than feels comfortable: **What problem are we actually trying to solve?** The word *actually* is doing real work there, because the first answer is usually a symptom. "We don't produce enough content" is rarely a content problem; it's often a system problem, where every piece starts from scratch and output is forever capped by effort. Add AI to that and you get more noise, faster. Define the real problem first and the same tool becomes a genuine multiplier. Get the question right and the rest gets easier. The technology choice almost makes itself, because you finally know what you're choosing it for. The solution holds up, because it was built around the work. And you can tell whether it succeeded, because you defined what success looked like before you bought anything. The teams that get real value out of AI aren't the ones who adopted it fastest. They're the ones who knew which problem they were pointing it at — and had the discipline to point it at one thing at a time. ## Frequently asked questions **What is the first question to ask before an AI project?** Ask "What problem are we actually trying to solve?" — the plain version, not "How can we use AI?". Starting with the technology means deciding the answer before agreeing the question, which produces solutions bent to fit the tool rather than the work. **Why do AI projects fail?** They often fail because they start with the technology and hunt for a use. Solutions built around a tool rather than a problem tend to be inelegant, brittle and siloed, so they get used briefly and then quietly drift into disuse. **What does "one problem, one bottleneck" mean?** Pick the single costliest problem, then find the one constraint within it that holds the whole chain up. Relieving that bottleneck moves everything; speeding up anything else only feels productive while the outcome stays the same. --- *At Smart AI Studio we tend to start in the least exciting place: your actual problems, in priority order, before any conversation about tools. If you'd like a working session to find the one bottleneck worth attacking first — and, just as usefully, where AI doesn't belong — Peter Lowe runs discovery calls built around that exact question. It's a working session, not a sales pitch.*