AI is not a feature; it is a tool. Before adding it to your product you need to be clear on the problem it solves, what it costs and what happens when it is wrong.
Key takeaways
- "Let's add AI" is not a product decision; the problem to solve has to be defined first.
- What the user sees when the model is wrong matters as much as the feature itself.
- Cost per use directly affects your business model as your user base grows.
- Where user data goes must be decided up front.
In this article6 sections
A large share of the requests we have received lately contain the same sentence: "Let's add AI to the product too." We understand the wish; the technology really does make a lot possible. But AI is not a feature in itself. Used in the right place it clearly improves a product; used in the wrong place it becomes an expensive, unreliable ornament. Before deciding, we ask these five questions.
1. Which problem does it solve?
If you can say "users lose this much time doing this task, and we will shorten it", you are on the right track. If the answer is "competitors have it" or "investors are asking", you need to find the problem first. Good AI features are often unobtrusive: they pre-fill a form, summarise a long record, or make search more accurate.
2. What happens when it is wrong?
Language models do not always give the right answer; this is not a bug to be fixed but the nature of the technology. So we start the design from this question: when the model produces a wrong output, how will the user notice and correct it? An error is tolerable in a text suggestion. It is not in interpreting health data or in a financial transaction. The higher the price of an error, the more you need a flow that leaves the decision to a person.
3. What does each use cost?
The cost of a classic feature is paid during development. With AI features every use is a separate cost. An amount that looks trivial at a hundred users can change your business model at a hundred thousand. So when we design the feature we work out usage limits, caching and which size of model is enough for which job from the start.
4. Where does the data go?
If your users' data will be sent to a model provider, they have a right to know. Your obligations under KVKK and GDPR change with which data is sent and where it is processed. Stripping personal data before sending it, agreeing data processing terms with the provider and, where necessary, using a model that runs on your own infrastructure are decisions to make up front.
5. How will you measure success?
How will you know the feature works? "Users liked it" is not enough. Did the time to complete the task go down, did support requests fall, what share of suggestions is accepted? If the measure is not defined before launch, the feature stays in the product as a part nobody dares to touch.
Where to start
Our advice is to begin with a small, clearly bounded use case. Aim for a measurable improvement in a single flow. If the result is good you expand; if not, you have learned at little cost. Putting AI at the centre of the product is a decision to take only after that first step.
