Pain-First AI Use Case Selection
Target painful, frequent manual work before building AI tools
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 6
- Confidence
- 98%
Begin with the work itself rather than with a model, vendor, or ambitious product vision. Interview practitioners and inventory tasks that are painful, time-consuming, manual, frequent, and common across the team. Those characteristics indicate that even a narrow improvement can return meaningful capacity and attract users without coercive change management. Build the smallest tool capable of reducing one selected pain, then observe whether colleagues with the same job voluntarily use it. Adoption provides early evidence that the problem and solution are real. Only after that evidence appears should the team add integrations, automation, or a polished interface. The mechanism converts firsthand workflow knowledge into a prioritized use-case backlog and uses behavior, rather than executive enthusiasm, to decide where further investment belongs.
Origin
Ethan Dewal developed this approach while moving from an SDR role into building AI tools for Asana's sales organization. His first use cases included outbound messaging, call preparation, call follow-up, and answering product questions. He selected them by examining painful, repetitive work he understood firsthand.
Core principles
- 01Build around genuine user pain
- 02Prioritize high-frequency manual work
- 03Start where many people share the same problem
- 04Validate usefulness before investing heavily
- 05Let practitioners identify the strongest opportunities
How to run it
- 1
Inventory recurring work
Ask people doing the role to list the tasks they repeatedly perform throughout a normal week. Capture the actual workflow rather than an idealized process map.
Pro tip Start with your own role when possible because firsthand pain is easier to evaluate accurately.
Watch out Do not begin with a fashionable AI capability and search afterward for somewhere to deploy it.
- 2
Score the pain
Evaluate each task for time consumed, manual effort, user frustration, frequency, and number of people affected. Favor tasks that score highly across several dimensions.
Pro tip A task that is both frequent and broadly shared can produce compounding returns.
Watch out A painful but rare edge case may not justify even a lightweight build.
- 3
Choose one narrow outcome
Select one use case and define the useful output clearly, such as a call-preparation document or a product answer. Keep the initial scope singular and testable.
Pro tip Choose an output whose quality an experienced practitioner can judge immediately.
Watch out Combining several uncertain use cases makes it difficult to learn why users adopt or reject the tool.
- 4
Prototype at low cost
Use a specialized chat and guided prompt before adding deep integrations. Let users supply data manually while the core value remains unproven.
Pro tip Manual copy-and-paste is acceptable during validation if it avoids premature engineering.
Watch out Do not mistake prototype inconvenience for proof that the underlying result lacks value.
- 5
Validate through behavior
Teach nearby colleagues how the prototype works and monitor whether people with the same pain use it repeatedly. Collect concrete examples of time saved and output quality.
Pro tip Voluntary reuse is stronger evidence than positive comments after a demonstration.
Watch out Do not scale based solely on excitement, survey responses, or executive sponsorship.
- 6
Invest behind proven demand
Improve the architecture, automation, and user experience only after usage demonstrates product-market fit inside the team. Repeat the process for the next pain point.
Pro tip Maintain a ranked backlog so validated needs shape the roadmap.
Watch out Avoid turning an unvalidated prototype into a large back-room project.
In the wild
A sales team discovers that every representative manually gathers account information before meetings. The work is frequent, disliked, and similar to personalized outbound research. The team creates a specialized chat that accepts pasted account data and produces a standardized call-preparation document. Representatives repeatedly use it because it turns a long research session into a quick review, giving the team evidence to automate data collection later.
→ The team validates demand before paying for CRM integrations and workflow automation.
Representatives repeatedly ask product specialists questions in Slack because the product guide is too large to search during sales calls. A lightweight retrieval assistant is tested against the documentation and introduced to a small group. Usage and answer quality are measured before the company invests in a polished sales interface.
→ A shared, high-frequency support burden becomes a validated AI use case.
Common mistakes
Starting with the technology
Choosing an architecture or vendor before identifying painful work produces tools that may be capable but irrelevant. Start with the user's recurring problem.
Prioritizing rare annoyances
A frustrating task is not automatically a strong use case. Frequency, manual effort, and the number of affected users determine whether the impact can scale.
Treating enthusiasm as validation
A compelling demonstration can attract praise without creating durable usage. Look for repeated behavior before expanding the investment.
Is it for you?
Best for
It is best for teams beginning an internal AI program with limited evidence about what employees will adopt.
Not ideal for
It is not ideal for mandatory compliance systems or infrastructure projects whose value cannot be judged through voluntary usage.
From the transcript
“you always want to build around pain”
“I tried to identify the aspects of my job when I was a seller that took a lot of time I didn't really enjoy doing…”
“high volume very manual a lot of people are doing this so I knew it would have big impact”
From the episode
He Automated His Sales Job With Ai… So His Boss Promoted Him