The email says "we need to add AI." Sometimes that means a chatbot in the corner that cannot do anything. Sometimes it means a real job, over your data, wired into the product. When AI belongs in a product is that split — not whether the model is fashionable.
I build this as AI-powered products, usually on top of SaaS and web products people already use. The brief I write before I quoteis where "add AI" either becomes a job, or gets cut. If you haven't named whether it's a website or a web product, stop — AI on a brochure is a demo with a bill.
What most AI product briefs actually mean
They mean a chat box. A vendor demo. A sentence on a fundraising slide. The product underneath might be a live SaaS tool, a site that barely converts, or an idea. The brief does not change. Someone heard that customers expect AI, so the work is to put a model somewhere visible.
Visible is not the same as useful. A bubble that answers from the open internet, next to a product that already has the answer in a table, is a second support channel you now have to babysit. It hallucinates a refund policy. It cannot click the button the user actually needed. You pay per message for a worse version of the screen you were avoiding.
I have shipped the other shape. The Chat Companyis a bot that only knows the pages you pick, then embeds on the site with one script — that is a product because the job is "answer from our site," not "talk." DelightLoop uses models inside a GTM workflow: a signal becomes a campaign, not a chat log. Both sit in selected work. The pattern is the same. The model is not the product. The job is.
When AI belongs in a product
Three things have to be true at once. One of them is not enough. This is the same cut I use on what belongs in a first version — a named person, a job that completes, something that stays up — applied to a model instead of a screen.
- 01
You can name the job without saying AI
Search the docs. Draft the next email from this account. Flag the invoice that doesn't match the order. If the sentence only works with "add AI" in it, you don't have a job yet. You have a trend.
- 02
The answer has to come from your data
A generic model already knows the internet. It does not know your catalogue, your policies, or last Tuesday's tickets. If a person with Google could do the same work, you don't need it inside the product.
- 03
It has to do something the product already does
Create the campaign. File the ticket. Book the slot. If the output is a paragraph the user then copies into another tool, you built a toy. Wire it to an action you already own, or don't ship it.
Search over your own pages and docs is the honest first feature more often than chat. Generation is honest when the user is already drafting something the product will send. An assistant is honest when it can take the next step in a workflow you already run — not when it narrates the dashboard.
Cost and speed are part of whether it belongs. Tokens, retrieval, and the wait on a phone are not a later optimisation. If the cheap version of the feature is a filter and a list, I will say so in the quote. Paying a model to re-rank ten rows is how a small product gets an invoice that looks like a headcount.
Belongs
Job, your data, an action
Someone finishes work they already came to do. The model is inside that loop.
Does not
A bubble beside the product
It talks. It cannot act. You now own a second channel that is wrong in a new way.
When a chatbot is the wrong AI interface
Chat is one interface. It is a good one when the question is messy, the corpus is large, and the user does not know the name of the thing they need. It is a bad one when the product already has a better noun: a calendar, a table, a status, a button.
- 01
The job is a form
Dates, quantities, a yes or no. Making someone chat their way through a booking is slower than the screen you already needed. Chat is a worse form, not a smarter product.
- 02
The job is find the page
People want the shipping policy, the price, the SKU. A search box over your content — typed, ranked, linked — is often the whole feature. Wrapping it in a talking bubble adds latency and a bill.
- 03
The job is show the status
Where is the order. Did the payout land. Who is assigned. That is a query and a screen. A model guessing the same number is how you get a support ticket about a sentence that was almost right.
If the honest interface is search, generation, or an action on a row, I still might use a model. I will not hide that work behind a chat widget so the homepage can say AI. The people who have to live in the product will use the screen. The bubble will be the thing they screenshot when it is wrong.
When AI is the wrong call for a product
I will say so. Pretending every product needs a model is how you become the shop that bolts a bot on and leaves. These are the cases where the honest work is a normal feature, a faster site, or a takeover of what already runs— not a new AI layer.
- 01
There is nothing worth searching
Five marketing pages and a hope. Ingesting that into a bot does not create knowledge. Write the pages. Make the site fast. Then ask again.
- 02
The brief is only "add AI"
A competitor put a bubble in the corner. An investor asked. Nobody can name the person who would be worse off without it. That is not a product decision. It is a slide.
- 03
You don't have a product yet
No login, no records, no job that completes. AI on top of a brochure is a demo with a model bill. Name whether you need a website or a web product first. Then decide what belongs in the first version.
If a normal feature would do the job, we build the feature. The model is not a personality. It is a tool with a bill.
If the product already exists and someone wants to start over "for AI," that is usually a rewrite wearing a trend. Repair the flows. Put the model in the one place it earns. If you're staring at a brief that only says add AI, send the job in a sentence instead — tell me what you're building. The rest of AI in a product is that sentence from different angles.
