Better Products Start with Qualitative Research

Qualitative research isn’t optional in product management. It’s foundational. But most teams treat it like a nice-to-have rather than the competitive advantage it actually is.

Why Most Teams Get Qualitative Research Wrong

Here’s the uncomfortable truth: most product teams don’t do qualitative research. They do checkbox research.

They’ll schedule five user interviews because someone told them that’s what good PMs do. They’ll ask leading questions that confirm their assumptions. They’ll take notes but never revisit them. Then they’ll tick the “user research” box and move on to building whatever they wanted to build anyway.

I’ve done this myself. Early in my career at a insurtech startup, we were convinced that our power users needed nicer UI. We interviewed eight users who all confirmed they wanted nicer UI. Three months of engineering effort later, usage didn’t change.

What went wrong? We’d asked users what they wanted instead of understanding what problems they were trying to solve. When we finally did proper qualitative research, we discovered they didn’t need nicer looking UI. They needed better navigation. The UI conversation was just their best attempt to articulate a deeper frustration.

This is what happens when you treat qualitative research as a validation exercise rather than a discovery tool.

A Framework That Actually Works

After years of making this mistake, I learned about a framework that forces me to stay honest. It’s called the Three Layers approach.

Layer 1: Observe Before You Ask

Start by watching users interact with your product (or your competitor’s) without asking them anything. Use screen recordings. Sit with them during their actual workflow. Take note of hesitations, workarounds, and moments of confusion.

At Spotify, the team working on playlist creation spent weeks just observing how users organised their music. They noticed users creating multiple playlists with overlapping songs, constantly switching between them based on mood or context. This observation led to features like playlist folders and smart shuffle, neither of which users had explicitly asked for.

The key insight: users adapt to broken experiences without even realising they’re doing it. If you ask them what’s wrong, they’ll often say “nothing” because they’ve normalised the friction.

Layer 2: Explore the Problem Space

Once you understand the behaviour, dig into the why. But don’t ask “why” directly. That puts people on the defensive and leads to rationalisations rather than truth.

Instead, ask about the last time they experienced the problem:

Walk me through what happened
What were you trying to accomplish?
What did you try first? What happened next?
How did it make you feel?
What did you do instead?

These questions reveal the emotional and practical context around user behaviour. You’re not gathering feature requests; you’re mapping the territory of user needs.

Layer 3: Test Your Understanding

The final layer is about validating your interpretation, not your solution. Before you build anything, synthesise what you’ve learned and take it back to users.

“Based on our conversations, it seems like the core challenge is X, which leads to Y, and forces you to do Z as a workaround. Is that accurate?”

This conversation is gold. Users will correct your misunderstandings and often reveal even deeper layers of the problem you hadn’t considered.

The Fundamentals That Make or Break Your Research

Good qualitative research isn’t just about asking questions. It’s about creating conditions where truth can emerge.

Sample Size Is a Trap

Forget the “talk to five users” rule you’ve read about. That’s a starting point, not a finish line. The right number is when you stop learning new things. Sometimes that’s three conversations. Sometimes it’s thirty.

For broad product changes affecting multiple user segments, I aim for at least 15-20 conversations. For narrow feature improvements, 5-7 often suffices. For major strategic decisions, I’ll talk to as many users as I can reasonably engage.

The pattern you’re looking for isn’t consensus. It’s recurring themes that explain user behaviour.

The Interview Script Is Just Training Wheels

Many PMs create detailed interview scripts and stick to them. This is a mistake. Your script should be a loose guide, not a straightjacket.

The best insights come from following unexpected threads. If a user mentions something surprising, chase it. Ask them to elaborate. Probe deeper. You can always come back to your script.

Document Everything, But Not How You Think

Most teams either take terrible notes or record everything and never review it. Both approaches waste the value of research.

Here’s what works: take structured notes during the conversation (direct quotes, behaviours, reactions), then immediately after, write a one-page summary answering three questions:

What surprised me?
What contradicted my assumptions?
What problem is this user really trying to solve?

These summaries are what you’ll actually reference. Raw notes and recordings are backup for when you need to verify a specific quote or detail.

Putting It Into Practice

The gap between understanding qualitative research and actually doing it consistently is where most teams fail.

Make It Regular, Not Special

The biggest mistake teams make is treating research as a project phase. It’s not. It’s a continuous practice.

Schedule recurring user conversations like you schedule your standups. Make it part of your rhythm, not an exception to it.

Build a Research Repository

Every conversation, every insight, every observation should go into a centralised, searchable repository. I use Notion with a simple tagging system: user segment, product area, problem type, and insight category.

This transforms research from isolated studies into institutional knowledge. When someone says “we should build feature X,” you can search your repository and instantly pull up five conversations that either validate or contradict that direction.

Involve the Whole Team

Product managers shouldn’t be the only ones doing research. Designers, engineers, and even executives should regularly engage with users.

Arrange for every member of my product team to shadow a customer call or sit in on a user session. Not to present or pitch. Just to listen and observe.

The empathy this builds is irreplaceable. Engineers stop seeing features as tickets and start seeing them as solutions to real human problems. Designers understand edge cases they’d never considered. Executives remember that the numbers on their dashboards represent actual people with actual frustrations.

Measure Your Research Impact

How do you know if your research is working? Track two metrics:

Decision confidence: Before making product decisions, ask yourself on a scale of 1-10 how confident you are. Over time, teams doing good research should see this number trend upward.
Surprise rate: What percentage of what you learn contradicts your assumptions? If it’s under 30%, you’re probably not digging deep enough or you’re suffering from confirmation bias.

Key Takeaways

Observation beats interrogation: Watch what users do before asking what they want. Behaviour reveals truth that words obscure.
The right sample size is when you stop learning: Don’t fixate on specific numbers. Research until patterns emerge and new conversations stop revealing new themes.
Document insights, not transcripts: One-page summaries capturing surprises and contradictions are more valuable than hours of recordings you’ll never review.
Make research continuous, not episodic: Regular weekly conversations keep you connected to user reality better than quarterly research projects.
Involve your entire team in research: Empathy and user understanding shouldn’t be concentrated in the PM role. Spread it across designers, engineers, and leadership.

The Uncomfortable Truth About Research

Here’s what I wish someone had told me earlier: good qualitative research will regularly prove you wrong. If it doesn’t, you’re doing it wrong.

The point isn’t to validate your brilliant ideas. It’s to expose your blind spots before they become expensive mistakes. The best PMs I know actively seek disconfirming evidence. They celebrate when research reveals they’ve misunderstood something important, because that’s much cheaper than discovering it post-launch.

Your job isn’t to be right. It’s to become right through continuous learning. Qualitative research is how you get there.

Have questions or thoughts? Get in touch - I’d love to hear from you!