MVP discovery interview guide

Surveys tell you what people say they want. Interviews show you what they actually struggle with. The difference matters when you are deciding what to build first.

A ten-question survey might get two hundred responses and a false sense of confidence. Five well-run interviews will surface the unexpected constraints, workarounds, and emotional triggers that drive real adoption.

Discovery interviews are not about validating your idea. They are about understanding the problem deeply enough to build something people switch to. If you go in trying to confirm your hypothesis, you will miss the signal.

Interview people who experience the problem today and are actively trying to solve it. Not people who might have the problem someday. Not your friends who will be polite.

Five to eight interviews is the sweet spot for an MVP. You will start hearing repeated patterns by interview four or five. If you are still hearing completely new information after eight, your target audience might be too broad.

Recruit from communities where your target users already gather. LinkedIn groups, Slack communities, Reddit threads, customer support tickets. Offer a small gift card if needed, but most people will talk for free if the topic is relevant to their daily work.

These questions are ordered to build context before specifics. Start broad and narrow as the conversation progresses.

One: Tell me about your role and what a typical week looks like. Two: What is the most frustrating part of that workflow? Three: How are you solving that problem today? Four: What have you tried that did not work?

Five: How much time do you spend on this problem each week? Six: What would a perfect solution look like? Seven: What would it need to do on day one to be useful? Eight: What could you live without for the first version?

Nine: Who else is involved in this workflow? Ten: How do you currently measure success? Eleven: What would make you switch from your current solution? Twelve: Is there anything I should have asked but did not?

Question twelve is the most important. It gives the interviewee permission to share what is really on their mind, and it often surfaces the insight you did not know to look for.

Keep it to thirty minutes. Respect people's time and you will get better signal. Rushed answers in a twenty-minute interview are more honest than polished answers in a sixty-minute one.

Record the conversation with permission. You will not remember the exact phrasing, and exact phrasing matters. The way someone describes their frustration reveals priority better than any feature request.

Do not pitch your solution during the interview. The moment you start explaining what you are building, the interviewee shifts from describing their problem to evaluating your idea. Keep those conversations separate.

After all interviews, create a grid with rows for each interviewee and columns for each question. Look for patterns across rows, not insights within a single interview.

Highlight phrases that appeared in three or more interviews. These are your strongest signals. A feature that one person asked for is a request. A problem that five people described independently is a market.

Rank features by how many interviewees described the underlying problem, not by how many requested the feature. People are bad at predicting what they will use. They are good at describing what frustrates them.

The output of this synthesis is a prioritized list of problems to solve, not features to build. Features come from your expertise as a builder. Problems come from your users.