I think a lot of growth teams talk about adoption as if the user is standing still waiting for a better idea.
They are not.
They already have a routine.
Maybe it is messy.
Maybe it is manual.
Maybe it lives across three tools, a spreadsheet, and one patient teammate.
Maybe it is not even a product so much as a patchwork of habits that sort of works.
That patchwork matters more than many teams admit.
When someone adopts your product, they are not only saying yes to a new interface.
They are renegotiating an old working arrangement.
They are deciding whether to trust a new system with a job that already has a home.
That is why I think some products undershoot the real challenge.
They design the new flow carefully and barely study the old routine they are asking the user to leave.
Then they act surprised when signups look interested, trials look polite, and real switching lags behind.
Switching is not the same as choosing
Choosing is a moment.
Switching is a period of life.
A user can agree that your product is better and still not move.
A team can like the demo and still keep the old system.
An admin can believe the migration will be worth it and still delay it for two months.
That is not always irrational.
It is often just a clear reading of the work involved.
The old routine already has memory.
It has shortcuts.
It has social norms.
It has fallback plans.
It has a place where people look when they forget what to do.
It has one field nobody likes but everyone understands.
It has one person who knows how to rescue the weird case.
Your product is not only competing with another product.
It is competing with accumulated familiarity.
I keep coming back to a line of thinking from Intercom’s piece on future customers already using another product. The useful reminder is that customers arrive with a backstory, not a blank slate. That should change how a growth team thinks about onboarding, evaluation, and activation.
The real competitor is often not feature parity.
It is the lived competence users already have somewhere else.
The current solution is usually bigger than the software
This is where product teams get sloppy.
We compare our product to the incumbent product feature by feature.
Meanwhile the user is comparing routines.
Their current setup may include a vendor.
It may include an internal process.
It may include a saved template, a Slack norm, a naming convention, and two unwritten rules about who is allowed to touch what.
That is why migrations fail in such ordinary ways.
The new tool handles the official workflow.
The old routine handled the unofficial one too.
The new tool imports the data.
The old routine also contained the labels people trusted, the weird exceptions they remembered, and the quiet reassurance that came from seeing familiar shape on the page.
The new product may be objectively cleaner.
The old one may still be easier to carry in the hand.
GOV.UK makes a version of this point in their guidance on learning about users and their needs. Before designing the future service, they say teams should learn how users currently get the job done and what frustrations sit inside that existing path. I think growth teams need that posture more often.
If you skip the current routine, you usually misread the adoption problem.
You think the user needs persuasion.
Often they need continuity.
Migration work is really continuity work
One of the best lessons from software architecture is that replacement rarely succeeds as a clean cutover story.
Martin Fowler’s Strangler Fig Application remains useful because the metaphor is so practical. New systems often work better when they grow around the old one gradually, delivering value while reducing risk instead of demanding one dramatic leap.
I think product adoption often needs the same humility.
Users do not always want a ceremonial switch.
They want a safe bridge.
They want to keep enough of the old world intact that the new one can earn trust.
That may mean importing old content before asking for new behavior.
It may mean preserving naming conventions before introducing a new taxonomy.
It may mean letting the product coexist with the spreadsheet for a while instead of declaring the spreadsheet dead on day one.
It may mean helping one team run one high value workflow first instead of asking the whole account to migrate every job at once.
This is not cowardice.
It is product judgment.
The team is acknowledging that adoption has sequencing risk.
A lot of products ask users to throw away competence too early.
That is a much bigger ask than many launch plans admit.
Change aversion is often a signal not a nuisance
Growth teams sometimes talk about reluctance as if it is mostly a marketing problem.
The user does not get it.
The buyer is conservative.
The account is slow to change.
Maybe.
Sometimes reluctance is the product telling you the bridge is weak.
The Google Research case study on minimizing change aversion for the Google Drive launch is useful here. The paper frames change aversion as a natural response and shows that teams can reduce anxiety by understanding the transition better rather than simply pushing harder.
I like that framing because it treats hesitation as information.
If users resist the move, ask what competence they are protecting.
Ask what memory the old system is holding.
Ask what downstream mess they think they will inherit if the migration goes sideways.
Ask what part of the old routine still feels easier to teach to the next person.
A lot of so-called resistance becomes legible once you study the thing being protected.
Then better product ideas appear.
Preview the imported result.
Preserve the familiar label set.
Create a reversible first step.
Give the user a side by side period.
Let one useful workflow go live before the whole system does.
These are not just launch tactics.
They are ways of respecting the fact that users built muscle memory somewhere else.
The artifact I like is an old-routine map
When a team says users should switch because the new product is clearly better, I like slowing the room down with one simple artifact.
Not a giant migration program plan.
Not a fifty row competitor grid.
Just a working map of the routine the user already has.
The question is simple.
What exactly are we asking the user to stop doing, stop trusting, or stop remembering in order to adopt this new thing.
Old-routine map
- Current tool or workaround the user relies on
- Job the old routine is actually doing
- What the old routine does well enough that users trust it
- Hidden helpers such as templates, teammates, naming conventions, exports, or reminders
- Most annoying part of the current routine
- Part users are strangely attached to
- What must be preserved for the first step to feel safe
- What can change immediately without raising risk
- What has to be translated, imported, mirrored, or wrapped
- Smallest slice of the job that can move first
- Evidence from interviews, support, sales calls, setup calls, or migration tickets
- Owner
This gets useful fast.
You find out the spreadsheet is not only a storage layer.
It is also the team’s shared source of truth during escalation.
You find out the old analytics tool is not beloved, but the weekly export it sends is deeply embedded in the manager’s review ritual.
You find out the user is not attached to the legacy system itself.
They are attached to not looking incompetent in front of coworkers during the switch.
That last one matters a lot.
Adoption work is often social risk management disguised as interface work.
Better activation sometimes starts before the user signs up
This is the part I wish more growth teams took seriously.
If your product mostly wins switchers, then activation may begin before account creation.
The work starts when the user first wonders whether the move is survivable.
Can I see my old world in the new product.
Can I bring enough of my context with me.
Can I test this without creating double work.
Can I explain the transition to my team without sounding reckless.
Can I go back if this turns messy.
GOV.UK’s guidance on moving away from legacy systems is nominally about government technology, but I like how directly it says you should understand the old constraints, reduce dependencies carefully, and avoid recreating the same system blindly. That is good product advice too.
A thoughtful growth PM should be asking similar questions.
Where are the dependencies.
What do users need to keep stable for a while.
What wrapper, bridge, import, or shared view would reduce the cost of trust.
What can be adopted in layers instead of all at once.
Those questions are often more useful than another round of homepage positioning tweaks.
Respect the old routine and you learn where the new one should begin
I do not mean the incumbent always deserves deference.
Some old routines are clearly bad.
Some are wasteful.
Some are held together by heroics.
Some should absolutely be replaced.
Still, the fact that a routine is flawed does not mean it is empty.
It usually contains logic about what users fear losing.
It contains clues about what they need to preserve while trust is still forming.
It contains evidence about what part of the new value proposition has to arrive first.
That is why I think growth product work gets better when it treats switching as a continuity problem before it treats it as a persuasion problem.
The best adoption systems do not only announce a better future.
They carry enough of the old world forward that users can cross the bridge without feeling foolish.
Before you redesign the new path, spend a little more time with the old one.
