You wouldn’t walk into a meeting and say, “I want to give Microsoft more money. What products can they sell me?”
That would be absurd. You’d start with a problem (collaboration is broken, security is lacking) and then evaluate whether Microsoft’s products solve it.
Yet this is exactly how most companies approach AI. They start with the technology and work backward to find problems it might solve.
The Question That Gets Everyone Stuck
When I run AI workshops, I used to ask teams: “What could AI do for your department?”
The responses fell into two buckets. Some people immediately jumped to chatbots, the most visible AI application, and either found a chatbot use case or concluded they didn’t have one. Others went blank entirely, unsure how to even approach the question.
Both responses share the same flaw: they let the technology define the solution space. If your mental model of AI is “fancy chatbot,” you’ll only see opportunities where a chatbot fits.
A Better Set of Questions
The workshops got more productive when I changed the framing:
“What would you do if you had double the staff, for free?” This surfaces capacity constraints. Where are people stretched thin? What would they do if they had breathing room?
“Where do your people spend most of their time?” Follow the hours. Manual data entry, report generation, answering the same questions repeatedly. These are signals of work that might not need humans at all.
“What processes do you hate but tolerate?” Every organization has workflows everyone knows are broken. They persist because fixing them isn’t urgent enough to prioritize. These are often low-hanging fruit.
None of these questions mention AI. That’s the point. You’re mapping the actual pain points before evaluating solutions.
The Punchline Nobody Expects
Here’s what happens when you start with problems instead of technology: at least half the solutions don’t require AI at all.
That’s not a failure. That’s the whole point.
When teams surface their real pain points, many turn out to be solvable with straightforward automation, workflow tools, or simple integrations. The data entry that consumes hours? Maybe that’s an RPA script. The weekly report everyone dreads? A dashboard that updates automatically. The repeated questions clogging the help desk? A better knowledge base with actual search.
None of these need a language model. None of them need machine learning. They need someone to finally fix the process.
Why This Matters for AI Specifically
I sell AI consulting. My business grows when companies adopt AI. So when I tell clients “you might not need AI for this,” I’m not being altruistic. I’m being practical.
AI projects that don’t have a clear problem to solve fail. They become expensive science experiments. The team builds something technically impressive that nobody uses, and eighteen months later the company is gun-shy about AI investment.
Starting with problems filters for genuine AI use cases: problems that actually require language understanding or pattern recognition that traditional automation can’t handle. It also builds organizational confidence by solving real problems, even when the solution isn’t AI.
A company that solves six problems (two with AI, four with simpler tools) is in a better position than one that tried to force AI into six problems and succeeded at none.
It’s Okay If There’s No AI
One of my standard lines when working with clients: “It’s 100% okay if the end solution has no AI at all.”
The goal was never to use AI. The goal was to solve the problem. AI is one tool among many. Sometimes it’s the right tool. Often it isn’t.
The companies getting value from AI aren’t the ones who asked “what can AI do?” They’re the ones who asked “what problems do we have?” and then evaluated every available tool, AI included, on its merits.
Start with the problem. The technology will sort itself out.