I think a lot of growth teams reach for personalization one step too early.
The homepage should adapt to source.
The onboarding should branch by persona.
The lifecycle should change by intent score.
The search landing page should flex by query cluster.
The AI assistant should infer what the user probably wants next.
Sometimes that is exactly the right move.
Sometimes it is a neat way to avoid admitting that the baseline path is still fuzzy.
If the common journey is weak, personalization rarely fixes the real problem.
It mostly spreads the problem across more states.
Now the team has six variants of a vague first session instead of one.
I do not think this is only a design issue.
I think it is a growth product judgment issue.
The baseline journey is where a product reveals what it believes the most likely user is here to do, what progress should feel like, and what the next obvious move should be.
If that default path is confused, every layer added on top of it inherits the confusion.
There is no neutral default
One reason this matters is that teams still talk about defaults as if they are passive.
They are not.
The default is a decision.
Which screen people land on.
Which project type is preselected.
Which recommendation appears first.
Which channel is highlighted.
Which audience gets the simpler flow.
Which trade is quietly baked into the easiest path.
That is why I still like Do Defaults Save Lives?. The context there is obviously much higher stakes than software product design, but the underlying lesson travels well. Defaults shape behavior because they lower the work of choosing and signal what the system expects.
Growth products do that constantly.
A default path tells the user what kind of behavior is normal here.
It tells the team what kind of user they optimized for.
It tells leadership what counts as the intended route.
That is not neutral.
It is product strategy wearing a usability costume.
Personalization is often camouflage for an underdesigned baseline
I have seen this in a lot of familiar places.
A search landing page underperforms, so the team adds more dynamic content instead of clarifying the base promise.
An onboarding flow is hard to follow, so the team adds persona routing before the common setup story is legible.
A dashboard feels overwhelming, so the team adds recommendation modules without deciding what the house view should make easiest first.
A lifecycle program brings users back, so the team adds more branching logic instead of improving the default landing state.
An AI assistant looks smart in demos, but the product still has not defined the one reliable action a new user can take when the inference is wrong.
In each case, personalization can create local lifts.
It can also make the system harder to reason about.
When the baseline is weak, the team starts learning from a moving target.
Was the result better because the right segment got the right path.
Was it better because the old path was bad.
Was it better because the new branch accidentally carried clearer copy.
Was it better because the personalized surface hid a navigation problem that still exists for everyone else.
That is why the Nielsen Norman Group advice in Customization vs. Personalization in the User Experience feels so durable to me. Start with a usable site. Build a tight base-level design. Then layer personalization or customization where it truly improves fit.
That sequence sounds conservative.
I think it is actually how ambitious teams protect learning.
Good defaults make personalization more honest
The point is not to reject personalization.
Some products absolutely need it.
Role based tools need it.
Content heavy products need it.
Large inventories need it.
Lifecycle systems need it.
AI products especially need it because intent is variable and the cost of a wrong guess can be high.
But I trust personalization more when the default path is already respectable on its own.
If a generic new user from search lands on the product, can they tell what the product is for.
If a teammate opens an invite, can they see the intended first move.
If a user returns from an email, does the baseline state make progress legible.
If the smart recommendations fail, is the fallback still useful.
If the segmenting logic breaks, is the common route still coherent.
That last question matters more than teams admit.
A lot of sophisticated growth systems are one bad model, one stale trait, or one missing event away from dropping users into a brittle experience.
The baseline path is your resilience layer.
Other fields respect the house route before they get fancy
Restaurants do this well.
A good restaurant can have specials, pairings, and off menu adjustments.
It still needs a house menu that makes sense without a waiter improvising the whole night.
Museums do it too.
They may offer alternate tours for families, scholars, or school groups.
They still design a main route that helps the average visitor understand where to begin, what matters, and how to keep moving.
Coaches script opening plays for a reason.
Even with opponent specific wrinkles, the team needs a base sequence that settles everyone into the game and reveals whether the fundamentals are stable.
Government services are stricter about this than many product teams are. The GOV.UK guidance on Start using a service pushes teams to give users enough context up front, help them understand whether the service meets their need, and support sign in or resume paths where relevant.
That is not anti personalization.
It is respect for the baseline.
Before you optimize the branches, make sure the main road is drivable.
The baseline often carries your product philosophy
This is the part I think growth teams miss.
The default path is not only a convenience.
It is an argument.
It says what kind of progress should come first.
It says what uncertainty is acceptable.
It says which user gets the cleanest path.
It says whether the product prefers education, exploration, automation, or proof as the first move.
That is why baseline work often feels oddly strategic even when the surface looks small.
Should the user start by connecting data or by seeing an example.
Should the workspace open empty or prepopulated.
Should the product ask for preferences or demonstrate value first.
Should the lifecycle link return people to a generic home or the unfinished thread.
Should the AI default to drafting or to clarifying the task.
Those are not only UX decisions.
They reveal what the team believes good adoption looks like.
If that philosophy is still muddled, personalization will not clarify it.
It will just let you avoid choosing in public.
The artifact I like is a default-path brief
When a team keeps trying to solve weak activation or messy return behavior with more segmentation, I like writing a default-path brief first.
Not a full journey map.
Not a giant targeting matrix.
Just a small artifact for one journey that matters.
What should the product make easiest for the most likely user if no personalization fires at all.
Default-path brief
- The user arriving on the baseline path
- The source or context that most commonly puts them there
- The job they are most likely trying to make progress on
- The one action the product should make feel safest and most obvious first
- The proof the product should surface before asking for deeper setup or commitment
- The information that should be visible by default rather than hidden behind inference or navigation
- The fallback state if recommendations, segmentation, or AI inference are wrong
- The assumptions built into this path about intent, ability, and urgency
- The important user type this baseline will underserve and why
- The signal that would justify branching away from the baseline later
- Evidence from research, behavior, support, or experiment readouts
- Owner
That is usually enough.
The point is not to ban adaptive experiences.
The point is to make the team earn them.
This changes what you learn from growth work
Once the default-path brief exists, several useful things happen.
You get clearer about whether personalization is solving a real user need or covering an unresolved baseline problem.
You become stricter about fallback behavior when targeting logic is missing or wrong.
You notice when the house route is optimized for internal certainty instead of user momentum.
You get better experiments because the control is more coherent.
You also get better cross functional conversations.
Engineering can see what has to remain stable.
Design can see what the baseline is trying to communicate.
Lifecycle can stop linking people back into dead generic states.
Analytics can separate baseline quality questions from branching quality questions.
The team stops asking only, should we personalize this.
It starts asking a more useful question.
If every smart layer fell away tomorrow, would the product still know how to help a likely user get moving.
That is the default I want to trust first.
