User interviews are the highest-leverage research tool a PM has - and the most commonly botched. The failure mode is almost never effort. It is asking questions that produce polite, useless answers: 'Would you use this?' 'Do you like it?' 'How much would you pay?' People are generous and imaginative in interviews, and their speculation is nearly worthless.
The one rule that fixes most interviews
Ask about the past, not the future. What people did is data. What they say they would do is fiction.
Instead of 'would you use a budgeting feature?', ask 'tell me about the last time you tried to work out where your money went'. The first question invites politeness; the second surfaces actual behaviour - the workaround spreadsheet, the abandoned app, the monthly panic - which is where real product opportunities live.
A simple interview structure
- Open with context (5 minutes): who they are, how the relevant part of their life or work is set up. Easy questions build comfort.
- Dig into recent, specific episodes (20 minutes): 'walk me through the last time you...'. Anchor everything to real events. When they generalise - 'I usually...' - pull them back to a specific instance.
- Probe the pain (10 minutes): what was frustrating, what did it cost them, what have they already tried? Existing workarounds are the strongest evidence of a problem worth solving.
- Close open-ended (5 minutes): 'what should I have asked about that I didn't?' regularly produces the best insight of the session.
Techniques that separate good interviewers
- Silence. After an answer, wait three seconds. The elaboration that follows is often more honest than the first response.
- Follow the emotion. When their tone shifts - frustration, embarrassment, pride - ask about that moment. Feelings mark the events that matter.
- Ask 'how' and 'what', rarely 'why'. 'Why did you do that?' triggers rationalisation; 'what were you trying to get done?' triggers recall.
- Never pitch. The moment you explain your idea, the interview becomes a performance of encouragement. Validate the problem; keep the solution out of the room.
- Write down exact quotes. 'I just gave up and rang my mum' will move a stakeholder more than any summary of it.
Making sense of what you heard
Insight lives in patterns, not individual conversations. After five or six interviews, lay your notes side by side and look for repeated behaviours, repeated workarounds, and repeated language. One person's complaint is an anecdote; four people independently describing the same workaround is a problem statement writing itself.
And hold your conclusions loosely. Interviews tell you what problems are real and how people experience them - they do not tell you what to build. That next step is where product judgement takes over: sizing the problem, weighing options, and deciding what to do first.