Using Voice of Customer in product development — collecting feature requests the right way

"We listen to our customers" — every company says it. In practice, many teams get whiplashed by the requests and lose product direction.

Converting VoC into decision-usable data for product development takes deliberate question design and analysis process.

Don't ship VoC directly as features

Taking "I want feature A" at face value is dangerous, for three reasons:

1. Customers are stating solutions to underlying problems — "want A" is really "have problem B"
2. Loud minority pull — vocal users aren't representative
3. Adding features erodes product coherence — patchwork builds degrade UX

The principle for VoC design: questions that surface "what to solve," not "what to build."

Effective VoC question structure

1. Ask about the Problem

Q1. What part of using our product is the most frustrating / annoying? (open text)

Q2. How often does this happen?
   ○ Daily
   ○ A few times a week
   ○ A few times a month
   ○ Once a month or less

Q3. How much time / friction does it cost when it happens?
   ○ Under 10 min
   ○ Under 30 min
   ○ Under 1 hour
   ○ More

Frequency × time loss = problem impact, quantified.

2. Ask about Solutions (optional)

Q4. What feature or mechanism would solve this? (open text, optional)

Solution suggestions stay optional — only motivated respondents write.

3. Ask about current workarounds

Q5. How do you currently handle this?
   ○ Use a different tool alongside
   ○ Manual workaround
   ○ Live with it
   ○ Other (open text)

Workaround = "live with it" → low priority. Workaround = "pay $30/month for another tool" → high priority.

4. Use case / context

Q6. What specific work situation triggers this? (open text, optional)

Knowing the use case dramatically changes feature prioritization.

Aggregation and prioritization

Theme classification (KJ method)

For 50+ open-text responses:

1. Break into individual statements
2. Group similar statements
3. Name the groups ("data import," "permissions," "notifications")
4. Compare group sizes

That alone reveals theme-level volume.

Frequency × Severity matrix

For each theme:

• Frequency — share of customers experiencing it
• Severity — business impact

Two-axis evaluation; high-high themes are top priority.

Jobs to Be Done framing

Re-interpret requests around "what job is the customer trying to get done":

"I want CSV export"

→ Underlying jobs:

• Build a monthly report
• Move data to another system
• Backups

With the job identified, alternatives (Slack notification, API integration, auto-report) come into scope.

VoC cadence and operation

Existing users (quarterly)

Q1. List 5 improvements you'd want (open text)
Q2. Most important?
Q3. Features you'd "hate to lose"?

Ask both satisfaction and dissatisfaction. "Hate to lose" identifies core features to protect.

Churning users (at churn)

Q1. Primary reason for canceling (multi-select)
Q2. What change would have kept you? (open text, optional)
Q3. If switching to another tool, what tipped the decision? (open text, optional)

Churn reasons are the strongest signal for new-development priority.

New users (30 days post-onboarding)

Q1. What tipped your decision to pick us?
Q2. Using us as expected?
Q3. Anything to improve?

Closing the expectation-vs-reality gap.

VoC analysis: what not to do

❌ Too many questions

15+ questions degrade back-half answer quality; noise increases.

❌ Only "open feedback"

"Just share your thoughts" leaves people unsure what to write; signal density falls.

❌ Only the heavy users' voices

Don't get pulled by the loudest. Always do per-attribute segment analysis.

❌ 100% data-driven decisions

VoC is input, not decision. Filtering through product vision is the dev team's responsibility.

Summary

Four moves that turn VoC into decision-usable data:

1. Center questions on Problem, not Solution
2. Quantify with frequency × severity
3. Theme-classify to aggregate requests
4. Survey churning and new users separately

Repoan's product bug report and feature request templates embed this Problem-first interview structure.

The biggest bottleneck in VoC programs is "can't read all the open text." Repoan's AI report feature (see AI-driven response analysis) auto-classifies open text into themes ("data import," "permissions," "notifications") and auto-generates the Frequency × Severity matrix in the executive summary. 100+ VoC responses → key takeaways in 30 seconds. For bug reports, file attachments capture screenshots alongside text.

Related reading

• Seven ways to collect VoC: VoC collection methods
• The motivation customers can't articulate themselves: discovering customer insight
• Why first-party data is gaining value: AI-era first-party data
• Building hypotheses from n=1: n=1 analysis