“Let’s add AI” starts with a solution and looks for a problem afterwards. The result may be a little-used chat window in a corner. We treat AI as part of product development, not a separate service or layer. Before building, we ask these seven questions.
1. What is the actual user problem? #
What can users not do today, or find difficult? “We have no AI feature” is not an answer. Be specific: customers browse too many pages to find the right product, support answers the same questions repeatedly, or employees transfer document data by hand.
A problem defined this clearly also suggests how to judge the solution. If it cannot be written down, the feature is a solution without a problem.
2. Can it be solved without AI? #
This question saves time. Could better search, appropriate filters, a clearer form or simple rules solve the same problem?
Rule-based solutions are predictable, inexpensive and consistent, with traceable errors. AI becomes useful when input is free-form language, options are too numerous for explicit rules, or content needs summarising or classification. Many products need both: rules where they suffice, a model where they do not.
3. Is the data suitable, and may it be used? #
A model depends on the information it receives. We check three things.
- Is the data available and organised? Scattered, contradictory or outdated content produces conflicting answers.
- Is its use permitted? Personal data, customer records and contract-protected information need a legal basis and clear usage limits.
- Where does it go? Understand upfront how the model provider processes and stores the data sent to it.
If these answers are unsatisfactory, organise the data before choosing a model.
4. What happens when the model is wrong? #
Language models can state false information as confidently as true information. This is a characteristic of the technology, not an exception, and the design must account for it.
Ask what a wrong answer costs. An incorrect product recommendation can be corrected; an incorrect price, health referral or legal statement may have consequences that cannot. As the stakes rise, restrict the model’s freedom: use approved sources, show them and block prohibited actions in application logic too. Make clear that users are talking to AI.
5. Is a human handoff needed? #
Some situations a model cannot, or should not, resolve: complaints, exceptions, requests beyond its authority and emergencies. Design how the conversation or task passes to a person before launch.
Handoff is part of the product, not a failure. Define the trigger, the summary given to the person taking over and what the user is told. Our product Grow4Me illustrates this approach: the assistant uses brand-defined knowledge and rules, stops at emergency language and flags unmatched cases in the dashboard. We explain the setup decisions in building an AI sales agent on WhatsApp.
6. Are cost and response time acceptable? #
AI costs do not end at development; they recur with every use. As usage grows, so does the bill. Estimate the relationship between the feature’s value and per-use cost before launch.
Response time is a design issue too. A few seconds waiting mid-flow are different from a few seconds in a background task. Where waiting is unacceptable, consider a smaller model, prepared results or a progressively displayed answer. Avoiding dependence on one provider is also part of the cost decision.
7. How will success be measured? #
“We have an AI feature” is not an outcome. The first question’s problem becomes the measure: are users completing work more easily, is less work handed over, and are answers correct?
Two types of measurement are needed. For quality, build a test set from real questions and rerun it after changes. For usage, track adoption, abandonment and human handoffs. Without a baseline, later measurements have no comparison.
Using the questions #
Put the seven answers on one page and one of three outcomes follows. The problem does not need AI, so build a simpler solution. The problem is real but the data is not ready, so prepare it first. Or the conditions are right, and the feature enters the first release with clear boundaries and measures.
Each outcome should be understood before building. In our SaaS and business software work, AI functions sit on the same roadmap as product scope, user flows and technical architecture.
