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.
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.
| Stage | Evidence to record | Question to explore |
|---|---|---|
| Initial task | Work the person wanted to accomplish | “What did you need to get done?” |
| First attempt | Setup and earliest real use | “Walk me through the first time you tried.” |
| Useful period | An instance when the product served the task | “When did it work well for you?” |
| Change | A new constraint, problem, or different priority | “What started to change?” |
| Last meaningful use | Final task completed or attempted | “What were you doing that last time?” |
| Cancellation | Administrative action and decision owner | “How did ending the subscription happen?” |
| Present approach | What 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
Original task
Why did the person begin?
- 2
Useful period
When did the product serve that task?
- 3
Change
What conditions or experiences shifted?
- 4
Exit
Separate last meaningful use from cancellation.
- 5
Present approach
What happens to the work now?