{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-06-22T20:54:03.103Z"},"content":[{"type":"documentation","id":"2c4df7ac-c2d7-4a54-a807-99dc43b1ed75","slug":"problem-interviews-vs-solution-interviews","title":"Problem Interviews vs. Solution Interviews: When to Use Each","url":"https://www.koji.so/docs/problem-interviews-vs-solution-interviews","summary":"Problem interviews validate whether a customer pain is real, frequent, and worth solving, using past-behavior questions; solution interviews come later and test whether a specific prototype or MVP relieves that pain. This guide explains the difference, when to run each, the questions that work, and how AI-moderated platforms like Koji let teams run both types continuously at scale.","content":"\nProblem 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.\n\nThe 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](https://www.cbinsights.com/research/report/startup-failure-reasons-top/).\n\n## The Core Difference\n\n| Dimension | Problem Interview | Solution Interview |\n|-----------|-------------------|--------------------|\n| Goal | Validate the problem is real and painful | Validate your solution actually solves it |\n| Stage | Customer discovery (before building) | Customer validation (mockup, prototype, MVP) |\n| Focus | Past behavior, current workarounds, pain | Reaction to a specific proposed solution |\n| Key question | \"Tell me about the last time this happened\" | \"Walk me through how you would use this\" |\n| Failure mode | Leading the witness toward your idea | Confirmation bias / politeness (\"looks great!\") |\n| Output | Validated (or invalidated) problem hypothesis | Evidence the solution reduces the pain |\n\nCustomer 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.\n\n## What Is a Problem Interview?\n\nA 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.\n\nAs 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.\n\n### Problem interview questions that work\n\n- \"Walk me through the last time you experienced [situation].\"\n- \"What were you trying to get done? What got in the way?\"\n- \"How do you handle that today?\" (workarounds reveal real pain)\n- \"How often does this happen?\"\n- \"What have you tried to fix it? Did you pay for anything?\"\n- \"What's the hardest part about [activity]?\"\n\nNotice 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.\n\n### What you are listening for\n\nA 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.\n\n## What Is a Solution Interview?\n\nOnce 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.\n\nThe 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.\n\n### Solution interview questions that work\n\n- \"Walk me through how you'd use this to solve [problem].\" (observe, don't explain)\n- \"What would you expect to happen when you click here?\"\n- \"Which part of this is most valuable to you? Why?\"\n- \"What's missing that would stop you from using it?\"\n- \"If this existed today, what would you stop doing?\"\n- \"What would you expect to pay for this?\" (probe for real commitment)\n\nThe 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.\n\n## When to Use Each\n\n**Use a problem interview when:**\n- You have a hypothesis about a customer pain but no proof it's real\n- You are exploring a new market or segment\n- You are early in customer discovery and have nothing to show yet\n- You want to size how frequent and severe a problem is before investing\n\n**Use a solution interview when:**\n- The problem is already validated by prior research\n- You have something concrete to react to — wireframe, prototype, or MVP\n- You need to choose between competing solution directions\n- You are pressure-testing pricing, packaging, or a specific workflow\n\nA 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.\n\n## The Modern Approach: Run Both at Scale with AI\n\nTraditionally, 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.\n\nAI-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.\n\n- **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.\n- **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.\n- **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](/docs/structured-questions-guide)).\n- **Automatic quality scoring.** Every interview is scored 1–5 for depth and usefulness, so low-signal sessions don't pollute your synthesis.\n- **Voice or text.** Run async voice interviews to capture tone and emotion, or text interviews for speed and global reach.\n- **Real-time thematic analysis.** Instead of spending a weekend coding transcripts, Koji surfaces patterns, representative quotes, and the frequency of each problem automatically.\n\nThe 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.\n\n## A Simple Sequence to Follow\n\n1. **Form a problem hypothesis.** Write down who has the problem and what you believe the pain is.\n2. **Run problem interviews** (Koji `discovery` or `mom_test` brief). Validate frequency, severity, and existing workarounds. Kill or refine the hypothesis.\n3. **Design a solution** only for problems that survived step 2.\n4. **Run solution interviews** with a prototype. Watch usage, probe for commitment, test pricing.\n5. **Iterate.** Feed what you learn back into the next round. With AI moderation, this loop runs weekly, not quarterly.\n\n## Common Mistakes to Avoid\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\n## A Real-World Pattern\n\nConsider 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.\n\nOnly 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.\n\nThis 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.\n\n## Related Resources\n\n- [Customer Discovery Interviews: The Complete Guide](/docs/customer-discovery-interviews)\n- [The Mom Test: How to Run Customer Interviews](/docs/mom-test-customer-interviews)\n- [Jobs to Be Done Interviews](/docs/jobs-to-be-done-interviews)\n- [How to Write Effective Interview Questions](/docs/writing-interview-questions)\n- [Structured Questions Guide: The 6 Question Types](/docs/structured-questions-guide)\n- [How Many Interviews Are Enough?](/docs/how-many-interviews-enough)\n","category":"Research Methods","lastModified":"2026-06-22T03:18:28.20567+00:00","metaTitle":"Problem Interviews vs. Solution Interviews — Koji","metaDescription":"Problem interviews validate whether a pain is real and worth solving; solution interviews test whether your product actually fixes it. Learn when to use each, the exact questions to ask, and how to run both at scale with AI.","keywords":["problem interviews vs solution interviews","problem interview","solution interview","customer development","customer discovery","validate problem"],"aiSummary":"Problem interviews validate whether a customer pain is real, frequent, and worth solving, using past-behavior questions; solution interviews come later and test whether a specific prototype or MVP relieves that pain. This guide explains the difference, when to run each, the questions that work, and how AI-moderated platforms like Koji let teams run both types continuously at scale.","aiPrerequisites":["Basic familiarity with customer interviews"],"aiLearningOutcomes":["Distinguish problem interviews from solution interviews","Know which questions to ask in each","Sequence both stages correctly in customer development","Run both at scale with AI moderation"],"aiDifficulty":"beginner","aiEstimatedTime":"11 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}