1. Put comparable problems on the table
Start with a small set of requests tied to the same product objective. “Improve reporting” is too broad to compare with “save report filters.” Rewrite each as an outcome for a defined user, and keep distinct problems separate even when customers suggest the same solution.
Remove duplicates only after comparing their audience and desired outcome. Ten requests from the same person are different evidence from ten independent customers encountering the same blockage. Keep the original context available to the team.
Use the feature request template when a card has a proposed solution but no explanation of the job. Ask what the customer cannot do today, how often it happens, and what their workaround costs them.
2. Write the evidence before the score
A vote signals support from someone who found the board and chose to participate. It is not a count of everyone affected, proof of willingness to pay, or a delivery obligation. Add evidence from actual usage and conversations where you have it; mark missing evidence as unknown.
- Reach: how many distinct people or accounts would use the change in the same defined period?
- Impact: what measurable workflow or customer outcome should improve?
- Confidence: what comes from observation, and what is still a guess?
- Effort: include discovery, design, implementation, testing, rollout, and the support burden you can anticipate.
3. Use a score to expose assumptions
The RICE method combines reach, impact, confidence, and effort into a comparison score. Our free RICE calculator uses reach × impact × confidence ÷ effort, with confidence entered as a percentage. Use consistent reach periods and person-months of effort across rows.
This example is fictional: saved report views reach 120 users per quarter, with impact 1, confidence 80%, and effort 1 person-month, for a score of 96. A new dashboard reaches 200, with impact 2, confidence 50%, and effort 4, for a score of 50. The first scores higher under those assumptions; it is not objectively twice as valuable.
Change the uncertain inputs before committing. If saved views only reach 40 people, that score falls to 32. A decision that reverses under a plausible estimate needs better evidence, not more decimal places. Intercom’s original RICE explanation describes the framework and its limitations.
4. Apply constraints explicitly
A security fix, contractual requirement, accessibility barrier, or prerequisite may need to come first regardless of its score. Record that exception so the team can tell a deliberate constraint from inconsistent prioritization.
Then check capacity and dependencies. A high-scoring project with an unresolved dependency is not ready for the next sprint. Give it a specific next action, such as testing the assumption or completing the prerequisite, rather than silently leaving it near the top forever.
5. Leave a decision someone else can follow
The internal record can contain estimates and sensitive context. The public explanation should state the customer-relevant reason without exposing account information. Avoid inventing a delivery date to make the answer feel complete.
Review the decision when evidence or capacity changes. In BuildCaster, feature requests stay attached to status history, and your roadmap communicates the current decision. A score alone never moves a card.