Feature Prioritization Research: How to Use Customer Interviews to Decide What to Build Next
Learn how to use customer interviews to prioritize features, validate demand, and make roadmap decisions without overreacting to the loudest request.
Start with problems, not feature ideas
If you want interviews to improve prioritization, do not ask customers which feature to build next. That gives you opinions about solutions, not evidence of demand. Prioritization research works best when it identifies recurring problems, who experiences them, how often they happen, and what they cost the customer or the business.
A better framing is: what job is failing, where is the workflow breaking, and what happens when it does? That gives you opportunity areas before the team debates specific features. If you need a refresher on asking open, non-leading questions, see How to conduct better customer interviews.
Interview for evidence, not enthusiasm
The goal is to measure pain and behavior without turning the conversation into feature pitching. Ask about recent events, current workarounds, and consequences. Past behavior is usually more reliable than future intent.
Use questions like:
- Walk me through the last time this happened.
- What were you trying to get done?
- What made that difficult?
- How often does this come up?
- What do you do today to solve it?
- What happens if you do nothing?
- Who else on your team is affected?
These questions help you translate requests into problems. “We need bulk editing” may actually mean “updating records one by one creates weekly operational risk.” That is much easier to prioritize than a raw feature request.
One practical tip: ask for a specific recent example, not a general opinion. “Tell me about the last time” will usually get you better evidence than “Would you use this?”
Recruit for comparison, not convenience
A common mistake is over-weighting whoever complained most recently: a strategic account, a vocal stakeholder, or a power user with edge-case needs. To avoid that, recruit across segments you may treat differently on the roadmap: new customers, mature accounts, churn risks, admins, daily users, and budget owners.
You do not need a huge sample. You need enough interviews to compare patterns and see whether the same problem repeats. For many prioritization studies, 12-20 interviews across key customer types is enough to expose the main opportunity areas. If you are unsure about sample planning, How Many User Interviews Are Enough? Sample Size Guidelines for Qualitative Research covers the tradeoffs.
Turn interviews into a prioritization input
Interview findings should not replace your prioritization framework. They should improve it. A lightweight model works well because it forces teams to turn raw feedback into explicit criteria.
| Criterion | What to score | What interviews add |
|---|---|---|
| Impact | How much value solving this creates | Severity, downstream consequences, workflow importance |
| Frequency | How often the problem occurs | Repetition across interviews and within workflows |
| Confidence | How sure you are the problem is real and worth solving | Consistency across segments, clarity of evidence |
| Effort | Cost and complexity to build | Not from interviews; comes from design and engineering |
This can sit alongside RICE, WSJF, or a simple impact/effort model. The key is that interviews inform impact, frequency, and confidence instead of leaving them as guesses.
A simple output format works well in practice: problem statement, affected segment, evidence quotes, current workaround, estimated frequency, and open questions. That gives product, design, and engineering something concrete to debate.
Validate prevalence after interviews
Interviews are strong for understanding problems deeply. They are weaker at estimating how common a problem is across your full customer base. Once interviews identify the top 2-3 opportunity areas, use a short survey, product usage data, support tickets, or sales notes to test prevalence.
That combination helps you avoid two common failures: building for a vivid anecdote, or ignoring an important issue because only a few customers explained it clearly. For more on choosing methods, read When to Use Surveys vs Interviews for Product Decisions.
Make roadmap debates more defensible
Good prioritization research does not tell you exactly what to build. It gives you a stronger basis for deciding. A strong output is not a list of requested features. It is a ranked set of customer problems with clear evidence: who experiences them, how often, how painful they are, what customers do now, and where confidence is still low.
That changes the roadmap conversation. Instead of saying, “Three customers asked for this,” you can say, “This workflow breaks weekly for operations teams, creates manual QA work, and showed up in 9 of 14 interviews across two segments.” That is the kind of evidence that helps teams choose what to build next for the right reasons.