I think a lot of growth teams are still a little too hypnotized by the first session.
The landing page converts.
The signup completes.
The onboarding checklist moves.
The activation milestone looks healthier.
Then the user comes back two days later from a different tab, a different mood, or a different meeting, and the product quietly asks them to solve a harder problem.
What was I doing here.
Why did this matter again.
What already happened.
What am I supposed to do next.
That is not a usage problem. It is a memory problem.
And I think growth teams under-design it all the time.
We spend a lot of energy helping someone start. We spend less energy helping them resume.
That is strange because a lot of products are not really judged in the first sitting. They are judged in the return.
The trial user comes back after internal debate.
The new account returns after the original urgency has cooled off.
The busy manager reopens the tool between meetings.
The learner picks the product back up after work and tries to remember where they left off.
If the product makes them reconstruct too much context from scratch, it creates what I think of as a memory tax.
And that tax compounds fast.
Most user loss is less about dislike and more about broken continuity
I do not think every quiet drop-off means the user rejected the value.
Sometimes they just lost the thread.
A lot of product experiences are more interruptible than teams admit.
People get pulled into Slack.
They switch devices.
Their boss pings them.
They leave halfway through setup because the meeting starts.
They finish the important part and assume they will remember the rest later.
Later arrives, and the product offers very little help.
This is where I still come back to Nielsen Norman Group’s piece on recognition rather than recall. The principle is simple and durable. Good interfaces reduce the amount a person has to remember by making options, history, and next steps visible when they are needed.
That idea gets discussed as a usability heuristic, which is fair.
I also think it is a growth heuristic.
If your return experience depends on the user remembering what the product failed to preserve, you are not only creating friction. You are weakening retention with every avoidable act of recollection.
The second session is often the real test
A first session can run on novelty, urgency, or politeness.
A second session is usually less forgiving.
The product has to help the user restart with less momentum and less spare attention.
That is one reason I like the Power of Small Wins idea from Teresa Amabile and Steven Kramer. Progress is motivating partly because it helps people feel the work is moving somewhere. If a return session hides that progress, the user has to rebuild conviction before they can rebuild momentum.
I think a lot of growth work should be more explicit about that.
When someone returns, the product should answer a few questions immediately.
- What did I already accomplish
- What unfinished job was I in the middle of
- What is the most sensible next move
- Why is that next move worth doing now
If the product cannot answer those cleanly, the user starts paying the memory tax before they reach value again.
That tax is easy to underestimate because it rarely looks dramatic in analytics.
It looks like a shorter session.
It looks like a return that never gets back to the meaningful event.
It looks like a user who opens the app, clicks around, then vanishes.
It looks like “they probably got distracted.”
Sometimes they did.
Sometimes the product did a bad handoff with the future version of the same person.
Good products leave evidence for the person who comes back later
I think about this the same way I think about good handoffs in other domains.
A nurse ending a shift does not say, “I am sure the next nurse will figure it out.”
A trail builder leaves cairns because the next stretch is easier when the route is legible.
A cook who expects to get interrupted leaves the station in a way that makes the next move obvious.
The common idea is not efficiency theater.
It is continuity.
The work keeps making sense after attention breaks.
Products should do that too.
The simplest version is often enough.
Show the draft.
Show what changed.
Show where the user stopped.
Show what still needs to happen.
Show the saved work.
Show the likely next step.
Not in a loud or needy way. Just in a way that lowers reconstruction cost.
This is where I think some onboarding and activation work gets mis-scoped.
Teams obsess over the first-run tutorial and forget to design the re-entry.
But if the first session is where interest is created, the second session is often where habit gets negotiated.
The artifact I like is a context carryover note
When a team is arguing about activation or early retention and nobody can quite explain why return visits feel soft, I would write a context carryover note.
This is not customer research theater.
It is a small working artifact for the journey between sessions.
The point is to force one practical question.
What has to survive the gap between now and later so the user does not come back cold.
Context carryover note
- Entry point or trigger
- What job the user believed they were starting
- Last meaningful progress the product should preserve
- What context the user is likely to forget by the time they return
- What proof of prior work should be visible on re-entry
- The cleanest next step
- What reminder or saved state should renew motivation
- Where the product is still forcing unnecessary reconstruction
- Evidence from behavior, support, research, or replay
- Owner
That is enough.
I do not think this needs a giant framework.
I think it needs honesty.
If the user returns after forty eight hours, what clues are waiting for them.
If the honest answer is “not much,” the team probably has a retention problem hiding inside a continuity problem.
What this changes in practice
Once you start looking at return paths this way, a few useful changes tend to follow.
You get stricter about whether setup work earns its place in the first session.
You stop treating saved state like a convenience feature and start treating it like growth infrastructure.
You become more careful about lifecycle messages that send the user back into a generic product state.
You look harder at whether dashboards, checklists, and notifications are actually restoring context or just making more noise.
You start noticing how many support questions are really failed resumability.
That last one matters.
A surprising number of “how do I finish this” tickets are really “you made me remember too much.”
I also think this makes experiment ideas better.
Instead of only testing stronger prompts, you start testing better continuity.
Resume where you left off.
Show the unfinished draft.
Summarize what changed since the last visit.
Preserve the next best action.
Connect the user back to the job they originally hired the product to do.
Those are growth interventions too.
They just happen to look a little more like product judgment than campaign energy.
A few places I would look first
If I were using this tomorrow, I would start in one of three places.
- users who completed setup work but did not return to the core workflow
- users who came back once but failed to reach the next meaningful milestone
- lifecycle traffic that clicks through and then produces strangely shallow sessions
Each group is telling you something slightly different.
The first group may not have preserved enough value from the first session.
The second group may be losing context between attempts.
The third group may be getting the reminder without the re-entry support.
You do not need a full retention overhaul to learn from that.
You just need to watch where continuity breaks.
The point
I do not think users need every product to become a perfect memory machine.
I do think they deserve better than having to reassemble the story on every return.
A lot of growth work is really the craft of helping momentum survive ordinary life.
Meetings happen.
Kids need dinner.
Tabs close.
Attention splinters.
The user who comes back later is not a new acquisition event.
It is the same person, trying to pick the thread back up.
Good growth product work respects that.
It leaves a trail back into the product.
