Ask about a specific event: what the person needed to do, what actually happened, what they used, and what made the outcome acceptable or difficult. Follow the answer before introducing your product. This guide gives founders with a demo or early SaaS a short interview script, an annotated fictional conversation, and a worksheet for deciding what to investigate when two people tell different stories about the same work.
Set one learning decision before the call
Write the decision in a sentence: Should our next prototype address waiting for a reviewer, or collecting the information that reviewer needs? Name the role and workflow you want to understand. The interview should help distinguish those explanations; it does not need to cover your entire roadmap.
Tell the participant who you are, what you are researching, and how you will use the notes. Ask permission before recording, retaining artifacts, or sharing excerpts. They can decline a question or show a redacted example. If you demonstrate your product later, mark where the demo began so reactions to your solution stay separate from the earlier account of their work.
Eight customer discovery questions to adapt
Replace the brackets with the participant's task. Use these as prompts, not a questionnaire to finish at all costs. A concrete answer deserves a follow-up; an unanswered question belongs in your notes as unknown.
Ask: Which recent [request or task] were you personally involved in, and what was your responsibility? Purpose: locate firsthand experience. Follow up: Where did your involvement begin and end? If they only heard about it, label the account secondhand and ask who performed the relevant step.
Ask: Starting when that request arrived, what did you do before it was finished? Purpose: find the actual sequence. Follow up: What were you waiting for at that point? Let them describe a smooth process too; do not insert a delay they have not reported.
Ask: What did you use to keep this particular request moving? Purpose: understand the current alternative. Follow up: Which part would you keep if the rest changed? If a shared inbox or ordinary conversation worked well, retain that as evidence against replacing it.
Ask: How did the outcome compare with what needed to happen? Purpose: separate inconvenience from a consequential failure. Follow up: What changed for someone else because of it? Keep an estimate labeled as an estimate; if no consequence is known, do not calculate a cost from a vague complaint.
Ask: Who handled the next step, and what did they need from you? Purpose: expose a dependency. Follow up: How did you know they had received everything they needed? If the participant is unsure, record the gap and seek a separate conversation with permission.
Ask: Can you recall another instance that went differently? Purpose: check whether the first event describes a recurring condition or an exception. Follow up: What was different before work began? A successful instance can be useful even when the founder expected to hear more complaints.
Ask: The last time your team changed this process, how was that decision made? Purpose: separate the user, process owner and approver. Follow up: What stopped or limited the change? If there has been no change, keep purchasing authority and budget unknown rather than inferring them from a job title.
Ask: I have written [brief account of the event]. What have I misunderstood or left out? Purpose: let the participant correct your notes. Then request one specific follow-up if needed. Agreement with your summary confirms their account, not demand for your product or permission to publish their words.
Repair a leading question before asking it
A founder can accidentally put the proposed solution inside the question. Keep the interpretation in your private hypothesis and ask about something the participant can describe. These are original examples to adapt, not a validated survey instrument. On small screens, scroll the table sideways to compare both versions.
| Dimension | Leading version | Neutral replacement |
|---|---|---|
| Assumed delay | Why is your reviewer always late? | When did this request reach the reviewer, and what happened next? |
| Suggested solution | Would automatic reminders fix that? | After the last reminder, what changed, if anything? |
| Assumed budget | Would you pay $50 to solve this? | What resources, if any, did your team commit to the last process change? |
Annotated example: two accounts of one delayed request
Everything in this example is fictional: the company, people, dialogue, request and document. It is a teaching case, not customer evidence or a Soloop result. A founder has built a demo that reminds internal reviewers to finish customer security questionnaires. The question is whether reminders address the delay or whether requests reach reviewers without necessary information.
Use organization ID A and event ID Q17 for both conversations. Interview I1 is with a sales engineer; I2 is with the security reviewer. The two people have different perspectives on one event at one company. They are not two independent companies demonstrating market demand.
Founder: After your last reminder on Q17, what changed? Sales engineer: “Nothing that day. I sent the questionnaire on Monday, chased twice, and got it back Friday.” Annotation: this is a reported sequence. It does not establish what caused the wait or whether a reminder was missed.
Founder: What did the reviewer need when you first sent it? Sales engineer: “I thought the form was enough. I do not know what else was missing.” Annotation: input completeness is unknown in I1. The useful follow-up is about the request's contents, rather than whether the person likes automatic reminders.
Founder: What was available when Q17 reached you? Reviewer: “The data owner was not named. I asked for that on Tuesday and got the name Thursday.” Annotation: I2 suggests an input dependency. It adds an explanation to investigate; it does not prove that reminder timing was irrelevant.
With permission in this fictional scenario, the founder views a redacted request log. It contains a Tuesday request for an owner and a Thursday reply naming one. Record those entries as observed in R1. The log supports that exchange; it does not show all work performed, why the owner was missing, or when the reviewer could have completed the task.
Founder: Can you recall a comparable request that arrived with an owner already named? Reviewer: “Q18 did, and I returned it the next day.” Annotation: Q18 is still only reported. Its complexity, queue position and urgency have not been compared with Q17; the different turnaround does not isolate a cause.
Keep the reminder demo unchanged while investigating request completeness. Ask to compare Q17 and Q18 on inputs, complexity, urgency and reviewer workload. If complete requests repeatedly sit unseen, revisit reminders; if missing inputs explain the wait, test clearer intake. Both branches still require evidence.
When interview answers conflict, choose a follow-up
- Check the unit first. Are people describing the same organization, event and period? Two statements about different requests may both be accurate. Give each source its own ID, then link it to the event it describes.
- Check the meaning. Ask what each person means by sent, ready or complete. A sender may mean that a form was forwarded; a reviewer may mean that every prerequisite was available. Preserve both definitions before treating them as a contradiction.
- Check the visibility. Separate what someone did, what they saw, what they were told, and what you inferred. An unmentioned delay is not a denial of a delay. A timestamp supports timing, not necessarily motive or causation.
- Write competing explanations and the smallest question or artifact that could distinguish them. If the missing evidence is unavailable, retain the uncertainty and choose a smaller, reversible next step. Do not average incompatible accounts into a confidence score.
Copy the interview decision worksheet
Copy this table into your own notes; no account is required. Start a record for each event, attach individual source notes, and update it after a follow-up. The filled column continues the fictional Q17 case. Keep exact quotations separate from paraphrases, and retain source references instead of copying private transcripts into every summary.
| Dimension | Your record | Fictional Q17 record |
|---|---|---|
| Decision | [Choice this interview can inform] | Investigate reminders or request completeness next? |
| Group | [Organization ID / event ID / date] | A / Q17 / illustrative week; actual dates unspecified |
| Sources | [Person, role, note ID, access permission] | I1 sales engineer; I2 reviewer; R1 redacted log |
| Accounts | [Exact quote or labeled paraphrase + source] | I1 reports two reminders; I2 reports missing owner; both concern Q17 |
| Observed | [What was actually inspected + reference] | R1: owner requested Tuesday, supplied Thursday |
| Explanations | [Explanation A / explanation B / other] | Request unseen / missing inputs / other workload |
| Challenge | [Evidence against the favored explanation] | I2 and R1 challenge the assumption that another reminder was sufficient |
| Unknown | [Missing fact; do not fill with a guess] | Whether a complete Q17 would have been finished sooner |
| Next check | [Question or artifact / owner / agreed timing] | Founder requests permission to compare Q17 and Q18; timing unagreed |
| Decision now | [Action / reversal condition / next review] | Keep demo unchanged; revisit reminders if comparable complete requests remain unseen |
How many interviews are enough?
There is no count in this worksheet that certifies demand. Continue when an unanswered question could change the decision and another relevant conversation can address it. Seek an additional organization when you need to learn whether a condition extends beyond the first company. Record how participants were found and which roles or situations remain absent.
Repeated wording is a reason to investigate a pattern, not a population estimate. Keep the interview result, a later product trial, and an actual purchase as separate outcomes. If the next decision concerns willingness to use or buy your specific product, design an appropriate next test rather than declaring that the interview already answered it.
Bring a bounded question to Soloop
You can run the interview and use the worksheet yourself. If you bring notes to Soloop, share only material you have permission to share and identify the exact records you want considered. Check the document's extraction state and ask which sources were actually read before relying on an answer.
A starter brief to adapt: My product is [URL or demo] for [role and workflow]. I am deciding [A or B]. These permissioned notes [source IDs] disagree about [event]. Help me examine the competing explanations and choose one follow-up question. Keep quotes, reports, observations and inferences separate; leave missing information unknown.
The Soloop manual describes a main conversation and separately approved research tasks. If further research is proposed, review its scope and credit cost on the action card. Conduct the interviews yourself; this guide does not establish an automatic interview, recording or transcript-analysis service. The Explore Soloop link below opens the public entry and does not transfer the worksheet.
Method references
These sources inform the interview and note-taking approach. The questions, Q17 case and worksheet above are original editorial examples; they have not been tested in a customer study or reviewed by an independent interviewer.
Dominika Blackappl describes choosing a learning goal, finding relevant people and organizing observation around listening. Use that guidance to separate learning about a workflow from presenting a solution.
Read Practical Design: User ObservationTeresa Torres describes keeping a compact record for each interview, including context and a map of the participant's experience. Keep individual accounts available when you compare what several people said.
Read The Interview Snapshot