The cancellation notice arrives on Monday. By Tuesday, the founder has a list of “churn questions,” a discount ready, and a theory about onboarding. That is three ways to contaminate the interview before it begins.
Research is not a save attempt
Decide the purpose before contacting anyone. If the purpose is to understand a cancellation incident, do not attach a retention offer, product defence, or feature demo. Participation must not affect the completed cancellation. A person should be able to decline without having to explain why.
Illustrative invitation: “I’m reviewing the sequence around your cancellation so we can understand where the workflow stopped being useful. This is research, not a sales call, and the cancellation is complete. If you are willing, we can discuss the last specific time you used the product. A written reply is also fine. There is no obligation to participate.”
That wording is a draft to adapt, not proof of legal compliance. Check communication preferences, your applicable lawful basis, privacy information, and recording rules for the jurisdiction and systems involved. Do not promise anonymity, deletion, confidentiality, compensation, or a retention period unless you can operate those promises.
Set the participation and data boundary first
GOV.UK user-research guidance says an informed-participation record should cover purpose, data collected, what participation involves, use and sharing, voluntariness, withdrawal, and recording. Its notes-and-recording guidance says to ask permission before taking notes or recording and to keep observations separate from interpretation. These are UK government research practices, not a universal legal basis for private SaaS research.
Before the conversation, determine and document the lawful basis that applies. If relying on consent, ICO guidance says it must be freely given, specific, informed, unambiguous, and withdrawable. The relevant ICO consent material was marked under review when observed on 2026-07-28, so revalidate it and obtain privacy or compliance review before relying on it.
Minimise what you collect. Do not ask for credentials, unrelated personal data, or copies of private business records merely because they might add colour. Ask separately before recording. Limit access to the people who need the research material, and define storage, retention, withdrawal, and publication handling before recruitment.
Follow the last concrete occurrence
Open questions are useful when they return the person to an incident. “Why did you churn?” invites a polished summary. “What happened the next time the report was due?” gives the sequence somewhere to start.
| Timeline state | Neutral prompt | Evidence to separate |
|---|---|---|
| Last successful job | “Walk me through the last time the product helped with the job.” | Recollection, product event, output, and surrounding workflow. |
| Next trigger | “What happened the next time that work came up?” | What changed in task, role, data, timing, or ownership. |
| Break | “What did you see, and what did you try next?” | Interface state, action, support contact, workaround, and missing artifact. |
| Replacement | “How is that job handled now?” | Another product, spreadsheet, service, reduced process, or no replacement. |
| Cancellation moment | “What made the cancellation happen then?” | Renewal, incident, role change, budget review, or another timing event. |
| Counterfactual limit | “What would have needed to be different before that point for staying to remain an option?” | A condition grounded in the sequence, plus any uncertainty. |
Use prompts such as “What happened next?” and “What did you see?” Do not explain how the feature was supposed to work. A contradiction is useful data, not an objection to overcome.
A fictional sequence that refuses a neat cause
Fictional dialogue, not a customer transcript or observed churn incident. Assume a reporting product and an internal role change.
Interviewer: What happened the next time the report was due?
Participant: The person who configured it had left. I could open the dashboard, but I did not know which data source fed the report.
Interviewer: What did you do next?
Participant: I exported the source data and rebuilt the report in a spreadsheet. I cancelled when the renewal notice arrived.
Interviewer: What would have needed to be different before then?
Participant: A handover showing the data connection and report owner would have helped. I do not know whether we would have stayed.
The sequence supports several hypotheses: unclear ownership, missing handover information, trust in the report, and renewal timing. It does not prove that any one of them caused churn, and it says nothing about prevalence.
Keep four columns that are allowed to disagree
| Column | Example from the fictional sequence |
|---|---|
| Verbatim | “I did not know which data source fed the report.” |
| Observable or checkable event | Role change, spreadsheet replacement, and cancellation at renewal would each require authorised corroboration. |
| Interpretation | Ownership continuity may have failed; report trust may have weakened. |
| Contradiction or gap | No evidence shows whether documentation existed, whether support was contacted, or whether a handover would have changed the decision. |
Only group cases after each incident has its own record. Theme labels should name a workflow break, not a mood. Link every code back to eligible incidents, include contradictions, and keep unknowns visible. One vivid interview is not a frequency estimate.
Let the record stay unfinished
An interview can suggest a product check, an onboarding review, a support investigation, or another research question. Before changing the product, compare the account’s timeline with eligible product events, tickets, billing records, and other authorised cases. Preserve the distinction between reported sequence and inferred cause.
Ignore the feature wishlist, the rescue discount, and the urge to calculate a churn category during the call. Also ignore broad labels such as “too expensive” until the timeline shows what changed, what alternative appeared, and when the decision became active.
The hard part is not asking a clever question. It is leaving a good story unfinished when the evidence is unfinished. “We do not know whether the account would have stayed” can be the most useful line in the record.
Run the interview only after the participation, recording, data and withdrawal boundaries are documented. End with one incident record and its gaps, not a saved account, a universal cause or a churn claim.