The Interview That Produces One Good Quote
Most discovery interviews follow a similar arc. The PM asks open questions. The customer talks. There are a few moments where something specific and useful gets said. The rest of the time is warm-up, tangents, general feelings about the product category, and polite agreement. The PM leaves thinking it went well. The notes from the call are a mix of verbatim quotes, paraphrases, and context that seemed important in the moment.
Two weeks later, those notes are not particularly useful. The one good quote does not tell you whether it represents a pattern or an outlier. The context has already faded. And if you try to compare notes from three different interviews, you quickly realize you captured different things from each one because you were listening for different things each time.
The problem is not that customers are hard to interview. It is that "listen and take notes" is not a signal extraction method. It is a transcription method, and a lossy one at that.
What a Signal Actually Is
Before you can extract signals, you need a working definition of what counts as one. In a product context, a signal from a customer interview has three components: a specific workflow description (not a general preference), a friction point within that workflow (something that slows them down, confuses them, or causes them to do extra work), and relevance to a product decision you could actually make.
The last point is the most commonly overlooked. A customer saying "it would be nice if everything was faster" is not a signal. A customer saying "when I export a filtered view with more than 500 rows, the download takes three minutes and my browser freezes sometimes" is a signal. One is a preference. The other points to a specific technical behavior you can investigate, reproduce, and fix.
Signals also have a directionality. They either point toward something your product should do differently, or they confirm that something your product does is working well enough that customers depend on it. Both are useful. The confirmation signals often get ignored in favor of the problem signals, but knowing what customers rely on is critical for making safe changes.
The Listening Mode Problem
Interviews tend to produce vague notes because of a specific listening failure: the PM is responding to the customer's narrative instead of probing the customer's workflow. When a customer says "I spend a lot of time cleaning up reports," the natural response is to note that down as a pain point. The more productive response is to pause on that statement and ask exactly what "cleaning up" means in their workflow.
"What does that look like? Walk me through what you actually do." This question, or some version of it, converts a vague complaint into a specific workflow description. Often the workflow description reveals that the complaint is about something entirely different from what the PM initially assumed. "Cleaning up reports" might mean reformatting columns every time because the export does not respect their saved settings. Or it might mean manually merging two exports because the filtering does not allow cross-type comparisons. Those are very different product problems.
The interviewing discipline that separates useful discovery from pleasant conversation is this: never leave a customer statement that contains an implicit workflow description without making it explicit. Every time a customer says "I have to" or "I end up" or "it takes forever to," that is an invitation to ask what they are actually doing, step by step.
Structured Capture During the Call
Taking better notes starts before the interview. A simple capture template with three columns changes what you notice: workflow step, friction point, product area. You are not trying to write down everything the customer says. You are scanning for rows that can fill in that template.
This sounds mechanical, but in practice it sharpens your attention. When you are not trying to transcribe the whole conversation, you notice more. You start to hear the specific language customers use for their workflows. You catch the moment when a customer mentions a workaround, which is almost always a signal worth probing.
Workarounds deserve special attention. A customer who has built a workaround for something your product should handle natively is telling you several things at once: the native behavior is insufficient, the need is real enough that they invested time in working around it, and they have probably accepted that your product is not going to solve it anytime soon. That last part is worth interrogating. Asking why they built the workaround instead of asking you about it often surfaces something about how customers perceive your responsiveness to feedback.
Making Signals Comparable Across Interviews
The value of a single interview is limited. The value of a consistent signal across five interviews is substantial. Getting there requires a tagging layer that you apply after each interview, while the memory is fresh.
A simple taxonomy works better than a complex one. Product area tags (export, filtering, integrations, reporting) plus a friction type (performance, missing functionality, confusing behavior, workflow gap) gives you enough structure to run a simple frequency count across interviews. How many customers mentioned export friction in the last quarter? That question should take two minutes to answer, not two hours.
The teams that build this well do not use elaborate systems. They use a spreadsheet or a lightweight tagging tool, applied consistently after every interview. The consistency matters more than the tool. If you tag three interviews and skip the next two because you were busy, your frequency data is unreliable. The discipline of tagging every interview is what converts a research practice into a decision-making input.
What Good Signal Extraction Does Not Mean
Structured signal extraction does not mean treating customer interviews as requirements-gathering sessions. Customers describe problems; product teams design solutions. A customer who says they need a CSV export might actually need a better way to share data with their operations team, and a CSV export is just the most familiar solution they can imagine. The signal is the need to share structured data. The solution is your call to make.
It also does not mean every signal becomes a backlog item. The purpose of extracting signals is to make patterns visible so that prioritization decisions are based on breadth of need, not recency or volume of the loudest voice. A signal that five customers described gets weighed against one that only one customer described. That comparison only exists if you have been extracting and tagging consistently.
