What should a customer interview help you decide?
Start with a decision you need to make about the product or its explanation. You might be unsure whether a particular profession encounters the problem, which part of the current process is difficult, or whether the input your app requires is normally available. Write one main question before arranging the conversation. A broad request for feedback can produce many opinions without resolving the uncertainty.
This guide is for builders who have a working app and are seeking early users. Choose interview participants using the first-audience worksheet. A potential user needs relevant experience with the task; they do not need to be a fan of your app. Someone who currently succeeds with a simple workaround may teach you why changing tools would be unattractive.
How can you invite someone without disguising a sales pitch?
Explain who you are, the specific process you want to understand, and the time you are asking for. Mention that you are building in the area, while making clear what the conversation involves. Let the person decline. Use an appropriate introduction or recruitment setting, and agree the time rather than sending a meeting booking as though it were already accepted.
An illustrative invitation could read: I am building a small tool for preparing project briefs and want to understand how independent designers handle the work after a client call. Would you be open to a short conversation about a recent project? I am interested in your current process; there is no requirement to try the app. Adjust the invitation to your actual research and availability.
If you later want to demonstrate the product, ask separately. A person may agree to discuss a workflow and decline a trial. Keeping those agreements distinct makes the interaction clearer and prevents your research log from counting every interview as a product lead.
Which questions reveal useful experience?
Y Combinator’s user-interview guidance emphasizes learning from specific past experiences rather than pitching the idea or asking hypothetical purchase questions. Apply that principle to your chosen task. The prompts below are a discussion aid: follow the person’s explanation and ask for clarification when a step remains unclear.
Avoid supplying the answer inside the question. If you ask whether a process wastes time, the person may agree without describing a significant difficulty. Ask them to reconstruct what happened, then explore the detail that matters to your decision. A completed task with an annoying step is different from a task they repeatedly abandon.
- Which recent project involved this task, and how did it begin?
- Could you walk me through the steps you took from there?
- Where did you pause, repeat work, or ask someone for help?
- What did you use to get it finished?
- Was there a consequence when that part went wrong or took longer?
- What have you already changed about the process, and what happened?
Work through a fictional interview about a project-brief app
Imagine a fictional conversation with a freelance designer about the last brief they prepared. They describe copying notes into a client document, then waiting for answers about scope. It is tempting to conclude that automated drafting would solve the problem. The missing scope information could be more important than the writing step. You need a follow-up that distinguishes those possibilities.
The table shows invented notes and possible interpretations, not quotes from customers or findings about designers. Its purpose is to demonstrate how an appealing explanation can outrun the evidence. A useful next question identifies which part of the process needs investigation before you rewrite the product’s promise.
| Invented observation | Possible interpretation | Alternative explanation | Follow-up |
|---|---|---|---|
| The designer copied call notes into a template | Drafting is repetitive | The template already makes drafting easy | Which step took effort in that particular project? |
| The brief waited for a client response | The brief was difficult to write | A decision about scope was missing | What information were you waiting for? |
| The designer liked the demonstration | They want to adopt the tool | They were being encouraging | Would a separate trial fit a real upcoming task? |
What should you record during the conversation?
Use a participant code and record the relevant context: their role, the situation, the current approach, and what you heard or observed. Give your interpretation its own column. Add a competing explanation and the next question you would need to resolve it. This creates a useful record when several conversations produce different stories.
Ask permission before recording, and explain the intended use of the material. GOV.UK’s interview guidance recommends open, neutral questions and attention to real examples. Our log adds a separate interpretation column so a later reader can distinguish what was said from the maker’s conclusion. Store only the detail needed for that purpose, and get explicit permission before publishing a person’s words or identifying context.
When should you show the product?
If the person agrees, move to a clearly separate demonstration or usability exercise after learning about their current task. State what you want to observe and choose a small, relevant activity. For the fictional brief app, a synthetic set of notes could let them create, inspect, and edit a sample brief. A narrated walkthrough and an independent attempt provide different observations.
Record where you helped. Completing the activity after the maker explains every button does not establish that a new user can complete it alone. Assistance may reveal useful product changes, but it should stay visible in the notes. The onboarding guide shows how to define a first useful result and check that it actually happened.
Can a few interviews validate your app?
A small set of interviews can expose assumptions, suggest a clearer audience, and help choose the next test. It cannot establish a universal conversion rate, representative market demand, or a reliable revenue forecast. Record how people were recruited and which types of prospective users are absent. Friends who build software and people responsible for the task may give different feedback for understandable reasons.
Look for evidence that changes a decision. If the input you require does not exist in the person’s process, investigate that mismatch. If they already have a satisfactory method, learn what would justify a switch. If they want a capability you cannot deliver, avoid counting a request for that future product as interest in the app available today.
How do interview notes improve marketing?
The words people use for the situation, the result, and their reservations can suggest a more understandable explanation. Check that those words accurately describe your product. A participant’s wish is not a feature you can claim to offer. Keep the distinction when drafting a headline, a directory description, or a demo script.
Use the one-sentence app description exercise to turn the evidence into a draft. Then ask a different relevant reader what they think the sentence promises. Their understanding can reveal a communication problem that enthusiastic feedback from the original participant did not expose.
What should you do after each interview?
Summarize what the conversation answered, what remains uncertain, and one next action. That action could be a different recruitment group, a product correction, another question, or an invitation to a separate trial. Avoid rewriting the whole roadmap after every opinion. Preserve contradictory observations so the next discussion can investigate them.
Download the log and add entries only for conversations that actually took place. Its starter rows are marked as not interviewed. Use the weekly marketing plan to schedule recruitment and review time, and the first-user guide when the next step is a real product trial.
A micro SaaS problem interview worksheet
Ask a prospective user to describe the last time the task happened: what started it, which steps followed, where the result went, and who was involved. Then ask what was difficult, how often it happens, what the current workaround costs in time or spending, and who would approve a different tool. Finish by asking whether a clearly described voluntary pilot would be useful. Avoid treating a hypothetical purchase answer as a payment.
For the fictional brief checker, ask how missing details were noticed and resolved before mentioning AI. Record the observed event, any quotation you have permission to retain, your interpretation, and an unanswered question separately. No customer interviews are presented as having occurred for this example.