I think a lot of growth teams still imagine one tidy user.
The person who sees the page is the person who signs up.
The person who signs up is the person who sets things up.
The person who sets things up is the person who comes back every day.
Sometimes that is true.
A lot of the time it is not.
In plenty of products, especially at work, the first believer and the eventual regular user are different people.
A manager starts the trial.
An operator inherits the workflow.
A team lead invites the group.
A coordinator gets asked to keep the thing alive after the original excitement has moved on to some other meeting.
That handoff is where a lot of adoption quietly breaks.
The evaluator says this looks promising.
The everyday user opens the product and thinks this looks like more homework.
Both reactions can be rational.
A lot of products are chosen in one room and lived in somewhere else
I think about this the same way I think about buying a house with a great open house and a bad kitchen.
The tour goes well.
The light is nice.
The listing photos did their job.
Then someone tries to cook there every night and learns what the place is actually like.
Products have the same split.
The evaluator is often judging possibility.
The everyday user is judging fit, effort, interruption cost, and whether this thing will make Tuesday afternoon easier or harder.
That is one reason I keep coming back to Jobs to Be Done. People do not adopt products because the category story was persuasive. They adopt them because the product helps them make progress on a real job in a real environment with real constraints.
The evaluator may care about strategic upside.
The everyday user may care about whether the first recurring task feels cleaner than the old workaround.
If the product only speaks convincingly to the first person, it may win the meeting and lose the week.
Growth teams often optimize the first yes and under-design the internal relay
I do not think this is just a sales problem.
It shows up in self serve products all the time.
The homepage promises collaboration.
The signup flow is built for one motivated person.
The onboarding celebrates account creation.
The first real workflow assumes the evaluator can translate the setup, teach the behavior, answer the objections, and carry the social risk of change for everyone else.
That is a lot to ask.
We would never treat a relay race as four separate sprints with no baton practice.
We would never treat a stage production as complete because the audition went well.
We would never treat a restaurant as healthy because the host stand felt polished while the kitchen line collapsed after the first ticket.
Yet product teams do versions of that mistake all the time.
They mistake persuasive entry for durable transfer.
The evaluator is not only buying the product
They are buying the explanation
This is the part I think more teams should notice.
When one person brings a product into a team, they usually have to explain it in absentia before the product ever gets the chance to explain itself.
Why this one.
Why now.
Why this workflow.
Why the setup is worth it.
Why the old way is no longer good enough.
If the evaluator leaves the first session without those materials in their head or in the product, the handoff gets sloppy fast.
This is where the GOV.UK guidance on starting to use a service is more useful than it first appears. Their pattern pushes teams to give people enough context before they begin, including what the service does, what they will need, and whether they can resume or update later.
That sounds like service design.
I think it is also adoption design.
The first believer often needs a clean way to hand the product to the next person without becoming unpaid customer success.
The wrong teammate often pays for the optimism of the right teammate
I have seen this a lot in onboarding and activation work.
The first user is willing to poke around because they chose the tool.
They tolerate rough edges because they are still in discovery mode.
They forgive some ambiguity because they already buy the potential.
The invited teammate is different.
They did not wake up wanting a new system.
They may already have a method that is ugly but dependable.
They may be inheriting someone else’s enthusiasm at the exact moment they are busiest.
That user does not need a more animated checklist.
They need a believable reason that the new workflow will make their own job easier soon enough.
I like the GOV.UK pattern on checking whether a service is suitable for a similar reason. It is blunt in a good way. Help people figure out early whether this is right for them, what they need, and what happens next.
That principle matters inside team adoption too.
The second person should not have to reverse engineer whether this product was chosen for them or with them in mind.
A lot of collaborative adoption fails because the proof does not survive the handoff
This is where I think growth product work starts looking a little like museum design and a little like shift handoff in a hospital.
The museum has to help one room teach the next room what matters.
The shift handoff has to preserve what the next person must know without making them reconstruct the whole day from scratch.
Good collaborative products have the same obligation.
What did the evaluator already learn that the teammate now needs.
What job was the team trying to solve.
What first evidence made the product feel promising.
What should the invited user do first so the product can prove itself in their terms, not only in the chooser’s terms.
If that evidence disappears, the invited user experiences the product as unexplained labor.
That is one reason I still like recognition rather than recall. The principle is not just about menus and interface labels. It is also about making the important context visible so the next person does not have to recall a conversation they were not even in.
The invited teammate should be able to recognize
- why they were brought in
- what has already been done
- what outcome the team is trying to reach
- what the best next move is
- what proof will show this is worth repeating
If those clues are absent, the teammate has to do interpretation work before they can do value work.
That is a bad bargain.
The artifact I like is an adoption relay note
When a team keeps winning initial interest but struggling to turn invites, shared accounts, or team rollouts into healthy repeated use, I would write an adoption relay note.
Not a giant implementation plan.
Not a deck full of stakeholder theater.
Just a small working artifact for one practical question.
What has to transfer cleanly from the chooser to the doer.
Adoption relay note
- Who first says yes
- Who has to use the product regularly after that
- What job the evaluator thinks the product will improve
- What job the everyday user actually needs help with first
- What proof convinced the evaluator
- What proof will matter more to the invited teammate
- What setup work the first person can do once so the second person does not have to
- What explanation should be visible inside the product rather than carried by memory or Slack
- What first shared outcome would make the handoff feel successful
- Evidence
- Owner
That is enough.
The point is not to formalize every multi-player workflow on earth.
The point is to stop pretending the baton passes itself.
What changes once you see the relay clearly
A few useful things usually happen.
You stop over-crediting account creation when the real adoption risk starts after the invite.
You get stricter about what the evaluator must set up before asking teammates to care.
You write invite flows and landing states that explain the job, not only the feature.
You look harder at whether the second user sees progress in their own language.
You become less impressed by top of funnel motion that depends on one enthusiastic internal champion doing too much translation labor.
That last one matters.
Some products do not have an acquisition problem.
They have a baton problem.
One person can get the team into the race.
The product still has to help the next person run their leg.
Good growth work respects the social shape of adoption
I think this is one of the reasons growth product work stays interesting.
It is not only about clicks, prompts, or flow completion.
It is also about reading the social geometry around the product.
Who discovers it.
Who blesses it.
Who configures it.
Who inherits it.
Who quietly decides whether it becomes part of the team’s real working rhythm.
Those are not always the same person.
When teams act like they are, they end up measuring the wrong victory.
The evaluator said yes.
The everyday user never really did.
If I were diagnosing a soft multi-user activation curve tomorrow, I would spend less time asking how to drive more invites and more time asking whether the invited teammate receives a useful handoff.
That is usually where the truth is hiding.
