--- title: "Add AI Is Not a Feature: Naming the Job Before You Build" description: "Most AI features fail because teams treat a conversational interface as the goal rather than one option among many. Here is how to decide when AI actually earns its place." author: "Kody Everson" url: "https://theipp.org/insights/add-AI-is-not-a-feature-naming-the-job-before-you-build" date: "2026-07-14T09:14:04.257Z" --- # Add AI Is Not a Feature: Naming the Job Before You Build ## Summary Most AI features fail because teams treat a conversational interface as the goal rather than one option among many. Here is how to decide when AI actually earns its place. ## Main content If your roadmap has a line item that says "add AI" without naming the job it does for a user, you are already building the wrong thing. The most visible model of AI, an LLM lends itself most easilly to a chatbot type interface, however the chatbot has become the default answer to a question nobody asked clearly, and the result is a wave of products where a conversational box has been stapled to a workflow that was working fine without one. The pattern is easy to spot once you look for it. A settings page that worked perfectly well now has a "chat with your settings" button. A dashboard with clear filters now invites you to "ask a question about your data" and returns a worse version of what the filters already gave you. A support flow that resolved issues in three clicks now routes you through a model that hallucinates a policy that does not exist. In each case the team optimised for the appearance of intelligence rather than the reduction of user effort. ## The fundamental flaw of AI features: interface mechanics versus job to be done Good product practice starts from the job a user is trying to get done, then works backwards to the mechanism. Somewhere in the last two years many teams inverted this. They started from the mechanism, a large language model behind a text box, and went looking for jobs to justify it. That is the fundamental flaw which has been exposed in the world of AI, and it explains most of the disappointing AI features shipped in the past eighteen months. A conversational interface is genuinely excellent at a narrow set of things: expressing intent that does not map neatly to a fixed set of controls, exploring an ambiguous problem space, and synthesising across sources a user could not easily assemble themselves. It is poor at things a structured interface does better: precise repeated actions, tasks where the user already knows exactly what they want, and any flow where correctness is non-negotiable and errors are expensive. Consider the difference between two real use cases. Asking a model to draft a first-pass summary of forty customer interviews is a strong fit; the input is unstructured, the output is a starting point the user will refine, and a rough answer beats a blank page. Asking a model to change a user's billing address through conversation is a weak fit; the user knows the address, a form captures it in seconds, and a misheard postcode is a genuine cost. The interface should follow the job, not the other way round. ## A four-part test before you build When a team proposes putting AI into a flow, I want four questions answered with evidence, not enthusiasm. If the honest answers are no, the feature does not belong in the flow, whatever the demo looked like. ### 1\. Is the input genuinely open-ended? If the range of things a user might want to do is small, repeatable and known, give them buttons. AI earns its place when the input space is large, messy, or unpredictable, and where enumerating every option in advance is impractical. A search over an unstructured knowledge base qualifies. A menu with six items does not, no matter how tempting it is to make it "conversational". ### 2\. Does the task require judgement, or just execution? Execution tasks, moving data from A to B, applying a known rule, formatting output, are automation problems, and deterministic automation is cheaper, faster, and more reliable than a model. AI adds value when the task requires interpretation, ranking, drafting, or synthesis; work where there is no single correct answer and a reasonable one saves effort. ### 3\. Can the model actually see the context it needs? A large share of failed AI features fail here. The model is asked to be helpful but has no access to the user's history, the current state of the system, or the domain rules that make an answer correct. A confident answer built on missing context is worse than an honest "I cannot help with that". If you cannot supply the context, do not ship the feature. ### 4\. Can a wrong answer be tolerated, or caught? This is the question most teams skip. Every model output carries an error rate. The right question is not "can we make it accurate" but "what happens when it is wrong, and who pays". In low-stakes, reversible contexts, a draft email, a suggested tag, the cost of error is a quick correction. In high-stakes, irreversible contexts, a financial transaction, a medical instruction, a legal claim, the same error rate is unacceptable unless a human reviews before commitment. ## The best AI removes work the user never wanted The strongest AI features share a characteristic that the bolted-on chatbot lacks entirely: they reduce the number of steps a user has to take, rather than adding a new surface the user has to learn. The chatbot approach usually adds effort. The user now has to compose a request in words, wait, evaluate the response for accuracy, and often reformulate. That is more cognitive load than a well-designed form, not less. > The question is never "where can we add a chat box". It is "where is the user doing work a machine could do invisibly". The invisible applications are frequently the most valuable. A smart default that pre-fills a field correctly nine times out of ten. A ranking that surfaces the three items a user most likely needs. A classification that routes a ticket to the right team without anyone touching it. None of these announce themselves as AI, and none of them require the user to learn a new interaction pattern. They simply make the existing flow shorter. That is the flow AI belongs in. ## Practical implications for product teams Turning this into practice means changing how you run discovery and how you govern the build. - **Frame the opportunity as a job, not a technology.** Ban "add AI" from the roadmap. Replace it with the user problem and the current cost of that problem. If AI turns out to be the best mechanism, it will survive that framing. Most proposals will not. - **Set an evidence standard before writing code.** Decide the acceptable error rate for the specific job, and how you will measure it against real inputs, not curated demos. A model that dazzles in a sales meeting and fails on the messy long tail of real data is a liability, not a feature. - **Assign decision rights and outcome accountability.** Name the person who owns what happens when the model is wrong. If nobody owns the failure case, the feature is not ready. This is the same accountability you would demand of any consequential product decision, and AI does not earn an exemption. - **Prioritise the invisible wins first.** Smart defaults, ranking, and routing usually deliver more value at lower risk than a conversational surface. Ship those, learn from them, and only reach for conversation when the input is genuinely open-ended and no structured interface can capture it. - **Design the exit.** Every AI feature needs a graceful path to a human or a deterministic fallback. The absence of a fallback is a signal that the team has not thought about the failure case, which is the most likely case to matter. ## Conclusion The maturity signal in AI product work is not how much AI you have shipped. It is how many times you decided against it for a specific job and could explain why. The teams that will build durable AI products are the ones treating the model as one option in a design space that still includes forms, automation, defaults, and doing nothing at all. The chatbot is occasionally the right answer. It is almost never the first one. Start from the job, demand evidence, own the failure case, and let the interface follow the work rather than the hype. ## Related pages - [Insights](https://theipp.org/insights.md) - [Product Profile](https://theipp.org/tools/product-profile.md) - [Standards](https://theipp.org/standards.md)