I think one of the easiest ways to lie to yourself in growth product work is to confuse user progress with operator rescue.
The signup gets completed.
The integration gets connected.
The team invites go out.
The first workflow gets launched.
The account renews.
Everything looks self-serve from the dashboard.
Then you sit in on the actual journey and notice someone has been quietly holding the whole thing together.
A support rep fixes the setup mistake over chat.
A founder rewrites the first campaign for the customer.
A customer success manager joins the kickoff call and translates the product into plain English.
An internal champion keeps reminding the rest of the team what button to press and why it matters.
A patient operator cleans up the data every Friday so the report still looks trustworthy on Monday.
The product gets credit.
The human absorbs the chaos.
I think this is one of the big reasons some growth systems look healthier in the metrics than they feel in the field.
The product may not be self-serve at all.
It may be assisted.
Just not in a way the team has bothered to count.
Self-serve is often a staffing decision disguised as a product win
I like borrowing from operations because operations people have a lower tolerance for flattering narratives than product teams usually do.
Google’s SRE book on eliminating toil has a useful definition for work that is manual, repetitive, automatable, and lacking enduring value. It is written for service operations, not onboarding or retention. I still think the idea travels cleanly.
A lot of products create user toil.
A lot of companies create customer-facing toil and then hide it inside human support.
That support may come from support, success, implementation, sales engineering, a power user inside the account, or one unusually patient teammate.
The reason I care about this as a growth PM is simple.
If a funnel only works when a hidden human keeps compensating for it, then the funnel does not really scale at the level your chart suggests.
It scales until the unofficial operator burns out, leaves, gets reassigned, or stops being unusually generous.
Then the “sudden” conversion problem arrives.
Usually it was there the whole time.
You were just measuring the product and not the human scaffold around it.
Other fields are much more honest about assisted success
One thing I respect about public service design is that it tends to be more explicit about the difference between a digital flow and a successful service outcome.
GOV.UK’s guidance on assisted digital support is blunt about the fact that some users will need help using online parts of a service and that teams need to design for that help deliberately.
That is a healthier posture than pretending help does not exist because the ideal funnel says it should not.
Their guidance on measuring user satisfaction is useful for the same reason. It points out that the end of a transaction is not always the end of the user’s experience.
That idea matters a lot in growth work.
A user completing the setup is not the same thing as a user becoming independently successful.
A customer sending the first campaign is not the same thing as a team being able to repeat the workflow without a guide.
A workspace getting activated is not the same thing as the account no longer needing a patient adult in the room.
I think product teams blur those lines constantly.
We count the event that is easiest to see.
We ignore the surrounding labor that made the event possible.
Then we act surprised when downstream retention looks weaker than activation predicted.
A lot of product wins are really human work transfer
This is not a new problem.
Youngme Moon and Frances Frei made a similar point years ago in Exploding the Self-Service Myth. The technology may lower transaction cost for the company while still creating a worse or more fragile experience for the customer.
I think modern growth teams recreate that trap in more polished forms.
We celebrate self-serve onboarding.
We celebrate AI setup assistance.
We celebrate lifecycle automation.
We celebrate collaborative activation.
Then the actual service quietly depends on shadow labor.
Maybe the help is internal.
Maybe it comes from the customer.
Maybe it sits with a teammate who has become the local translator, cleaner, or confidence donor for everyone else.
In a consumer product that operator might be a parent, teacher, coach, or organizer.
In B2B it might be the one operations lead who keeps rebuilding context for the rest of the team.
In both cases the same question matters.
If that person disappeared tomorrow, would the product still deserve the metric you are celebrating today.
That is not a cynical question.
It is a product judgment question.
Hidden operators change the meaning of the funnel
This is where growth metrics get dangerous.
If a customer success manager has to intervene for every serious account to reach the first win, then your activation rate is partly a staffing ratio.
If support tickets, office hours, onboarding calls, or internal champions are doing the real work of interpretation, then your retention may be measuring relationship glue as much as product fit.
If one determined user keeps repairing imports, reconciling permissions, and reminding everyone what the workflow means, then your expansion story may be leaning on human duty more than product clarity.
That is why I have become skeptical of teams that ask whether support should count against self-serve conversion.
Of course it should count.
The more useful question is whether the product is becoming more independently usable over time or whether the same category of rescue keeps reappearing.
If the rescue is shrinking, good.
If the rescue is stable, you probably have a product problem.
If the rescue is growing with user count, you definitely have a scaling problem.
The chart may still look green for a while.
That does not make it self-serve.
It makes it subsidized.
I like a small artifact called an operator dependency map
When a team says the funnel is healthy but the lived experience smells more labor-intensive than the dashboard admits, I like making a small working note.
Not a six-lane service blueprint.
Not a giant handoff diagram nobody will revisit.
Just a practical map for one question.
Where is human labor quietly compensating for product weakness in the path to activation or repeat usage.
Operator dependency map
- Core user outcome we say is self-serve
- Human role currently helping it happen
- What that person actually does
- Trigger for intervention
- Whether the user knows they are being rescued
- Whether the work is teaching, reassurance, cleanup, translation, or exception handling
- Frequency
- Segment most dependent on the help
- What product weakness the help is compensating for
- Whether the work is shrinking, stable, or growing over time
- What would break if the help disappeared for a month
- Owner
I like this artifact because it changes the conversation fast.
The team stops arguing in abstractions about whether a journey is “mostly self-serve.”
Now you can see the specific labor.
Support is rewriting import files.
Success is joining calls to explain the setup decision.
Sales engineers are quietly serving as product documentation.
One team admin is re-teaching the same workflow after every teammate invite.
That is real information.
It tells you what the product still cannot do on its own.
Some support is healthy and some support is camouflage
I do not mean every human touch is a failure.
Some help is part of the value.
Advice can be valuable.
Coaching can be valuable.
High-trust onboarding can be valuable.
White-glove implementation can be a deliberate strategy.
The problem is not help.
The problem is mislabeled help.
If the business is intentionally service-heavy, say that.
If the product is early and support is helping you learn, say that too.
What I do not like is when a team calls something self-serve while quietly depending on recurring human repair to make the experience survivable.
That creates bad forecasting, bad prioritization, and bad product judgment.
It also puts the burden on the least visible people in the system.
The dashboard celebrates product efficiency.
Someone else inherits the maintenance job.
What I would do with this in practice
I would start with one journey you currently describe as self-serve.
Usually that is new account activation, first project setup, first campaign launch, or first collaborative workflow.
Then I would spend a week pulling evidence from support threads, success notes, onboarding calls, session replays, and internal anecdotes.
Not because anecdotes beat metrics.
Because anecdotes often reveal the hidden labor your metrics forgot to label.
Then I would ask three plain questions.
Where does a human repeatedly step in.
What category of weakness are they compensating for.
Is that dependence shrinking as the product matures or merely becoming more normalized.
If the answers are uncomfortable, good.
That usually means you have found a real leverage point.
The goal is not to remove every human from the system.
The goal is to stop crediting the product for work the product is not yet doing.
That is how you get a cleaner read on activation.
That is how you avoid mistaking patience for retention.
That is how you build a self-serve motion that deserves the name.
