Where AI creates value in a product, and where it does not

Every product team is under pressure to add artificial intelligence, and most are unsure what to add. The useful question is not whether to use it but where AI creates value in a product: which tasks it makes faster, cheaper or possible at all, and which it merely decorates. Getting this wrong produces features that cost money on every request and that nobody uses. This article offers a practical way to tell the two apart before you commit budget to building anything.

Where does AI create value in a product?

Current AI models are good at a specific family of tasks: working with language, images and other unstructured material where rules are hard to write down. The strongest cases share a pattern. There is a high volume of work, the input is messy, a good answer is recognisable when you see it, and an occasional imperfect result is acceptable or easily corrected.

In practice that means:

• Extraction and classification. Reading invoices, emails, contracts or support tickets and turning them into structured data or routing them to the right place.
• Search and retrieval. Letting users ask questions in their own words across documentation, catalogues or internal knowledge, with answers that cite their sources.
• Drafting. Producing a first version of a reply, a description, a summary or a report that a person then reviews.
• Summarising. Condensing long conversations, meetings or records into what the next person needs to know.
• Translation and adaptation. Converting content between languages, formats or reading levels.
• Assistance inside a workflow. Suggesting the next step or filling a form from context, with the user confirming.

In each case the value is measurable: time saved per task, more requests handled, or a capability that was previously impractical.

Where does AI not create value?

The weak cases are just as recognisable.

• Problems with exact rules. Calculating tax, checking stock or validating a form is ordinary software. It is cheaper, faster and always gives the same answer.
• Tasks where every error is costly. A language model can produce confident, plausible and wrong output. Where a mistake has legal, financial or safety consequences and nobody reviews the result, it is the wrong tool on its own.
• Chat as a substitute for interface. If a user can reach something in two clicks, asking them to type a sentence is slower. A chatbot placed in front of a product that is hard to use does not make it easier to use.
• Features without data. Personalisation and prediction need relevant, clean history. Without it, the output is generic.
• Features added for the announcement. If you cannot name who will use it and what they will stop doing manually, it is decoration.

How can you test whether a feature needs AI at all?

Run each idea through a short set of questions before any design work:

• What task does the user do today, and how long does it take?
• Could a rule, a filter, a template or a better form solve it? If so, build that.
• What happens when the answer is wrong, and who notices?
• Is there a person in the loop to check, or a way to verify the output automatically?
• Do we have the content or data the feature would rely on, and may we lawfully use it?
• How will we know it is working?

Then test cheaply. Gather a few dozen real examples of the input, try them against an existing model with a carefully written instruction, and have the people who do the task today judge the results. This shows quickly whether the idea is viable.

What does an AI feature need to work in production?

A convincing demonstration is the smaller part of the work. To be dependable in a real product, a feature needs:

• Grounding. Answers drawn from your own verified content, not from the model’s general knowledge, with sources shown where possible.
• Evaluation. A fixed set of test cases with expected results, run whenever the instructions or the model change. Without it, you cannot tell whether an update improved or damaged quality.
• Guardrails and fallbacks. Limits on what the feature may do, sensible behaviour when it is unsure, and a route to a person.
• Review design. An interface that makes checking and correcting the output quick, since that is where the user’s time now goes.
• Privacy and compliance. Clarity on what data is sent to which provider, where it is processed, whether it is retained, and what your users have been told.
• Monitoring. Logging of quality, response time and running cost.

What drives the cost and timeline of an AI feature?

Unlike most software, AI features carry a usage cost: each request to a model is charged according to how much text or media goes in and comes out. Volume, the size of the model and the length of the context all affect the running bill, so it should be estimated per user action before launch.

Build effort depends mainly on the state of your data, the number of systems to integrate, how accurate the result must be, and how much review tooling is needed. Preparing and cleaning content is frequently the largest task. Most products do not need a custom-trained model. A well-chosen existing model, connected to your content and properly evaluated, covers the majority of cases.

How should you measure whether it is working?

Define the measure before building. Useful ones are concrete: time to complete the task, share of outputs accepted without edits, number of cases handled without escalation, cost per completed task compared with the manual route. Track adoption too. A feature that is accurate but unused has not created value.

Set a review point after launch. If the numbers do not justify the running cost, simplify the feature or remove it.

Frequently asked

If you have an idea and want to know whether it is worth building, our AI development team can test it against your real data and give you a straight answer.