Every product team drowns in the same flood: feature requests from sales, support tickets, a founder's Slack DM, three users in a row asking for the same thing, and one very loud customer who threatens to churn. The requests are real. The problem is that they all arrive labeled urgent, and none of them arrive labeled here's how it ranks against everything else you're already not doing.
Triage is the discipline of turning that flood into a queue. Not a perfect queue. A defensible one. This post walks through running RICE scoring directly on a card, so the scoring lives next to the request instead of in a spreadsheet nobody opens after the meeting.
Key takeaways
- RICE (Reach, Impact, Confidence, Effort) gives every request one comparable number, so you stop arguing about gut feelings.
- Putting the score on the card itself means the reasoning travels with the request forever.
- Custom number fields hold the four RICE inputs; the card's priority becomes the output.
- Labels capture the theme of a request so you can spot clusters, not just rank individuals.
- An automation can react the moment a priority changes, so triage decisions don't stall in someone's inbox.
Why feature-request triage breaks down
Most teams don't lack a process. They lack a process that survives contact with a busy week. The spreadsheet works for exactly one planning session, then the data goes stale because nobody updates a second source of truth. The voting board works until the same five power users vote for everything. The "we'll discuss it in the next roadmap meeting" approach works until the meeting is 40 requests long and you spend it relitigating priorities you already set.
The fix isn't a fancier framework. It's putting the scoring where the work already lives: on the card. When the request, the discussion, and the score share one surface, triage stops being a separate ritual and becomes something you do in 30 seconds as requests arrive.
RICE in one paragraph
RICE scores each request on four inputs. Reach: how many users or accounts this affects in a given period. Impact: how much it moves the needle for each one, usually on a small scale (0.25 minimal, 3 massive). Confidence: how sure you are about your Reach and Impact guesses, as a percentage. Effort: rough person-weeks to build. The score is (Reach × Impact × Confidence) ÷ Effort. A request that touches a lot of users, helps them a lot, that you're confident about, and that's cheap to build, floats to the top. A pet feature for one account that takes a quarter sinks. That's the whole point.
Step 1: Turn each request into a card
Start with a board and one list called something like Incoming Requests. Every request becomes a card. The title is the request in the user's words. The description holds the context: who asked, what problem they're actually trying to solve (not the solution they proposed), and any links to the original ticket or thread.
This first move matters more than it looks. A request written as "add a CSV export button" hides the real job: "I need to get this data into my finance team's tool." Capture the job in the description. You'll score the job, not the button, and you'll often find a cheaper path to the same outcome.
Step 2: Add four custom number fields for RICE
On the card, create four custom fields, each set to the number type: Reach, Impact, Confidence, and Effort. Now the four RICE inputs live structurally on the card instead of buried in prose. You fill them in as you triage, and because they're real fields, you can scan a whole list and compare scores at a glance.
A quick worked example. A request to fix a confusing onboarding step: Reach 800 (new signups per month it touches), Impact 2 (high, it's a drop-off point), Confidence 80%, Effort 1 week. Score: (800 × 2 × 0.8) ÷ 1 = 1,280. Compare that to a niche bulk-edit tool one agency asked for: Reach 15, Impact 3, Confidence 50%, Effort 4. Score: (15 × 3 × 0.5) ÷ 4 = roughly 5.6. The onboarding fix wins by two orders of magnitude, and now you have the number to say so when the agency's account manager pushes back.
Step 3: Let priority be the output
Here's where the card system earns its keep. After you compute a score, set the card's priority to reflect it. Pick simple bands your team agrees on: top-decile scores get Urgent, the strong middle gets High, the long tail gets Normal, and the "we're keeping it on record but not building it" pile gets Low.
This separation is the trick most teams miss. The four custom fields are inputs, the thing you debate. Priority is the output, the thing you act on. When someone asks "why is this only Normal," you don't argue about vibes. You point at the four numbers that produced it. And when an input changes, because the request now affects more users, or the engineering team revised the effort estimate, you change the number and the priority follows. The decision is always traceable back to its reasoning.
Step 4: Label the theme, not just the rank
Priority tells you what to do next. Labels tell you what's happening across the whole pile. Add color-coded labels for the theme of each request: onboarding, integrations, reporting, mobile-web, whatever your product's natural seams are. Labels are reusable across the board, so they stay consistent.
The payoff comes at scale. When you filter to the integrations label and see eleven separate Normal-priority requests, you've found something a per-card score would never surface: a cluster. Eleven small requests pointing at the same gap might collectively outrank the single Urgent card you were about to start. Labels turn a ranked list into a heatmap of demand.
Step 5: Automate the handoff
Triage decisions die in the gap between "decided" and "someone told the right person." Close that gap with an automation. Set a rule that triggers when a card's priority changes, and have it post a comment or send a notification so the relevant owner sees the new ranking without you chasing them. You can also trigger on a label being added, so every new integrations request pings whoever owns that area.
The goal is that no triage decision waits on a human remembering to forward it. The system moves the information the moment the decision is made.
Making it a habit, not an event
The reason this works at any team size is that it scales down as well as up. A solo founder runs it in their head in two minutes a day. A 30-person product org runs the same four fields and the same priority bands, just with more cards and a weekly review of the top of the queue. The framework doesn't change. Only the volume does.
Run triage as a standing weekly pass, not a quarterly bloodbath. Twenty minutes a week scoring new arrivals beats a four-hour roadmap meeting where everyone's already entrenched. The cards carry the reasoning between sessions, so you're never starting cold.
FAQ
How is RICE better than just voting on requests?
Voting measures volume, not value. A vote count tells you how many people clicked a button, not how much building the thing actually matters relative to effort. RICE forces you to estimate reach, impact, confidence, and cost explicitly, which makes the trade-off visible and the decision defensible.
Do I have to use exact numbers for Reach and Impact?
No, and pretending you have precision you don't is its own trap. RICE is a relative ranking tool. As long as you're consistent in how you estimate across cards, rough numbers sort the queue correctly. The Confidence input exists precisely to discount the guesses you're least sure about.
What do I do with requests that score low?
Don't delete them. Set them to Low priority and keep them on the board with their theme label. Low-scoring requests are data. If five more of the same theme arrive, the cluster might cross the threshold, and you'll already have the history captured instead of rediscovering the demand from scratch.
How often should I re-score?
Re-score when an input genuinely changes: a request now affects more users, an effort estimate gets revised after technical discovery, or your confidence shifts. You don't need to re-score the whole board on a schedule. Because the score lives on the card, updating one field and letting priority follow is a 10-second edit.
Can a small team or solo founder use this?
Yes. The method is deliberately audience-agnostic. A solo founder uses the same four fields and priority bands as a large product org, just with fewer cards. The discipline of writing down why something ranks where it does is valuable at any size.
Stop arguing, start ranking
Feature-request triage isn't about saying yes to the best ideas. It's about being able to say no to good ideas without it turning into a fight, because the reasoning is written down and anyone can check it. Put the score on the card, let priority be the output, label the themes, and automate the handoff. The pile becomes a queue, and the queue becomes a roadmap you can defend.
Ready to run your own request queue this way? Try it in Zoobbe and turn your next flood of requests into a ranked list in an afternoon.
Photo by Andy Brown on Unsplash