Record Every Time a Person Steps In to Make the Path Work

Rescue Ledger template

Companion to The Product Manager’s New Job Is Acceptance · Updated 2026-09-30

The chapter “Unplanned Help Weakens the Evidence” explains why. Keep the ledger during trials, demos, onboarding, implementation, UAT, and early use. One line per intervention is enough.

DateAccount or participantPath stageWho stepped inCategoryPlanned or unplannedWhat they didMinutesSeverityBuild in, price as service, or leave?Reveals a wrong ICP assumption?Reveals a false promise?

Categories

Use these eight and no others, so counts compare across tests.

CategoryMeaning
NoneThe participant proceeded without help.
Clarification requestedThe participant asked what a term or screen meant and got an answer.
Navigation hintSomeone pointed to where a control is.
Domain explanationSomeone explained a concept the product assumes the user knows.
Technical rescueSomeone fixed an error, environment, or compatibility problem.
Setup rescueSomeone configured, imported, or connected something for the customer.
Workflow rescueSomeone showed how to fit the product into the real workday.
Operator overrideSomeone did the task for the participant, or changed the system to make it pass.

Planned or unplanned. A planned rescue is designed, priced, and disclosed, such as a paid onboarding call. An unplanned rescue is help nobody designed or priced. Planned help is service. Unplanned help is what to look for.

Reading the ledger

Read counts as clues and not as verdicts.

  1. Count interventions by stage. A stage with a rescue in most accounts often marks a product gap, though it can also be an implementation the customer expects.
  2. Count by segment. A rescue confined to one segment is often an ICP problem.
  3. Count by claim. A rescue that every demo needs points to a promise problem.
  4. Separate intended service from hidden rescue. If the product is sold with implementation, label that work as service, and price it.

Rules

  1. The ledger measures the path and not the person. Report it by stage and never by rescuer.
  2. Customer success owns the entries and sees the findings first.
  3. Log one cohort or a window of about six weeks, then stop.
  4. Have a second reader check a sample, since the rescuers write their own entries.

Who should write entries

Everyone who can step in: salespeople, sales engineers, implementation staff, customer success, support, product managers, engineers, administrators, executive sponsors, and consultants. Add a required field to the CRM, the support system, and the onboarding checklist so the entry is made when the help is given.