Running Your First User Interviews as an APM Without Leading the Witness

Your first user interviews will produce false validation if you ask questions designed to confirm your idea rather than test it. Run them like a skilled PM: ask about specific past behavior, avoid hypotheticals and opinions, and listen for the forces already pushing someone toward or away from a change. That single shift — disconfirm, don't confirm — separates a useful interview from a flattering one.

Quick Answer: Novice interviewers ask "would you use this?" and hear what they want to hear. Skilled interviewers ask "tell me about the last time this happened," apply the Mom Test, and map the interview to the Forces of Progress (push, pull, anxiety, habit) to find the real job behind the request.

Why your first instinct will be to interview for validation

New APMs walk into interviews wanting their idea to be right, so they unconsciously steer the conversation toward agreement. This isn't dishonesty — it's a structural bias baked into having built something you're proud of. The fix is procedural, not moral: change the questions, not your willpower.

This bias has a name in the research world: confirmation bias, first characterized systematically by psychologist Peter Wason in his 1960s rule-discovery experiments, where subjects overwhelmingly sought evidence that confirmed their hypothesis rather than tests that could break it. PMs do the same thing with product ideas.

A junior PM asks, "Would you use a feature that does X?" A user, wanting to be nice, says "yeah, probably." Nothing was learned. The APM writes "validated" in their notes and ships six weeks of work on a foundation of politeness. This pattern — and how to recognize it before it costs you a sprint — is covered in more depth in our complete guide to the APM playbook.

The confirm-vs-disconfirm mindset shift

Novices treat an interview as a pitch meeting with a survey attached. Experts treat it as an experiment actively trying to break their own hypothesis. That reframe changes every question you write beforehand.

• Novice framing: "I think users struggle with onboarding. Let me ask if onboarding is hard."
• Expert framing: "I think users struggle with onboarding. What's the strongest evidence that would prove me wrong?"
• Novice framing: "Would this feature be useful to you?"
• Expert framing: "Walk me through the last time you needed something like this and what you actually did."

The second framing in each pair forces you toward facts instead of forecasts. Facts about the past are falsifiable; opinions about the future are not.

What the Mom Test actually teaches you to do

The Mom Test, a heuristic popularized by Rob Fitzpatrick's book of the same name, states that a good customer question is one your own mother couldn't lie to you about, even if she wanted to spare your feelings. In practice, that means banning questions about opinions, hypotheticals, and the future.

The test works because it removes the user's incentive to be polite. Your mom can't lie about what she did yesterday; she absolutely can lie about whether your business idea is "great."

Three rules that operationalize the Mom Test

1. Talk about their life, not your idea. Ask about their process, their last attempt, their workaround — never pitch the concept mid-interview.
2. Ask about specifics in the past, not generics or opinions about the future. "Tell me about the last time" beats "do you usually" beats "would you ever."
3. Talk less, listen more. If you're talking more than 20% of the interview, you're leading. Silence after a question is a tool, not a failure.

Fitzpatrick's core insight generalizes past interviewing: any question that lets someone be generous with you instead of honest with you is the wrong question. This is also why a junior PM's first hard "no" from a stakeholder can feel like a personal failure rather than useful signal — see your first real pushback as an APM for the same reframe applied to internal conflict instead of customer conversations.

How to structure open, past-behavior questions

Open, past-behavior questions ask a user to narrate a specific, already-happened event in detail, rather than to evaluate a concept or predict a future action. The narration itself surfaces context, workarounds, and emotional stakes that a yes/no answer never will.

Start every interview segment with a story request, not a question. "Walk me through the last time you [did the thing]" produces five minutes of unscripted material. A closed question produces one word.

The anatomy of a good story request

• Anchor to a specific instance: "the last time," "the most recent time," "an example from this week" — never "generally" or "usually," which invites summarized fiction instead of memory.
• Ask for the sequence: What happened first? Then what? Who else was involved? Sequence questions keep the user in memory-recall mode instead of opinion mode.
• Probe the workaround: "What did you do instead?" almost always reveals more than the original complaint. Existing workarounds are the clearest signal of unmet demand.
• Quantify casually: "How often does that happen?" and "How much time did that take?" convert vague frustration into a rough, honest magnitude.

A bad-vs-good rewrite, side by side

Notice the good column never mentions your product. That's deliberate — a question that name-drops your feature invites a reaction to the feature, not a description of the underlying reality.

Reading interviews through the Forces of Progress lens

The Forces of Progress framework, drawn from Bob Moesta and Chris Spiek's Jobs to Be Done research (later popularized in Moesta's book Demand-Side Sales 101), explains switching behavior as a contest between four forces: the push of the current situation, the pull of a new solution, the anxiety about switching, and the habit of sticking with the status quo. A user only changes behavior when push plus pull outweighs anxiety plus habit.

Interviews that only ask "what features do you want" miss three of these four forces entirely. Structuring questions around all four turns a feature-request conversation into a switching-decision diagnosis.

Why this matters more than a feature checklist

A feature request is an artifact, not a cause. The Forces of Progress lens forces you to ask what pushed the user to the point of requesting a feature at all — and that push is usually the real, sellable insight. This same principle — that behavior is driven by underlying jobs rather than surface preferences — is the foundation of our complete guide to jobs-to-be-done, which goes deeper into the theory this article applies tactically.

Mapping an interview to push/pull/anxiety/habit also exposes contradictions a feature checklist hides. A user might report high push (real pain) but also high habit (deeply embedded workaround) — meaning your feature needs to beat inertia, not just solve the problem on paper.

Finding the real job behind a feature request

Feature requests are almost always a symptom, not a spec. The job underneath is usually simpler, more emotional, and more transferable across users than the specific feature the user asked for — and it's your responsibility as the interviewer to dig for it, not just log the request.

A worked example: "Can you add a CSV export button?"

An APM hears this request in three separate interviews and starts writing a spec for a CSV export button. Before doing that, the APM goes back and asks a past-behavior follow-up: "Walk me through the last time you exported data — what did you do with it after?"

1. User A exports to build a slide for a Monday leadership review. The real job: "help me look credible in front of my boss," not "give me a CSV."
2. User B exports because the in-app filters can't combine two conditions at once. The real job: "let me ask a more specific question of my data," not "give me a CSV."
3. User C exports to hand data to a teammate who doesn't have a login. The real job: "let me share this with someone outside my account," not "give me a CSV."

All three said the same word — "export" — and meant three unrelated things. A CSV button would technically satisfy all three requests while solving none of the underlying jobs well: User A still has to build the slide manually, User B still can't combine filters, and User C still has to explain the file over email.

This is the pattern the Jobs to Be Done community calls the request being a "solution in disguise" — the interviewer's job is to keep asking "what were you trying to get done when you needed that" until the answer stops being a feature and starts being an outcome.

How to keep digging without sounding like an interrogation

• Ask "what happens next" after every answer — it keeps unwinding the causal chain toward the actual goal.
• Ask "what would you have done if that wasn't available" to expose whether the request is load-bearing or a nice-to-have.
• Notice when the same literal request maps to different underlying jobs across users — that's the signal to segment, not to build one generic feature.

Once you can articulate the job in a sentence that contains no product nouns, you've found something real. If the sentence still contains the word "button," "dashboard," or "export," keep digging.

Where a structured tool helps you stay disciplined

Even disciplined PMs drift back into feature-logging under deadline pressure — it's the path of least resistance when you're tired and the backlog is loud. Prodinja's Customer Jobs tool, part of its Studio suite, is designed to walk you through structuring interview notes around Jobs to Be Done and Ulwick-style opportunity scoring instead of a flat feature-request list, with the Forces of Progress framing built into how you tag what you heard.

Rather than a running list of "users asked for X," the tool is built to help you record push, pull, anxiety, and habit signals against each job as you go — so a pattern like the CSV example above surfaces from your own notes instead of getting lost in a spreadsheet. It's one structured way to keep interview discipline over dozens of conversations, not a promise that the tool interviews for you.

Key Takeaways

• Novices interview to confirm; skilled PMs interview to disconfirm — write questions designed to break your hypothesis, not flatter it.
• The Mom Test filters out questions about opinions, hypotheticals, and the future — ask about specific past behavior instead, because people can't lie about what they already did.
• Open, past-behavior questions ("walk me through the last time...") produce narrative evidence; closed, future-facing questions produce polite fiction.
• The Forces of Progress (push, pull, anxiety, habit) reveal why a switching decision does or doesn't happen — a feature list alone only ever captures pull.
• Feature requests are solutions in disguise — keep asking "what were you trying to get done" until the answer contains no product nouns.
• The same literal request can hide different jobs across users — that's a segmentation signal, not a reason to average requests into one generic feature.