Problem Interviews vs. Solution Interviews: When to Use Each

Problem interviews discover whether a pain is real, frequent, and worth paying to solve. Solution interviews test whether your proposed product actually relieves that pain. They sit at different stages of customer development, ask different questions, and fail in different ways. Run them in the wrong order — or skip the problem interview entirely — and you risk building something nobody needs.

The short answer: run problem interviews first to validate the problem, then run solution interviews to validate your answer. Most teams skip straight to showing off a solution, which is exactly how you end up among the 43% of startups that fail because of poor product-market fit, according to CB Insights' 2024 analysis of failed companies.

The Core Difference

Customer development pioneer Steve Blank framed the entire discipline around a single instruction: "get out of the building" and talk to customers before you write a line of code. Problem and solution interviews are the two halves of that fieldwork.

What Is a Problem Interview?

A problem interview is a structured conversation designed to learn whether a problem you suspect exists is actually real — without contaminating the answer by pitching your idea. You are a detective, not a salesperson.

As Cindy Alvarez writes in Lean Customer Development, "What features your customers ask for is never as interesting as why they want them." The job of a problem interview is to redirect people away from proposing solutions and back toward describing the problem and what they do today.

Problem interview questions that work

• "Walk me through the last time you experienced [situation]."
• "What were you trying to get done? What got in the way?"
• "How do you handle that today?" (workarounds reveal real pain)
• "How often does this happen?"
• "What have you tried to fix it? Did you pay for anything?"
• "What's the hardest part about [activity]?"

Notice these are all rooted in past behavior, not hypotheticals. Alvarez's classic example: instead of asking how many times someone plans to go to the gym next week, ask them to open their calendar and count how many times they actually went last week. Stated intent lies; behavior doesn't.

What you are listening for

A problem worth solving is frequent (it recurs), painful (it costs time, money, or stress), and already being worked around (people hack together spreadsheets, hire help, or pay for inadequate tools). If nobody has built a workaround, the problem probably isn't painful enough to sell against.

What Is a Solution Interview?

Once a problem is validated, the solution interview tests whether your specific approach relieves it. You show a mockup, prototype, landing page, or early MVP and watch how people react and use it.

The danger flips. In problem interviews the risk is leading people toward your idea. In solution interviews the risk is politeness and confirmation bias — people say "that looks great!" to be nice. Rob Fitzpatrick built The Mom Test around exactly this trap: ask questions so good that even your mom couldn't lie to you. Compliments are not data; commitments and behavior are.

Solution interview questions that work

• "Walk me through how you'd use this to solve [problem]." (observe, don't explain)
• "What would you expect to happen when you click here?"
• "Which part of this is most valuable to you? Why?"
• "What's missing that would stop you from using it?"
• "If this existed today, what would you stop doing?"
• "What would you expect to pay for this?" (probe for real commitment)

The strongest signal in a solution interview is commitment: a customer who gives you their time, reputation (an intro), or money is telling you something a compliment never will.

When to Use Each

Use a problem interview when:

• You have a hypothesis about a customer pain but no proof it's real
• You are exploring a new market or segment
• You are early in customer discovery and have nothing to show yet
• You want to size how frequent and severe a problem is before investing

Use a solution interview when:

• The problem is already validated by prior research
• You have something concrete to react to — wireframe, prototype, or MVP
• You need to choose between competing solution directions
• You are pressure-testing pricing, packaging, or a specific workflow

A common, expensive mistake is running a solution interview as if it were a problem interview — showing your product and asking "would you use this?" The answer is almost always a polite yes, and you learn nothing about whether the underlying problem justifies the build.

The Modern Approach: Run Both at Scale with AI

Traditionally, the bottleneck wasn't knowing the difference between these interview types — it was capacity. A founder or PM could realistically run five to eight interviews a week, each requiring scheduling, a live 30–45 minute session, note-taking, and hours of transcription and synthesis. That ceiling forced teams to undersample and rush to building.

AI-native research platforms like Koji remove that ceiling. With Koji you can run both problem and solution interviews continuously, in parallel, with dozens or hundreds of participants — and get synthesized themes in minutes instead of weeks.

• Methodology-aware briefs. Koji's research brief supports distinct frameworks including mom_test, discovery, and jtbd for problem-focused interviews, and exploratory and concept-validation flows for solution interviews. The AI interviewer adapts its probing depth to the framework you choose.
• AI-moderated interviews that probe like a researcher. Koji's AI consultant asks the open-ended, behavior-focused follow-ups that separate a good problem interview from a leading one — and it never gets tired or biased after the 40th conversation.
• Six structured question types. Mix free-form discovery with open_ended, scale, single_choice, multiple_choice, ranking, and yes_no questions to quantify how frequent and painful a problem is, or to force trade-offs in a solution interview (see the Structured Questions Guide).
• Automatic quality scoring. Every interview is scored 1–5 for depth and usefulness, so low-signal sessions don't pollute your synthesis.
• Voice or text. Run async voice interviews to capture tone and emotion, or text interviews for speed and global reach.
• Real-time thematic analysis. Instead of spending a weekend coding transcripts, Koji surfaces patterns, representative quotes, and the frequency of each problem automatically.

The result: teams using AI-assisted research compress time-to-insight dramatically, making it realistic to validate a problem and a solution in the same week rather than over a quarter. While legacy survey tools like SurveyMonkey can only collect static, closed-ended answers — useless for the "tell me about the last time" depth a problem interview needs — Koji conducts the actual conversation.

A Simple Sequence to Follow

1. Form a problem hypothesis. Write down who has the problem and what you believe the pain is.
2. Run problem interviews (Koji discovery or mom_test brief). Validate frequency, severity, and existing workarounds. Kill or refine the hypothesis.
3. Design a solution only for problems that survived step 2.
4. Run solution interviews with a prototype. Watch usage, probe for commitment, test pricing.
5. Iterate. Feed what you learn back into the next round. With AI moderation, this loop runs weekly, not quarterly.

Common Mistakes to Avoid

• Pitching in a problem interview. The moment you describe your product, you stop learning about the problem and start collecting polite validation. Stay curious about their world, not your idea.
• Asking hypotheticals. "Would you use a tool that does X?" produces fantasy data. Anchor every question in what the person actually did, paid for, or built a workaround for.
• Treating compliments as commitment. In solution interviews, "I love it" means nothing. A calendar hold, an intro to their boss, a pre-order, or a signed pilot means everything.
• Skipping problem interviews because you "already know" the problem. This is how experienced teams build features nobody adopts. Founder intuition is a hypothesis, not evidence.
• Too small a sample. Five interviews can reveal a theme but rarely confirm one. Patterns get trustworthy as you cross 15–30 conversations — which is exactly where manual research stalls and AI moderation shines.

A Real-World Pattern

Consider a team that suspects busy parents struggle to plan weeknight dinners. A problem interview asks: "Walk me through what happened the last three weeknights at dinnertime. What did you do? What was frustrating?" The team learns parents already pay for meal kits but abandon them because prep still takes too long — a validated, frequent, painful problem with an existing (inadequate) workaround.

Only then does the team build a prototype and run solution interviews: "Here's a 10-minute meal planner — show me how you'd use it tonight." They watch where people hesitate, probe what would make them switch from their current meal kit, and ask what they'd pay. The sequence — validate the problem, then validate the solution — keeps the team from building a clever product for a problem that wasn't worth solving.

This two-stage discipline is the heart of customer development, and AI-moderated interviewing is what finally makes it fast enough to run on every product decision.

Related Resources

• Customer Discovery Interviews: The Complete Guide
• The Mom Test: How to Run Customer Interviews
• Jobs to Be Done Interviews
• How to Write Effective Interview Questions
• Structured Questions Guide: The 6 Question Types
• How Many Interviews Are Enough?