Customer discovery

How to interview customers who stopped using your product

Use a churn timeline to separate adoption problems, changes in customer needs, cancellation triggers, and the work people do after leaving.

Instant Expert EditorialPublished 5 min read

A churn interview should explain what changed between choosing a product and no longer using it. Cancellation is one event in that sequence. The experience that made the product less useful may have happened earlier, or the customer’s circumstances may have changed entirely.

Treat billing status, product activity, and the customer’s own account as different kinds of evidence. Someone can stop doing meaningful work in a product while a subscription remains active. Someone else can cancel a subscription while continuing a task through another arrangement.

The worksheet below organizes the conversation around a lifecycle. It uses a fictional project-handoff tool to illustrate the method; the example is not a report about a real customer or product.

Define the group before recruiting

“Churned customers” can mean former paying accounts, people who canceled during a trial, organizations with no recent activity, or individual users who left an otherwise active account. Choose the group that matches your decision and describe it precisely.

If the question concerns recurring customer value, a person who never finished setup represents a different experience from someone who used the product for a year. Both may matter, but combining them too early can hide the problem you need to investigate.

Record the relevant period, account context, and participant’s role. Check that contacting them is consistent with their communication preferences. A research request does not erase an earlier request to stop contact.

Reconstruct the original purpose

Ask what was happening when the person first considered the product. What job did they hope to accomplish? What did they use before? What changed when they began?

GOV.UK’s user-needs guidance focuses on what people are trying to achieve and how they currently do it. Apply that perspective to the customer’s original task before concentrating on your feature set. Read the user-needs guidance.

Avoid reading the original sales promise back as if it were the participant’s own goal. If their account differs from the onboarding notes, preserve both and investigate the difference.

Use a lifecycle ledger

Build the following ledger during or immediately after the conversation. Exact dates are helpful when available, but an approximate sequence is better than a fabricated date.

StageEvidence to recordQuestion to explore
Initial taskWork the person wanted to accomplish“What did you need to get done?”
First attemptSetup and earliest real use“Walk me through the first time you tried.”
Useful periodAn instance when the product served the task“When did it work well for you?”
ChangeA new constraint, problem, or different priority“What started to change?”
Last meaningful useFinal task completed or attempted“What were you doing that last time?”
CancellationAdministrative action and decision owner“How did ending the subscription happen?”
Present approachWhat now happens to the original work“How is that task handled today?”

This is not a requirement that every customer had a useful period. If they never completed the task, mark that explicitly and examine the first attempt in more detail.

Separate the trigger from the underlying difficulty

A cancellation email might mention price. The person may describe a different sequence: a team reorganization reduced usage, the owner stopped checking the product, and a renewal notice prompted the final decision.

That is one possible sequence, not a general explanation of churn. Ask what actually happened in the participant’s case and who experienced each step.

When the person says the product was too expensive, ask what value they were receiving at that point and what alternatives they considered. Do not turn the interview into a negotiation about a lower price. You are trying to understand the decision, not train the participant to give an answer that produces a discount.

Examine an ordinary successful use too

A memorable failure may dominate the conversation. If the product had once been useful, ask about a specific successful task. Compare its circumstances with the last unsuccessful or abandoned task.

Did the same people participate? Was the work similar? Had the team’s tools, volume, responsibilities, or requirements changed? These comparisons can reveal where the product’s usefulness had a boundary.

A discussion guide can hold those questions while allowing follow-up on the participant’s experience. That is consistent with GOV.UK’s guidance for in-depth interviews. Read the interview guidance.

Work through a fictional account

Imagine an agency that adopted a project-handoff tool when several freelancers worked on each client project. In the fictional account, the agency later brought the work in-house. Handoffs continued, but a daily internal meeting covered them. The subscription was canceled during an expense review.

“Cost” describes the final review, while the changed team structure helps explain why the product had become less useful. A new handoff feature might not address that situation.

A useful next question would be whether the product still fits agencies with distributed contributors, or whether another job remains unresolved after work moves in-house. The interview alone cannot answer either question across the market.

Compare the account with available records carefully

If you have permission and appropriate access, compare the timeline with relevant product events, support requests, and billing dates. Use the records to clarify chronology, not to cross-examine the participant.

An event log can show that an action occurred. It may not show why the person performed it or whether the outcome was useful. An interview can supply context but may contain incomplete recall. Keep both limitations visible.

When records disagree, note the discrepancy and ask a neutral clarification if further contact was agreed. Do not silently overwrite the customer’s explanation with an inference from activity data.

Choose the right follow-up action

Use the ledger to locate the uncertainty. A failed first attempt may call for observing setup. A formerly useful workflow may require studying changed responsibilities. A migration to another approach may require understanding that new workflow. A cancellation caused by a closed business may not point to a product defect at all.

Write the action alongside the evidence and the strongest alternative explanation. Keep requests for renewed business separate from research follow-up.

A good churn interview leaves you with a more precise account of where usefulness ended, which part remains unexplained, and what evidence would justify a change. That is more actionable than a single cancellation reason in a spreadsheet.

The working model

Follow usefulness through the customer lifecycle

  1. 1

    Original task

    Why did the person begin?

  2. 2

    Useful period

    When did the product serve that task?

  3. 3

    Change

    What conditions or experiences shifted?

  4. 4

    Exit

    Separate last meaningful use from cancellation.

  5. 5

    Present approach

    What happens to the work now?

Last meaningful use and cancellation can happen at different times. Preserve both events before choosing an intervention.