Product Discovery: User Interviews and Framing the Problem First

A university library notices that its study rooms are fully booked every afternoon, yet walking past them at 3 pm shows half of them empty. Within ten minutes of the first meeting someone says, "We need a reminder email before each booking." Everyone nods. The email gets built, and the empty rooms stay empty. Nobody had asked a single student why they booked a room and then did not use it.

Why the first solution is usually a guess

A team that jumps to a solution has quietly decided what the problem is. The reminder email assumes students forget. Maybe they do. Or maybe they book three rooms at once because the booking window is short and rooms vanish quickly, so they hoard. Or the Wi-Fi in that wing is poor and they leave after five minutes. Each of those causes needs a completely different fix, and the email only helps with the first.

Product discovery is the work you do before committing engineering time: finding out who has the problem, how they cope today, and how much it hurts. Its output is not a feature. Its output is a problem statement that the team agrees on, backed by things real people said and did.

The right-hand column still leaves room for many solutions. That is the point: a good problem statement names a person, a situation and a cost, and it does not mention a screen, a button or a technology.

Planning the interviews

Before you talk to anyone, write down the one thing you most want to learn. For the library it might be "What happens between a student booking a room and deciding not to use it?" That single question decides who you recruit and what you ask.

• Recruit people who recently did the thing. Students who booked a room in the last two weeks remember far more than students who booked one last term.
• Include people who gave up as well as people who stayed. Users who quit tell you more than loyal ones.
• Keep each conversation to 30 to 40 minutes. Longer sessions tire both of you and the last half is rarely useful.
• Stop when answers start repeating, not at a magic number. Within one group of similar users you will usually hear the same stories again after a handful of conversations. Then widen to a different group.
• Take notes or record with permission. Say at the start that you are recording to listen better, and delete the recording when you finish.

A sample interview guide

A guide is a list of prompts, not a script to read aloud. Its shape matters more than the exact words: warm-up, a recent real story, the details of that story, and only then any reaction to ideas.

GOAL: understand what happens between booking a room and not using it.
LENGTH: 35 minutes. Recording: ask permission first.

1. Opening (3 min)
   "Thanks for talking to me. I am not testing you and there are no wrong
   answers. I just want to understand how you study. May I record this
   so I can listen instead of typing?"

2. Context (5 min)
   "Tell me about a typical study week for you."
   "Where do you usually study, and why there?"

3. The last time (15 min)  <- the core of the interview
   "Think about the last time you booked a study room. Walk me through it
   from the moment you decided you needed one."
   Follow-ups, one at a time:
   - "What were you trying to get done?"
   - "How did you pick that time slot?"
   - "What happened when the time came?"
   - "Did you use the room? What happened if you did not?"
   - "What did you do instead?"

4. Workarounds (5 min)
   "Have you ever booked a room you did not use? Tell me about the last
   time that happened."
   "Have you ever wanted a room and could not get one? What did you do?"

5. Close (5 min)
   "Is there anything I should have asked and did not?"
   "Who else should I talk to about this?"
   Thank them. Do NOT pitch a solution.

Ask about the past, not the future

People are unreliable at predicting their own behaviour and very reliable at describing what they did yesterday. "Would you use a reminder email?" gets a polite yes from almost everyone, which tells you nothing. "What did you do when your booking time arrived?" gets a story you can learn from.

Use short, neutral follow-ups: "Tell me more about that", "What happened next?" and a few seconds of silence. The skills from Active Listening at Work apply directly: paraphrase to check you understood, and resist filling every pause.

From notes to a framed problem

After each interview, write down facts and direct quotes separately from your interpretations. Then lay the notes from all interviews side by side and look for what several people did or said. One person's complaint is an anecdote. The same story from four people is a pattern.

OBSERVATIONS (what people did or said)
- 5 of 6 had booked a room they did not use in the last month.
- 4 of 6 booked two or three overlapping rooms "to be safe".
- 3 of 6 said bookings open only 48 hours ahead, so "if you wait,
  they are gone".
- 2 of 6 said they cancelled "when I remembered" - none cancelled
  more than an hour before.
- 1 of 6 said the room was too cold; others did not mention it.

PATTERN
Students hold rooms defensively because availability is scarce and
unpredictable, and cancelling feels pointless or is forgotten.

FRAMED PROBLEM
Students who rely on study rooms book more slots than they need because
rooms are hard to get at short notice. The unused slots stay blocked,
so other students cannot get a room even though many sit empty.

NOT YET KNOWN (next questions)
- Would a shorter hold or auto-release reduce hoarding?
- Does it differ near exam weeks?

Notice that the framed problem contains no reminder email. Notice also the "not yet known" list. Good discovery ends with sharper questions as well as answers, and it tells the team honestly how confident you are.

Common mistakes

• Pitching your idea in the interview. Symptom: every participant says "sounds great" and the notes contain no stories. Hold the idea until the last minute, or skip it entirely.
• Only talking to colleagues and friends. Symptom: the findings match what the team already believed. Recruit strangers who match the real user group.
• Asking several questions at once. Symptom: the participant answers only the last one and you lose the rest. Ask one question, then wait.
• Treating one vivid quote as the truth. Symptom: a roadmap built on a single loud story. Count how many people said or did the same thing.
• Recording opinions instead of events. Symptom: notes full of "I think" and "I would". Steer back to "last time".

How this shows up in real projects and interviews

In a real team you will rarely get weeks for discovery. Expect a handful of short calls, support tickets, and data pulled from the product, and a stakeholder who already has a solution in mind. The skill is asking "what problem does this solve, and for whom?" without sounding obstructive. Offering to talk to three users before the next planning meeting usually lands better than arguing.

In product manager interviews, questions like "How would you improve our booking feature?" are tests of exactly this habit. Strong candidates start by choosing a user group and naming a problem, and they say what they would want to learn before proposing anything. Candidates who open with a feature list sound like the library team before the interviews.