Why the silent majority creates a measurement problem
Most product demand never becomes a formal feature request. A small group submits posts, upvotes, or tickets. Everyone else complains in passing on calls, mentions a workaround in chat, churns quietly, or never says anything. If you only prioritize what gets submitted, you bias the roadmap toward loud users and easy-to-capture inputs.
The fix is not “ask for more feedback.” It’s to quantify demand from non-submitters by treating every operational system as a partial sensor: support tags, CRM fields, call transcripts, and auto-captured conversations. The goal is a defensible demand model that answers two questions:
- How many accounts likely care about X, even if they never submitted it?
- How valuable are those accounts (revenue, segment, strategic fit)?
Define demand as a latent signal, not a count of requests
“Demand” is not the number of Canny posts, Zendesk tickets, or Intercom conversations. Those are observable events. Real demand is latent: it exists even when it never gets logged.
So quantify it as a probability per account:
- P(account needs X) based on signals you already capture
- Expected value by multiplying that probability by account value (ARR, plan tier, expansion potential)
Even a simple model beats a raw request tally because it makes quiet segments visible.
Inventory your signals and standardize the vocabulary
Before you calculate anything, standardize how you refer to “the thing.” Most orgs have five names for the same request (feature name, internal code name, support macro label, sales objection, and customer phrasing). Build a lightweight taxonomy:
- Theme (high level): “SSO,” “Exports,” “Permissions”
- Use case (job): “Require SSO for all users,” “Scheduled export to S3”
- Constraint (context): “SOC2,” “HIPAA,” “EU data residency”
Then map every system’s labels to that taxonomy. You do not need perfection. You need consistency.
Quantify demand from support tags and conversation metadata
1) Tag coverage score
If support agents tag issues inconsistently, your counts are fiction. Measure tag coverage:
- Coverage = % of relevant conversations that have at least one product/theme tag
- Drift = top themes by month; watch for sudden drops or spikes after workflow changes
Low coverage doesn’t mean you can’t use the data. It means you’ll need a correction factor later.
2) Theme incidence rate per account
Convert conversation counts into an account-level signal:
- Incidence = # of accounts with at least one conversation tagged with theme X in the last N days
- Frequency = average tagged mentions per affected account (helps separate “one-off” from “recurring pain”)
Account-level incidence is usually more stable than raw ticket volume because it reduces the effect of a few power users spamming support.
3) Correct for under-tagging with a calibration sample
Pick a random sample of, say, 200 conversations. Manually label whether theme X appeared. Then estimate:
- Precision: of tagged-as-X, how many truly were X
- Recall: of true-X, how many got tagged
Now you can correct your observed incidence. If recall is 0.6, your true incidence is roughly observed/0.6 (with caveats). This is the easiest way to quantify the silent gap without building a full ML pipeline.
Use CRM fields to expand “who cares” beyond who asked
CRM data is where the silent majority hides: deals lost for missing capability, renewals at risk, and expansion blocked by governance needs.
Look for fields and artifacts that correlate with themes:
- Closed-lost reason (e.g., “No SSO,” “Missing audit logs”)
- Security review status (passed/failed/pending; time-to-complete)
- Plan tier and employee count (enterprise features correlate with org size)
- Competitor mentioned or procurement requirement
Create a simple mapping: if a deal is lost for “No SSO,” the account gets a strong SSO-demand signal even if they never submitted a request.
Auto-captured conversations turn qualitative mentions into countable demand
Call recordings and transcripts (Gong, Zoom, etc.) are where customers speak naturally. The problem is extraction: without structure, it stays anecdotal.
The practical approach is keyword-to-theme mapping plus review loops:
- Define a keyword/phrase set per theme (including customer language, not internal names).
- Capture matches from transcripts and chat logs.
- Classify each match as “true request,” “question,” “objection,” or “unrelated.”
This creates a second incidence dataset that complements support tags. If you want a concrete workflow for this, the same logic applies as in building a keyword alert system for customer calls: start narrow, measure false positives, then expand. Build a keyword alert system for customer calls.
Merge signals into a single demand score per theme
You now have multiple partial lenses. Combine them into a score that is easy to explain and hard to game.
A clean scoring template:
- Support incidence (S): % of active accounts with theme-tagged conversations (corrected for recall)
- CRM pressure (C): weighted count of pipeline/renewal events tied to the theme
- Conversation mentions (M): % of accounts with call/chat transcript mentions (after filtering)
- Revenue weight (R): ARR of affected accounts / total ARR
Then compute something like:
- Demand score = 0.35S + 0.25C + 0.25M + 0.15R
The exact weights matter less than consistency. Pick weights, document them, and revisit quarterly.
Deduplicate themes so the model doesn’t double-count the same pain
The silent majority problem gets worse when you count near-duplicates as separate items. “Bulk export,” “CSV download,” and “Data extract” can split demand and make each look small.
Do a recurring dedupe pass:
- Merge synonyms into a single theme.
- Keep distinct use cases separate only when they drive different solutions.
- Track “parent theme” and “child use case” so reporting stays coherent.
If you need a detailed process for merging large volumes of similar requests, use a structured deduplication playbook rather than ad hoc cleanup. The feedback deduplication playbook for merging 1 000 similar requests.
Operationalize it with one system of record
Once you’ve quantified silent demand, you need one place where product, support, and sales can see it. A feedback platform helps because it links themes to accounts, segments, and revenue, and keeps the discussion attached to the underlying evidence.
This is where canny.io fits naturally: use it as the canonical theme list and decision log, while pulling in signals from support tools, CRM, and call platforms. If you’re using AI-assisted capture and deduplication, you reduce manual tagging overhead and keep the demand model current as new conversations happen.
What to report each month
- Top themes by affected ARR (silent + submitted combined)
- Silent-to-submitted ratio per theme (how much demand you’d miss by only counting posts)
- Segment splits (SMB vs mid-market vs enterprise)
- Trendline (3-month rolling incidence)
- Data quality (tag coverage, transcript false-positive rate)
This keeps prioritization grounded in measurable demand, not whoever spoke last.
Vertical Video
