User interview questions for validation

Most user interview questions fail before the first answer arrives. The ones that actually work have one simple trait: they push the person across from you to talk about what they did, not what they think.

This guide lays out the order of questions, the probes, and the scoring rubric that help turn a conversation into a go/no-go decision.

Start broad before you try to validate anything

The instinct is to get to the point fast: name the problem, ask if it hurts, move on. That usually gets you polite agreement. People want to be helpful, and if you hand them the answer, they'll often confirm it.

Good validation questions start with context, not with the problem you're hoping to hear about.

The opening questions that get people talking

Start with three questions that show who you're talking to and what their world looks like before you name anything:

• "Walk me through a typical week in your role — what does most of your time actually go to?" This isn't small talk. It tells you where your problem sits in their priority stack.
• "What tools or processes are you using to handle [broad domain — not your specific problem]?" You want the ecosystem, not a yes/no on your feature.
• "What's the most time-consuming part of that process right now?" Let them pick the pain. If they name your problem unprompted, that's signal. If they don't, that's also signal.

This order gets cleaner answers because the person has already described their world before you narrow in. They're not performing for you. They're reporting.

What to skip when you want honest detail

Leading questions are the fastest way for founders to contaminate their own research. The common traps are solution-first framing ("would you use a tool that automatically did X?"), approval-seeking prompts ("does that sound useful?"), and hypotheticals ("how would you handle this if it happened?"). Research on interview bias has documented for decades that interviewees adjust their answers to match what they think the interviewer wants. If your question contains the answer, you'll get the answer back.

Ask about the last real instance. Not the hypothetical one.

Ask about the workflow, not the feature you want to build

The gap between what people say they do and what they actually do is wide. Good user research questions close that gap by targeting behavior, not opinion.

The current-state questions that expose habit

Once you have context, go deeper into the workflow:

• "What triggers this task for you — what makes you start it?" Triggers show whether the problem is reactive or proactive, scheduled or chaotic.
• "Take me through what you actually do, step by step, the last time this came up." The phrase "step by step" slows them down. Vague summaries ("I just handle it") turn into specifics when you press for the sequence.
• "Where does the process usually break down or slow you down?" This surfaces friction without you naming it.

These product validation questions work because they map the workflow as it exists, not as it should exist.

The last-time question that beats abstract opinions

"What do you usually do?" produces a cleaned-up, idealized version. "What did you do last time?" gives you the messy, real one. That matters because you're building for the messy real version.

PostHog's guide to validating product ideas makes this point directly: validate that they've actually had the problem, and get specific about their situation. Abstract opinions ("I'd probably just...") are cheap. A concrete recent instance is evidence.

Follow up the last-time question with: "And how long did that take you?" and "What did you do with the result?" The downstream action tells you whether the task actually mattered.

Probe for pain, frequency, and the workaround they already live with

This is where most validation interviews stop being polite and start being useful.

Severity questions that get past polite agreement

"Is this painful?" gets a yes. Everyone's problems sound painful when asked directly. The follow-ups that separate real pain from mild inconvenience:

• "What happens if you don't handle this well — what's the downstream effect?" Mild problems have mild consequences. Painful problems have named costs: lost revenue, missed deadlines, someone else's complaint.
• "How much time does this cost you in a bad week?" Time is a decent proxy for severity. An hour a week is a different problem than twenty minutes a month.
• "Have you tried to fix this before? What happened?" Prior attempts to solve a problem are strong evidence it's real. Failed attempts are even stronger.

If they stay vague, press a little: "When you say it's frustrating, what does that actually look like for you?" That usually gets you out of the clouds.

Frequency questions that tell you whether this is real

Severity without frequency is a niche. Frequency without severity is an annoyance. You need both.

• "How often does this come up — daily, weekly, once a quarter?"
• "Is it getting more frequent, or has it always been roughly this often?"
• "When it happens, does it always look the same, or does it vary?"

A problem that shows up once a quarter and takes twenty minutes is unlikely to produce paying customers. A problem that shows up three times a week and eats an hour each time is a different conversation.

The workaround question that reveals hidden demand

The strongest signal in a user interview is a real workaround. Not "I'd probably use a spreadsheet" — an actual spreadsheet they're already using.

Ask: "What do you do today to handle this — is there something you've cobbled together, even if it's ugly?"

A spreadsheet, a shared doc, a Slack channel used as a database, a manual process someone does every Friday — these are the real competitors. They're also proof that the problem is real enough for someone to build something around it, even if that something is terrible. First Round's early user research playbook treats workarounds as one of the clearest validation signals available: if people are already paying in time and effort to solve this, they know the problem exists.

Separate user pain from buyer urgency before you call it validation

User interviews and buyer interviews are not the same thing. Mixing them up is how you get twelve enthusiastic users and zero paying customers.

Who feels the pain is not always who signs the check

The person doing the work often isn't the person with budget authority. In B2B especially, the user is often a few layers removed from the decision-maker. You need both conversations.

For the user: "How does this problem affect your day-to-day?" For the buyer: "How does this problem affect the team's output — and is it something leadership has noticed?"

Ask early in the conversation: "If your team decided to buy a tool to solve this, who would be involved in that decision?" The answer tells you who else you need to talk to.

The budget and ownership questions founders forget

These feel awkward to ask. Ask them anyway:

• "Do you have a budget for tools like this, or would it need to go through an approval process?"
• "Is there already something in place that handles part of this — even if it's not working well?"
• "Who owns this problem internally — is it yours to solve, or does it sit with someone else?"

A user who loves the idea but has no budget and no ownership is a reference, not a customer. Knowing that early saves you from building for the wrong person.

Close with switching behavior, pricing, and a clean next step

The end of the interview is where you find out whether enthusiasm is real.

The switching question that tells you how hard adoption will be

Customer discovery questions that surface switching behavior are more useful than any "would you use this?" prompt:

• "What would you stop doing if this existed — what does it replace?"
• "What would have to be true for you to actually switch from what you're doing now?"
• "What would make you not switch, even if this solved the problem?"

The last question matters most. Switching costs, internal politics, integrations, and inertia are all real obstacles. If someone can't name a reason they wouldn't switch, they haven't thought seriously about it.

The closing question that avoids fake compliments

Never end with "would you use this?" The answer is almost always yes, and it means almost nothing. End with a concrete ask instead:

• "Would you be willing to try an early version and give me feedback?"
• "Can you introduce me to two or three other people who have this problem?"
• "If we built this, would you want to be on the list to hear when it's ready?"

A referral is stronger than enthusiasm. A willingness to be contacted again is stronger than a compliment. Concrete next actions separate real interest from polite interest, and that distinction is the whole point of the interview.

---

FAQ

Q: What questions reveal whether the problem is painful and frequent enough to build for?

The cluster that does real work is: "What happens if you don't handle this well?" for severity, "How often does this come up?" for frequency, and "What do you do today to handle it — even if it's ugly?" for workaround. Enthusiasm alone isn't signal. Repeated pain, a named downstream consequence, and an existing workaround are signal. If you're getting vague agreement but no one can name a workaround, the problem probably isn't painful enough yet.

Q: How do I ask user interview questions in an order that starts broad and gets to validation fast?

Start with context: role, workflow, what takes most of their time. Then narrow to the specific domain without naming your solution. Then ask about the last real instance, the workaround, and the downstream cost. Then close with switching behavior and a concrete next step. If you skip the broad opening and jump straight to pain, you'll get polite confirmation. People will tell you what they think you want to hear because you've already handed them the frame.

Q: What follow-up questions uncover real workarounds, urgency, and switching behavior?

For workarounds: "What do you do today to handle this — is there something you've cobbled together, even if it's ugly?" For urgency: "What happens if you don't handle this well?" and "Have you tried to fix this before?" For switching: "What would you stop doing if this existed?" and "What would make you not switch, even if this solved the problem?" Listen for concrete actions, not opinions. A spreadsheet someone actually uses beats ten hypothetical yes answers.

Q: How do I avoid leading questions that create fake validation?

Three main traps show up again and again: solution-first framing ("would you use a tool that automatically did X?"), approval-seeking prompts ("does that sound useful?"), and hypotheticals ("how would you handle this if it happened?"). The fix is the same for all three: ask about the last real instance instead. "What did you do last time this came up?" gets you actual behavior. "What would you do?" gets you a performance.

Q: What questions should a founder ask differently if the interviewee is a user versus a buyer?

For the user: focus on workflow, frequency, severity, and the workaround they're already living with. For the buyer: focus on whether the problem has budget attached, who owns it internally, what approval looks like, and what's already in place. Ask both: "Who would be involved in a decision to buy something like this?" early in every interview. It tells you which conversation you're actually in.

Conclusion

Run the script on three conversations this week. Score each one before you build anything: did they name a workaround? Did they describe a downstream cost? Did they give you a concrete next action at the close, or just a compliment? Validation is when the answers get specific enough that shipping feels earned, not when enough people say the idea sounds good.