AI Use Case Discovery · Identifying Work Projects
AI Use Case Discovery
What is AI use case discovery?
- Start with repetitive work, not the technology
- Break work into tasks, then plot by impact and difficulty
- Assign one business owner to each use case
If you run use case discovery as a meeting to brainstorm what you could do with AI, you get dozens of sticky notes and almost no projects that get done. The starting point is the technology. Flip the order and start from work that is time-consuming and repetitive today. The output of discovery is not a list of ideas but a task definition sheet stating who produces what output, from what input, and how often.
The method is task decomposition. Break one job into 10 to 20 weekly tasks, then record each task's time spent, frequency, input materials, and output format. Then ask three questions. Is the input in a form AI can read, such as documents, tables, or conversations? Can a person review the result? Is the damage from a wrong answer tolerable? Tasks that pass all three become candidates. Typical examples are drafting, summarizing, classifying, cross-checking, and reformatting. Conversely, a task with no way to verify the result is dropped from the list, even if the impact looks large.
Once you have candidates, plot them on two axes: impact and difficulty. Estimate impact as 'time saved per task × monthly frequency × number of people affected', and judge difficulty by data access rights, security level, and integration with existing systems. Run two or three high-impact, easy use cases first, and pass high-impact but difficult ones on as PoC candidates. If you don’t name one business-side owner per use case, nobody moves after the workshop ends.
Two things tend to go wrong in practice. The first is gravitating toward showy projects. A chatbot or dashboard that looks good in an executive report gets picked first, while the ordinary cleanup task that eats 30 minutes every day gets pushed back. But adoption spreads through small, frequent tasks. The second is putting tasks that involve personal data or confidential customer information on the candidate list without a security review. If they get blocked right before launch, participants lose motivation, so a security officer should help screen them during the discovery stage.
John KimInstructor John Kim, author of B2B Marketing Design and CEO of Nanum Consulting
Seolyeong ParkGenerative AI and AX training specialist with 17 years of hands-on experience and 200+ lectures, helping non-technical staff put AI to work right awayThe term “use case” originally described software requirements as scenarios of how a user works with a system. In corporate AI adoption it has broadened to mean 'the work a solution is applied to.' The discovery method itself has no single founder; it took shape out of work-analysis and project-selection practice.
Consider a hypothetical case. Company C sells and services industrial equipment and has 280 employees. Early in the year it collected 63 ideas through a company-wide AI idea contest, but only 2 were executed in six months, and most were broad proposals like a 'customer service chatbot.'
- The training and planning teams dropped the open call and switched to half-day workshops by department. When 8 members of the service team broke a week of work into 17 tasks and wrote down how long each took, they found that maintenance report writing alone took 11 hours a week.
- For each task, the facilitator asked, "Is the input a document? Can someone review the result? How risky is it if it's wrong?" Of 17 tasks, 6 remained as candidates.
- The information security officer put one candidate on hold on the spot because it involved customer contracts. The service team lead replied, "Better to know now than to get blocked later."
- We ranked the remaining 5 by impact and difficulty and decided to start with drafting maintenance reports and sorting parts-inquiry emails. For each use case, we wrote down a named owner and a 4-week deadline.
- Two months later, 14 use cases were defined across 6 departments and 9 had moved into execution. The service team’s weekly time on maintenance reports dropped from 11 hours to 4.