Learn to Talk to Users Before You're a PM: A Customer Interview Starter Kit

Practice customer interview skills now by asking about specific past behavior instead of future intentions, and by never pitching an idea mid-conversation. This one habit — extracting what people actually did, not what they say they'd do — is the most transferable, practice-anywhere skill in the entire PM toolkit, and you can start tonight with five willing friends and a notebook.

Quick Answer: Ask what someone did the last time they faced a problem, not what they'd do if a solution existed. Never ask "would you use this?" Extract the job-to-be-done by finding the moment they went looking for a fix, then work backward to the trigger and the tradeoffs they weighed.

Why Customer Interview Skills Matter More Than Any Framework You'll Memorize

Interviewing is the one PM skill that transfers directly from your current job, whatever it is, into your first PM role — you don't need a title to practice asking better questions. Frameworks like RICE or Kano are useless without accurate inputs, and interviews are where those inputs come from. Recruiters can teach you a template in an afternoon; they can't teach you to hear past a polite lie in real time.

Rob Fitzpatrick's book The Mom Test built its entire premise around one uncomfortable truth: almost everyone will lie to you, even your own mother, if you ask them whether they like your idea. Not out of malice — out of politeness, optimism, and a desire to be encouraging. The fix isn't better rapport. It's better questions.

Why this matters before you have a PM title:

1. It costs nothing to practice — you need a willing subject, not a company Slack login.
2. It's the fastest way to build a portfolio story for interviews ("I ran 12 interviews and found...").
3. Bad interviewing habits calcify. Learning to avoid leading questions before you have organizational pressure to "validate" a roadmap is far easier than unlearning it later.
4. It's the foundation skill underneath customer discovery, which underpins everything from writing a job-to-be-done statement to mapping a full customer journey.

If you're earlier in your PM journey and want the fuller roadmap this fits into, the complete guide for aspiring PMs covers where interviewing sits relative to portfolio-building, networking, and interview prep.

The Mom Test Principle: Past Behavior Over Future Promises

The core rule is simple to state and hard to follow under pressure: ask about specific things that already happened, never about hypothetical things that might happen. A person's memory of last Tuesday is data. Their prediction about next year is a guess dressed up as an answer, and guesses are almost always optimistic about products they haven't had to actually pay for or integrate.

Fitzpatrick's framing breaks questions into two buckets. Bad questions ask for opinions, feature requests, or future intentions — "Do you think this is a good idea?" Good questions ask for facts about the past — "Tell me about the last time you tried to solve this."

The table above compares four question shapes you'll reach for instinctively in an interview. Notice the pattern: the weak questions are all about the future and invite a favor to you; the strong ones are all about a specific remembered event and cost the interviewee nothing to answer honestly.

Why People Lie Without Meaning To

Three forces push interview subjects toward false positives, and none of them are the interviewee being dishonest on purpose:

• Politeness: nobody wants to tell a founder or PM their idea is unremarkable to their face.
• Ego: people like to see themselves as early adopters and forward-thinking, so they say yes to novelty.
• Optimism about the future: a hypothetical commitment ("I'd definitely use that") costs nothing right now, so it's cheap to grant.

Past-behavior questions route around all three, because you're not asking them to predict or flatter — you're asking them to recall something that already happened, which is much harder to fake convincingly.

Three Leading Questions to Never Ask

Leading questions smuggle the answer you want into the question itself, and interview subjects almost always oblige. Cut these three from your vocabulary entirely — they generate confident-sounding but worthless data, and they're the fastest way to convince yourself a bad idea is validated.

1. "Would you use a tool that did X?" This is a hypothetical purchase decision with zero real cost attached, so it reliably produces enthusiastic yeses that evaporate the moment a real product asks for money or setup time.
2. "Don't you think it would be great if...?" This bakes your desired answer directly into the grammar of the question. Almost nobody says "no, actually I don't think that."
3. "How much would you pay for this?" Willingness-to-pay stated in the abstract, before a real product exists, is one of the least reliable numbers in product research — people anchor on round numbers or what sounds reasonable, not what they'd actually authorize.

Replace all three with a variant of: "Tell me about the last time [problem] happened. What did you do?" That single reframe does more for interview accuracy than any amount of rapport-building or careful tone.

If you're coming from engineering or design, this reframe might feel unnatural at first — both disciplines train you to solve the problem in front of you, not sit in the discomfort of not proposing anything yet. The engineer-to-PM transition guide and the designer-to-PM transition guide both cover this adjustment in more depth if that's your path in.

A Starter Interview Guide You Can Run Today

A workable starter interview has five parts and takes roughly 20-30 minutes: context-setting, a recent-event walkthrough, workaround excavation, an emotional-weight check, and a close that resists pitching. You don't need a recruiting pipeline or a research budget — you need one willing person and a notebook.

The Five-Part Structure

1. Context first (2 minutes). Ask about their role, their day, or their broader situation before narrowing in. This grounds every later answer in a real context rather than an abstract one.
2. The recent-event walkthrough (10 minutes). "Tell me about the last time [general problem area] came up." Follow the thread wherever it leads — resist steering toward your hypothesis.
3. Workaround excavation (5 minutes). "What did you do about it? What did you try first? What didn't work?" This is where you find existing substitutes — the competition you didn't know you had.
4. Emotional-weight check (5 minutes). "How did that make you feel? How much did that cost you — in time, money, or frustration?" Frustration intensity is a proxy for how much someone would actually change behavior to fix it.
5. A non-pitching close (2-3 minutes). Ask what they'd change if they had a magic wand, then stop. Do not describe your idea. If they ask what you're building, deflect gently: "Still early — I'm mostly trying to understand the problem right now."

A Few Ground Rules Worth Memorizing

• Talk less than 20% of the time. If you're doing more talking than that, you're pitching, not interviewing.
• Silence is a tool. Let a pause sit for three full seconds after their answer — people often add the most useful detail after they think the question is over.
• Take notes verbatim where possible. Paraphrasing in the moment loses the specific language people use, which matters later when you're trying to extract a job-to-be-done.
• Never say your idea out loud until after the interview is over, if at all. The moment you do, every subsequent answer becomes contaminated by their desire to be supportive.

How to Extract a Job-to-Be-Done From a Transcript

Extracting a job-to-be-done means finding the moment in a transcript where the person went looking for a fix, then naming the underlying progress they were trying to make — independent of any specific solution they mention. Clayton Christensen's Jobs to Be Done framework, built on decades of innovation research at Harvard Business School, reframes "what feature do they want" into "what progress are they trying to make in their life."

The mechanical process, applied to a raw transcript:

1. Find the trigger. Scan for the first moment something went wrong or a need became visible — a specific line like "that's when I realized the spreadsheet wasn't going to cut it."
2. Isolate the struggling moment. Look for language of frustration, workaround, or compromise — this is usually where the real job hides, not in a feature request they mention later.
3. Strip out any named solution. If they say "I needed a dashboard," don't take the dashboard as the job — ask what the dashboard was supposed to let them see or decide, and write the job at that level instead.
4. Name the job as a verb-plus-object statement, in their language, not yours: "help me decide which vendor is falling behind before the client notices," not "improve vendor visibility."
5. Check it against Forces of Progress. Bob Moesta and Chris Spiek's Forces of Progress model, an extension of JTBD research, names four forces at play in any switch: the push of the current situation, the pull of a new approach, the anxiety about switching, and the habit of the status quo. A well-extracted job should let you point to evidence of at least the push and the pull somewhere in the transcript.

A Worked Micro-Example

Say a transcript includes: "Honestly, I just kept a spreadsheet of every client update by hand because Slack scrolled too fast and I'd lose track of who needed a follow-up." The named solution is "a spreadsheet." The trigger is "Slack scrolled too fast." The job underneath both isn't "build better spreadsheet software" — it's closer to "help me know which client conversations still need a response before I lose the thread." That distinction is the whole point of the exercise: the spreadsheet is disposable, the job is durable.

For a deeper walkthrough of the full JTBD method beyond extraction — writing job statements, scoring opportunities, and building a job map — the complete guide to jobs-to-be-done goes further than this article's scope.

Practicing With Structure: Where Prodinja Fits

Running interviews well is a skill you build through repetition with structure, not through memorizing a framework once and hoping it sticks under pressure. Prodinja's Customer Jobs Studio is grounded in JTBD and Forces of Progress, and it's designed to give you a structured way to log a real conversation, tag the trigger and struggling moment, and see how a job statement takes shape as you go — a scaffold for the exact extraction process walked through above, while you're still building the underlying instinct yourself.

It won't run the interview for you, and it isn't a substitute for actually talking to a person — no tool is. What it can do is take the pressure off remembering the framework mid-conversation, so you can focus on listening for the trigger instead of mentally cross-referencing a book chapter.

Key Takeaways

• Ask about specific past behavior, never future intentions — memory of last Tuesday beats a prediction about next year every time.
• Cut all three leading-question patterns — "would you use this," "don't you think," and abstract willingness-to-pay all generate false positives.
• Talk less than 20% of the time and let silences sit for a few extra seconds before filling them.
• Never pitch your idea during the interview — the moment you do, every later answer becomes politeness, not data.
• Extract the job by stripping out the named solution and naming the underlying progress in the interviewee's own words.
• Check every extracted job against push, pull, anxiety, and habit from the Forces of Progress model before trusting it.
• You can practice this today, with no title and no company — the skill transfers directly into your first PM role.