RICE Scoring

A score that ranks features by how many users they help, how much they help, how sure you are, and how hard they are to build.

When to use this

You have 10+ features to compare and you want a defensible ordering. You have rough usage data (analytics, support tickets, sales call counts) so Reach isn't pure guesswork. You're aligning a team or a stakeholder group on what ships next quarter.

When NOT to use this

You have fewer than 5 features (just decide). You're evaluating a strategic bet where Reach is unknowable. Your team disagrees on what "Impact" even means -- fix the goal first, then score.

Inputs

Reach: How many users (or accounts, or sessions) will encounter this in a fixed period. Pick monthly or quarterly and stick with it.
Impact: How much it moves the needle per user. A 0.25 / 0.5 / 1 / 2 / 3 scale. 3 means transformative, 0.25 means barely noticeable.
Confidence: How sure you are the Reach and Impact estimates are right. A percentage, usually 50% / 80% / 100%.
Effort: Total work across design, eng, QA, docs, and launch. Pick a unit (person-weeks or person-months) and stick with it.

The math

Score = (Reach x Impact x Confidence) / Effort

Reach times Impact gives you the total user benefit. Multiply by Confidence to discount estimates that could be wrong. Divide by Effort to get benefit per unit of work. Higher score, higher priority.

A worked example

Say you're a PM at a B2B SaaS with 8,000 monthly active users. You're scoring three features for the next quarter. Effort is measured in person-weeks.

Feature A: Bulk export to CSV. Reach: 5,000 users (most users hit reporting once a month). Impact: 2 (high -- removes a real friction point that shows up in calls). Confidence: 80% (10 customer interviews, clear demand). Effort: 4 person-weeks.

Score = (5,000 x 2 x 0.8) / 4 = 2,000.

Feature B: Custom dashboard widgets. Reach: 1,200 users (only power users will configure these). Impact: 3 (transforms the workflow for that segment). Confidence: 50% (we think they want it, no test yet). Effort: 12 person-weeks.

Score = (1,200 x 3 x 0.5) / 12 = 150.

Feature C: Onboarding tooltips refresh. Reach: 2,000 new users per quarter. Impact: 0.5 (small lift on activation). Confidence: 80% (we've A/B tested similar). Effort: 2 person-weeks.

Score = (2,000 x 0.5 x 0.8) / 2 = 400.

Ranking: A (2,000), C (400), B (150). Ship A first. C is a cheap second. B needs validation before it earns a slot -- the score isn't low because the feature is bad, it's low because you're guessing.

How pmtoolkit does it differently

The calculator auto-flags any feature with Confidence under 50% so you can see at a glance which scores rest on assumptions. It surfaces relative ranking, not just absolute scores -- comparing 2,000 to 150 matters more than the raw numbers. You can score multiple cohorts (this quarter's vs last quarter's) side by side to see drift in your estimates.

Common mistakes

Treating Effort as fixed. It's an estimate. Add a 30% buffer or your ranking is biased toward features you've underestimated.
Confusing Impact with revenue. Impact is per-user benefit, not dollars. Revenue lives in the goal you're scoring against.
Scoring features in isolation. A score only means something next to other scores. Always batch.
Ignoring Confidence on novel work. New features default to 50%, not 80%. You don't know yet.