A thousand $1,000 to $10,000 AI use cases sit in front of every business right now, and most leaders are hunting the wrong ten. The strategic ten ($250,000 to $1,000,000 plays) get stuck in decision committees and slide decks, the thousand small ones stay untouched, and meanwhile the strategy conversation in the room dissolves into a debate about what platform, licenses and governance models.

I have come to call this pattern the enterprise AI conundrum.

It is solvable, but most businesses are treating it as one conversation when it is in fact three separate questions that need different thinking, different people, and different decisions. When they get collapsed together, everything stalls. Scattered pilots, disconnected tools, a growing feeling that AI is not doing what it was supposed to do.

The challenging part is that in most cases the chosen tools are doing exactly what they were asked to do. The problem is what they were asked to do was the wrong thing, or misguided by people without relevant expertise and foresight of the changes they're pushing through. Businesses are getting useful outputs from the wrong workflows, which feels like failure even when the technology is working.

There is no single right answer here, every business is different. There is, however, a framing I keep coming back to in the work that we do, and it's helped to unstick a few conversations.

Most businesses have got past the why.

The board is not asking whether AI matters anymore; that debate is settled. But, what we're seeing is the pressure mounts, and three questions that require specific answersget collapsed into one:

  • what do we apply AI to

  • how do we build and sustain it, and

  • where does the value land?

Before any of those can be answered, there is one other question that has to come first.

Separate productivity AI from engineered AI.

They are two different conversations that almost every business runs as one, and that is where the committee paralysis starts.

  1. Productivity AI has a clearer path (not necessarily easier, change management is not straightforward!), and the job is to get people using Copilot, ChatGPT, and Claude, building the muscle and awareness of what these tools can do. This is more about breaking old habits, and changing mindsets. Ironically, it's less about the technology. It does not need a strategy paper, it needs enablement, practice, and 9 times out of 10, external support.

  2. In parallel, take the people who have already caught up. The ones whose enthusiasm has already pulled them forward can start on tactical engineering AIuse cases now (the stuff that genuinely shows up on the P&L), not in six months once the data strategy has landed. This split kills the worst pattern in AI transformation, which is decision by committee waiting for everyone to align before anything ships.

To be super clear, separating these two conversations is uncomfortable, because it forces leadership to admit that not every team moves at the same speed, and it requires those at the top (most often the CEO or MD) to make the difficult (and correct) call to ruthlessly prioritise and select their favourite child to receive the candybar (resource, space and focus to experiment with AI). Quite frankly, I don't understand why businesses believe that every team can and should move everyone at the same time. We've never run roll-outs like this in the past for tech or other business transformations, why do we instinctively think these principles don't hold true in AI?

Businesses move faster when one or two teams find the next small use case, ship it, create momentum and (as Zach Duenow put it to Raffi Salama and I some three years ago in the case of building organisational momentum) create organisational envy(OE). OE is arguably one of the healthiest emotions to evoke within a company to generate go-forward rather than falling into the all-to-common human trap of waiting for perfect, or consensus.

The 'what' is about specificity, not category.

The next question to ponder is about looking at "AI for marketing" or "AI for finance". The intent behind specificity is identifying which mechanical task takes three days and should take three minutes? Which customer interaction is repeated four hundred times a month with the same outcome?

The harder version of the what is as follows. Business leaders know where the pain is, but they cannot prioritise what they cannot imagine. Most of them have never used more than 5% of the capabilities that AI possesses. Most of them have never used AI on anything real beyond rewriting emails, analysing PDFs and asking a chatbot questions for new ideas, so the prioritisation conversation has to start by showing them what is possible against their own work, not someone else's.

A friend and ex-colleague of mine, Stephen Morison, sees two buckets (which felt like a lightbulb when I heard it). This is where the approach in focusing on productivity AI (everyone with a license) and engineered AI (your AI enthusiasts ready to run) can diverge depending on your business capability and willingness to move.

  1. The thousands of $1k - $10k use cases sit in front of any business, small mechanical wins any half-engaged team can solve. Productivity AI and tactical engineered AI sit here.

  2. The dozens of $250k to $1m strategic use cases that matter at the enterprise level. This is strategic engineered AI at work.

Scale the values to your organisation and you get the point.

Both buckets exist in any business, and the trap is that almost every business goes hunting the ten and ignores the thousand. The strategic ten need cross-functional alignment, exec/board approval, data foundations, and external support that no business has fully in-house, so they take +6-months to orchestrate, and most die in committee.

The thousand do not. The right people can handle them internally, with basic human and technical capability in place. Have your team of enthusiasts focus here.

I sat with a Head of Finance recently who was spending two days every week assembling a board pack from data that already lived in her warehouse. We rebuilt the report in front of her in twenty minutes; she did not need to learn prompts, she needed to see her own work change shape, once. After that, the use case prioritisation conversation took ten minutes instead of two months.

That is one of the thousand, and the same pattern repeats across every team in the business once leadership stops hunting the ten.

Finding more of them is straightforward.

Take one or two adjacent teams (sales and marketing, or marketing alone, or customer service) and have them think in advance against three questions.

  1. What process takes too long, costs too much, or produces inconsistent results?

  2. What would good look like, and what would success be?

  3. What data exists, and which teams hold it?

Then score every candidate on two axes, one to five each.

  • Business value, meaning how much does this shift revenue, reduce cost, or unlock a strategic priority

  • Execution readiness, meaning can the team build it in 90 days with the data, systems, and skills available

Plot them on a quadrant and the answer falls out.

  • Build now for the high-value, high-readiness use cases, fast-tracking them through a light governance model.

  • Pilot next for the high-value, low-readiness ones, de-risking before committing.

  • Quick wins for the low-value, high-readiness ones, run alongside the main work.

  • Park the low-value, low-readiness ones and revisit when capabilities have matured.

The whole exercise is one workshop.

  1. List candidates on a shared board.

  2. Score them as a group.

  3. Plot the matrix

  4. Pick the top three to five from "build now"

  5. Write a one-page brief per use case covering the problem, the proposed solution, the estimated value, the data requirements, and the governance readiness

  6. Put it in front of a sponsor already brought on the journey (solves most of the what question without a strategy paper, a steering committee, or a six-month waiting room.

The 'how' is where most businesses are kidding themselves.

The standard answer is infrastructure, governance, data architecture, and that is true. The harder truth is that the how is never stable. Models change, prompts drift, a system that worked last quarter behaves differently this quarter because the underlying model was updated and nobody tested it.

Most businesses are building AI like it is software, which is to say ship it, maintain it, and then they're done. AI is not software, it is closer to managing a team of unpredictable contractors who change their behaviour every few months. Designing for continuous testing and evaluation from day one is the only way to catch the breaks before they reach production.

The platform question should not hold the whole thing up. Do we have the platform? What type do we need? Nobody is locking themselves in for decades; the answer changes every six months, and any expert locking you in by building a modular context foundation underneath doesn't understand AI information architecture.

Pick something credible, ship use cases against it, and let the next decision be informed by what the work reveals.

The 'where' is the question nobody wants to answer honestly.

Cost reduction, revenue growth, speed, decision quality. These are the standard categories, and most businesses cannot measure any of them against AI initiatives with confidence yet.

The where is supposed to force AI work to connect back to business outcomes, but in practice it mostly forces people to make up numbers for a business case. The challenge ia that most leaders know the ROI exercise is theatre, but they feel obligated to put numbers on the page anyway.

The more honest version asks what would have to be true for this to be worth continuing? That reframes it from proving ROI (which is mostly theatre at this stage) to defining the conditions under which the business would keep investing. It is a smaller question, and a much more useful one.

MIT's NANDA initiative (debatably) reported last year that around 95% of generative AI pilots produced no measurable bottom-line impact, and McKinsey and BCG have published similar findings with the same direction of travel.

Across the +20 builds this year, the same pattern keeps showing up for us. Leaders chase the wrong-sized use cases through the wrong-sized governance process, with endless board papers for the Microsoft versus Anthropic decision, data foundations reviews, and cross-functional steering committees. Meanwhile the thousand $1,000 to $10,000 use cases sit untouched in front of the people who could ship them today.

Nobody has this completely solved yet.

The ones making progress run productivity AI and engineered AI in parallel, hunt the small use cases first, and let infrastructure decisions run in parallel and follow the work instead of leading it.

Key to all of this is (if you haven't already), just start this week, not next quarter.

  1. Take the three questions (what, how, where), and run them as separate conversations with different people in the room.

  2. Then take one team, give them the three pre-work questions, score the candidates on the two axes, and pick something to ship.

  3. Build it, learn from it, go again.

That alone might be the thing that gets the business unstuck.

Passionate about all things AI, emerging tech and start-ups, Mike is the Founder of The AI Corner.

Subscribe to The AI Corner

The fastest way to keep up with AI in New Zealand, in just 5 minutes a week. Join thousands of readers who rely on us every Monday for the latest AI news.