Voice of the Customer

What is Voice of the Customer?

Voice of the Customer (VoC) is the practice of systematically capturing what customers say in their own words, and turning it into structured input that shapes product decisions. It is not a single survey or a single interview. It is the discipline of turning what customers say into organized, ranked input that a team can actually use to decide what to build next, which is why VoC sits inside User Feedback as one of its most formalized methods.

The term comes out of quality engineering, not marketing. Quality Function Deployment (QFD), the manufacturing methodology that VoC was built to feed, traces to Yoji Akao's work in Japan starting in 1966, with the House of Quality matrix first applied at Mitsubishi Heavy Industries in 1972. VoC as a named, standalone discipline is commonly attributed to Abbie Griffin and John Hauser's 1993 Marketing Science paper "The Voice of the Customer" (Vol. 12, No. 1, pp. 1-27), which laid out VoC as three sequential tasks: identifying customer needs from raw interview data, arraying those needs into a multi-level hierarchy of needs, then determining which needs matter most. So there are two lineages worth separating: QFD is the older manufacturing framework, and Griffin and Hauser's paper is what gave the "voice of the customer" component its own name and method inside that framework. Produck uses the term the way Griffin and Hauser defined it, as a structured pipeline from raw customer words to ranked needs, not as a loose synonym for "customer feedback."

That distinction matters in practice. A support inbox full of quotes is not VoC. VoC only exists once someone has pulled needs out of that raw language, organized them, and ranked them against each other.

Why it matters for product-market fit

VoC is a method for the Listen stage of Produck's loop: Listen, Diagnose, Decide, Ship. Most teams already do a version of Listen. They run a User Interview or two and read support tickets, then call it done. What VoC adds is the structuring step Griffin and Hauser described: turning scattered verbatims into a ranked hierarchy of needs, before anyone tries to decide what to build.

This is exactly where teams lose the thread. As we've written about in why most teams have a loop problem, not a PMF problem, the failure mode isn't a lack of listening, it's that the signal captured during Listen never survives structuring, so Diagnose and Decide happen on vibes instead of on a real hierarchy of customer need. A team can run twenty interviews and still walk into a roadmap meeting arguing from memory rather than from a ranked list.

Produck's Listen stage is built to do this structuring automatically: feedback comes in from interviews, support, sales calls, and app reviews, and it gets organized into named needs rather than a pile of quotes. That structured output is also what makes Diagnose possible, because you can't diagnose a pattern you haven't organized yet. It is also why VoC pairs naturally with quantitative signals like Net Promoter Score: NPS tells you how customers feel in aggregate, VoC tells you what specifically is driving that number, in their own words.

When it works, and when it doesn't

It works when:

• You're gathering verbatims from more than one source, so the hierarchy of needs isn't shaped by whichever channel happens to be loudest that month.
• Someone owns the structuring step. Raw quotes sitting in a spreadsheet are not VoC until a person or a system has grouped and ranked them.
• The needs get revisited over time. A hierarchy built once and never updated goes stale the moment your customer base shifts.
• The output actually reaches the people deciding what to build. VoC that lives in a research team's archive never touches the roadmap.

It falls short when:

• Teams collect quotes and stop there, treating a folder of verbatims as the deliverable instead of the input to a structuring process.
• The sample is thin. A handful of interviews with your loudest users produces a hierarchy that looks confident and isn't.
• It's run as a one-time project instead of a standing habit, so the needs hierarchy describes last year's customer, not this year's.
• The ranking step gets skipped, so every need looks equally urgent and priority calls get made on whoever spoke last in the meeting.

How to apply it

1. Pull raw verbatims from at least two channels this week: interview transcripts, support tickets, sales call notes, and app reviews are the easiest starting points.
2. Extract discrete customer needs from the language. A need is what the customer is trying to accomplish, not the feature they asked for.
3. Group similar needs into a hierarchy. Most teams find a three-tier hierarchy works well, moving from broad themes down to the exact phrasing customers used.
4. Rank the needs. Frequency of mention is a reasonable starting proxy, but weight it against how painful or costly the need is when unmet.
5. Bring the ranked hierarchy into your Decide conversation as the input, not a supporting slide. If the roadmap discussion isn't referencing it directly, the structuring step didn't do its job.
6. Repeat on a cadence, at least quarterly, so the hierarchy tracks your customer base as it changes rather than freezing a snapshot from six months ago.