pruthivim RICE Scorer
RICE is a prioritization framework that forces gut feelings into numbers so a backlog can be ranked objectively instead of by whoever argues loudest in the meeting. The score is:
RICE Score = (Reach × Impact × Confidence) / Effort
Your job is to run this process end to end: collect the backlog, get honest numbers for each variable (asking where it matters, estimating where it doesn't), do the math, and hand back a ranked table the user can actually defend to a stakeholder.
Step 1: Get the backlog
The user might paste a list in chat, upload a file (CSV, Excel, doc), or want to build the list conversationally one idea at a time. Any of these are fine, just make sure you end up with a clean list of named features/initiatives before moving on. If a file is uploaded, read it first (see file-reading skill if the content isn't already visible in context).
If the list is vague ("we have like 10 ideas floating around"), ask the user to name them rather than guessing what they are. You can estimate the scoring later, but don't invent the backlog itself.
Step 2: Score each item
For every feature, you need four numbers. The goal isn't to interrogate the user on all four for every single item, since that's slow and annoying. Instead, ask when the answer meaningfully changes the ranking or you'd otherwise be guessing blind, and estimate (with a visible justification) when you have enough context to make a reasonable call. Always let the user override any number you land on.
Reach
How many people/customers does this affect in a given time period (e.g., users per quarter). This should be a real, groundable number, from analytics, a known user base size, or a stated segment size. If the user hasn't given you a number and you don't have a solid basis for one, ask rather than invent it, since a fabricated reach number undermines the whole point of the exercise.
Impact
How much this moves the needle for each person it reaches, on the standard scale:
| Value | Meaning |
|---|---|
| 3 | Massive impact |
| 2 | High impact |
| 1 | Medium impact |
| 0.5 | Low impact |
| 0.25 | Minimal impact |
This one is usually reasonable to estimate from the feature description and its stated goal. Flag your reasoning in one short phrase (e.g., "0.5, nice-to-have, doesn't unblock anything").
Confidence
How sure you are about your Reach and Impact estimates, as a percentage:
| Value | Meaning |
|---|---|
| 100% | High confidence, backed by data |
| 80% | Medium confidence |
| 50% | Low confidence, mostly a guess |
If Reach or Impact for an item were estimated rather than given, Confidence should reflect that. Don't let a guessed Impact sit next to a 100% confidence score.
Effort
Estimated person-time to build, as a number of person-weeks by default. This keeps the math consistent with how most teams actually plan sprints. If the user's team works in longer cycles and person-months is a better fit for their planning cadence, that's fine too, just pick one unit, use it consistently across the whole backlog, and say which unit you used. Round to the nearest 0.5; RICE effort estimates are meant to be rough sizing, not committed estimates.
Effort is usually worth asking about rather than guessing, since it depends on team context you don't have (existing infrastructure, team size, technical debt).
Justification notes
For every variable on every item, keep a short justification. A phrase is enough (e.g., "Reach: 4,000, active users on the affected plan per Q, from user's message"; "Impact: 1, solves a real but non-blocking pain point"). These notes are the whole point of the exercise: they're what makes the score defensible instead of another gut call. Mark anything you estimated (rather than the user provided) so it's easy to spot and challenge.
Step 3: Calculate and rank
RICE Score = (Reach × Impact × Confidence) / Effort
where Confidence is used as a decimal (80% becomes 0.8). Compute this for every item, then sort descending, highest score ships first.
Step 4: Deliver the output
Produce two things:
A markdown table in chat with columns: Rank, Feature, Reach, Impact, Confidence, Effort, RICE Score, Key justification (keep this last column brief, a clause or two, not the full notes). This gives the user something to read and copy immediately.
An interactive sortable artifact: build this as a single-file React or HTML artifact (see frontend-design skill for styling) with a table the user can click to re-sort by any column, and each row expandable or hoverable to show the full justification notes for that item. This is the deliverable the user will likely actually use and share, so make it clean and readable, not just a proof of concept.
If any inputs were estimated rather than user-provided, call this out clearly in both outputs (e.g., a visual flag or an "estimated" label) so the user knows what to double check before presenting the ranking to anyone else.
A note on honesty
The entire value of RICE over gut-feel prioritization is that the numbers are real and the reasoning is visible. Resist the urge to smooth over uncertainty. If you had to estimate Reach for a feature because nobody gave you a number, say so plainly rather than presenting it with false confidence. A ranked list built on invisible guesses is worse than no framework at all, because it looks objective when it isn't.