Good user interview questions ask about specific past behavior, not opinions or hypotheticals — they surface what someone actually did, felt, and worked around, not what they think you want to hear. Below are 50 questions organized by discovery stage, Forces of Progress, and importance-versus-satisfaction pairs, so every answer can feed a structured opportunity score instead of just piling up in a notes doc.

Quick Answer: Skip "What do you like?" Ask about the last specific time they hit the problem, what they tried instead, and how important fixing it is relative to how satisfied they are today. Those three question types map directly onto JTBD forces of progress and Ulwick-style opportunity scoring — turning interview transcripts into a ranked backlog instead of a pile of quotes.

Why "What Do You Like About Our Product?" Fails

"What do you like about our product?" fails because it invites flattery, not evidence — people answer with opinions about you, not facts about their own behavior. A better interview question asks about a specific past event, because memory of a real incident is far harder to fake than a general impression.

This isn't a minor wording nitpick. Rob Fitzpatrick's The Mom Test built an entire framework around one observation: people are reflexively polite, and they will tell you a product idea is "great" to avoid an awkward conversation, even when they'd never buy it. Ask about the future or their opinion, and you get politeness. Ask about the past, and you get evidence.

The gap between what people say and what they actually do is well documented enough to have its own name in research circles — the say-do gap. If you want the deeper mechanics of why stated preference diverges from observed behavior, and how to catch it before it corrupts a roadmap, see this breakdown of why contradictory data and the say-do gap trip up product teams.

Here's the same weak question reframed against three stronger alternatives:

Weak QuestionWhy It FailsStronger Reframe
"What do you like about our product?"Invites flattery, not evidence"Walk me through the last time you used it — what were you trying to get done?"
"Would you use a feature that did X?"Hypothetical; people overestimate their own future behavior"What have you done in the past when this problem came up?"
"Do you think this is a good idea?"Asks for an opinion, not a fact"What have you tried before to solve this, and how did that go?"
"How important is this to you?" (asked alone)No anchor point; answers cluster at "very important""How important is this relative to how satisfied you are with your current solution?"
"What features do you want?"Treats the customer as the designer"What are you still struggling to get done, even with your current tools?"

The pattern across every reframe: anchor the question in a real, specific moment. A specific memory carries detail an opinion never does — what tool they opened, who they emailed, how long it took, what they did when it failed.

The Anatomy of a Question That Surfaces Real Insight

A question surfaces real insight when it asks for a specific, past-tense, behavioral answer that can later be scored — not a general opinion that dead-ends in a notes doc. The best discovery questions are written backward, from the decision they need to inform.

Three properties separate a question that produces a usable data point from one that produces a pleasant but useless quote:

  1. Specificity. "Tell me about the last time" beats "How often do you..." — specificity forces recall of a real event instead of an estimated average, which people are notoriously bad at generating on the spot.
  2. Neutrality. A good question doesn't hint at the answer you want. "Isn't it frustrating when X happens?" is a leading question wearing a discovery costume.
  3. Scorability. The best questions map cleanly onto a framework you'll use later — importance, satisfaction, or one of the four Forces of Progress from Jobs-to-Be-Done theory (push, pull, anxiety, habit).

That third property is the one most interview guides skip, and it's the difference between research that produces synthesis and research that produces a prioritized backlog. If your interviews only feed a synthesis document, you get a rich, qualitative understanding with no clean way to rank what matters most — read this complete guide to user research synthesis for how that step normally works, and why it's insufficient on its own.

Every question in the bank below is written to be paired with a scoring method later — either an importance/satisfaction rating pulled from Anthony Ulwick's Outcome-Driven Innovation work, or a Forces of Progress tag pulled from Clayton Christensen and Bob Moesta's Jobs-to-Be-Done research. That's the structural difference between this list and a generic "interview tips" article.

The 50-Question Bank

Below are 50 questions grouped into seven categories, moving from context-setting through behavioral evidence, motivational forces, and prioritization signal, ending with a close that keeps the door open. Use them as a menu, not a script — a good interview follows the answer, not the list.

Opening & Context Questions (1–6)

Start broad enough to let the participant set the scene in their own words, before narrowing into specifics.

  1. Walk me through the last time you did [the core task] — what happened, step by step?
  2. What were you using, or doing, before you started using [product or category]?
  3. How did you first realize you needed to solve this problem?
  4. What does a typical week look like for you in this part of your job?
  5. Who else is involved when you do this, and what do they expect from you?
  6. What's the very first thing you do when [the triggering situation] happens?

Past Behavior & Workaround Questions (7–14)

This is where the say-do gap gets caught — ask for the workaround, not the wish list.

  1. Tell me about the last time this went wrong — what did you do next?
  2. What tools, spreadsheets, or workarounds have you cobbled together to handle this?
  3. How much time did that actually take, start to finish, the last time you did it?
  4. What did you try before you landed on your current approach?
  5. Have you ever paid for something — a tool, a consultant, a course — to solve this? What was it?
  6. What did you do the last time you almost gave up on solving this?
  7. Can you show me exactly where you go and what you click when this comes up?
  8. What's still broken about your current process, even with your workaround in place?

Forces-of-Progress Questions: Push, Pull, Anxiety, Habit (15–22)

Straight from Jobs-to-Be-Done theory: people switch solutions when a push (frustration with the old way) and a pull (attraction to something new) outweigh their anxiety (fear the new thing won't work) and habit (comfort with the status quo).

  1. What was happening right before you decided you couldn't keep doing it the old way? (push)
  2. What finally made this problem too expensive — in time, money, or stress — to keep ignoring? (push)
  3. What did you imagine your work looking like once this was actually solved? (pull)
  4. What made you believe a new approach could work better than what you had? (pull)
  5. What almost stopped you from trying something new — what were you worried might go wrong? (anxiety)
  6. What would have to be true for you to trust a new tool with this? (anxiety)
  7. What do you still do out of habit, even though you know a better way exists? (habit)
  8. What would make it hard for you to give up your current process, even if a new one is technically better? (habit)

Importance-vs-Satisfaction Questions for Opportunity Scoring (23–32)

Ask these as pairs — one question anchors how much a job matters, the paired question anchors how well it's currently handled. The gap between the two is where the opportunity lives.

  1. On a day you do this task, how important is getting it right the first time?
  2. How satisfied are you with how well that part is handled today?
  3. How important is it that this happens quickly versus perfectly?
  4. How satisfied are you with the speed of your current process?
  5. How important is it that other people can see or trust this output?
  6. How satisfied are you with how much visibility your team currently has into it?
  7. How important is it that this fits into your existing tools and workflow?
  8. How satisfied are you with how well your current tools talk to each other?
  9. If you had to rank the three hardest parts of this job, what would come first?
  10. Of those, which one, if solved tomorrow, would actually change how you spend your day?

Emotional & Journey Questions (33–38)

Emotion is a leading indicator of where a job breaks down — frustration and relief both mark moments worth mapping onto a journey.

  1. Where in this process do you feel most confident, and where do you feel most anxious?
  2. What's the moment in this process where you'd normally close the laptop and walk away?
  3. What did it feel like the last time this went really well?
  4. Where do you usually get stuck long enough that you have to ask someone else for help?
  5. What's the difference between how this task feels on a good day versus a bad day?
  6. If you described this whole process as a rollercoaster, where's the drop?

These emotional highs and lows are exactly what a journey map is built to plot against time — see this complete guide to mapping the customer journey for how to turn scattered emotional beats into a single visual.

Prioritization & Trade-off Questions (39–44)

These surface what the participant would sacrifice, which is a far more honest signal than what they'd request.

  1. If you could only fix one part of this process this quarter, which would you pick, and why?
  2. What would you be willing to give up — speed, cost, control — to make this easier?
  3. How do you currently decide what to work on first when three things need attention at once?
  4. What's a "good enough" outcome here, versus what would be the ideal one?
  5. If two options cost the same but one saved you an hour a week, would that matter to you? Why or why not?
  6. What's something you've stopped doing altogether because it wasn't worth the effort anymore?

Closing & Referral Questions (45–50)

The close is where a single interview turns into a pipeline of interviews, and where you catch the one thing your question list didn't anticipate.

  1. Is there a question I should have asked that I didn't?
  2. What's the one thing about this that you wish more people understood?
  3. If you were in my position, what would you go find out next?
  4. Who else deals with this the way you do — could you introduce me?
  5. Can I follow up with you again once we've tried a few ideas?
  6. What would make you tell a colleague this was worth solving?

From Interview Answers to a Structured Opportunity Score

A transcript full of good answers is only half the job — the other half is converting importance and satisfaction ratings into a ranked score, so ten interviews produce one prioritized list instead of ten separate stories. This is the step most teams skip, and it's why so much research dies in a synthesis doc instead of reaching a roadmap.

The Opportunity Algorithm: Importance vs. Satisfaction

Anthony Ulwick's Outcome-Driven Innovation work, developed at Strategyn, formalized this into a simple formula:

Opportunity Score = Importance + max(Importance − Satisfaction, 0)

Ask each participant to rate a job's importance and their current satisfaction on a 1–10 scale (questions 23–32 above are built for exactly this). A job rated high-importance and low-satisfaction produces a high opportunity score; a job that's already important and well-served scores low, because there's nowhere left to improve.

Here's how the math plays out on a hypothetical job step, purely to illustrate the mechanic:

Job StepImportance (1–10)Satisfaction (1–10)Opportunity Score
Get a clear cost estimate before committing9.14.313.9
Compare options side by side7.86.09.6
Track status after the decision is made6.27.46.2

Read the table as a triage list, not a scoreboard: the top row is underserved and important — an obvious opportunity. The bottom row is already well-satisfied relative to its importance, which usually means it's not where the next roadmap bet should go.

Mapping Answers to Forces of Progress

Where the opportunity score tells you how much a job matters, the Forces of Progress answers (questions 15–22) tell you why someone would or wouldn't switch to solve it. A high-opportunity job that's also full of switching anxiety needs a different response — de-risking, onboarding, a trial — than one blocked by simple habit inertia, which needs a bigger pull, not more reassurance.

Teresa Torres, in Continuous Discovery Habits, argues for weekly customer touchpoints specifically so this mapping stays current instead of going stale between big research pushes. A single round of 50 questions is a starting point, not a one-time event — the forces shift as competitors, budgets, and habits shift underneath your customers.

If you want the step-by-step mechanics of building job statements and force maps from raw notes, this practical guide to Jobs-to-Be-Done walks through the execution, and this complete guide to Jobs-to-Be-Done covers the underlying theory in full.

Where Prodinja Fits: The Customer Jobs Workspace

Running this scoring by hand across even a dozen interviews gets unwieldy fast — which is the specific gap Prodinja's Customer Jobs workspace is built to close. It's designed to take your interview notes and turn them into structured JTBD statements, Ulwick-style opportunity scores plotting importance against satisfaction, and a Forces of Progress map across push, pull, anxiety, and habit — so the questions above land somewhere more durable than a shared doc.

You still do the interviewing and the listening; the workspace is built to handle the part that normally falls apart under spreadsheet math — keeping every job statement, score, and force tagged consistently as more interviews come in. That consistency is what turns a stack of transcripts into something you can actually rank against.

Interview Mistakes That Quietly Kill Good Questions

Even a perfectly worded question fails if the interviewer talks too much, leads the witness, or stops after too few conversations to see a real pattern. The question list is necessary but not sufficient — execution errors quietly undo good design.

Watch for these five, roughly in order of how often they show up in early-career PM interviews:

  • Talking more than listening. If you're explaining the product instead of asking about the participant's world, you've turned a discovery interview into a sales pitch.
  • Leading with a solution. "Would you use a dashboard that shows X?" plants an idea instead of uncovering one — ask about the problem first, the solution never.
  • Stopping at one interview. A single conversation is an anecdote, not a pattern; Erika Hall's Just Enough Research frames the goal as "enough" signal to act, which almost always means a handful of conversations, not one.
  • Filling silence too quickly. The best follow-up is often just waiting — participants routinely add their most useful detail three or four seconds after they think they've finished answering.
  • Skipping the synthesis step. Notes that never get structured into themes, jobs, or scores are effectively lost — see this guide to automating parts of user research synthesis for where tooling can reasonably take over the repetitive parts of that step.

Key Takeaways

  • Ask about the past, not the future. Specific, past-tense questions produce evidence; hypothetical and opinion questions produce polite fiction, per Rob Fitzpatrick's Mom Test framework.
  • Pair importance with satisfaction. Asking either question alone gives you a number with no context; asking both gives you Ulwick's Opportunity Score — the gap is the opportunity.
  • Tag answers to a Forces of Progress. Push, pull, anxiety, and habit explain why someone would switch, which changes what you build in response to a high-scoring job.
  • A question bank is a menu, not a script. Follow the participant's answer over your list; the best follow-up questions are rarely written in advance.
  • One interview is an anecdote. Treat early conversations as hypothesis generation, and keep interviewing on a regular cadence rather than treating discovery as a one-time event.
  • Scoring is what turns synthesis into prioritization. Themes and quotes are necessary groundwork, but a ranked opportunity list is what actually moves a roadmap decision.

Frequently Asked Questions

How many user interviews do you need before you can trust a pattern?

There's no fixed number, but most practitioners look for a theme to repeat across five to eight conversations with the same user segment before treating it as a pattern rather than a coincidence. Teresa Torres' Continuous Discovery Habits argues for a steady weekly cadence over a single large research sprint, so patterns get validated continuously instead of once a quarter.

What's the difference between a discovery interview and a usability test?

A discovery interview asks about problems, context, and past behavior to figure out what to build; a usability test hands someone a specific design and watches them try to use it to see whether it works. Discovery questions from this bank belong earlier in the process, well before there's a prototype to test.

Should you ever ask customers directly what features they want?

Generally no — customers are experts on their own problems, not on product design, so a direct "what feature do you want" question tends to produce a workaround dressed up as a request. Ask about the underlying job and let the importance-versus-satisfaction gap point toward the opportunity instead.

How do you write good follow-up questions during a live interview?

The strongest follow-up is usually the simplest: repeat the participant's last few words back as a question, or ask "what happened next?" Resist the urge to jump to your next scripted question the moment they pause — the most useful detail often arrives after a few seconds of silence.

Can you run a good user interview without a dedicated note-taker?

You can, but it costs you attention — splitting focus between listening and transcribing means you catch fewer follow-up opportunities in the moment. Recording the conversation (with consent) and reviewing it afterward, or bringing a second person to take notes, generally produces sharper follow-up questions than solo note-taking does.