Let me confess something every PM secretly knows: we all cheat at RICE. Not on purpose, exactly. But when you score the feature you personally championed, your Confidence number drifts suspiciously high and your Effort estimate drifts suspiciously low, and somehow your pet project ends up on top. RICE is a great framework precisely because it makes your assumptions visible, which is also why it is so easy to fudge them in your own favor.
Using the prompt as an adversary, not a calculator
After a few months with the Score and Rank a Feature Backlog with RICE prompt, I stopped using it just to compute scores and started using it to attack my own reasoning. The trick is in the input. I write each backlog description in the most neutral, evidence-only language I can manage, deliberately stripping out my own enthusiasm. For my favorite feature, I force myself to write only what is actually true: 'requested by 3 customers, no usage data, depends on a system we have not built.' Then I let Claude Sonnet 4.6 score it cold.
The result is humbling and useful. Because the prompt is instructed not to let popularity inflate confidence, it reads my neutered description and assigns the low confidence the evidence actually supports. My pet feature dropped from where my gut put it, third, to seventh out of seven. The stress-test section said the quiet part out loud: 'Confidence is 25 percent because reach and impact are both assumptions; validate with a fake-door test before committing engineering time.' That sentence saved me from spending a sprint on a hunch.
I cannot overstate how much my emotional reaction to that ranking taught me. I felt defensive. I wanted to argue with a language model about a number it computed from words I myself had written. That defensiveness is the tell. If I had written an honest description and the score still hurt, the problem was never the prompt; it was that I had fallen in love with a feature that the evidence did not love back. Catching that feeling early, in private, at my desk, is a thousand times cheaper than catching it three weeks into a build when an engineer asks me why we are doing this and I do not have a real answer.
The two-pass technique I actually use
Here is the workflow that makes this reliable. I run it twice, and the gap between the two runs is the insight.
- Pass one: score every item with neutral, evidence-only descriptions. This is your honest baseline and it is usually uncomfortable.
- Pass two: for any item where I disagree with the ranking, I add the specific evidence I think justifies a higher score, then re-run. If real evidence exists, the score moves. If I cannot find evidence to add, that silence is the answer.
- Compare the two rankings. Items that moved up had real evidence behind my gut. Items that stayed flat were just my preference wearing a costume.
- Take the pass-two ranking to the team with both versions visible, so the discussion is about evidence and not about who argued hardest.
What this does to a roadmap meeting
The first time I brought a two-pass RICE readout to a planning meeting, the energy was completely different. Instead of six people defending six features, we were all looking at the stress-test flags and asking 'what would it take to raise the confidence on this one.' That is the meeting you want. The fight stops being about taste and starts being about what we would need to learn. We even adopted the prompt's own toss-up tiebreaker language as a team norm, so now when two features land within ten percent of each other, someone inevitably says 'which one unblocks something downstream,' and the argument resolves in about ninety seconds instead of forty minutes.
There is one failure mode I will warn you about, because it bit me. If you write descriptions that are too sparse, the model has nothing to score and will tell you so, which is correct but unhelpful. 'Add team workspaces' is not a description; it is a title. The two-pass technique only works if pass one contains real, if neutral, facts: who asked, how many, whether usage data exists, what it depends on. The discipline the prompt enforces is only as good as the honesty you feed it. Garbage in, confident garbage out. The whole point is to make the honesty mandatory before the meeting, not during it.
If you have ever quietly inflated your own confidence score to win a prioritization debate, and you have, try running the Score and Rank a Feature Backlog with RICE prompt on Prompt Dock with the most neutral descriptions you can stand to write, then let it argue with you. Once the ranking holds up under its own scrutiny, hand the top item to my Write a User Story and Acceptance Criteria from a Plain Feature Description prompt and turn the winning bet into something an engineer can build on Monday.