Customer interview questions for micro-SaaS founders

1. Find people close to the problem

Define the role, business type, and recent experience that make someone relevant to your idea. A person who uses a workflow, a manager who approves a change, and a buyer who controls the budget can give different answers. Record which perspective you are hearing.

Recruit beyond friends and people who already like your product. Ask what would make someone ineligible before you count their interview. For a tool aimed at small agencies chasing overdue invoices, a consumer waiting for a refund is discussing a different problem.

Explain the purpose and expected length of the conversation. Ask permission before recording or retaining documents. Let people decline or redact sensitive details; you usually need the shape of the workflow rather than customer names, account numbers, or private files.

2. Ask about a recent occurrence

Use these prompts as a conversation guide, not a questionnaire you must complete in order. Start broadly, then follow concrete examples.

1. What is your role in this workflow, and who else is involved?
2. When did this problem last happen? Walk me through it.
3. What triggered it, and what did you do next?
4. How often has it happened recently?
5. What happened when it was not resolved?
6. What time, expense, delay, or other consequence can you describe?
7. What tools or manual steps do you use today?
8. What have you tried changing, and why did that work or fail?
9. What do you currently pay, including time spent maintaining the workaround?
10. Who decides whether a new tool can be bought and used?
11. What would make switching difficult or unacceptable?
12. Is there anything important about this problem that I have misunderstood?

3. Follow the evidence, including the awkward parts

When someone says a task is painful, ask for the latest example and how it compares with their other priorities. Do not turn a vague complaint into a quantified saving. If they cannot estimate a cost, record it as unknown.

If a buyer says their existing product is sufficient, keep that answer. Ask what makes it sufficient instead of arguing. Negative answers can identify an unsuitable segment or prevent you from building an unnecessary feature.

Check independence when synthesizing interviews. Several people from one company may share the same purchasing decision. That can give you a detailed view of one account without demonstrating demand across several accounts.

4. Discuss a specific offer separately

After learning about the problem, ask whether they want to hear about a proposed test. Describe the outcome and its limits plainly. A price question becomes more meaningful when the buyer understands the delivery, timing, responsibilities, and alternatives.

Track what happens next. A buyer who agrees to introduce the decision-maker or schedules a pilot has made a different commitment from someone who compliments the idea. Record cancellations, refusals, and objections as carefully as positive responses.

Do not interpret “I would buy that” as a sale. Equally, do not assume a refusal proves no demand: timing, authority, integration work, or the offer itself may explain it. Write down the competing explanation and the next test that would distinguish it.

5. Record observations before interpretation

Immediately after the interview, separate what the person said or did from what you infer. A useful note might read: “The owner said the last overdue invoice required three emails.” Your interpretation could be: “Follow-up may be costly.” The unanswered question is whether a new tool would reduce that cost enough to justify switching.

Review patterns across qualified participants while retaining exceptions and missing information. Avoid inventing percentages from incomplete notes. The interview should change your hypothesis or next action, not merely provide a quote for a pitch.

Copy the interview worksheet

Date and participant reference:
Role, segment, and qualification:
Recent incident and trigger:
Steps and tools used:
Consequences and evidence of cost:
What works well today:
Previous attempts to improve it:
Buyer, approver, and switching barriers:
Exact observation or approved quote:
My interpretation:
Alternative explanation:
Offer discussed and actual next action:
Contradictions, unknowns, and follow-up:

Use these notes alongside the micro-SaaS validation checklist. Killgate can help keep the hypothesis, research, and next test visible; your real interviews supply evidence that generated personas cannot provide.