I think a lot of growth work still over-focuses on the front door.
We audit acquisition.
We tighten onboarding.
We tune activation.
We celebrate the first meaningful action.
All of that matters.
Then the user starts actually living with the product.
That is where a different class of problem shows up.
Not dramatic failure.
Not obvious confusion.
Just upkeep.
The small repeated chores the product quietly hands back to the user in order to keep the value alive.
Reconnect the integration.
Re-clean the data.
Re-explain the workflow to the next teammate.
Rebuild the report because the defaults never quite hold.
Recheck the settings because trust has not been earned.
Those moments do not always kill the first session.
They often poison the third, seventh, or twentieth one.
I think that is why some products look promising in activation reporting and still struggle to become a durable habit.
The product produced a first win.
It also produced a maintenance job.
Growth teams often count arrival better than upkeep
I have been borrowing a phrase from SRE for this.
Google describes toil as the repetitive, manual work that scales with the system and creates no enduring value. That language was written for operating services, not onboarding a user into a product. I still think it travels well.
Some product experiences create user toil.
Not because the product is broken in the obvious sense.
Because the product keeps requiring small acts of maintenance that do not deepen value.
A founder can still call that engagement.
A dashboard can still call that activity.
The user usually calls it annoying.
This matters more in growth product than teams often admit.
A lot of retention loss is not one big disappointment.
It is a slow accumulation of chores.
The user has to keep doing work that feels adjacent to the real job instead of part of it.
You can have a product that is easy to start and subtly expensive to maintain.
That pattern is dangerous because the early funnel does not tell the whole truth.
Repeated effort changes the relationship
One of the best service design habits from GOV.UK is the standard that a service should help people succeed the first time with the minimum of help. Their guidance on making the service simple to use sounds basic. I think the deeper lesson is that simplicity is not only about first-use comprehension. It is also about whether the service keeps creating avoidable work later.
That is the part I think growth teams under-measure.
We are good at spotting first-run friction.
We are less disciplined about recurring friction.
The first type hurts conversion.
The second type changes the relationship.
A user can forgive setup work if it clearly buys future ease.
A user gets much less patient when the same category of effort keeps returning.
That is when a workflow starts feeling like lawn care.
You thought you were buying a clean yard.
You inherited a Saturday obligation.
Not all effort is bad
I do not mean products should eliminate all effort.
Some effort is the value.
Writing is effort.
Learning is effort.
Collaboration is effort.
Decision-making is effort.
The question is whether the effort belongs to the user’s job or to the product’s unfinished housekeeping.
That distinction matters.
Google’s toil framing is useful because it separates meaningful engineering work from repetitive maintenance work that should be designed away or automated. In product, I think the same filter helps separate valuable user investment from avoidable product upkeep.
Did the user spend time drafting the message because the message itself mattered.
Good.
Did the user spend time hunting through settings because the product cannot remember a stable preference.
Different story.
Did the user repeat a calibration step because their judgment improved with practice.
Maybe that is the point.
Did the user repeat it because the product forgot context it already had.
That is upkeep tax.
A lot of hidden churn comes from maintenance burden
This is one reason public service design has become more interesting to me.
Brookings has written about how poor service design and disconnected systems increase administrative burden and waste time for both the public and the staff supporting them. Different domain, same smell.
When systems make people restate information, switch channels, or recover from process complexity that should have been designed out, trust erodes.
Products do this too.
A CRM asks the team to keep cleaning the same fields because imports never normalize well enough.
An AI workflow asks users to keep re-establishing brand voice because the system never really learns the operating context.
A collaboration product asks each new teammate to reconstruct decisions that should have survived the handoff.
A reporting tool asks operators to keep exporting to spreadsheets because the product never made recurring review easier.
Each of those chores may look survivable in isolation.
Together they create a maintenance burden that users start pricing into the relationship.
That burden changes a retention question from do I like this product to do I want to keep carrying this product.
Interaction cost compounds when it keeps coming back
NN group has a useful framing in their piece on zen mode. The article argues that hiding necessary controls can increase interaction cost and cognitive load even when the interface looks cleaner.
I think the broader product lesson is that users notice recurring retrieval work more than teams expect.
If the user has to repeatedly remember where something lives, how to recover state, or how to rebuild context, the product is charging rent on attention.
One extra step is not always a problem.
A step that returns every week becomes a tax.
This is why I have become skeptical of retention discussions that focus only on delight, novelty, or new feature pull.
Sometimes the best retention work is less glamorous.
Remove the repeated little chores.
Lower the amount of remembering.
Reduce the number of times the product makes the user do janitorial work.
The artifact I like is an upkeep tax map
When a product gets decent first-use signals but struggles to become part of normal life, I like making an upkeep tax map.
It is not a giant journey map.
It is not a lifecycle dashboard with eight tabs.
It is a small working artifact for one practical question.
What work does the product keep handing back to the user after the first win.
Upkeep tax map
- Repeated user task that appears after initial setup or activation
- Frequency
- What user outcome the task is supposed to protect
- Why the task keeps returning
- Whether the effort belongs to the user’s real job or to product housekeeping
- Signs the task is creating avoidance, delay, or workaround behavior
- What could be automated, remembered, templated, prefilled, or designed away
- Segment most affected
- Evidence from support, replay, research, lifecycle responses, or churn notes
- Owner
This gets useful quickly.
You start noticing that some of your healthiest-looking accounts are held together by one determined operator doing quiet cleanup.
You notice that team plans sometimes depend on an internal champion who keeps compensating for product memory gaps.
You notice that users who never complain are still doing a lot of repetitive repair work.
That is rich growth information.
What changes once you can see the upkeep tax
The first thing that changes is your understanding of retention.
You stop treating churn only as a story about missing value.
Sometimes the value is there.
The issue is that the cost of preserving access to that value keeps showing up.
The second thing that changes is your roadmap quality.
A lot of teams respond to weak retained usage by adding more prompts, more reminders, more education, or more incentive layers.
Sometimes the better move is simpler.
Stop creating maintenance labor that the reminder system is trying to paper over.
The third thing that changes is your read on power users.
Power users are often not proof that the workflow is healthy.
Sometimes they are proof that one segment is unusually willing to carry the upkeep burden.
That is a very different lesson.
Good retention work often feels a little like service design and a little like facility management
I like that combination because it keeps the work honest.
Service design asks whether the journey works cleanly across moments, channels, and constraints.
Facility management asks whether the thing can keep operating without requiring constant heroic intervention.
Growth product needs both instincts.
It is not enough for the experience to make a good first impression.
It has to remain livable.
A hallway that looks beautiful on day one but needs repainting every week is not a triumph of design.
A product that generates a strong first win but requires recurring cleanup from the user is not as sticky as the dashboard might suggest.
The question I want teams asking more often
Not only where are users getting stuck.
Also where are users doing our maintenance for us.
That question has changed how I look at activation, onboarding, lifecycle, and retained usage.
Because a lot of growth work is not about creating more motion.
It is about removing the quiet chores that make continued motion feel heavier than it should.
The first win matters.
The cost of keeping that win alive matters too.
