How to Find AI Use Cases Worth Building (Let 100 Ideas Compete)
How do you find AI use cases worth building?
Instead of paying a consultancy to deploy engineers to figure out use cases for you, the better-spent dollar is to source ideas broadly inside your own company and let people try their own use cases first. This does a good job of weeding out the good and bad ideas.
The funnel works in stages:
- Have 100 people come up with things — the pool whittles down to the six or seven pretty good ideas.
- Turn those six or seven into the one or two real home runs.
- Your company develops the proof of concepts (POCs); the winners go to professionals who take them the last mile.
Letting your own people build the POCs surfaces the strong ideas cheaply before you commit serious effort. For more on getting those winners shipped, see last-mile-ai-why-most-ai-projects-fail-before.
Why should you let 100 people pitch AI ideas?
Encouraging people to try their own use cases first weeds out good and bad ideas without spending your budget on engineers to figure them out. But once an idea survives, you have to become a product manager quickly.
With AI-driven development, the time between something you've thought about and something you actually see on the screen might be six minutes. In pre-AI days, the path from idea through planning, development and testing was long enough that a product manager could catch their breath and really think about it.
That speed is why the winners need people who both understand AI and the tools and have built software before. Without that grounding, it's easy for your people to answer Claude's questions in a way that takes you down a rabbit hole, a dead end, a path that won't scale, or a mix of technologies that isn't a good idea.
“your dollar is better spent saying, "let's have 100 people come up with things," and it'll whittle down to the six or seven pretty good ideas”
What separates a good AI use case from a bad one?
Two narratives make a strong case for AI:
- Removing work people shouldn't be doing. A sales rep's role is to actually generate sales — they're incentivized to hit quota. They don't want to do proposals; proposals are a means to an end. Remove that, and you get them to their ultimate goal faster.
- Doing things you couldn't do before. Voice agents picking up the phone outside office hours generate sales when no human would otherwise answer.
Two more patterns qualify: small use cases that were too expensive to run can now be done, and removing mundane, repetitive tasks so humans focus on what they do best. One example: replacing a complex offer-and-promotion system full of clicking with one where you input a narrative — "I want to target all customers between this age range, in this geographic zone, who spend this much" — and the system builds the promotions. You could have done it before, but only with a lot of overhead or far more agents.
“They don't want to do proposals; proposals are a means to an end. So if you can remove that, you get them to their ultimate goal faster, which is a strong case for AI.”
When is AI the wrong tool for the job?
There's no one-size-fits-all with AI. A voice agent isn't right if every person reaching out has a very specific, technical request — but in a case like IKEA's, where contacts are mostly FAQs, it's relevant.
The governing question for any pitch is: is this the right tool for this job? AI is really good at some things and awful at others. We've all had the moment of spamming the zero and yelling "agent, agent" — those are the wrong use cases.
Executives can see a headline, do a tutorial or watch a webinar and think "that'll work for everything." That's how companies lay off thousands of people only to hire them back six months later after realizing they made a mistake. The person being asked to implement it should ask whether there's risk involved before building. For how to navigate that decision without stalling, see beating-analysis-paralysis-enterprise-ai-projects.
“AI is really good at some things and awful at others. We've all had that moment of spamming the zero and yelling "agent, agent" — those are the wrong use cases.”
Frequently asked questions.
- How many AI ideas should you start with?
- Source ideas broadly — let 100 people come up with things. That pool whittles down to six or seven pretty good ideas, which professionals then narrow to the one or two real home runs worth taking the last mile. Letting people try their own use cases first is what weeds out the good and bad ideas before you commit budget.
- Why is automating a task you already do a weak AI strategy?
- Because the strongest cases aren't just speeding up existing work — they remove work people shouldn't be doing or enable things you couldn't do before. A sales rep's job is to generate sales, not write proposals; proposals are a means to an end, so removing them gets the rep to their goal faster. Voice agents answering outside office hours create sales no human would otherwise capture.
- When is AI the wrong tool for the job?
- When the job doesn't fit the tool. A voice agent is wrong if every contact has a very specific, technical request, but right when contacts are mostly FAQs. There's no one-size-fits-all: AI is really good at some things and awful at others. The test before building is whether there's risk involved and whether it's the right tool for this job.
- Why do you have to become a product manager when building AI use cases?
- With AI-driven development, the time between an idea and seeing it on screen might be six minutes — too fast to catch your breath the way a longer pre-AI cycle allowed. You need a point of view on strategy: what the product does and who it serves. People trained in that answer Claude's questions well; those who aren't can take the project down a dead end or a path that won't scale.
- Should you build every exciting AI demo an executive sees?
- No. Executives can see a headline, do a tutorial or watch a webinar and think "that'll work for everything." That mindset leads to companies laying off thousands of people and rehiring them six months later after a mistake. Whoever implements it should first ask whether there's risk involved and whether it's the right tool for the job.