When picking AI projects, judge task boundary, employee willingness, human judgment authority, and validation difficulty — together. That’s how you filter out the AI projects not worth doing.
AI isn’t a smooth capability curve — it’s a jagged frontier
The same model can be stunning on some tasks and unstable on tasks that look almost the same. When picking projects, don’t ask “can it do it” — ask “under what conditions is it stable.”
The capability frontier is not a smooth curve
Good projects usually aren’t the flashiest projects — they’re the ones with a clear task boundary, verifiable output, controlled error cost, and employees willing to adopt them.
Principle 1: don’t pick AI projects by job title — pick by task
“Can sales use AI” is too broad. The better question: which specific tasks in sales are frequent enough, painful enough, and verifiable enough?
Principle 2: don’t only look at AI capability — look at employee willingness
If employees won’t hand the task to AI, or worry the output isn’t controllable, even the strongest model struggles to enter the real workflow.
Four quadrants set project priority
| Quadrant | Read |
|---|---|
| Green Light | Employees want it, AI can do it. Take it into pilot first. |
| Red Light | AI can do it, but employees don’t want to hand it over. Handle adoption resistance carefully. |
| Opportunity | Employees want it, but AI isn’t strong enough yet. Worth ongoing observation and small experiments. |
| Low Priority | Employees don’t want it, AI isn’t strong either. Usually not a fit for an early project. |
Principle 3: distinguish “automate” from “augment”
Fewer humans isn’t always better — the right pairing is. Many high-value scenarios aren’t full automation; they’re letting people make faster, steadier, more evidence-backed judgments.
Fewer humans isn’t always better — the right pairing is
| Level | Mode | Fit |
|---|---|---|
| H1 | Automate | Low risk, high repetition, easily verifiable output. |
| H2 | Review-style collaboration | AI processes first, humans confirm. |
| H3 | Human-AI co-creation | AI provides candidates and evidence; humans judge. |
| H5 | Human-led | High risk, high responsibility, high context. |
Principle 4: pick “easy-to-validate” tasks first
The easier to validate, the better the fit for an early pilot. Hard-to-validate tasks can be explored, but aren’t right for the first organization-level AI project.
Principle 5: beware the “quality improved” illusion
“Better quality” has to be broken into observable metrics — otherwise it’s easy to be misled by one slick demo.
Principle 6: stop AI from making everyone look the same
If AI converges all output, it can erode differentiated judgment, brand voice, and professional depth.
Principle 7: don’t pick projects with demos — pick them with experiments
Demos help understand possibility. Experiments decide whether something is worth investing in. Don’t conflate them.
10 questions to ask before chartering
- Is this task frequent enough? — Low-frequency tasks aren’t unimportant — but they rarely produce ROI quickly.
- Is this task painful enough? — Without a strong pain point, even a strong model rarely sees sustained use.
- Are employees willing to let AI in? — Don’t only ask leadership. Ask the people who do this task every day.
- Is current AI capability stable enough? — Don’t be sold by one successful demo. Look across samples and edge conditions.
- Is the output easy to verify? — The easier to verify, the better the fit for an early pilot.
- How high is the cost of error? — High-cost-of-error tasks can use AI assistance — automate them carefully.
- How much human agency does this task need? — H1 fully automated, H3 human-AI collaboration, or H5 human must lead?
- Is the task embedded in a real workflow? — An isolated AI tool tends to become another system nobody opens.
- What’s the success metric? — Time saved, quality up, errors down, conversion up, experience improved — say it up front.
- If AI gets stronger tomorrow, can this project scale? — Good AI projects evolve as model capability grows.
Final read: good AI projects usually look plain
They’re rarely the most launch-event-ready projects — they’re the ones that enter real work, get used by the team consistently, and clearly validate value.