Every product team hits the same wall. The feature requests pile up faster than you can read them. Sales wants a thing. Support has a spreadsheet. Three customers emailed the CEO. And your backlog is now a landfill where good ideas go to be forgotten next to bad ones.

The problem isn't that you lack requests. It's that you have no shared way to compare them. "This feels important" loses to "the loudest person asked for it" every time. RICE fixes that. It's a scoring framework that turns gut calls into numbers you can defend in a room.

This post walks through triaging feature requests with RICE, run on a single card, so the score, the reasoning, and the decision all live in one place your team already opens every day.

Key takeaways

  • RICE scores each request on four factors: Reach, Impact, Confidence, and Effort.
  • The formula is (Reach × Impact × Confidence) ÷ Effort. Higher score wins.
  • You can run the whole thing on one card using custom number fields, priorities, and labels.
  • The score is a starting point for the conversation, not a verdict that ends it.
  • Consistency matters more than precision. Score everything the same way and the ranking holds up.

What RICE actually measures

RICE breaks a fuzzy "should we build this?" into four questions you can answer one at a time.

Reach

How many people does this affect in a set period? Use a real unit: users per quarter, accounts per month, tickets per week. If a request touches 2,000 users a quarter, Reach is 2,000. Don't estimate a percentage. Count something.

Impact

When it reaches someone, how much does it move the needle? Since you can't measure this precisely up front, RICE uses a fixed scale: 3 for massive, 2 for high, 1 for medium, 0.5 for low, 0.25 for minimal. Pick one number. The scale keeps everyone honest.

Confidence

How sure are you about your Reach and Impact guesses? This is the reality check. 100% for solid data, 80% for some evidence, 50% for a hunch. Confidence is what stops a wildly optimistic Reach estimate from rocketing a shaky idea to the top.

Effort

How much work is it, in person-months (or person-weeks for smaller teams)? Count design, engineering, and QA. Effort is the denominator, so a small effort with decent upside beats a huge effort with big upside more often than you'd expect.

RICE score = (Reach × Impact × Confidence) ÷ Effort. A request reaching 2,000 users, Impact 2, Confidence 80%, Effort 2 months scores (2000 × 2 × 0.8) ÷ 2 = 1,600.

Run it on a single card

The mistake most teams make is keeping RICE in a spreadsheet nobody opens, disconnected from where the work happens. Put it on the card instead. In Zoobbe, a feature request becomes one card that carries its own score, its reasoning, and its decision from first triage to shipped.

Step 1: Capture the request as a card

One request, one card. Title it plainly ("Bulk-edit tags on contacts"). Drop the original ask into the description, and if it came from a customer conversation, paste the quote in a threaded comment so the context never gets lost. Now the request has a home.

Step 2: Add the four RICE scores as custom fields

Create four custom number fields on the board: Reach, Impact, Confidence, and Effort. Every request card now has four boxes to fill. Because they're number fields, the values are consistent and comparable across the whole board. No more "was that a 2 or a II?" One person can propose the numbers; the team can adjust them in review.

Step 3: Compute the score and set a priority

Do the math (a calculator is fine for a weekly triage). Then translate the number into a priority the whole team reads at a glance. Zoobbe cards have four priorities, so map your score ranges to them:

  • Urgent — top-scoring requests you're committing to now
  • High — strong candidates for the next cycle
  • Normal — real but not yet
  • Low — parked, revisit later

The raw score orders the list. The priority makes the decision visible without anyone opening the card.

Step 4: Label the theme

Add a color-coded label for the type of request: onboarding, integrations, reporting, performance, whatever your themes are. Labels are reusable across the board, so once you've tagged a few dozen cards you can filter to "show me every reporting request" and see whether a cluster of medium-scoring asks actually points at one big opportunity. Triage isn't only about ranking single cards. It's about spotting patterns.

Step 5: Record the decision where it happened

When triage ends, the outcome lives on the card. Move it to the right list, set the priority, and leave a comment explaining the call: "Scored 1,600, but we're holding until the billing migration ships in Q3." Six weeks later when someone asks why this wasn't built, the answer is right there. The activity log tracks who changed what and when, so the history holds up on its own.

Why the card beats the spreadsheet

A RICE spreadsheet is a snapshot that rots the moment you close it. A card is alive. The score sits next to the customer quotes, the checklist of open questions, the comment thread where design pushed back on the Effort estimate. When priorities shift, you re-score in place and the whole team sees it move.

It also kills the two failure modes of feature triage. The first is politics: when the score and the reasoning are public on the card, "my exec asked for it" has to compete with actual numbers. The second is amnesia: nobody re-litigates a decision that already has its reasoning attached.

Keep it honest

RICE is a tool, not an oracle. A few guardrails keep it useful:

  • Score in batches. Rank ten requests in one sitting, not one at a time. Relative scoring is far more consistent than absolute.
  • Distrust suspiciously high scores. A runaway number usually means an inflated Reach or a Confidence that should've been lower.
  • Let the score start the argument, not end it. If a low-scoring request feels urgent, that's a signal your inputs are missing something. Find out what.
  • Re-score quarterly. Reach and Confidence change as you learn. Yesterday's parked idea can climb.

The point isn't a perfect ranking. It's a shared, visible, defensible one, so the next time the requests pile up, you have a system instead of a shouting match.

FAQ

What's a good RICE score to build something?

There's no universal threshold. RICE is relative, so the number only means something compared to your other requests. Score a batch, sort descending, and draw the line where your capacity runs out for the cycle.

How is RICE different from a simple priority label?

A priority label is the conclusion. RICE is the reasoning that produces it. Running RICE first and then setting the priority means the label reflects a defensible score instead of a gut feeling, and you can show your work when someone challenges it.

Do small teams need RICE, or is it overkill?

It scales down cleanly. Solo founders and small teams can use person-weeks instead of person-months for Effort and skip the fancy scale. The value is the same at any size: a consistent way to compare requests so the loudest voice doesn't automatically win.

How often should we re-triage the backlog?

A light weekly pass to score new requests, plus a deeper quarterly re-score of the whole backlog. Reach, Impact, and Confidence all drift as you ship and learn, so a parked request can legitimately move up over time.

Can we automate any of this?

The scoring judgment stays human, but the housekeeping around it doesn't have to. You can set up rules so that when a card's priority changes, it moves to the matching list, or so new request cards land in a triage queue automatically. The thinking is yours; the shuffling is the tool's job.

Ready to stop triaging in a spreadsheet nobody opens? Try Zoobbe and run your next RICE session on cards your whole team already lives in.

Photo by Solstice Hannan on Unsplash