Qualitative research for product managers: from customer calls to product decisions

Qualitative research for product managers means running structured customer interviews, coding the findings systematically, and translating what you heard into concrete product decisions. The goal is not academic rigour for its own sake but actionable clarity: why users behave as they do, what problems actually hurt, and which solutions are worth building.

Why do PMs get qualitative research wrong?

More than 60% of product organisations report having product managers who do not talk to customers regularly, spending their time instead on PRDs, design files, and sprint planning. Those who do run interviews often stop short of the analysis step. They come away with vague impressions, a few sticky-note clusters, and the feeling that they "know what the customer needs" without being able to say precisely why.

The result is predictable. CB Insights research found that 42% of startups fail because they build products that do not solve a meaningful market problem. In nearly every documented case, that information existed before the product was built. The customers could have said so. Nobody asked in a way that produced a usable answer.

Three failure modes appear repeatedly:

Running interviews as demos. A PM books a customer call, spends thirty minutes showing the new feature, and calls it research. Feedback is positive because people are polite. The PM hears what they expected to hear.

Treating notes as insights. After the call, raw notes go into a Notion doc and stay there. The PM has data; they do not have analysis. The difference matters enormously in a team setting, where decisions have to be justified.

Skipping synthesis. Most PMs talk to customers one at a time, in serial, and form impressions incrementally. By interview ten, the early interviews have faded. No one looks across the full set for patterns that only emerge at scale.

Good qualitative research for PMs fixes all three. It is not about adding academic ceremony to your discovery process. It is about getting findings you can actually act on.

What kind of qualitative research do PMs actually need?

The academic literature describes many qualitative methods: ethnography, discourse analysis, phenomenology, grounded theory. Most PMs need two.

Customer discovery interviews are the workhorse. Semi-structured conversations, forty to sixty minutes each, focused on specific problems or use-case contexts. You are not testing a prototype; you are understanding the customer's current world. See our guide to customer discovery interviews for a full treatment.

Jobs-to-be-done (JTBD) interviews go deeper into motivation. Rather than asking what features customers want, you explore what "job" they are hiring the product to do and what they were using before. This is especially powerful for positioning and for evaluating whether you are solving the right problem. We cover the full JTBD methodology in a dedicated guide.

A third method worth knowing is usability research, where you watch users attempt tasks with a product. That is closer to UX research than customer discovery, and it is useful for different decisions. If you work alongside a UX researcher, you will often hand off to this method once you have defined the problem clearly enough.

For product managers specifically, the most critical skill is not choosing the right methodology. It is running a discovery interview well and then analysing the findings systematically enough to make a decision.

How to design good customer discovery interviews: 5 rules

Teresa Torres, author of Continuous Discovery Habits, recommends that product teams conduct at least one customer interview per week as a standing cadence. The research argument is straightforward: the more interviews you run, the faster your understanding compounds. The practical problem is that most PMs treat each interview as a standalone event rather than a running programme.

These five rules apply to discovery interviews specifically.

1. Interview about the past, not the future. "What features would you like to see?" is a useless question. People are bad at predicting their own behaviour. Instead, ask: "Tell me about the last time you tried to do X." Specific past events generate concrete, trustworthy data. General future intentions generate wishful thinking.

2. Write an interview guide, not a script. A guide gives you topic areas and a handful of anchor questions. A script makes you a bad listener because you are watching for the next question instead of following the thread. Our post on how to write a perfect interview guide covers structure, question types, and common mistakes.

3. Recruit for the problem, not the product. If you are trying to understand why users churn, recruit recent churners. If you are validating a new use case, recruit people who currently solve that problem some other way, not your existing customers. Convenience sampling (talking only to happy customers who respond to emails) is one of the most persistent biases in PM research.

4. Use the "tell me more" technique ruthlessly. The most common mistake in customer interviews is accepting the first answer. A customer says: "The onboarding was confusing." Most PMs move to the next question. Effective interviewers dig in: "Which part? What did you expect to happen? What did you do instead?" The insight is almost always in the third or fourth layer, not the surface response.

5. Record and transcribe everything. Notes taken during an interview are a lossy representation of the conversation. You are half-listening, half-writing, and you are filtering unconsciously towards what confirms your priors. A recording, transcribed and searchable, gives you the raw material for real analysis. Most modern call tools (Zoom, Google Meet, Teams) offer built-in transcription.

How to analyse fast: from transcripts to product decisions in 2 hours

Manual qualitative coding takes significantly longer than most PMs expect. Research suggests that for every hour of interview, manual analysis takes between three and eight hours, including transcription, coding, and theme development. A small study of ten one-hour interviews can consume forty to eighty hours of total analysis time. For a PM juggling a sprint cycle, that is not a viable cadence.

The practical answer is not to skip analysis. It is to analyse differently.

Here is a two-hour workflow that gets you from a batch of transcripts to a summary you can take to your team.

Step 1: Define your analysis frame before you start (15 minutes). Decide what questions you are trying to answer. "What barriers prevent trial users from activating?" is a good frame. "What did people say?" is not. Your frame drives the coding. Deductive coding (applying a pre-built framework) is much faster than inductive coding from scratch, and for most PM decisions it is good enough. See the full guide on how to code qualitative data.

Step 2: Code the transcripts for themes (45 minutes). Read each transcript once, tagging excerpts that relate to your frame. You are not trying to capture everything; you are pulling the signal relevant to your question. For ten thirty-minute interviews, this step should take thirty to forty-five minutes with a consistent coding frame. Tools like Skimle automate this step, running structured AI analysis across your full transcript set and surfacing relevant excerpts by theme, which typically reduces this phase from hours to minutes.

Step 3: Synthesise across transcripts (30 minutes). Look at all excerpts coded to each theme. What is the pattern? Where is there divergence? Which pain points appeared in most interviews versus a vocal minority? This is the step most PMs skip, and it is where the real insight lives. Our guide to synthesising user research covers frameworks for this.

Step 4: Draft your findings document (30 minutes). Write up the key findings in plain language. Three to five points, each backed by specific quotes. This is the deliverable. Not a hundred-page report, a one-page summary with evidence. If you can present it to an engineer in ten minutes and they understand what to build next, you have done your job.

The total: two hours for a batch of ten interviews, if you work systematically. Without structure, the same dataset can absorb a full week without producing a usable answer.

Turning qualitative insights into roadmap decisions

This is where most PM qualitative research breaks down. The interviews get done. The notes exist. But the findings never make it to the roadmap in any meaningful way because there is no clear pathway from "customers said X" to "we should build Y."

Four practices that close the gap:

Anchor findings to problems, not features. The most common mistake is to translate what customers said directly into feature requests. If ten customers said "I wish the export was faster," the finding is not "add faster export." The finding is "export speed is a significant friction point in the workflow, particularly for users doing X." That framing opens up a wider solution space and prevents premature convergence on a specific implementation.

Quantify the qualitative where you can. "Several customers mentioned" is weak. "Seven out of ten customers described export speed as a blocker" is actionable. You do not need statistical significance for discovery research. You need enough data to make a confident directional decision. Counting how many interviews surfaced a theme is a simple way to add weight to qualitative findings. This is exactly what analysing customer interviews at scale enables.

Map findings to the customer journey. Where in the workflow does the pain occur? Onboarding, daily use, or advanced configuration? Pain at different stages of the journey has different implications for what to fix and when. A barrier in the first ten minutes of use matters more than an efficiency complaint from power users, because it affects more people.

Link to metrics you already track. If your activation rate is low and interviews reveal that users cannot understand the value proposition during onboarding, you have connected a qualitative finding to a quantitative signal. That connection makes the finding persuasive to stakeholders who might otherwise dismiss "what customers said" as anecdotal. Our post on presenting qualitative research findings to executives goes deeper on this.

3 tools PMs use for qualitative research

Tool	Best for	Limitation
Dovetail	UX research teams with existing research operations	Expensive for solo PMs; positioned for UX rather than product discovery
Notion / Google Docs	Small teams, quick capture	No analysis capability; a storage tool, not a research tool
Skimle	PMs running regular customer interview batches who need fast, structured analysis	Built for analysis depth; less suited to lightweight usability testing

Dovetail is the best-known research repository in the UX space. It handles tagging, highlighting, and sharing clips well. For teams that already have a research operations function, it fits naturally. For a PM running discovery on their own, the cost and the UX-first design can feel like a mismatch. We cover Dovetail alternatives in detail including pricing comparisons and use-case fit.

Notion and Google Docs are where most PMs actually store their research today. They are fast to set up and everyone already has access. The problem is that they are document tools, not analysis tools. You can read your notes; you cannot find patterns across fifty transcripts.

Skimle is purpose-built for structured qualitative analysis. You upload transcripts, define a coding framework (or let Skimle generate one inductively), and get a structured breakdown of themes and excerpts across your full dataset. For a PM who runs ten to twenty customer interviews per quarter, it compresses the analysis phase from days to hours. Interview analysis software in 2026 varies widely in focus and price; Skimle sits at the analysis-depth end of the spectrum rather than the lightweight tagging end.

One underused capability for product teams is Skimle Ask, which enables AI-powered interviews at scale. Rather than booking forty customer calls, you can deploy an AI interviewer that follows a structured guide and adapts to responses, collecting rich qualitative data from hundreds of users. The output feeds directly into Skimle's analysis engine. For teams building a customer advisory board or running continuous discovery programmes, this changes the economics of qualitative research significantly.

How to build a qualitative research habit without a full UX team

Most PMs operate without dedicated UX research support. They are expected to ship features, manage stakeholders, and somehow find time to understand customers. Here is how to make qualitative research sustainable in that context.

Batch your interviews. Running two or three interviews in a single morning is more efficient than spacing them across the week. You stay in "listening mode" and the patterns are easier to spot when the conversations are fresh.

Use a shared research repository. Whether you use a dedicated tool or a structured Notion database, make sure your findings are accessible to the team. Research that lives in one PM's head is not research; it is intuition. A research repository that people actually use is the infrastructure for a learning organisation.

Involve engineers and designers in interviews. When an engineer hears a customer describe the problem in their own words, the resulting solution is usually better than anything a PM could specify. Regular customer exposure builds shared understanding that no document can replicate.

Create a research calendar, not a research project. Qualitative research should not be a one-off sprint before a big feature. It should be a continuous cadence: ten interviews per quarter is a minimum to stay calibrated on fast-moving products. Torres's weekly interview habit is aspirational for most teams, but it represents the right direction of travel.

Frequently asked questions

How many customer interviews does a PM need to run?

For discovery research, ten to fifteen interviews are enough to identify the major themes around a specific problem or use case. You will start hearing the same issues repeated after six or seven interviews, a phenomenon researchers call data saturation. The goal is not a large sample; it is consistent themes across a meaningful slice of your target segment. For narrowly scoped problems, five to eight interviews can be sufficient. For broad discovery across a new market, you may need twenty to thirty.

What is the difference between customer discovery interviews and usability testing?

Customer discovery interviews explore problems, context, and motivation. You are trying to understand the customer's world before you have a solution. Usability testing evaluates a specific product or prototype. You watch users attempt tasks and identify where they get stuck. PMs tend to need both, but at different stages: discovery before you commit to a direction, usability testing once you have a prototype to test.

How do you analyse customer interviews when you only have notes, not transcripts?

Notes are lossy, but they are workable. Treat each set of interview notes as a document and apply the same coding framework you would to a transcript. Be aware that your notes already reflect your interpretive biases (you wrote down what seemed important at the time), so weight your findings accordingly. For future interviews, record and transcribe. The additional clarity is worth the setup time.

How do you handle contradictory findings across interviews?

Contradictions are data, not problems. If some customers say the product is too complex and others say it is not powerful enough, that is a segmentation signal. It tells you that you are talking to two different user populations with different needs. Map the contradictory findings back to participant attributes (role, company size, use case, tenure) and see if the divergence correlates with a meaningful segment. Often it does.

Can qualitative research replace metrics for product decisions?

No. Qualitative research tells you why users behave as they do; metrics tell you what they do at scale. The combination is what produces confident decisions. Use qualitative research to explain the patterns you see in data (why is activation low?) and to explore territory where you do not yet have data (what would a new user segment need?). Neither source is sufficient on its own.

Ready to run faster, more rigorous customer research? Try Skimle for free and analyse your next batch of customer interviews in a fraction of the time it takes manually.

Want to go deeper? Read our guides on how to analyse customer interviews at scale, customer discovery interviews, and how to synthesise user research.

About the authors

Henri Schildt is a Professor of Strategy at Aalto University School of Business and co-founder of Skimle. He has published over a dozen peer-reviewed articles using qualitative methods, including work in Academy of Management Journal, Organisation Science, and Strategic Management Journal. His research focuses on organisational strategy, innovation, and qualitative methodology. Google Scholar profile

Olli Salo is a former Partner at McKinsey & Company where he spent 18 years helping clients understand the markets and themselves, develop winning strategies and improve their operating models. He has done over 1000 client interviews and published over 10 articles on McKinsey.com and beyond. LinkedIn profile

Qualitative research for product managers: from customer calls to product decisions

Product managers run customer interviews but rarely analyse them well. Here's a practical guide to turning qualitative research into clear product decisions.