MVP Customer Interviews: How to Talk to Users Before You Build
The most expensive mistake in product development is building something nobody asked for. Customer interviews done right — before a single screen is designed — reveal the actual problem, the actual language users use to describe it, and the actual outcome they are willing to pay for. The framework, the questions, and how to avoid the most common interviewing mistakes.
The Mistakes That Make Interviews Useless
MVP customer interviews are structured conversations with target users designed to validate or invalidate the assumptions behind a product idea before any development begins. Done correctly, 10-15 customer interviews reveal whether the problem you are planning to solve is real and frequent enough to support a business, whether your target user is the right one, what language users actually use to describe their pain (which directly shapes the value proposition and landing page copy), and what alternatives they have already tried. Done incorrectly — by pitching the idea, asking hypothetical questions about future behaviour, or interviewing friends who will not be honest — customer interviews produce false confidence that leads directly to building a product that real users do not adopt.
The most influential framework for customer interviews is Rob Fitzpatrick’s The Mom Test: a set of interview principles designed to get honest, useful information from people who want to be polite and supportive rather than candid. The core insight: never ask anyone if they like your idea, because they will say yes to spare your feelings. Instead, ask about their actual behaviour, their actual problems, and their actual spending decisions — questions where social politeness does not distort the answer.
Questions That Get Honest Answers
| Wrong Question (Produces Bad Data) | Right Question (Produces Real Insight) | Why the Difference Matters |
|---|---|---|
| Would you use a product that automates your client reporting? | Walk me through how you currently handle client reporting. How long does it take? What do you use? | Hypothetical questions get aspirational answers. Behaviour questions reveal actual workflow and actual pain. |
| How much would you pay for this? | Have you spent money trying to solve this problem? What did you pay? | People dramatically overestimate future willingness to pay. Past spending behaviour is far more reliable. |
| Is reporting a major pain point for you? | What was the last frustrating thing that happened with your client reporting process? | Yes/no questions get yes. Story questions reveal whether the pain is real and specific. |
| Would you switch from your current tool? | Why did you choose the tool you’re using now? What made you start looking for it? | Switching intent is hypothetical. Adoption history reveals what actually drove past decisions. |
| What features would you want? | Can you show me how you currently do this task? | Users are bad at specifying features. Observing the actual workflow reveals what the product must do. |
How to Structure a 45-Minute Customer Interview
Opening: establish context and permission (5 minutes)
Start by explaining what you are trying to learn: you are exploring a problem space, not pitching a solution. Give the interviewee explicit permission to say that the problem is not relevant to them — this is the most useful information they can give you. Example opening: ‘I am trying to understand how agency founders manage client reporting. I might be completely wrong about what the problems are, and I would genuinely find it more useful if you tell me the problem is not significant than if you reassure me it is. Nothing you say will hurt my feelings — honest feedback is far more valuable than polite feedback.’
Problem exploration: what actually happens today (15 minutes)
Ask the interviewee to describe their current process for the specific workflow you are investigating. Listen for the words they use, the tools they mention, the moments they express frustration, and the workarounds they have invented. Ask follow-up questions: ‘And then what happens?’ ‘How long does that take?’ ‘How often does that occur?’ ‘What do you do when that goes wrong?’ Do not mention your product concept at any point in this section.
Frequency and severity assessment (10 minutes)
Establish how often the problem occurs and how significantly it affects them: ‘How often does this happen in a typical week?’ ‘When was the last time this was a problem for you?’ ‘What happens if you don’t handle it well — what’s the cost?’ ‘Have you tried to solve it before? What did you try?’ The answers tell you whether the problem is frequent enough and painful enough to motivate a paid solution.
Alternative assessment: what they already do or pay for (10 minutes)
Ask about the alternatives they have tried: ‘What tools or services do you currently use to deal with this?’ ‘Have you ever paid for something to help with this problem?’ ‘Why did or didn’t that work?’ The answers reveal the competitive landscape from the user’s perspective, the price anchors they already have in their mind, and the specific gaps in existing solutions that your product could address.
Closing: permission to follow up and referrals (5 minutes)
End with two requests: permission to follow up as you build something based on their feedback, and an introduction to two or three other people with similar roles who might have valuable perspectives. The follow-up permission establishes a warm relationship with a potential early adopter. The referral request is the most efficient way to fill your interview pipeline without cold outreach.
🔗 Related reading on sasolutionspk.com
Bubble SaaS Customer Interview Guide
SA’s complete guide to running customer interviews specifically for SaaS product founders — templates, questions, and synthesis frameworks.
Bubble SaaS Product-Market Fit
How customer interview insights feed directly into the product-market fit measurement framework — from discovery to retention metrics.
Turning Conversations Into Build Decisions
Raw interview notes are not product decisions. The synthesis step — extracting patterns across multiple interviews — is where the actionable insight is created. SA recommends a simple synthesis process after every set of 5 interviews:
Count the mentions
How many interviewees mentioned each specific pain point, each current tool, each workaround? Pain points mentioned by 8 of 10 interviewees are validated problems. Pain points mentioned by 2 of 10 are edge cases — real but not universal enough to anchor a product around.
Extract the exact language
What words did multiple interviewees use to describe the same pain? The language from customer interviews is the most effective raw material for landing page copy, email subject lines, and value proposition statements because it is the language the target audience actually uses, not the language the founder would choose.
Identify the priority hierarchy
Which pain points consistently came up earliest and with most energy in interviews? The problems that interviewees raise without prompting and describe with specific examples and stories are the genuine priority problems. The ones that emerge only in response to direct questions are secondary.
Q: How many customer interviews do I need before starting to build?
SA’s recommendation: a minimum of 10-15 interviews before finalising the product specification, spread across at least 3-4 subgroups within your target user definition. 10-15 is enough to identify the patterns that indicate a validated problem — the same themes appearing across multiple interviews from different people. Below 10, you may be seeing individual variation rather than systematic patterns. Above 20, you are typically getting diminishing returns unless you are discovering significant new themes at interview 18 that were not present at interview 12, which suggests your target user definition was too broad.
Q: What do I do if every interviewee says the problem I’m solving isn’t important to them?
This is the most valuable possible interview outcome — even though it feels like failure. If 8 of 10 interviewees say the problem is real but minor, or that they have already solved it adequately with existing tools, you have learned something that would have cost you $15,000 and 3 months to discover in an MVP build. The right response is to use the interview data to identify whether there is an adjacent problem that IS significant to the same user group, whether the same problem is significant to a different user group, or whether the fundamental hypothesis needs to be rethought before any development investment is committed.
Q: Can I run customer interviews while also building the MVP?
Yes — and SA recommends it for the first 30 days after an MVP launch. Post-launch customer interviews with early users who have experienced the product are fundamentally different from pre-build discovery interviews: they reveal where the product delivered on its promise and where it fell short, which features users engage with most, and what would need to change for them to pay more or recommend it to others. SA typically includes a post-launch interview protocol in the Discovery Sprint deliverable alongside the build specification.
Ready to Build Your MVP?
SA Solutions builds MVPs in weeks using Bubble.io. Start with a free audit or scope your build in 48 hours with a Discovery Sprint.
