What Is a Problem Interview? Definition and Goal
A problem interview is a customer conversation you hold before building anything, to learn whether a problem is real, painful, and frequent. You ask about the person's actual life, past behavior, and current workarounds — not about your idea. The goal is evidence that a problem is worth solving, not agreement that your solution is good.
Quick Answer: A problem interview is a pre-build conversation that tests whether a problem actually exists and hurts enough to matter. You explore the customer's real experiences and past behavior — never pitching a solution — so you learn the truth about the problem before you commit time and money to a fix.
Founders skip this step because talking about a problem feels slower than building the fix. But a problem interview is the cheapest way to find out you're wrong before it gets expensive. Done well, it is disciplined and specific; done badly, it becomes a pitch dressed up as research. This piece defines the method, shows how to structure it, walks through an example, and separates a problem interview from its follow-up, the solution interview.
The Goal of a Problem Interview: Confirm the Problem, Not the Solution
The single goal is to find out whether a problem is real and painful enough that people are already trying to solve it. You are looking for evidence in behavior, not enthusiasm in opinion. A problem interview sits inside the broader practice of customer discovery — the work of understanding who your customer is and what they struggle with before you assume you know.
That framing changes what counts as a good outcome. In a pitch, a "yes, I'd use that" feels like success. In a problem interview, that same sentence is nearly worthless, because people are polite and imagining the future is easy. What you want is a story: what they did last time the problem hit, what it cost them, what workaround they cobbled together. Past behavior is data. Predicted behavior is a wish.
Rob Fitzpatrick's The Mom Test is built on this distinction. Its core rule is to ask questions even your mother couldn't lie to you about — questions about specifics of their life and past, not opinions or hypotheticals about your idea. Ask "would you buy a tool that does X?" and everyone who likes you says yes. Ask "walk me through the last time you dealt with X," and you get the truth, because the past already happened and can't be flattered into existence.
How a Problem Interview Is Structured: Questions About the Past
A problem interview is loosely structured around the customer's real experience, moving from their world, to the problem, to how they cope today. You are steering a conversation, not running a survey — and a few principles keep it honest.
Ask about the past, not the future. Replace "would you" with "when did you last." Hypotheticals invite people to invent answers; recollections force them to describe what really happened.
Dig into specifics. When someone says a task is "annoying," that is a signal to slow down, not move on. Ask how often, how long it took, what they were doing when it came up, and what they tried. Specifics reveal whether the pain is real and how big it is.
Avoid leading questions and compliments. The Mom Test warns against fishing for approval. "Don't you think this is a big problem?" plants the answer you want. Ask neutrally and let them tell you it isn't a problem — that's the most valuable answer you can get.
Talk less; listen more. Giff Constable's Talking to Humans stresses letting the customer do the talking and following curiosity where it leads. Your job is to understand their world deeply, not to defend or explain your plan.
Notice what is missing: your idea. In a well-run problem interview you barely mention what you're building. The moment you describe your solution, people shift from reporting their reality to reacting to your pitch — and the data goes soft.
A Problem Interview Example: What It Sounds Like
Suppose you think freelance designers waste time chasing invoices. A weak, pitch-flavored question would be: "Would you pay for an app that automates invoice reminders?" It leads the witness and asks them to predict the future.
A strong problem interview goes the other way. You ask: "Walk me through the last time a client paid you late." Now the designer tells a story — the project that dragged on, the awkward follow-up email they rewrote three times, the spreadsheet where they track who owes what, the month rent was tight because two invoices were overdue. You ask how often it happens, what they've tried, and whether they've paid for anything to fix it.
By the end you know something real: whether this problem actually bites, how they cope today, and whether they care enough to have acted — all without describing your product once. That is the shape of a good problem interview: their story, their past, their workarounds.
Problem Interview vs. Solution Interview: What Each One Tests
These two conversations are often confused, but they answer different questions and belong at different moments. A problem interview asks is there a problem? A solution interview asks does my solution solve it? You earn the right to the second only after the first gives you a real problem worth solving.
Here is how they differ on the dimensions that matter:
| Dimension | Problem interview | Solution interview |
|---|---|---|
| Core question | Is this problem real and painful? | Does my proposed solution address it? |
| When it happens | Before you build anything | After a real problem is confirmed |
| What you talk about | Their past, life, and workarounds | Your prototype, mockup, or concept |
| What "success" looks like | Evidence the problem hurts and recurs | Evidence the solution fits and is wanted |
| Biggest risk | Slipping into a pitch | Politeness masking a weak fit |
Takeaway: Don't collapse the two into one conversation. If you demo a solution before confirming the problem, an interviewee's enthusiasm tells you they like you, not that the problem is real. Confirm the problem first; test the solution second.
Where Problem Interviews Fit in the Validation Sequence
Problem interviews come early — near the very start of validation, before prototypes, landing pages, or pre-sales. They are how you make sure the problem you've assumed is one your customers actually feel, so you don't spend months building a precise solution to a problem nobody has. Understanding, in depth, how problem interviews reveal pain points is what turns a vague hunch into a validated starting point.
From there the sequence flows outward: confirm the problem, then test whether your solution fits, then test whether people will act — sign up, pay, show up. Each step de-risks the next, and the complete guide to startup idea validation lays out the full path. The tools a platform like Edmired provides only matter once you've done this groundwork: no software substitutes for talking to the people who have the problem.
Key Takeaways
- A problem interview is a pre-build conversation that tests whether a problem is real, painful, and frequent — before you commit to any solution.
- The goal is evidence, not agreement. You want stories about the customer's past behavior and workarounds, not their opinion of your idea.
- Ask about the past, not the future. The Mom Test's core rule: probe specifics of their life that they can't flatter into existence, and avoid leading questions and compliments.
- Keep your solution out of the room. The moment you pitch, people react to you instead of reporting their reality, and the data turns soft.
- A problem interview is not a solution interview. One asks whether the problem exists; the other asks whether your fix works — and you earn the second only after the first.
- It comes first in the sequence. Confirm the problem before prototypes, landing pages, or pre-sales, so you don't build a precise answer to a question nobody is asking.
Frequently Asked Questions
What is the goal of a problem interview?
The goal is to learn whether a problem is real, painful, and frequent enough to be worth solving — before you build anything. You gather evidence from the customer's actual past behavior and current workarounds, not from their opinion of your idea. Success is a clear picture of the problem, including cases where you discover the problem isn't as big as you assumed.
How is a problem interview different from a solution interview?
A problem interview tests whether a problem exists and hurts; a solution interview tests whether your proposed fix solves it. The problem interview comes first and talks only about the customer's world. The solution interview comes later, once a real problem is confirmed, and introduces your prototype or concept. Running them together risks a pitch that produces false enthusiasm.
Should I pitch my idea during a problem interview?
No. Pitching is the most common way founders ruin a problem interview. The instant you describe your solution, the customer stops reporting their real experience and starts reacting politely to your plan. Keep the conversation on their past behavior and workarounds. Save your idea for a separate solution interview after you've confirmed the problem is genuine.
What kinds of questions should I ask in a problem interview?
Ask about the past, not the future: "When did you last face this?" rather than "Would you use a tool that…?" Dig into specifics — how often it happens, how long it takes, what they've tried, what it cost them. Avoid leading questions and compliments. As The Mom Test puts it, ask questions the person couldn't flatter you by answering.