I think one of the fastest ways to fool yourself in growth product is to study the visible path and ignore the invisible saves.
The dashboard says activation improved.
The signup rate climbed.
The trial looks healthier.
The onboarding step stopped leaking.
Maybe that is all true.
It is also possible that a support rep jumped in at the right moment, a sales engineer cleaned up the setup, an ops person fixed the data behind the scenes, or a PM quietly explained the product in a way the product still cannot explain itself.
The user progressed.
The funnel looked cleaner.
The product may not have gotten meaningfully better.
It may have been rescued.
I do not mean that as a criticism of the team doing the rescue work. Some of the best product companies I know stay healthy because people care enough to catch users before they fall all the way through the floor.
The problem starts when those rescues stay invisible.
Then the company calls the journey self-serve when it is actually part self-serve, part backstage heroics.
A smooth front stage can hide a crowded backstage
This is one of the reasons I like borrowing from theater.
If the scene change looks effortless, it does not mean the production is simple. It often means someone behind the curtain moved fast, anticipated the miss, and saved the scene before the audience noticed.
Products work like that more often than teams admit.
A new user imports messy data and someone on the team cleans the file.
A workspace invites teammates and customer success explains the setup in a one-off loom.
A lifecycle email revives an account because support already clarified a billing misunderstanding.
A sales-assisted account reaches activation because an internal expert effectively operated the first week for them.
From the outside, the product journey looks healthy.
From the inside, it may be held together by a relay of manual interventions.
That is why service blueprinting is so useful beyond service design circles. The Department for Education write-up on building a service blueprint is a good reminder that the real service includes the supporting processes and operators behind the visible journey. Growth teams need that same discipline. If the experience depends on hidden labor, the labor is part of the product truth.
Rescue moves are often evidence, not noise
I think teams sometimes treat manual assists as contamination.
Something to mentally subtract.
Something that makes the analysis messier.
Sometimes that is exactly why they matter.
A rescue move is often the clearest evidence of where the product still cannot carry its own weight.
If users only complete setup after a support nudge, that nudge is pointing at missing product clarity.
If dormant accounts only reactivate when a human rewrites the recommended next step, that rewrite is pointing at weak lifecycle judgment.
If team invites only convert after sales explains who should do what first, the explanation is pointing at a collaboration model the product has not made legible yet.
The workaround article from Harvard Business Review, What Customer Workarounds Can Reveal About Your Business Model, travels well here. Their point is that workarounds are not just friction artifacts. They reveal a mismatch between how the product is packaged and how people actually need to make progress. I think rescue moves do the same thing inside the funnel. They expose the gap between what the product claims to support and what the organization is still compensating for manually.
The metric can rise while the burden simply moves sideways
This is where growth work gets more subtle.
A metric improvement can be real for the user and still unhealthy for the system.
The user got help.
The outcome improved.
But the cost moved sideways into another team, another tool, or another untracked habit.
I have seen this happen with onboarding, lifecycle, and monetization work.
A form gets shorter, then support gets longer tickets.
A trial flow looks simpler, then account teams spend more time rebuilding context later.
A reactivation campaign lifts return sessions, then the retained users are disproportionately the ones who needed manual recovery.
A new acquisition path grows volume, then internal teams quietly filter low quality signups by hand.
That is still a product outcome.
It is just not a clean one.
The Microsoft Experimentation Platform piece on Patterns of Trustworthy Experimentation During-Experiment Stage makes the case for measuring holistically, not just locally. I like that framing because growth teams often over-read the local lift and under-read the surrounding cost. If the treatment raises conversion while increasing abandonment, support burden, or downstream confusion, the story is not finished. A rescue-heavy funnel creates the same measurement problem. The lift is visible. The compensation cost often is not.
Other fields count assists more honestly
Restaurants know the dining room depends on the kitchen, the expo line, and someone catching the wrong plate before it reaches the table.
Hospitals know a calm handoff may still depend on extra triage, extra chart cleanup, or a nurse noticing what the system did not surface clearly enough.
Airports know an on-time departure can hide a lot of last-minute coordination that nobody wants to normalize forever.
Those environments are not embarrassed by the fact that backstage work exists.
They are cautious about mistaking repeated rescue work for a stable operating model.
I think product teams should borrow that caution.
Not every assist is a failure.
Repeated assists in the same place are a design signal.
The artifact I like is a rescue move ledger
When a growth surface looks better on paper but still feels suspiciously fragile in the real world, I like creating a rescue move ledger.
Not a giant postmortem.
Not a blame document.
Just a small working log that helps the team answer one uncomfortable question.
What had to happen off screen for this user to keep moving.
Rescue move ledger
- User segment or account type
- Funnel moment or workflow step
- What the user was trying to do
- What went wrong, stalled, or became ambiguous
- Who intervened
- What they actually did to rescue the moment
- Whether the rescue was visible to the user or purely backstage
- How often this pattern is happening
- What metric currently looks healthy in spite of it
- What product change would make the rescue less necessary
- Owner
That is enough.
The point is not to catalog every kindness in the company.
The point is to separate product strength from organizational compensation.
What changes once the rescue work is visible
A few useful things usually happen.
You stop calling a journey self-serve just because the user never booked a formal support call.
You get more honest about the cost of a metric improvement.
You notice where lifecycle, support, sales, and product are repeatedly covering for the same missing explanation or fragile step.
You get sharper about which experiments created durable product progress and which ones merely improved the choreography around a still-weak experience.
You also get better raw material for product judgment.
Some rescue moves should become product features.
Some should become clearer defaults.
Some should become better instrumentation.
Some should stay human because the edge case is rare and the user risk is high.
That is the kind of tradeoff I want a growth PM to make consciously.
Not every manual step is debt.
But every repeated manual step deserves inspection.
Before you celebrate the cleaner funnel
I think a lot of good growth teams become great when they stop asking only whether the user moved forward and start asking how much backstage help the movement required.
That question sounds operational.
It is also strategic.
If a journey only works when the company keeps catching it, the company has not solved the journey yet.
It has staffed around it.
Sometimes that is the right short-term decision.
It is a bad thing to forget.
Before the next activation win turns into a slide, count the rescue moves.
They may be the clearest map you have to the product work that still matters.
