Most product managers are currently being asked to add AI to something. The request rarely arrives as a customer problem. It arrives as a board slide, a competitor launch, or a sentence beginning "shouldn't we be using AI for...".
This article is the counterweight. Not because AI features are bad — several are the most valuable things you will ship this decade — but because the failure mode of this moment is applying a probabilistic, expensive, slow tool to a problem that wanted a deterministic, cheap, instant one.
The test
Four questions. A no to any of them is a strong signal to stop.
- Is the task genuinely ambiguous? Language models earn their cost on judgement, synthesis and open-ended input. If the rules can be written down, write them down — a decision table is faster, cheaper, testable and explainable.
- Can the user tolerate a wrong answer? Not "will it be right most of the time" — what happens on the occasion it is confidently wrong. If the answer involves money moving, a legal position, a medical claim or an irreversible action, you need a human in the loop or a different approach.
- Can the user tell it is wrong? This one gets missed. Users can spot a bad summary of a document they wrote. They cannot spot a plausible-sounding but wrong answer about something they came to you because they did not know.
- Is it worth the latency and the cost? A model call is measured in seconds and fractions of a cent. Both compound. A feature used forty times a day by every user is a very different economic proposition to one used monthly.
The dangerous quadrant is high-plausibility, low-verifiability: the model is usually right, sounds right when it is wrong, and the user has no way to check.
Four cases where the answer is no
1. It is a rules problem wearing an AI costume
"Use AI to categorise incoming tickets" is often solvable with a dozen keyword rules that run in a millisecond, cost nothing, and can be corrected by a support lead without a deploy. Start there. If the rules reach fifty and still miss cases, you have earned the model — and you now have a labelled dataset to evaluate it against.
2. Search, dressed up
A great many "AI assistant" features are a worse interface to information the user could have found with a filter. If someone knows what they want and can name it, a fast search box beats a chat box every time. Chat is for when the user cannot articulate the query in your product's vocabulary.
3. Deterministic output is the actual requirement
Invoices, exports, calculations, compliance documents. Users expect identical inputs to produce identical outputs, and a model that varies by a word between runs will read as broken even when it is accurate. Non-determinism is a product characteristic, not just an implementation detail — decide whether your users can live with it.
4. The volume makes the economics impossible
Run the arithmetic before design starts. Cost per call multiplied by calls per user per month multiplied by users is a number that has killed a lot of demos. This deserves its own treatment — see the unit economics of AI features.
Prompt iteration has a ceiling, and teams routinely spend six weeks discovering where it is. If the first honest evaluation shows 60% accuracy on a task that needs 95%, prompting will not close that gap. Retrieval, fine-tuning, a narrower scope or a different approach might. Decide which before the sprint, not during it.
Where AI is genuinely the right answer
The mirror image of the test. Strong candidates share these traits:
- Unstructured input. Free text, documents, images, speech — things rules cannot parse.
- The user can verify instantly. Summarising a call they attended. Drafting an email they will read before sending.
- A draft is genuinely valuable. Getting from blank page to 70% is the whole job; the user finishes it.
- Errors are cheap and reversible. Regenerate, edit, ignore.
- The alternative is nothing. The task is currently not done at all because it is too tedious.
That last one is where the durable wins live. Features that make an existing action 10% faster get noticed briefly. Features that make a previously impossible action routine change behaviour.
Design for being wrong
If you do proceed, the design work is mostly about the failure case. The teams that ship well-received AI features are not the ones with better models — everyone has roughly the same models. They are the ones who designed for the 15% of the time it is wrong.
- Make editing trivial. Output that lands directly in an editable field beats output in a box the user has to copy.
- Show the source. Citations, highlighted passages, "based on these three tickets". Verifiability converts a guess into a starting point.
- Frame it honestly. "Suggested reply" sets a different expectation to "Answer". The label is doing real product work.
- Offer the escape hatch. A visible way to do it manually, always. Trapping users in a probabilistic flow is how you generate support tickets.
- Fail visibly, not silently. Low confidence should say so rather than presenting a shrug with the same styling as a good answer.
Not the demo. The day it produces something confidently wrong for your largest customer, who screenshots it. If your answer to that scenario is "we would apologise", the feature needs more guardrails before launch, not after.
The organisational version of this problem
Sometimes the request genuinely is not about customer value — leadership needs an AI story for the market, and that is a real business need rather than a stupid one. Say so out loud rather than pretending it is a customer problem. Then you can serve it deliberately with a small, safe, well-scoped feature instead of quietly distorting the roadmap around a requirement nobody has named.
And once something does ship, the hard part starts: knowing whether it works. Traditional product analytics will not tell you — see evaluating AI features.