How to Prioritize Product Feedback
Prioritize product feedback by the customer problem, the evidence behind it and the decision it informs. The most frequent request is not automatically the most valuable improvement. Neither is the request from the largest prospect.
A good prioritization process makes tradeoffs visible. It helps a team explain why it will fix something now, investigate it further or leave it outside scope.
Capture the problem behind the request
For each item, record who reported it, the segment, the task, what happened, the consequence and the current workaround. Keep the original wording or evidence reference. Do not collapse “needs an export” and “cannot share a report with a client” into the same requirement without checking the underlying workflow.
Group related observations into opportunities. Count distinct affected customers rather than duplicate messages from the same unresolved case. Note the denominator: five complaints among ten relevant accounts is different from five among ten thousand. Silence still does not establish that everyone else is satisfied.
Keep feedback from people who left, declined to buy or never completed setup. A backlog based only on active customers can optimize the product around those who already tolerate its limitations.
Separate urgent obligations from optional investments
Security incidents, data loss and failures of essential functionality need a defined triage route. Do not make them compete against cosmetic improvements through a generic feature score. Evaluate consequence and urgency first.
For the remaining opportunities, ask how closely the problem fits the target customer, how often it occurs, what it prevents and how credible the evidence is. Engineering and design should help estimate effort and dependencies before a delivery commitment is made.
Use RICE as a discussion aid
Intercom’s RICE framework combines reach, impact, confidence and effort. In its usual form, the score is reach multiplied by impact and confidence, divided by effort. Use the same time period and effort unit across compared options. In a hand calculation, use confidence as a fraction, such as 0.8 for 80%. In this site’s calculator, enter 80 in the field labelled “Confidence (%)”; the calculator converts it to 0.8 internally.
The calculation organizes assumptions; it does not turn subjective estimates into facts. A small difference between two scores may mean little when reach and impact are uncertain. Compare ranges and identify what evidence could change the order.
Hypothetical worked comparison
A fictional team compares two improvements against the same goal: successful report sharing during the next quarter. Impact uses the team’s common relative scale, confidence is an estimate and effort is measured in person-months.
| Opportunity | Reach | Impact | Confidence fraction for hand calculation | Effort | Illustrative score |
|---|---|---|---|---|---|
| Explain a blocked sharing permission | 120 accounts | 2 | 0.8 | 1 | 192 |
| Add a new visual report theme | 200 accounts | 0.5 | 0.5 | 2 | 25 |
The permission explanation ranks higher under these assumptions. The team still checks whether the real defect is an incorrect permission, which a message would not fix. If so, the solution and effort estimate change. Scoring the first proposed feature without investigating the problem could prioritize the wrong work.
Make and communicate the decision
Assign an owner and a decision state: investigate, planned, in progress, completed or declined. Explain the reasoning in terms of customer outcomes and constraints. Avoid promising delivery dates before dependencies and capacity are understood.
If you decline a request, describe the current alternative and whether the decision may be revisited. A clear answer is usually more useful than an indefinitely “under consideration” status.
After release, check whether the change solved the original problem. Compare relevant task outcomes and support cases, and contact affected customers where appropriate. A shipped feature closes the development task; verified improvement closes the learning loop.
Begin with a small set of evidence-rich opportunities. Connect the choice to the product development process and test significant uncertainty through a beta. Revisit priorities when new evidence changes the underlying assumptions.
Use an evidence record before using a score
Create one opportunity record for each underlying problem. Include the target segment, distinct affected accounts, relevant denominator, recent example, task consequence, workaround, source links and unresolved questions. Attach proposed solutions as options rather than allowing the first feature suggestion to define the opportunity.
For example, “export to a spreadsheet” might represent a client’s review requirement, an internal approval process or mistrust of a calculation. Those explanations need different responses. Ask what the customer does with the export and observe a recent case where possible.
Use the customer interview notes template to collect context consistently. Preserve contradictory evidence. If some customers prefer the current workflow, record why rather than treating them as resistance to a supposedly obvious improvement.
Calibrate reach, impact and effort together
Choose a shared planning horizon for reach. An option affecting 100 accounts per month cannot be compared directly with one affecting 100 accounts per year without adjustment. Decide whether the unit is a person, paid account or task occurrence, and use it consistently.
Define the impact scale in relation to the same outcome. If one estimate means revenue and another means satisfaction, multiplying them into a common score hides a disagreement. Confidence should reflect the quality of the reach, impact and effort evidence, not simply how strongly a manager supports the idea.
Include design, engineering, rollout and operational effort where relevant. A feature that is quick to code but requires extensive migration is not a small investment. Use the RICE calculator for transparent arithmetic after the assumptions are agreed. Its confidence field accepts a percentage number, not the fraction shown in the hand-calculation table.
To reproduce the permission example in the calculator, enter the following values and select Calculate:
| Calculator field | Value to enter |
|---|---|
| Reach in your chosen period | 120 |
| Impact (0-3) | 2 |
| Confidence (%) | 80 |
| Effort (person-months) | 1 |
The score is 120 multiplied by 2 multiplied by (80 divided by 100), divided by 1, which equals 192. Enter 50 in the confidence field for the report-theme example to obtain 25. Entering 0.8 into the percentage field means 0.8% confidence and produces a different score.
Run a sensitivity check
In the fictional report-sharing example, the permission explanation scores 192 and the theme scores 25 under the stated assumptions. Ask what would make that ordering change. If the permission fix reaches only twenty accounts and takes two person-months, with impact 2 and confidence 0.8, its score becomes 16. The original ranking was conditional, not a measurement of objective value.
Investigate the assumption most likely to change the decision. A quick engineering review might clarify effort; an event-data check might clarify reach. Do not spend weeks refining every input when two options are clearly far apart under plausible ranges. Conversely, avoid pretending that scores of 51 and 50 justify a confident ranking.
Handle strategic commitments and dependencies explicitly
Some work enables later options, fulfils a real commitment or addresses a substantial risk. Record that reason directly rather than manipulating the scoring inputs until the desired project wins. State who approved the exception and what evidence or obligation supports it.
A shared infrastructure change might score poorly when evaluated only against immediate feature adoption, while being necessary for reliability. A large prospect’s request might look valuable but lead away from the target segment. Both cases require a strategic decision outside a mechanical ranking.
Limit the number of opportunities admitted to delivery. Starting everything ranked “high” creates delay and makes promises unreliable. Keep a visible queue and revisit it when evidence, capacity or strategy changes.
Verify the original problem after release
Attach the expected outcome and measurement window to the selected work before implementation begins. After release, compare the relevant task and review affected cases. Confirm that customers can find and use the improvement, since an undiscovered feature cannot resolve an obstacle.
If the result is weak, distinguish implementation failure, inadequate adoption and a mistaken problem hypothesis. Update the opportunity record and explain the finding to staff who collected the feedback. This connects prioritization to a real customer feedback loop instead of treating the backlog order as the end of the process.
Check the arithmetic before publishing priorities
Use a positive effort estimate; a zero denominator makes the score undefined. For 80% confidence, use 0.8 in the hand formula or 80 in the calculator’s percentage field. Keep the effort unit consistent and include the planning horizon in the record. Round the displayed result sensibly so decimal precision does not imply precise evidence. Ask a second person to inspect the assumptions and units, not merely whether the spreadsheet formula evaluates. A mathematically correct ranking can still represent the wrong customer problem.