How to Run User Interviews Before Writing a Single Line of Code

How to Run User Interviews Before Writing a Single Line of Code

The most common mistake in startup validation is not skipping it. It is doing it wrong — asking the wrong questions, to the wrong people, and drawing the wrong conclusions.

This article gives you the exact framework for user interviews that produce usable signal, not comfortable noise.

The Core Principle: Ask About the Past, Not the Future

Rob Fitzpatrick's book The Mom Test captures this in one rule: never ask anyone if they would use your product. Ask them about their past behavior instead.

"Would you use an app that helps you track freelance invoices?" is a bad question. People say yes to avoid awkwardness. They are not lying — they genuinely believe they might use it — but hypothetical future behavior is unreliable.

"Tell me about the last time you had trouble with an invoice" is a good question. It produces a specific memory, real details, and actual emotions. The answer tells you whether the problem is real for this person, how often it happens, what they already tried, and how much they care.

Every question you ask should be about something that has already happened. If you catch yourself asking "would you" or "could you imagine," rephrase it.

Who to Recruit and Where to Find Them

Bad interviews come from convenient participants: friends, family, colleagues who are trying to be supportive. You need people who might actually be your customers and have no personal reason to encourage you.

The most effective recruiting channels:

LinkedIn direct messages. Find people whose job title suggests they have the problem. Write a message that mentions the specific pain — not your solution. "I'm researching how [role] handles [specific task]. I'd love 20 minutes to hear about your experience — no pitch, just research." Response rates of 5–15% are typical with a well-crafted message.

Reddit and Facebook groups. Find communities where your target user spends time. Post a genuine question about the problem, not a promotion. The comments will tell you how real and common the problem is, and you can follow up with the most engaged commenters.

Respondent.io and similar platforms. You pay $25–$50 per participant, but you get screened participants who match your criteria. Useful when you need 10–15 interviews quickly.

Referral chains. At the end of every interview, ask: "Is there anyone else you think I should talk to?" One warm introduction is worth five cold messages. Good referral chains can get you from 5 interviews to 20 in a week.

The 45-Minute Interview Structure

First 5 minutes: Context Introduce yourself, explain that you are doing research (not a sales call), tell them you will not pitch anything. This lowers their guard. Ask one open-ended question to get them talking about their work or life in general.

Next 20 minutes: Problem exploration Ask about the problem domain. Let them lead. Follow their answers with "tell me more about that" and "what happened next?" Your goal is to understand their experience, not confirm your hypothesis. Listen for: how often the problem occurs, what they feel when it happens, and what they currently do about it.

Next 10 minutes: Current solutions Ask what they have tried. "What have you done to solve this?" "How well did that work?" "What do you wish was different?" This maps the competitive landscape and reveals the gap your product could fill.

Next 10 minutes: Willingness-to-pay signals You are not pitching. But you can ask: "If a tool existed that completely solved this, how much would you expect to pay for it?" and "Is this something you currently budget for?" These are not commitments — they are calibration signals.

Final 5 minutes: Referrals and close "Is there anyone else you think I should talk to about this?" Thank them, offer to share your findings when the research is complete. This keeps the relationship open.

Detecting Validation Theater

The biggest risk in user interviews is collecting encouraging feedback that does not translate into customers. Here is how to tell the difference:

Validation theater: They nod along, say "absolutely," and never email you again.

Real signal: They send you a message afterward linking to a competitor they found. They introduce you to a colleague. They ask how they can sign up for beta access. They describe a workaround they built themselves — this is the clearest proof the problem is real enough to solve.

The threshold for a "validated" interview is not enthusiasm. It is specificity. Can they describe exactly when this happened, exactly what they did, exactly what it cost? Specific answers are real answers.

What to Do With 15 Interviews

After 15 interviews, build a simple insight map. Group what you heard into four categories:

1. Core jobs: What are people trying to accomplish?
2. Pain intensity: How much does the current situation frustrate them? (1–10 scale works fine.)
3. Current workarounds: What are they already doing? How much does it cost in time or money?
4. Unmet needs: What do they wish existed that does not?

Where these four categories overlap — high-pain jobs, poor workarounds, clear unmet needs — is where your MVP should focus. This map becomes the foundation of your product brief.

---

*Appsademia's Module 1 covers the full user research process, including how to synthesize interview findings into an MVP scope document that developers can build from. €79 one-time, lifetime access.*