Those are reasonable things to work through. But they tend to crowd out the question that matters most, which is quieter and a little less satisfying to ask: where has the business lost leverage?
Most of these conversations open with the tool. "How do we use AI?" feels like the responsible thing to ask, because it sounds like action. But starting there points everyone in the wrong direction. It sends teams hunting for use cases, demos, and vendors before anyone has agreed which problem is worth solving. You end up with motion — pilots, new workflows, a sense of momentum — but a year later you'd be hard pressed to point to a decision that got faster, a cost that came down, throughput that improved, or a customer who noticed.
I don't think this happens because the technology is overhyped. AI is genuinely powerful. It compresses certain kinds of work to a degree that would have sounded absurd a few years ago. The problem is more ordinary than hype: power applied to the wrong place doesn't change the business. AI creates leverage when it's aimed at work that already matters — and figuring out what already matters is a business question, not a tooling one.
A Better Question
The more useful place to start is the opposite end: where has leverage been lost?
It's harder, because it doesn't let you skip ahead to solutions. It asks where the organization spends real effort and gets too little back, and the answers are usually unglamorous — the work that eats a team's week without moving anything, the process that survives only because of a constraint that disappeared two years ago, the decision that's simple on the merits but takes three weeks because four people have to sign off. Often it's just teams optimizing their own corner of the work while the thing the company actually needs sits untouched.
None of that announces itself as an "AI problem," which is exactly why starting with the tool misses it. You only find it by looking at the business honestly first.
Starting with the tool sends teams looking for use cases. Starting with the constraint sends teams looking for the place where change would actually matter.
A team told to "find AI use cases" will find them. There is always somewhere to apply a capable tool, and the search rewards whatever is easiest to demo, not whatever is most consequential. A team asked to find where effort is getting too little back starts from the business and works back toward the tool, which means AI shows up only where it would actually change something. Same technology, very different outcomes, decided mostly by which question got asked first.
A Concrete Case
Here's a version of this I've watched play out more than once. A company wants to use AI to improve engineering productivity, and the reasoning is intuitive: engineers are expensive, code is the output, so anything that helps them write it faster should help the business. Copilots get rolled out, velocity ticks up on the dashboards, everyone feels good.
In one case, the constraint was never engineering speed. It was prioritization. The roadmap turned over every few weeks, features got abandoned half-built, and the work that did ship was quietly descoped a month later. Faster code didn't touch any of that. If anything it made things worse — the team now produced the wrong things faster, and the gap between effort and outcome widened instead of closing. The constraint was sitting in the decision layer the whole time, where no amount of engineering tooling could reach it.
Nobody needed to ask whether AI could help write code faster; the answer was obviously yes. The thing worth asking was what limited the useful work that actually shipped — and that pointed somewhere the tool couldn't help until the prioritization problem got dealt with first.
What This Looks Like in Practice
Once you've named the constraint, AI gets much easier to evaluate, because you finally have something concrete to hold it against. It either improves the constraint enough to matter, or it doesn't.
The way I'd put it: AI is useful when the bottleneck is the time it takes to turn scattered information into a decision. It's much less useful when the real bottleneck is that no one has agreed which decision needs to be made. The first is a compression problem, which is what AI is good at. The second is an organizational problem that technology can easily disguise, and automating around it usually just hides the signal leadership most needs to see.
I've seen the same pattern show up in customer-facing teams. Faster responses are valuable if response time is the constraint. But if product, operations, and support all understand the customer's problem differently, AI-generated replies mostly make the visible part of the process move faster while the real issue stays stuck.
That's why some AI initiatives feel busy without ever becoming strategic. The company is adding capability without changing the system that determines outcomes. A faster process built on top of a broken one is still broken — it just costs more to maintain.
The Discipline
The companies that get the most out of AI won't be the ones running the most experiments. They'll be the ones willing to be honest about where the work is getting stuck, and disciplined enough to point the tool there first.
AI is not the strategy. It's a tool for changing the system once you understand the constraint — and understanding the constraint is the part no tool can do for you.