Voice-of-Customer Interviews: from customer words to design requirements

A VoC need statement describes a desired outcome or experienced struggle in the customer’s frame: “I need to know the order will arrive before I promise my client a date” — not “add delivery estimates to checkout” (a solution) and not “improve reliability” (a company abstraction).

The craft is elicitation around concrete experience: recent episodes of use, workarounds, moments of delight and abandonment — with probing that turns evaluations into specifics. Feature requests are welcomed and then mined (“what would that let you do?”) for the need underneath.

The foundational study is Griffin and Hauser’s The voice of the customer, whose empirical results set the method’s defaults: roughly 20–30 one-on-one interviews identify the large majority of needs in a product category; one-on-ones are more efficient than focus groups per hour for need surfacing; multiple analysts reading transcripts identify more needs than one; and customers themselves structure needs differently — and more usefully for design — than company experts do.

• Ahead of roadmap and requirements decisions, when the team’s need-list is actually a feature backlog wearing needs’ clothing.
• Entering unfamiliar segments or use contexts, where internal intuition has no standing.
• Feeding structured methods downstream — quality function deployment, Kano studies, journey redesign — all of which consume well-formed need statements.
• Refreshing a stale canon: mature products often run on VoC gathered years ago; needs drift, and the interviews are the audit.
• Not as a substitute for prioritisation research — interviews surface and phrase needs; ranking their importance across a market is survey work built on the interview output.

A field-service software company ran 26 VoC interviews — dispatchers, technicians, and operations managers across customer sizes, plus five churned accounts. Interviews walked yesterday’s schedule, the last emergency re-route, the last time the plan fell apart.

Extraction (two readers per transcript) produced 412 verbatim voices, clustering into 61 distinct needs. The hierarchy’s customer-built structure surprised the product team twice. First, statements the team had filed under “route optimisation” were grouped by customers under keeping promises — “I need to know which jobs I can still make before I call anyone” sat with communication needs, not routing. Second, an entire primary branch existed that the roadmap did not: defending my decisions — technicians and dispatchers needed evidence for pushing back (“I need to show the customer why the 8am slot was impossible”), a need the churned accounts voiced most sharply.

The roadmap consequence was structural: the planned routing-engine investment was re-scoped, and a commitments view (promise tracking, feasibility-at-a-glance, exportable justification) moved up two quarters. Each requirement in the spec carried its voices; when a stakeholder challenged the commitments view months later, the chain from spec line to nine named customers’ words ended the argument in minutes.

• Features transcribed as needs. “Customers need dark mode” — the request is data; the need underneath is what survives into the hierarchy.
• Company language in, company language out. Interview guides built from internal category names harvest back the org chart.
• Single-reader extraction. One analyst’s ear defines the market’s needs; the evidence says use several.
• Expert-built hierarchies for customer-facing decisions. Engineering’s structure optimises for architecture, not for how customers experience the problem space.
• Losing the verbatim. Paraphrased needs (“ease of use concerns”) shed exactly the specificity design needs and traceability requires.
• Interviews as ritual. VoC gathered, deck presented, backlog unchanged — the pipeline’s last step is connection to decisions, and skipping it retroactively wastes the rest.

Customers voice needs within the world they know: VoC reliably maps struggles and outcomes, and reliably misses discontinuous possibilities no experience has taught them to want. It bounds imagination with evidence — pair it with generative design methods, not against them.

Articulate customers are over-heard: interview samples tilt toward the engaged, and needs of silent segments (light users, blocked buyers, the churned who won’t talk) require deliberate, awkward recruiting.

And needs elicitation is not importance measurement: the interviews say what needs exist and how customers phrase and relate them; how much each matters, to which segments, is quantification the interview sample cannot carry.

In-depth interviews supply the underlying craft; VoC specialises it toward need statements and downstream structure.

Jobs-to-be-done interviews reframe elicitation around progress and switching forces — a compatible lens on the same conversations.

Focus groups test concepts and surface shared vocabulary once needs exist; per the founding research, they are the less efficient tool for surfacing needs themselves.

Review and feedback mining harvests unprompted voices at scale — the corpus counterpart to the interview’s depth.

The VoC pipeline’s middle — transcripts to verbatim voices to deduplicated, clustered needs, with traceability intact — is precisely structured coding at corpus scale. Evidano transcribes the interviews, extracts and codes need statements with every voice linked to its speaker and passage, and keeps the requirement-to-quote chain clickable for the arguments that come later; the multiple-reader finding becomes cheap to honour when the second pass costs hours, not weeks.

What stays human is the ear in the room and the mining of requests for the needs beneath them — and the organisational work of letting customers’ structure, rather than the org chart’s, shape what gets built.