I think a lot of growth teams spend too much time staring at clean funnels and not enough time studying messy almosts.
Almost signed up.
Almost finished setup.
Almost understood why this mattered.
Almost came back.
Almost renewed.
Those moments are rarely dramatic enough to earn a postmortem. They often look like ordinary drop-off, support noise, soft confusion, or a session that just quietly ends.
That is part of why they matter.
A broken experience is easy to notice. An almost-leave is easier to rationalize away.
Maybe the user was busy.
Maybe the traffic was lower intent.
Maybe the segment was never going to convert.
Sometimes that is true.
Sometimes the user was one good handoff away from staying.
Growth work gets better when you study the handoff, not only the outcome
I keep coming back to customer experience work for this reason.
Not because growth teams need to become service designers overnight, but because customer journey thinking forces a more honest view of where momentum breaks.
Adam Richardson wrote in Harvard Business Review about customer journey maps as a way to map the experience you actually deliver, not the one your org chart imagines. Sarah Gibbons makes a similar point in NN group’s journey mapping primer when she describes the value of a shared view across the full experience.
That framing is useful in growth because a lot of user loss happens between functions.
Marketing promises one thing.
The landing page sharpens it.
The signup flow asks for something else.
The product opens in a generic state.
The lifecycle email arrives with the wrong reminder.
Support hears the complaint after everyone else has moved on.
No single step is catastrophic on its own.
The handoff is what fails.
Most churn has a prehistory
By the time a user fully disappears, the story has usually been developing for a while.
There was the search visit that created curiosity but not conviction.
There was the onboarding step that felt heavier than the expected payoff.
There was the feature that technically worked but did not connect to the job the user was trying to get done.
There was the return visit where the product did not help them reconstruct context.
There was the lifecycle message that sounded automated because it was.
There was the support interaction that solved the ticket but not the underlying confusion.
That is one reason I still come back to Jobs to Be Done in Harvard Business Review. If you lose sight of the job, every rough spot starts to look like generic friction. When you stay anchored in the user’s job, you can see whether the product is helping someone make progress or quietly asking them to do translation work.
I think a lot of growth analysis starts too late.
It starts once the user is already gone.
I would rather study the moments where they were still persuadable.
The artifact I like is a friction ledger
This is not a dashboard.
It is not a giant taxonomy exercise.
It is a small running document for moments where users nearly leave, stall, or downgrade their conviction.
Friction ledger
- Moment in the journey
- User job or expected outcome
- What the product or message asked them to do
- Why the handoff likely felt off
- Evidence from behavior, support, research, or replay
- Cost if ignored
- Best next fix
- Owner
That is enough.
The point is not to create a grand unified system. The point is to stop treating every drop as an isolated metric event.
Once the ledger exists, patterns show up quickly.
You may find that several different surfaces are producing the same user question.
You may find that acquisition is bringing in intent the product does not honor well.
You may find that support tickets are concentrated around moments the lifecycle team keeps trying to patch with reminders.
You may find that a supposedly small piece of confusion is expensive because it appears before the user has seen any believable value.
Those are growth problems, not only UX problems.
Why this is better than a bug list
A bug list is useful when something is broken in the conventional sense.
A friction ledger is useful when something still functions but creates avoidable doubt.
That distinction matters.
A lot of important growth problems are not defects.
They are mismatches.
The copy is accurate but not clarifying.
The flow is logical from the company perspective but not from the user perspective.
The email arrives on time but with the wrong narrative.
The setup step is technically required but poorly sequenced.
The support answer resolves the issue but leaves the original expectation gap untouched.
If you only log hard failures, you miss the softer moments that shrink trust.
Those soft moments accumulate.
I think the best friction work feels a little like field research and a little like operations
This is one of the reasons I enjoy growth product work in the first place.
You are borrowing from different crafts at once.
A bit of user research.
A bit of systems thinking.
A bit of copy judgment.
A bit of instrumentation discipline.
A bit of customer support humility.
A bit of editorial instinct about where the narrative lost the reader.
Good friction work often feels less like inventing a clever growth trick and more like noticing that several different teams are each holding one piece of the same broken story.
That is also why I do not think this ledger should live with only one function.
Product should use it.
Lifecycle should use it.
Support should use it.
Whoever owns acquisition should use it.
The artifact works because it gives the team one place to notice that the same user confusion is surfacing in different costumes.
A lot of lifecycle work is downstream from an earlier missed handoff
I like Braze’s writeup on customer lifecycle marketing mostly because it reinforces the idea that the relationship is cumulative. The user does not experience your lifecycle as separate departments. They experience one ongoing sequence of interactions.
That sounds obvious, but teams still act as if every channel gets a clean slate.
It does not.
If the user left a setup flow unconvinced, the win-back email inherits that skepticism.
If the landing page framed the wrong use case, the onboarding flow inherits that confusion.
If the product failed to preserve context, the return session inherits that memory tax.
That is why I think a lot of lifecycle optimization is really handoff repair.
Not all of it, obviously.
But enough of it that growth teams should keep asking whether the message is compensating for something the product should have handled earlier.
What I would do with this in practice
I would not try to inventory every rough edge in the product.
That becomes theater fast.
I would start with a narrow slice of the journey that matters commercially.
Maybe a high intent SEO landing path.
Maybe the first week for newly activated accounts.
Maybe the return path for trial users who viewed value once and then went quiet.
Then I would pull evidence from a few places at the same time.
- session replays or pathing
- support tickets
- lifecycle performance
- a handful of user interviews or call notes
- the actual copy and product states the user saw
I would log the repeated almost-leaves.
Then I would force prioritization with one question.
Which moments create the most avoidable doubt before the user has formed stable conviction that this product is worth keeping around
That is a sharper question than asking where conversion is low in the abstract.
The ledger also improves experiment quality
One thing I have noticed is that experiment backlogs get better when they are grounded in real friction moments instead of generic funnel ambition.
Without that grounding, the team starts shipping ideas like
- make the CTA louder
- add urgency
- shorten the form
- send another reminder
- push the upgrade prompt later
Some of those might work.
But they are often guesses about symptoms.
When the backlog is fed by a friction ledger, the hypotheses get more specific.
You are not only trying to lift a step.
You are trying to repair a known handoff that is creating confusion, doubt, or context loss.
That usually leads to better tests and better post test interpretation.
A simple gut check
Pick one funnel drop that your team talks about all the time.
Now ask a less abstract question.
What was the last moment before that drop where the user still had a believable chance of staying, and what exactly made that moment harder than it needed to be
If your team cannot answer that clearly, I would not trust the fix list yet.
You may be looking at the smoke instead of the spark.
The point
Growth teams do not only need cleaner dashboards.
They need better memory for the moments where user conviction got weaker.
That is why I like a friction ledger.
It gives the team a place to notice the near exits, the broken handoffs, and the small moments of doubt that never look important in isolation but become expensive in aggregate.
A lot of product growth work is not about inventing a new loop.
It is about repairing the moment right before someone would have stayed.
