Problem Interviews: 20 Questions That Reveal Real Pain Points

You ask your target customer: "Don't you think [problem] is frustrating?"

They respond: "Yeah, totally frustrating."

You feel validated. You have signal. You're ready to build.

Six months later, your MVP launches. Nobody wants it.

What happened? Your interview subject lied to you. Not intentionally — they were being polite. They agreed with your premise because you'd already decided it was a problem. They were being nice.

This is the Mom Test problem: Even your mom will tell you your idea is good. Especially your mom.

This guide teaches you how to ask questions that surface real pain points instead of polite agreement.

The Mom Test Principle

The Mom Test (named after the book by Rob Fitzpatrick) has one core principle:

Good questions about bad ideas get honest answers. Bad questions about good ideas get agreement.

A bad question: "Do you think [problem] is annoying?" A good question: "Tell me about the last time you ran into [problem area]. What happened?"

Bad questions invite agreement. Good questions reveal behavior.

The 20 Questions: Problem Discovery Script

Here's a script you can use for problem interviews. These 20 questions follow the Arc:

1. Build rapport (questions 1-3)
2. Surface problems (questions 4-12)
3. Understand current solutions (questions 13-16)
4. Identify constraints (questions 17-20)

Rapport Building (1-3)

Q1: "Before we dive in, can you tell me a bit about your role and what you're working on these days?"

• Why: Warm-up, get them talking, establish legitimacy of their expertise

Q2: "How long have you been doing this?"

• Why: Understand seniority and familiarity with the space

Q3: "What does a typical week look like for you?"

• Why: Establish context for problems that'll emerge

Problem Exploration (4-12)

Q4: "I'm trying to understand how people like you handle [problem area]. Tell me about the last time you ran into [specific problem area]."

• Why: Move to specificity. "Last time" is more honest than "usually"

Q5: "Walk me through what happened. What did you do?"

• Why: Get the full story, not the summary

Q6: "Why did you handle it that way?"

• Why: Understand their reasoning and constraints

Q7: "How often does this situation come up?"

• Why: Validate frequency. "All the time" vs. "once a quarter" matters hugely

Q8: "How much time do you spend on [specific task]?"

• Why: Quantify the time cost. "Feels like forever" → "Usually 3-4 hours"

Q9: "What's the financial impact when something goes wrong here?"

• Why: Understand the cost/consequence. Decision-making is tied to this

Q10: "What would it feel like if this problem disappeared?"

• Why: Understand the emotional and practical upside

Q11: "Have you tried to solve this before? What happened?"

• Why: Understand their history with attempted solutions

Q12: "Why doesn't that work for you?"

• Why: Understand why previous solutions failed. Your solution needs to solve this specific gap.

Current Solutions (13-16)

Q13: "What's your current workaround for this?"

• Why: Map the existing workflow. Don't assume it's obvious to you.

Q14: "How is that solution imperfect?"

• Why: Understand the specific gaps. These informed product design.

Q15: "What would your ideal solution look like?"

• Why: They'll describe their dream state. Extract specific needs from this.

Q16: "What's stopping you from switching to [competitor product]?"

• Why: Understand why they're not using existing solutions

Constraints & Decision (17-20)

Q17: "If you were going to fix this, what would need to be true?"

• Why: Understand non-negotiable requirements and constraints

Q18: "Who else would need to be involved in a decision to use a solution like this?"

• Why: Map the decision-making unit. Understand who has authority.

Q19: "What would need to change for you to seriously consider a tool like this?"

• Why: Understand their threshold for adoption

Q20: "If something like this existed and solved this problem for you, how would you want to use it?"

• Why: Understand the workflow, frequency, and integration points

How to Use This Script

Don't read it robotically. Use these as a guide, not a survey.

The best interviews feel like conversations, not interrogations. If they're talking really deeply about Q7, don't jump to Q13. Let the conversation flow.

Listen for:

• Emotional language: "Nightmare," "hate," "love," "waste"
• Quantified pain: Hours, $, percentage of time
• Workarounds: "We just manually..." (sign of unsolved problem)
• Competing tools they use: This reveals the competitive set

Early Warning Signs of Bad Feedback

They're being polite, not truthful:

• They keep saying "Yeah that sounds cool" without specific examples
• They can't articulate a recent time they had the problem
• They keep deflecting to "my teammate would probably..."
• They phrase everything as "in theory..." or "probably..."

Red flags:

• "I don't really have this problem" or "It's not a big deal"
• They're already using a solution that fixes 80% of the problem (your space is small)
• They focus on minor issues vs. core pain ("The UI would be better if..." not "This costs me $1K/month")

Real Example: From Bad to Good Questions

Bad interview:

• You: "Expense tracking is a nightmare for freelancers, right?"
• Them: "Yeah, totally."
• You: Conclude: "They want expense tracking software." ❌

Good interview:

• You: "Tell me about the last time you submitted an expense report."
• Them: "Oh, it was probably last month. I had to dig through emails and screenshots to match my spending."
• You: "How long did that take?"
• Them: "Probably 2 hours? I had receipts scattered everywhere and had to categorize them."
• You: "Why don't you just track it as you go?"
• Them: "I do, kind of, but I forget. And I work with multiple clients so I don't always know which coding account to charge to."
• You: Conclude: "The real problem isn't expense tracking software. It's: 1) Forgetting to track immediately, and 2) Confusion around cost allocation across clients." ✅

See the difference? One leads to a vague product. One tells you exactly what to build.

Follow-Up Question Arsenal

Sometimes an answer is vague. Use these follow-ups:

After the Interview

Within 24 hours:

1. Listen to the recording again (if you recorded)
2. Re-read your notes with fresh eyes
3. Tag specific quotes that revealed new insights
4. Ask: "Did this person confirm my assumption or contradict it?"

Across 5-10 interviews:

1. Look for patterns. Do 80% mention the same problem?
2. Look for contradictions. Do some say it's critical and others say it's minor?
3. Extract the 3 most common workarounds
4. Identify which specific user persona has the sharpest pain

Connection to Validation Framework

Problem interviews are the foundation of comprehensive customer research →. They replace assumptions with lived experience.

Once you have problem clarity from interviews, you can move to testing solutions → with confidence.

Ready to run real problem interviews?

The beauty of this script is it forces you to listen instead of pitch. Once you ask question 4 ("Tell me about the last time..."), the interview runs itself.

Use Edmired to design custom interview questions for your specific problem space, then track patterns across your interview cohort. Join the beta.