Open your feature-request board and sort by votes. The first item has 40. Your support inbox contains six complaints about the same workflow. Sales has heard the request twice this month.
It feels like a pattern. It may be one. But before it becomes a roadmap item, ask a more important question:
Who had a realistic chance to give you this feedback, and who did not?
Customer feedback is not a census. Support tickets, app reviews, community posts, NPS replies, and feature votes all come from people who chose to speak. The people who stayed quiet may have different needs, different habits, or a different relationship with your product.
This is the silent majority problem in customer feedback: the evidence in front of you can be useful while still describing a narrow, self-selected part of your customer base.
The answer is not to ignore your most vocal users. It is to stop confusing what they say with what everyone needs.
The 90–9–1 rule is a warning, not a customer metric
Jakob Nielsen popularised the term participation inequality for a recurring pattern in online communities. In his 90–9–1 shorthand:
- 90% of people observe without contributing;
- 9% contribute occasionally; and
- 1% account for most contributions.
The exact proportions are not a law of nature, and the article is about online communities rather than B2B SaaS research programmes. Do not assume that precisely 1% of your users generate all feedback.
The useful part is the shape of the distribution. Participation is usually uneven. Nielsen cites a study of more than two million Usenet messages in which the most active 3% of posters contributed 25% of messages. He then makes the product-research implication explicit: companies that rely on web postings for customer feedback receive an unrepresentative sample.
Commercial data points in the same direction, but needs careful attribution. Alchemer, a feedback-software vendor, reports that brands often hear from less than 1% of customers through unsolicited feedback. The company does not publish enough methodology on that page to turn the figure into a universal benchmark. Treat it as an example of the scale of the blind spot, not as a number to paste into your board deck.
Your own participation rate could be 0.5%, 5%, or 20%. The decision risk is the same: people who volunteer feedback are unlikely to be a random sample of everyone who uses, abandoned, or considered your product.
The quiet majority is not one group
“Silent majority” sounds like a large group with a shared opinion. It is not.
Some quiet customers are satisfied and have no reason to interrupt their day. Some have built workarounds and no longer notice the friction. Some are new, confused, and not invested enough to complain. Some tried once and left. Others work in roles that never see your feedback portal or are not authorised to speak for the account.
Silence tells you none of this. It means only that a channel produced no statement from that person.
Research on online reviews shows why voluntary feedback can mislead. Nan Hu, Paul Pavlou, and Jie Zhang found that Amazon review scores commonly followed a J-shaped distribution: many positive ratings, fewer negative ratings, and relatively little in the middle. In an experiment where every respondent wrote a review, the distribution was approximately normal. The authors attributed the difference partly to under-reporting bias: people with more polarised views were more likely to report them than people with moderate views.
That does not prove that every SaaS feedback channel over-represents the happiest and angriest users in the same proportion. It does show why voluntary reviews cannot be read as a neutral measure of the whole population.
What passive feedback channels can and cannot tell you
Every feedback channel has a selection mechanism. Knowing that mechanism helps you use the evidence without overstating it.
| Channel | Who is easiest to hear from | Useful for | Weak evidence for |
|---|---|---|---|
| Support tickets | Users motivated enough to seek help | Reproducible problems, severity, support demand | How common a problem is across all users |
| Feature-voting board | Engaged users who know the product and portal | Language, desired outcomes, possible unmet needs | Market-wide priority or willingness to pay |
| App-store or public reviews | Users motivated to post publicly | Reputation risks and memorable experiences | The experience of the moderate middle |
| NPS or email survey | People who notice, open, and complete the request | Directional change within a stable method | Why nonrespondents stayed silent |
| Sales notes | Prospects whose questions reached the sales team | Objections and buying context in that segment | What activated, churned, or non-buying users need |
A feature board is a good example. Suppose 40 of your 800 active users vote for CSV export. You have learned that 40 identifiable users want something they describe as CSV export. You have not learned that the remaining 760 oppose it, support it, understand it, or even saw the board.
The request also names a solution before you understand the problem. Those 40 votes could represent several jobs: sharing data with a non-user, reconciling numbers in a spreadsheet, keeping an audit trail, or feeding another system. One build will not necessarily solve all four.
Janna Bastow’s practitioner critique of feedback voting describes further distortions: power users and survivors are over-represented, early or highly placed ideas attract more attention, visible totals encourage bandwagon effects, and votes strip away commercial context. ProdPad sells an alternative approach, so read the piece as an informed vendor argument rather than independent research. The underlying questions are still worth asking of any voting system.
A higher response rate does not automatically remove bias
It is tempting to solve the problem with volume: send more surveys, offer a bigger incentive, or celebrate a higher response rate.
Response rate matters, but it is not a direct measure of representativeness. Nonresponse bias occurs when respondents and nonrespondents differ in ways that affect the estimate you care about. A low response rate can produce little bias on one question; a higher rate can still leave important groups missing on another.
Robert Groves’s review of household surveys found that nonresponse can, but does not always, create nonresponse bias. Groves and Emilia Peytcheva later examined 59 methodological studies to understand when response rates and bias are related. Michael Davern’s peer-reviewed editorial summarises the practical lesson: response rates are a poor proxy for nonresponse bias.
These studies concern survey estimates, not qualitative interview findings. That distinction matters. An interview sample is usually too small to estimate what percentage of all customers hold a view. Its job is to reveal experiences, mechanisms, and unmet needs that you can investigate further.
So do not claim that “customers want X” because five interviewees mentioned it. Say what you actually know: “Five of eight recently churned admins described the same handover failure.” Then check behavioural or quantitative data before estimating prevalence.
How to hear from people who rarely volunteer feedback
You cannot force every customer to speak. You can design research that gives quieter groups a realistic chance to be heard.
1. Start with the decision, not the channel
Write down the decision you are trying to make. “What should we build next?” is too broad. Better questions include:
- Why do invited teammates fail to complete setup?
- What happens before an active account stops using the reporting workflow?
- Which part of the first-week experience separates retained accounts from cancelled ones?
A clear decision tells you which experiences need to appear in the sample.
2. Build a sample from behaviour
Do not begin with whoever replied last time. Pull segments from product and account data:
- activated and never-activated users;
- frequent, occasional, and inactive users;
- retained, downgraded, and churned accounts;
- people who contacted support and people who never did;
- administrators, daily users, and other relevant roles.
This is not a claim of statistical representativeness. It is deliberate coverage of contrasting experiences.
Teresa Torres calls the qualitative version interviewing for variation: talk to power users and disengaged users, first-time users and experienced users, then choose further variation based on the outcome your team is working towards.
3. Recruit from the missing cells
Create a simple coverage table. Rows are behavioural segments; columns are the roles or account types that matter. Mark whom you have heard from. Recruit next from the emptiest relevant cell.
If all six interviews came from enthusiastic administrators at large accounts, interview number seven should not be another enthusiastic administrator just because they are easy to schedule.
Maren’s guide to recruiting participants for user interviews includes invitation templates and practical ways to reach participants beyond the usual volunteers.
4. Reduce the effort required to participate
Every hoop changes who makes it through. Long forms, fixed meeting times, desktop-only tools, and vague invitations select for people with spare time and high motivation.
Make the invitation specific. Explain why this person’s recent experience matters. Offer an appropriate format and duration. Let people opt into a time that works for them, and automate the recurring invitation where possible. Product Talk’s guidance on customer recruiting for continuous discovery argues that recruitment needs to become a system rather than a fresh weekly scramble.
Lower friction broadens access. It does not eliminate self-selection, so keep recording who still does not respond.
5. Ask for stories, not votes
When someone asks for a feature, move backwards:
- “Tell me about the last time you needed to do that.”
- “What were you trying to get done?”
- “Walk me through what happened.”
- “What did you do instead?”
- “What was the consequence?”
The feature request becomes a lead into a real event. You can then compare that event with stories from users who never voted.
6. Pair conversations with behavioural evidence
Interviews can explain a pattern; they should not manufacture its size. Check the stories against activation events, retention by segment, support volume, workflow completion, and other data you already collect responsibly.
This is also why a high NPS response count cannot carry a roadmap decision on its own. Maren’s article on why NPS is a weak signal for product decisions explains the measurement problem in more detail.
Keep vocal feedback, but label it honestly
Your vocal users are not noise. They may be your most experienced customers, the first people to notice a serious problem, or the clearest source of language for a need.
The mistake is not listening to them. The mistake is changing the label on the evidence:
- Honest: “Our most active feedback-board contributors want bulk editing.”
- Not supported: “Our users want bulk editing.”
- Honest: “Six recent support tickets describe failed CSV imports.”
- Not supported: “CSV imports are the main reason customers churn.”
Treat inbound feedback as a source of hypotheses, examples, and urgent incidents. Test its broader relevance with deliberately recruited conversations and behavioural data.
Where Maren fits
Maren is built for the repeated conversation part of this work. You decide which people and behavioural segments to invite, then share an interview link. Maren runs adaptive text conversations, asks follow-up questions, and brings the transcripts and themes together for review.
That can make it easier to include churned users, people who never activated, and quiet users who will not book a call. It does not make the sample representative, choose the right segments for you, or turn interview themes into prevalence estimates. Those research decisions remain yours.
The principle is simple: the feedback that arrives is evidence from the people who sent it. Learn from it, but do not let its volume or visibility disguise who is missing.