You have a feature in mind. You can already picture the changelog entry. The only thing standing between you and shipping it is a nagging question you keep pushing down: does anyone actually have this problem?
A problem discovery interview answers that question before you write the code, not after. It is the conversation where you stop pitching and start listening, where you find out whether the thing you are about to build solves a problem people genuinely have or a problem you have talked yourself into.
The stakes are real. In March 2026, CB Insights analysed 431 VC-backed startups that had shut down since 2023. Among the 385 companies where failure reasons could be identified, poor product-market fit appeared in 43% of cases. The taxonomy has shifted over time — older summaries used “no market need”; the current report uses “poor product-market fit” — but the product lesson is stable: teams fail when they build a careful answer to a question the market was not asking.
This piece is a template you can use this week. It covers what a problem discovery interview is, when to run one, the structure to follow, the exact questions to ask, the ones to avoid, and how to know when you have heard enough. If you have read Maren’s guide to running your first user interview, think of this as the version aimed squarely at one job: finding problems worth solving.
What a problem discovery interview actually is
A problem discovery interview is a research conversation aimed at understanding a person’s experiences, frustrations, and current way of getting a job done — without testing a solution.
Nielsen Norman Group describes user interviews as especially useful in discovery, where the goal is to learn about users’ experiences, needs, and pain points. The word that matters is discovery. You are not validating a design. You are not asking whether someone likes your idea. You are trying to learn something you do not yet know: what the day looks like, where it goes wrong, and what people do about it.
This is also where founders quietly sabotage themselves. The temptation is to use the conversation to describe what you are building and watch for nods. But a discovery interview that drifts into a demo stops being discovery. NN/g is blunt about the cost: when interviews are run for the wrong purpose, or poorly planned and analysed, they lead to bad design decisions.
The product decision should not depend on whether someone was polite while you described a feature. It should depend on whether you understand a real problem well enough to recognise it when it shows up again.
When to run one
Run a problem discovery interview when you are early: when you have a hunch about a problem but no evidence, when you are deciding what to build next, when retention is leaking and you do not yet know why, or when support tickets point at symptoms but not causes.
Teresa Torres argues that discovery should not be a one-off project but a habit. Product teams doing discovery well stay in regular contact with customers and keep asking what they need to learn next. For a founder, that can be as simple as one focused conversation a week.
Do not run a problem discovery interview when your real question is about behaviour in a specific design. If you want to know whether people can use your onboarding flow, watch them use it. That is a usability test, not a discovery interview. If you want to know whether people will buy a feature, asking “would you buy this?” will not get you reliable evidence. NN/g lists future behaviour and feature needs among the questions interviews cannot answer reliably on their own.
Discovery interviews are for understanding the problem. Save solution questions for later, and answer them with behaviour whenever you can.
The one rule: past, not future
If you take one thing from this template, take this: the most reliable signal in a discovery interview comes from what someone actually did, not what they say they would do.
Rob Fitzpatrick built The Mom Test around the same idea. The three rules, often summarised as: talk about their life instead of your idea, ask about specifics in the past instead of opinions about the future, and talk less than you listen.
The reason is simple and uncomfortable. People are kind, optimistic, and bad at predicting themselves. Ask “would you use a tool that did X?” and most people will say yes — partly to be nice, partly because the imagined future version of themselves is more disciplined than the real one. Ask “tell me about the last time you ran into X” and there is less room to perform. They either have a story or they do not, and a missing story is itself an answer.
Torres frames the same move as choosing story-based questions over ideal-behaviour questions. Instead of “what do you usually do?”, ask “tell me about the last time you did it.” NN/g gives the same advice for a different reason: memory. Asking about a specific event helps jog the participant’s memory and makes useful details more likely.
Generalisations produce generalisations. Specific incidents produce evidence.
The template: a 30-minute structure
Here is a structure you can run in about thirty minutes. It borrows from NN/g’s interview guidance: know the goal, prepare a short guide, start easy, build rapport, and probe carefully. Keep your guide short. A few well-designed, open-ended questions beat a long checklist.
1. Open and set the frame: 2–3 minutes
Put the person at ease and make it clear there are no right answers.
“Thanks for making the time. I am trying to understand how you currently handle [area]. There is nothing to sell here and no right answer. I would love to hear about your real experience.”
Then start with something easy to answer:
- “Can you walk me through your role?”
- “Where does [area] show up in your week?”
- “Who else is usually involved?”
Easy openers matter because nervous participants need a moment to warm up. You are not wasting time; you are making the rest of the conversation more honest.
2. Map the current world: 5 minutes
Before you go near a problem, understand the context.
- “Walk me through a typical week when you are dealing with [area].”
- “What tools, people, or workarounds are involved?”
- “What has to happen before this work is considered done?”
You are building a picture of how things work today so that when a frustration surfaces, you understand where it sits.
3. Find the struggling moment: 10 minutes
This is the heart of it. Bob Moesta’s Jobs-to-be-Done work calls this the struggling moment: the point at which the current way stops feeling acceptable.
Get the participant to relive a specific instance:
- “Tell me about the last time [area] went badly. What happened?”
- “Walk me through that day. What were you trying to get done?”
- “What did you do about it?”
- “What did you try first?”
- “What did you use to solve it — a tool, a spreadsheet, a colleague, nothing?”
That last one matters more than founders expect. The current workaround — the messy spreadsheet, the Slack message to a teammate, the thing held together with manual effort — is the clearest evidence a problem is real. People do not build workarounds for problems they do not have.
4. Understand the forces: 5 minutes
Moesta describes every switch as a tug-of-war between forces: the push of the current problem, the pull of something better, the anxiety of trying something new, and the habit of what people already do.
You do not need to recite the framework. Just ask questions that reveal it:
- “What finally made you look for a different way of doing this?” (push)
- “What were you hoping would be better?” (pull)
- “What made you hesitate, or nearly not bother?” (anxiety and habit)
For founders, the anxiety and habit questions are gold. They tell you why a problem can be real and still not produce a purchase.
5. Ask the scary question: 3 minutes
Fitzpatrick’s most useful advice is to ask the question that could kill your assumption.
- “How are you handling this today, and honestly, how much of a problem is it really?”
- “What happens if you do nothing?”
- “Where does this sit compared with the other problems on your plate?”
If the honest answer is “it is a minor annoyance, I have basically stopped thinking about it”, you just saved yourself months. A problem people have stopped caring about is not a business.
6. Close and leave the door open: 2 minutes
Thank them, then ask:
- “Is there anything I did not ask about that I should have?”
- “Who else sees this problem from a different angle?”
- “Would it be useful to show you what we learn once we have spoken to more people?”
The best insight often arrives after the formal questions end. If they are a strong fit, commitment becomes a signal: a follow-up, an introduction, or a shared artefact costs something. A compliment costs nothing.
The follow-ups are the interview
The questions above are scaffolding. The real learning happens in the follow-ups — the moments where you resist moving on and instead dig into what someone just said.
NN/g recommends keeping probing questions visible during the conversation:
- “Tell me more about that.”
- “Can you give me an example?”
- “Why is that important to you?”
- “What did you do next?”
There is also a follow-up that is not a question: silence. Steve Portigal, in Interviewing Users, treats the deliberate pause as a tool. When you stop talking and let the gap sit, people often fill it with the more honest, less rehearsed version of the answer. It feels awkward the first few times. Do it anyway.
Indi Young’s listening work pushes the same instinct further: pay attention to the participant’s inner thinking, not just the answer that fits your guide. Her Listening Deeply material teaches prompts such as “what went through your mind?” and “more about that”, and it frames listening as the basis for later pattern-finding. The practical lesson for a founder is simple: let the participant lead more than your agenda does. The most valuable thing they say is rarely on your list.
The questions to never ask
Some questions feel productive and quietly poison the data.
Avoid:
- “Would you use this?”
- “Would you pay for this?”
- “Do you think this is a good idea?”
- “Don’t you find [X] frustrating?”
- “Which of these features would you want?”
The pattern is consistent: questions about the future, about your idea, or with the answer baked in.
Replace them:
| Avoid | Ask instead |
|---|---|
| “Would you use this?” | “Tell me about the last time you needed to do this.” |
| “Would you pay for this?” | “What have you paid for recently to solve something similar?” |
| “Do you think this is a good idea?” | “How are you handling this today?” |
| “Don’t you find this frustrating?” | “What happened the last time this came up?” |
| “Which features do you want?” | “What were you trying to do when the current workflow broke down?” |
For a deeper pass on wording, read Maren’s guide to avoiding leading questions.
How many people do you need?
Fewer than you fear, but more than five.
There is no magic number. The right answer is saturation: the point where new conversations stop teaching you much that changes the decision. NN/g defines saturation as the point where themes are fleshed out enough that more interviews are unlikely to provide new insights.
Some useful anchors:
- The famous “five users” rule is for usability testing, not exploratory discovery.
- NN/g is clear that five participants are often too few for exploratory interview studies.
- Griffin and Hauser’s classic marketing research estimated that 20–30 interviews uncover most customer needs.
- Guest, Bunce, and Johnson found saturation arriving around twelve interviews in a specific qualitative context, with high-level themes emerging earlier.
Do not turn those numbers into religion. The practical move is to start with five or six, analyse as you go, and keep recruiting while new conversations still surprise you. As soon as you can predict what the next person will say before they say it, you are probably done — for now.
After the interviews: do not skip synthesis
The most common failure is not the interview. It is what happens afterwards.
NN/g warns that when interviews go unanalysed, only the memorable insights get reported and personal bias colours the findings. You remember the vivid quote and forget the quieter pattern that mattered more.
The fix is to treat synthesis as part of the work, not admin. Capture each conversation, pull out moments where someone described a real struggle, and cluster those moments into themes. Torres’s opportunity solution tree is a clean way to organise what you find: problems, unmet needs, and pains become opportunities before you let yourself jump to solutions.
The discipline is in resisting the leap. A problem you have heard five different people describe, in their own words, with their own workarounds, is worth ten features you dreamed up alone. For more on turning raw conversations into themes, read Maren’s guide to synthesising user interviews.
Where Maren fits
Problem discovery is exactly the kind of conversation Maren is built to run.
Maren stays in the past, asks for specific moments, avoids leading questions, and keeps probing when someone gives a vague answer. She does not defend a product, sell a feature, or accept “it’s fine” as the end of the story. Then she brings back the themes across conversations, with the quotes and incidents attached.
You still choose the research question. You still decide who to invite. You still judge what the evidence means. Maren’s job is to talk to people with warmth and discipline, then tell you what she learned.
That matters because most founders do not fail at discovery because they lack curiosity. They fail because discovery is hard to sustain while building. Maren makes the habit easier to keep.
A template you can run this week
Problem discovery is not complicated, but it is easy to do badly: talk too much, ask about the future, lead with your idea, and skip the analysis.
The useful version fits on an index card:
- Understand the current world.
- Find a specific struggling moment.
- Dig into what they actually did.
- Ask the scary question.
- Stay quiet long enough for the truth to surface.
- Synthesise the stories before deciding what to build.
Do that with a dozen well-chosen people and you will know more about whether the problem is real than most teams learn in a year of shipping.
The founders who win are not the ones with the most feature ideas. They are the ones who understood the problem first.