The short answer
Every AI feature request looks reasonable in isolation. The useful comparison is frequency of the task, time saved when it works, cost of being wrong, and cost per use.
Those four together usually reorder the list substantially.
The four questions
| Question | Why it matters |
|---|---|
| How often does this task happen | Rare tasks rarely justify the work |
| How long does it take today | Bounds the saving |
| What does a wrong answer cost | Decides how good it must be |
| What does each use cost to run | Decides whether it is viable |
| Can a person check the output easily | Decides whether it ships early |
The last row is the practical filter. Features whose output can be checked at a glance are much safer to ship than ones where an error is invisible.
Start where mistakes are cheap
- Build something where errors are visible and low consequence.
- Use it to build your evaluation and monitoring.
- Learn what your users tolerate and correct.
- Then tackle the higher consequence cases.
- Do not make the first one the important one.
Teams that begin with the highest value, highest risk feature usually take longer to ship anything, because they are building the feature and the supporting practice simultaneously.
Watch the running cost
A feature used constantly at a high cost per use can be unprofitable even when customers value it. Estimate cost per use before committing, not after launch.
Where the cost is unavoidable, that is a pricing decision to make deliberately rather than a surprise on a later invoice.
Ask whether it needs AI at all
- A rule covers most cases here
- A search would answer this
- A template would be enough
- The real problem is missing data
- The task should be removed rather than automated
The last point is worth asking seriously. Automating a task nobody should be doing is an expensive way to preserve it.