For the product you sell
How to add AI features to an existing product
You have users, data, permissions, and a roadmap. “Add AI” is the board’s ask. This is the practical version: which features fit a product that already exists, what makes them work, and how to ship one in weeks without breaking the trust you’ve built.
Start from the job, not the model
The fastest way to add AI to a product badly is to start from the model. A chatbot appears in the corner, answers questions it wasn’t asked, and gets closed. It ships, it demos well, and six months later nobody can point at a number it moved.
The features that stick start from something your users already do — repeatedly, reluctantly, or slowly. Three questions find them:
Where do users produce a first draft?
Reports, replies, summaries, configurations, descriptions. Anything typed from scratch that could be typed from a suggestion.
Where do they wait?
On a search, on a review, on someone else’s approval, on a report that runs overnight.
Where do they search instead of ask?
Help articles, old records, other people’s files. Every search box is a question your product could answer directly.
Each answer is a feature candidate with a metric attached: drafts accepted, minutes not waited, searches that became answers.
The four shapes AI features take inside an existing product
Almost every AI feature that works inside a product is one of four shapes. Naming the shape early decides the architecture, the risk, and the metric.
Assist
A draft or a suggestion inside the workflow the user is already in — the reply, the summary, the next field, the likely category. The user stays in control; the model saves the first ninety seconds. Lowest risk, easiest to measure (accepted or edited), and the right first feature for most products.
Retrieve
Answers over the customer’s own data: their documents, their records, their history — with the source shown. This is where asking the product becomes real, and where permissions decide everything: the answer must never include what the user couldn’t open by hand.
Extract and classify
Turning what arrives — documents, tickets, emails, images — into structured fields your product can act on. Invisible to the user when it works, and often the feature with the clearest operational payoff.
Automate, with a gate
An agent that takes actions inside the product on the user’s behalf — files, updates, schedules, notifies — with a person approving until the action class has earned autonomy. Highest value, highest stakes; never the first feature.
Most products will ship one assist feature, discover a retrieve feature underneath it, and only then be ready for an agent.
What your product already has — and what it doesn't
An existing product brings three things a greenfield AI project never has: a UX users already know, a permission model, and a data model with history in it. The feature should live inside all three. That is the whole advantage over a bolted-on tool — and it is where the traps are.
Permissions
Retrieval that ignores tenancy is a data leak with a friendly interface. The model sees only what the requesting user can see, enforced at query time, not by prompt.
Latency
A three-second wait is fine for a draft the user asked for and unacceptable in a field that autocompletes. Decide per feature whether the model runs in the request path, in the background, or ahead of time.
Cost per call
A feature that calls a large model on every keystroke can cost more than the plan it sits in. Design for it: smaller models where they suffice, caching, batching, and a budget per tenant that the product respects.
Evaluation
You cannot ship what you can’t measure. Before launch, a test set drawn from real usage — real drafts, real questions, real documents — with known-good answers, run every time the prompt, the model, or the data changes. It is the only way to know whether a change improved the feature or just moved the failures.
Data readiness
“We have the data” and “a model can use it” are different states. Quality, structure, access, and retrieval each need checking against the feature you actually want; the gap is usually the first thing to fix, and it is rarely glamorous. Data Readiness for AI is that work.
Model choice, briefly
This is the decision product teams spend the most time on and that matters the least at the start.
Commercial models via API get you to a working feature fastest. Start here for assist and retrieve features unless a hard constraint says otherwise.
Open-weight models on your own infrastructure win when data cannot leave your environment, when volume makes per-call pricing untenable, or when latency has to be controlled. They cost more to operate and less to run.
Classic machine learning — not a language model at all — is the right answer when the input is a table and the output is a prediction or a score. Cheaper, faster, and explainable.
Fine-tuning teaches a model a format or a narrow task, not your business. Grounding on your data does that. Reach for fine-tuning late, for cost or latency, not first.
Whatever the choice, the model is a component behind an interface your product owns. Swapping it should be a configuration change, and the evaluation set is what makes that safe.
Shipping it without breaking trust
Existing users have expectations a new product doesn’t. A feature that is confidently wrong once costs more than one that was never there.
Ship to a cohort behind a flag
Ten customers who opted in, then a hundred. The feature earns its way out.
Show the source, allow the edit
Retrieval answers cite; drafts are editable; the user can see why the product suggested what it did.
Keep a gate on actions
Anything that changes data waits for a person until that action class has a track record. Autonomy is something a feature earns, one action at a time. AI Agents & Assistants is built around exactly that.
Measure adoption, not usage
Not “how many clicked” — how many kept using it in week four, how many drafts were accepted, how many answers were corrected. The correction rate is the feature’s health.
Instrument it like any other feature
Logs, error tracking, and a trace from every output back to the model, the prompt, and the data that produced it.
Say what it is
Don’t call it “AI-powered.” Say what it does: “drafts your reply,” “answers from your documents,” “flags invoices that don’t match.” Users trust functions, not adjectives.
How long, and what it costs
A first assist or extract feature, scoped to one workflow, is weeks of work, not quarters — if the data is ready and the evaluation set exists. Retrieval over customer data adds the permission work. An agent that acts adds the gate, the audit trail, and the time it takes to earn autonomy.
What it costs depends on which of those you are building and what your data can support today, which is why we don’t publish a menu. We do publish how to find out: a two-week AI Discovery Sprint with the engineers who would build it, which ends with the two or three features worth building first, their feasibility against your real systems, and a scoped pilot with a budget you can take to the board.
Where products get it wrong
The bolted-on chatbot. Generic, disconnected from the data model, closed within a week.
The demo that never ships. Impressive on curated inputs, never measured on real ones.
Retrieval that ignores permissions. Discovered by a customer, not by QA.
No evaluation set. Every prompt change is a guess; every model update is a risk.
“AI” as the feature name. A label instead of a job; users don’t know when to use it, so they don’t.
Starting with the agent. The highest-stakes shape as the first one, before the product has earned any trust for it.
Questions product teams ask
Do we need our own model?
Almost never at the start. You need your data, your permissions, and a feature scoped to one job. The model is a component.
Will our customers’ data train someone else’s model?
It shouldn’t, and it doesn’t have to. Commercial providers offer terms that exclude your data from training; open-weight models on your infrastructure remove the question entirely. Decide it in the architecture, and say it plainly in the product.
What about hallucinations?
Grounding on your data, citing sources, saying “I don’t know” when retrieval comes back empty, and an evaluation set that measures the rate. Reduced, not eliminated — which is why the user keeps the edit and the action keeps the gate. Responsible AI is how we design that in.
Can our own team build it?
Often yes, once the scope is right. The hard parts are scoping, data readiness, and evaluation — the parts a sprint produces, and that a roadmap written to be executed with us or without us hands to your team.
How do we know it worked?
The metric you attached to the job in the first section. If you can’t name it, the feature isn’t ready to build.
Find the feature that pays off first.
Two weeks with the engineers who would build it: an opportunity map of your product, the two or three features worth shipping first, feasibility against your real data and permissions, and a pilot scoped to ship.