Measure Whether Customers Recover When Your Product Fails

Most growth funnels assume the product works. A customer arrives, starts a task, reaches a result and hopefully returns. When something goes wrong, the customer disappears from the analysis into a generic failed, abandoned or inactive state.

That is becoming a serious blind spot.

Products are gaining more permissions, making more decisions and touching more sensitive data. At the same time, platforms are tightening access controls, security problems can stop planned development, and physical products face recalls or intervention when software-led behaviour creates real-world problems. Product publications are rightly giving more attention to failure planning and better error states. But most growth teams still measure only the successful route.

I think we need to measure recovery as its own customer journey.

Consider an AI feature that needs access to files on a customer’s device. The customer denies that access, the operating system blocks it, or company policy prevents it. The normal funnel records that the feature was not activated. That tells us almost nothing. Did the customer understand what happened? Were they shown a safe alternative? Could they complete part of the task manually? Did they return after asking an administrator for access? Or did the product leave them at a dead end?

Those are product and growth questions, not just technical support questions.

The same applies to a failed payment, an interrupted data import, a rejected identity check or an integration that loses its connection. Teams often invest heavily in improving the start of these journeys. They test the call to action, reduce unnecessary fields and tune the onboarding sequence. Once the task fails, however, the experience is delegated to a generic message and a link to contact support.

I would add a recovery funnel next to the normal funnel. It should show how many affected customers see the problem, understand it, take a corrective action, complete the original task and continue using the product afterwards. The exact stages will differ by product, but the principle is simple: a failure is not the end of measurement.

This also changes how teams prioritise error handling. An error affecting relatively few customers may still deserve attention if almost nobody recovers from it and the blocked task is valuable. A common error may be less urgent if the product explains it clearly and customers recover within seconds. Counting incidents alone cannot show that difference.

There also needs to be an owner. Engineering can fix the underlying defect, but that does not automatically produce a good recovery experience. Product needs to decide what alternative routes are acceptable. Design needs to make the next action clear. Growth needs to measure whether customers resume the journey. Support needs a way to identify where customers remain stuck. Legal or security may need to define what the product must not offer as a workaround.

This is especially important for AI products. Their failures are not always clean technical errors. An action may be blocked because authority is missing, an output may need review, or the system may be uncertain about what to do next. Simply asking the customer to try again is not a recovery design. Sometimes the correct route is to narrow the task, request confirmation, hand over to a person or preserve the work so it can be resumed later.

A product that never fails is not a realistic goal. A product that helps customers recover is. If we only optimise the successful path, we will keep improving the experience for customers who need the least help while losing the ones who have just discovered how the product behaves under pressure.