Product prioritization: choose the next investment with evidence
Product prioritization decides where limited team capacity should go next. The decision becomes easier to explain when each opportunity names the outcome it could improve, the evidence behind that expectation and the work it requires. A score helps compare those assumptions, but cannot establish whether they are true.
Choose one outcome for the comparison
Suppose a collaboration app wants more new teams to complete their first shared plan. It could improve invitations, add templates or rebuild reporting. Before ranking these ideas, ask how each would help that particular outcome. Reporting may serve an important existing customer need while belonging to a different decision.
Separate work the team must complete, such as resolving an active data-loss incident, from discretionary improvements. Otherwise a convenient score can hide a constraint that already determines the order of work.
Use RICE to make assumptions visible
Intercom's RICE framework combines reach, impact, confidence and effort: score = reach × impact × confidence ÷ effort. Reach uses a defined period, impact uses a shared rating scale, confidence discounts uncertain estimates, and effort covers the people needed to complete the work.
Keep units consistent across the comparison. In the example below, reach means new team accounts per quarter, impact is a relative rating, confidence is expressed as a fraction, and effort is measured in person-months. The numbers are hypothetical planning inputs.
| Option | Reach | Impact | Confidence | Effort | RICE score |
|---|---|---|---|---|---|
| Repair invitation recovery | 600 | 2 | 0.8 | 2 | 480 |
| Add planning templates | 1,200 | 1 | 0.5 | 1 | 600 |
Ask what could reverse the ranking
Templates score higher with these assumptions: 1,200 × 1 × 0.5 ÷ 1 = 600. Invitation recovery scores 600 × 2 × 0.8 ÷ 2 = 480. Neither result is a forecast of additional activated teams.
Now suppose the template estimate omitted the work needed to migrate existing plans. If effort rises to two person-months, its score falls to 300 and the order reverses. That makes the missing estimate worth resolving before the team commits.
Record the source of each input. Reach may come from account events, the expected effect from research, and effort from an engineering discussion. A confidence rating is a planning judgment, not a statistical confidence interval.
Review dependencies and the cost of waiting
A high-ranked change may require work that another option does not. If templates depend on a new permission model, assess the complete usable result rather than scoring only the attractive final screen.
Also ask whether delay changes the opportunity. A commitment to an existing customer, a seasonal need or a time-limited distribution opportunity can matter. Document why it changes the decision instead of adjusting the inputs until the preferred item wins.
Leave a decision the team can revisit
Choose the next commitment and state what remains uncertain. In this example, the team might first estimate template migration, then compare the two complete options. Alternatively, it could address invitation failures immediately if they block the core task for the intended launch cohort.
Keep the decision beside the assumptions and review it when relevant evidence changes. After release, use product analytics to check whether more teams complete a shared plan. Adoption of the new feature alone does not answer that question.
- Outcome: more new teams complete their first shared plan.
- Evidence: affected accounts, observed obstacles and research findings.
- Cost: design, engineering, migration and support work.
- Decision: the selected investment and the reason for its place in the queue.
- Review trigger: a changed estimate, new evidence or measured release outcome.
Sources
Discuss your product's next step
I help define product priorities, plan launches and investigate where users drop out.
