Every second discovery call now includes a request for "AI". Usually the picture in the client's head is a chat box in the corner of their product. Almost every time, the chat box is the wrong shape for the problem.
The test
Before we scope an AI feature we ask three questions. If any of them has no answer, the feature is not ready to build.
- Which task does a person currently do by hand? Not a category of work — a specific task, performed by a named role, with a frequency.
- How long does it take today? If nobody has measured it, we measure it during discovery. This becomes the number the feature is judged against.
- What happens when the model is wrong? Every model is wrong sometimes. The interface has to make that survivable.
Chat is a fallback, not a feature
A chat interface is what you build when you do not know what the user wants to do. That is occasionally true — general research assistants, for example. It is rarely true inside a product where the workflow is already known.
If your users spend their day extracting figures from scanned delivery notes, the AI feature is not a chat box. It is an upload area that returns a validated, editable form with each field linked back to the region of the scan it came from.
The model should shrink a task, not add a new surface to learn.
Constrain the output
We almost never let a model return free prose into a product surface. Output goes through a schema, and the schema is validated before anything is stored. When a model must categorise, it picks from a fixed taxonomy that the product already understands.
This is dull, and it is the difference between a feature that survives contact with real users and a demo.
Cost is a design constraint
Per-operation cost belongs in the design conversation, not in a surprise invoice three months after launch. We track cost per operation from the first sprint and cap it. If a feature only works at a price the business cannot support, better to find out in week two.