Before investing in recommendations or adaptive experiences, determine whether personalisation will solve a valuable customer problem or simply automate a weak product decision.
A founder arrives with a familiar brief: the catalogue is growing, new users struggle to choose and retention is below plan. Soon, the proposed solution has a name. The app needs a personalised feed, AI recommendations or onboarding that adapts to every user.
That may be right. It may also turn a navigation problem, unclear product journey or weak catalogue into an expensive recommendation system. Before we scope the feature, we would want one simpler sentence: which user decision should become easier, and what valuable behaviour should change when it does?
If you cannot answer that yet, you are not ready to build personalisation.
A product team rarely starts with personalisation for no reason. People may be unable to find useful content, abandon a large catalogue or stop after completing the first obvious action.
The problem is that the same symptom can have several causes.
Someone who leaves a content app after browsing for a minute may need better recommendations. They may also be looking at vague categories, poor search results or content that is not useful enough. Someone who ignores the suggested next lesson may want a different lesson, but they may also have no idea why that lesson comes next.
A recommendation engine can rank the available options. It cannot decide whether those options, categories or journeys were useful in the first place.
If the product already makes the wrong assumptions, personalisation simply applies them more consistently.
Personalisation becomes easier to judge once the team stops describing the feature and names the decision behind it.
What should the user watch next? Which plan suits their current goal? Which specialist should they book? What should they do after onboarding?
Consider a hypothetical meal-planning app with 120 plans. New users open the library, scroll through several similar options and leave without choosing their first week. A personalised feed sounds sensible because the catalogue clearly contains too much choice.
But the immediate decision is narrower: help a new user choose one suitable starting plan.
The app might solve that with a flexible seven-day default that is easy to preview and change. If dietary needs create meaningful differences, it could ask two questions and show a suitable version. Neither option requires the product to infer individual preferences from months of behaviour.
So ask:
If every user saw the same well-designed default, would the problem still exist?
If the answer is no, personalisation may be an expensive route around a weak first experience. If the answer is yes, the next job is to understand how users genuinely differ.
The choice is rarely between no personalisation and a custom AI model. There are several useful steps in between.
Begin with one strong default
This works when most users need a similar first result. For the meal-planning app, that could mean placing one flexible starter plan first and explaining who it suits. The full catalogue remains available, but choosing where to begin no longer requires comparing all 120 options.
Let users select their context
If people have a few clear goals, ask them. Their role, experience, dietary needs or current task can direct them towards one of several designed paths.
This needs little behavioural data, the logic is easy to explain and the user can correct it when their situation changes.
Use transparent rules
Rules-based personalisation helps when the next useful action follows behaviour the product can interpret confidently. Complete a beginner plan and the app suggests an intermediate one. Save several vegetarian recipes and it brings the vegetarian collection closer.
This works until the rules multiply, conflict or rely on actions that mean different things in different contexts.
Consider an individual model
A model starts to make sense when the catalogue is large, behaviour repeats often enough to create meaningful signals and simpler rules can no longer handle the variation. The expected improvement must also justify the cost of collecting data, training the system and measuring its decisions.
These are not stages of product maturity. A product does not graduate from defaults to AI. The right level is the cheapest one that makes an important decision easier without creating a larger problem elsewhere.
Optimizely’s guidance on personalisation frames a hypothesis around what changes, who sees it and why it should improve the original objective. For a digital product investment, we would test five connected questions.
“Users need more relevant results” is too broad to fund.
“New users cannot choose their first plan and leave before starting it” gives the team a moment to study, a behaviour to measure and a boundary for the feature.
Look at goals, context and constraints. Then check whether those differences belong to separate people or to separate moments in the same person’s life.
Someone cooking for a family this week may not need the same plan they chose for themselves last month. In that situation, one question asked now may be more useful than a detailed history of past behaviour.
Registered users, isolated clicks and repeated interactions are different things. A catalogue also needs enough structure for the system to understand what it is recommending.
The requirements published by recommendation platforms make this distinction quite physical. For example, Amazon Personalize requires at least 1,000 interactions and 25 users with repeated interactions before certain recommenders can be created. For one current “Recommended for You” model, Google’s requirements include 10,000 page-view events, 100 catalogue items and data collected across several days.
Those are technical minimums, not evidence of product value. A trainable model can still use outdated signals, misunderstand temporary behaviour or solve the wrong problem beautifully.
A recommendation needs a job beyond generating more clicks.
Should more users complete their first plan? Find a suitable specialist? Return for another lesson? Buy a product they can genuinely use?
Choose the behaviour before the system. Otherwise, almost any activity can be presented as engagement while the customer remains no closer to the outcome they opened the app for.
Establish the baseline too. How many users encounter this problem, how often does it happen and what does it currently cost the business? Without that, the team cannot distinguish an important product constraint from an occasional inconvenience.
Then estimate what the change would be worth. A feature can improve a metric and still fail to justify the cost of designing, building and maintaining it.
A poor film recommendation wastes a few seconds. A poor recommendation involving health, money or someone’s career can exclude important information or direct the user towards a harmful action.
As the cost of being wrong rises, the experience needs clearer explanations, more control and a dependable way back. A more accurate model does not remove that design work.
Once the hypothesis is clear, the first test can be much smaller than the proposed feature.
The meal-planning team could focus on the moment when a new user chooses their first plan. It could prepare three routes based on an explicit goal, show them to a small group and keep the general route as a control.
The test should follow what happens next. Do people understand why the plan suits them? Do they choose faster? Do they start it? When the suggestion is wrong, can they recover without returning to the full catalogue?
Clicks can show that people noticed the recommendation. They cannot prove that it improved the decision.
This prototype will not prove long-term retention. It can show whether the proposed difference is useful, reveal where the logic fails and give the team better facts for scoping the feature. If the simple version does not help, the product has avoided turning an unproven assumption into permanent infrastructure.
If it does help, the team has evidence for funding the next level of complexity rather than a reason to jump immediately to the most sophisticated one.
The recommendation itself is only one state in the experience.
The product still needs a useful default for someone with no history. It needs to work when data is loading, confidence is low or an old signal no longer reflects the user’s situation.
It also needs to explain enough of its reasoning. Nielsen Norman Group’s research found that people valued understanding the source of recommendations and having ways to adjust them. That might mean showing “because you completed the beginner course”, letting someone remove an irrelevant interest or keeping the full catalogue within easy reach.
Control also leaves space for discovery. NN/G’s research on overpersonalisation shows how narrow or stale suggestions can make an experience repetitive. A technically accurate system may keep serving one category because the user once clicked it, even when that click came from a temporary need.
So the scope must cover:
That is why personalisation begins as a product strategy and UX problem before it becomes a technical one.
The resulting decision can be straightforward.
The goal is to remove the right amount of effort from an important decision without removing the control, variety or context that made the product useful.
