How to Prioritize User Insight

A vote count is a signal, not a roadmap

A feedback board can tell you which contributors chose to vote. It cannot independently tell you how common a problem is across the customer base, how severely it interrupts work, or how closely it relates to the product strategy. One person may vote for a convenient improvement while another does not encounter the board at all. Several colleagues from one account may represent the same underlying workflow. Votes still matter, but their meaning depends on who contributed and how the feedback was collected.

AAPOR's best practices for survey research emphasize defining the population, choosing a sample that represents it, writing neutral questions, and disclosing the method. A public feature board is not usually designed as a representative survey. Its totals therefore describe activity among its contributors, not a prevalence estimate for every customer.

Use request and vote volume to notice possible opportunities and changes over time. Then investigate the affected segment, the job people are trying to complete, the consequences of the current problem, and the evidence missing from the record. A strong signal deserves attention, not automatic commitment.

Translate feature requests into problems

Customers often express a real need through the most obvious solution available to them. The team's first job is to preserve the request without accepting its proposed implementation as the only answer. GOV.UK's discovery guidance recommends interrogating a predefined solution, reframing it as a problem, and learning about users in the wider context of what they are trying to achieve. Intercom's start-with-the-problem principle similarly asks who has the problem, what job they are doing, how severe the gap is, and what behavior should change.

Consider a clearly hypothetical example. A B2B SaaS team sees 46 votes for bulk editing. After reviewing the fictional records, it finds that the votes came from 15 administrators across nine accounts, with some people voting and contacting support about the same issue. Interviews suggest that these administrators update ownership and status on many records after organizational changes. The request volume is 46, the known affected segment is administrators at nine accounts, and the underlying opportunity is reducing slow, error-prone repetitive updates. Those are three different facts.

The team can now explore bulk editing, import rules, automation, safer defaults, or another response without losing the original evidence. It should also seek contrary cases and avoid claiming the interviews establish how widespread the problem is. The example is illustrative, not a Palette customer story or a forecast of results.

Build an evidence record for each opportunity

Create one record for the customer opportunity rather than one backlog item per requested feature. Keep the original language and source attached so later synthesis does not erase context. A useful record includes:

• Problem and desired outcome. Describe what people struggle to accomplish and what a better outcome would allow, without prescribing a feature.
• Affected users and context. Record relevant roles, account characteristics, workflow stage, frequency, and conditions.
• Source evidence. Link requests, support threads, interviews, usability observations, and behavioral measures with dates and provenance.
• Strength and limits. Separate what was observed from what the team inferred. Note selection effects, missing segments, small samples, and conflicting evidence.
• Strategic connection. State which product outcome or business constraint makes the opportunity relevant now.
• Open questions. List the uncertainties that could change priority or solution direction.

This record should evolve as the team runs continuous user research. Keep distinct observations together when they concern the same opportunity, but do not flatten disagreement into a confident summary.

Compare opportunities across the same questions

Product Talk recommends prioritizing opportunities before solutions. This avoids comparing a fully imagined feature with a loosely described customer concern. Put candidate opportunities at a similar level of specificity, then ask the same questions of each.

1. Importance: How consequential is the problem for the relevant user, and what evidence supports that judgment?
2. Reach: Which users encounter it within a stated period, and is the estimate based on representative data, product measurement, or a weaker proxy?
3. Outcome alignment: How could addressing it advance the product outcome the team has chosen?
4. Current satisfaction: How well can people complete the job today, including workarounds and alternatives?
5. Evidence quality: Are there multiple relevant sources, recent behavioral evidence, contradictory cases, and clear limitations?
6. Cost of delay: What becomes harder or more costly if the team waits, and is that urgency observed or assumed?

The answers do not need identical units, but they do need consistent definitions. If reach means active accounts for one opportunity and individual respondents for another, the comparison is misleading. Record the time window and unit beside every estimate.

Keep value, confidence, and effort visible

A compact scoring framework can expose assumptions that prose leaves hidden. Intercom's original RICE prioritization guidance compares reach, impact, confidence, and effort. Its useful discipline is estimating each factor explicitly and applying the same definitions across candidates.

RICE is a comparison aid, not objective truth. Reach may be estimated from incomplete instrumentation. Impact is a judgment about a future change. Confidence is a team's assessment of its evidence, not a statistical guarantee. Effort can change once engineering explores the work. A precise-looking score inherits every uncertainty in its inputs.

Keep the inputs beside the output. Use ranges when they communicate uncertainty better than a single number, and link each estimate to its basis. Compare the score with strategic commitments, accessibility and security needs, contractual obligations, platform health, and risks that the formula does not represent. If an executive constraint overrides the score, record that decision instead of manipulating an input until the preferred item wins.

Make the decision and record the tradeoff

Prioritization ends with a choice, not a dashboard. Bring product, design, engineering, research, support, and commercial context into a short review proportionate to the decision. Select the opportunity to pursue, identify what will not be pursued now, and name the person accountable for the next step.

Write a decision note that states the chosen opportunity, relevant outcome, supporting evidence, confidence, important objections, rejected alternatives, constraints, and review date. A useful note also records what new evidence would reverse or weaken the choice. This turns disagreement into inspectable reasoning and helps a future teammate understand why a lower-vote problem moved first.

Choosing an opportunity does not authorize a particular feature. Before development, validate the feature proposal against the problem, workflow, and realistic tasks. Build, revise, investigate, and stop are all responsible outcomes.

Revisit priorities when the evidence changes

A priority is a time-bound decision made under current conditions. Revisit it when new research changes the problem definition, usage data changes the reach estimate, a workaround improves, strategy shifts, implementation risk emerges, or a release produces evidence about the original need. Do not wait for an arbitrary quarterly reset when a central assumption has already failed.

After shipping, compare the observed outcome with the baseline and decision rule recorded before building. Adoption alone does not prove the customer problem was solved, and a qualitative comment does not establish a causal effect. Combine appropriate measures with follow-up research, then update the opportunity record so future decisions can learn from what happened.

How Palette makes the evidence trail reviewable

Palette is designed to connect requests, support feedback, interviews, usability studies, and product signals to shared opportunities through its research workflow. Teams can inspect the sources behind a synthesized finding, preserve uncertainty, and carry selected evidence into build-ready product work. Human reviewers still decide which evidence is relevant, how strongly it supports a conclusion, and which tradeoff to accept.

The goal is a visible chain from customer signal to opportunity, decision, proposed solution, and outcome. If that approach fits how your team wants to work, you can join the Palette waitlist. A tool can make the trail easier to maintain. It cannot turn a vote count or scoring formula into certainty.