Voice of the Customer
#What it is
The verbatim definition from my competency model: the ability to leverage user feedback (usability tests, focus groups, surveys, other research) to understand how users engage with the product, make better decisions, and drive meaningful outcomes for the business.
If Fluency with Data is reading what users do, Voice of the Customer is understanding why, and then carrying that understanding into the room where decisions actually get made. Read that last clause again: "drive meaningful outcomes for the business." This is not a competency about being nice to users or collecting feedback for its own sake. It is about converting human truth into better product bets. A PM who runs lovely interviews and changes nothing has failed it, and I say that as someone who has run a few of those interviews.
#The behaviors
My model names two behaviors, and they form a pipeline: gather the truth, then apply it.
User Persona & Journeys Comprehension. Understanding users' goals, contexts, and pain points through research, surveys, and UXR; collaborating with UX and research partners; and identifying unmet needs, the ones users cannot always articulate but feel. This is the gathering half, and the underrated skill in it is collaboration. The best insight usually comes from a PM, a designer, and a researcher synthesizing together, not from a PM doing solo ethnography. The methods are in User Research and Discovery and the artifacts in User Personas and Journey Mapping.
User Insights Application. Translating research into concrete product improvements, advocating user needs in prioritization and design, and letting insight shape strategy. This is the half most people skip, and it is the difference between a PM who has insights and one who uses them, the one who walks into a roadmap debate and says "we're not building that, because I've watched ten users fail at the thing it's distracting us from."
The most dangerous PM is the one who is the target user, because they stop listening. "I know what fans want, I am one." I have done this and been wrong about it. You are a proxy for the user, and proxies drift. Worse is the team that treats Voice of the Customer as "do whatever the loudest customer asked for". Users are brilliant at describing their problems and terrible at designing solutions, so your job is to hear the problem under the feature request, not to take dictation. This is exactly why Jobs To Be Done focuses on the job, not the ask.
#How it shows up by level
| Level | What Voice of the Customer looks like |
|---|---|
| APM | Sits in on interviews and usability tests; takes notes; knows the persona for their feature. |
| PM | Plans and runs research for their area; synthesizes findings; brings the user's voice to their own decisions. |
| Sr PM | Decides what's worth researching; advocates user needs in cross-team prioritization; reshapes the roadmap around an unmet need. |
| Director/VP | Builds the org's research function and a continuous-discovery cadence; makes "talk to users weekly" non-negotiable. |
#How to grow it
- Talk to a customer every week. No exceptions. This is the single highest-leverage habit in the whole area, and it is the spine of Continuous Discovery. Skills atrophy between quarterly research sprints. They compound with weekly contact.
- Separate observation from interpretation in your notes. Write what the user did and said in one column and what you think it means in another. It stops you from hearing only what confirms your roadmap.
- Bring a verbatim quote to every prioritization meeting. Abstractions like "users want speed" lose arguments. A real person's words, "I gave up and used my buddy's app", win them. This is advocacy, the second behavior, in practice.
- Ask "why" three times. The first answer is the feature request. The third is usually the actual job.
#How AI is changing it
AI now synthesizes interviews, support tickets, app-store reviews, and open-text survey responses in hours, surfacing themes a human would take weeks to code by hand. Tools like Dovetail will even draft evidence-backed summaries with citations back to the source. That makes the aggregation of customer voice nearly free. What it cannot do is sit in the discomfort with a confused user, hear the need they never quite say out loud, or decide which of the synthesized themes is worth betting the roadmap on. There is a real danger here too: lean too hard on the summarized voice and you average away the sharp single anecdote that should have reframed everything. More in AI in Discovery and Research.
#Continue Reading
- User Research and Discovery for the methods that produce the voice, and when to use each.
- Continuous Discovery for making customer contact a weekly team habit, not a project.
- Jobs To Be Done for hearing the job under the feature request.
- User Personas and Journey Mapping for the artifacts that carry the voice through the team.
- Fluency with Data for the quantitative partner that tells you what while this tells you why.