user-feedback-aggregation

User Feedback Aggregation

A senior product leader's playbook for collecting and synthesizing user feedback across channels into continuous decision signal. Support tickets, NPS surveys, in-app feedback, sales calls, social mentions, customer councils, all aggregated into a triaged synthesis the team can actually act on.

Most product programs accumulate feedback they do not use. Channels overflow with submissions; CSAT and NPS scores get reported in monthly updates; customer council meetings produce notes that nobody references. The loudest voices steer roadmap because they are easiest to hear; quieter signal that matters more goes unaddressed.

This skill is the triage discipline that turns continuous feedback streams into continuous decision signal. Each channel surfaces different signal at different reliability. Each signal type warrants different weight in different decisions. The team that aggregates feedback well makes better decisions; the team that drowns in feedback makes the same decisions they would have made without the feedback.

Different from discovery-research-synthesis, which covers one-off research projects (a defined batch of artifacts, a defined synthesis output). This skill covers the always-on streams: feedback that arrives every day, every week, every month, and that the team must continuously triage and synthesize.

The voice is the senior product leader who has watched feedback aggregation work and watched it fail. Concrete, opinionated about which channels matter for which decisions, willing to call out where loudest-voice or averaged-noise patterns produce bad outcomes.

When to use this skill: building a feedback aggregation system, auditing a feedback program that is producing volume without decisions, deciding which feedback channels matter for the program, or designing the synthesis cadence for ongoing feedback streams.

What this skill is for

This skill spans continuous user-feedback aggregation. The PM-skill distinction:

• discovery-research-synthesis is one-off discovery research. Defined batch, defined output.
• user-feedback-aggregation (this skill) is ongoing feedback streams. Always-on channels needing continuous synthesis.
• beta-program-management covers feedback specific to beta participants. This skill spans all users continuously.
• ux-research is structured research projects. This skill is unsolicited feedback.
• pm-spec-writing is downstream: specs use feedback aggregation as input.
• roadmap-planning is downstream: roadmap uses feedback patterns as input.

The audience: senior PMs, product directors, customer success and support managers running feedback programs, in-house teams aggregating feedback across many channels.

What is not in scope: structured discovery research (covered by discovery-research-synthesis); beta-specific feedback (covered by beta-program-management); commissioned research projects (covered by ux-research).

Loudest-voice vs averaged-noise vs triaged-synthesis

The keystone framing.

Loudest-voice. Whoever complains the most gets their feature. Vocal minorities steer roadmap. Silent majority's needs go unaddressed. The squeaky-wheel anti-pattern. Cost: the program optimizes for the loudest customer, not for the broader customer base; quieter customers leave for products that addressed their needs.

Averaged-noise. Every signal weighted equally. 1 enterprise customer's feedback = 1 trial user's feedback = 1 angry social mention. Volume aggregates without weighting; noise drowns signal. Cost: the team cannot tell which feedback matters; decisions get made on aggregate sentiment that does not reflect the customers who matter most for the strategy.

Triaged-synthesis. Signal weighted by source quality, frequency, and decision relevance. Different feedback types have different weights for different decisions. The team that does this well makes decisions grounded in the signal that matters; the team that does it badly defaults to loudest-voice or averaged-noise.

The litmus test. Pick a recent product decision. Can the team explain why specific feedback signals weighted into the decision the way they did? If yes, the aggregation is triaged. If the answer is "we heard a lot about this from customers," without specificity about which customers in which contexts, the aggregation is loudest-voice or averaged-noise.

Feedback channels and what each surfaces

Six common channels. Each surfaces different signal at different reliability.

Support tickets. What users hit when things break or confuse them. High volume, high signal-on-friction, biased toward users willing to contact support.

NPS surveys. Aggregate sentiment toward the product or specific features. Periodic, quantitative-with-comments, bias toward respondents who feel strongly (positive or negative).

In-app feedback. Friction at the moment users encounter it. Contextualized to specific product moments; volume varies; quality varies.

Sales calls. Pre-purchase prospect perspective. Objections, competitive mentions, gaps between marketing and what sales leads with. Bias toward prospects, not existing customers.

Social mentions. Public commentary about the product. Real-time but biased toward customers willing to post publicly; often skews negative or hyper-positive.

Customer councils. Curated panels of customers in structured forums. High-quality feedback from selected customers; bias depends on selection.

Each channel has strengths and weaknesses. Strong feedback aggregation triangulates across channels rather than relying on one.

Detail in [references/channel-types-and-what-each-surfaces.md](references/channel-types-and-what-each-surfaces.md).

Channel-source weighting

The discipline that distinguishes triaged-synthesis from averaged-noise.

The principle. Different sources warrant different weights in different decisions.

Worked example. A decision about whether to prioritize an enterprise admin feature.

• Sales call data showing enterprise prospects asking for the feature: high weight (the decision is about enterprise; the source matches).
• Support ticket data from enterprise customers: high weight (existing enterprise customers' friction is directly relevant).
• NPS data from small-team customers: low weight (the feature is not for them; their satisfaction is not load-bearing for the decision).
• Social mentions: variable weight (signal depends on who is mentioning; enterprise practitioners on LinkedIn carry more weight than anonymous trial users on social).

The discipline. For each decision, identify which sources matter most. Weight accordingly. Volume from low-weight sources should not override signal from high-weight sources.

The averaged-noise failure. Decisions made on aggregate volume regardless of source. The enterprise admin feature gets deprioritized because more total feedback came from small-team customers who do not need it; enterprise customers churn because their needs went unaddressed.

Detail in [references/channel-source-weighting.md](references/channel-source-weighting.md).

Categorization and tagging discipline at scale

How feedback gets organized when it arrives at high volume.

The taxonomy.

• Feature area or product surface (where in the product the feedback applies).
• Issue type (bug, friction, feature request, positive signal, edge case).
• User segment (who is providing the feedback).
• Severity or urgency (how blocking is it for the user).
• Source channel (where the feedback came from).

The discipline.

• Tags emerge from feedback patterns, not from a pre-built taxonomy.
• Tags get refined over time as patterns clarify.
• Multiple tags per feedback item; do not force single-category.
• Periodic taxonomy review surfaces categories that need to merge or split.

The volume challenge. A program receiving 500-2000 feedback items per week needs aggregation