"How do you prioritize your backlog?"

This tests judgment, not framework recall. Naming RICE is table stakes; the signal is whether you treat the score as a truth machine or a map, how you handle confidence, and what you explicitly choose not to build.

Structure a strong answer

Anchor on the current goal before touching the backlog. Then use RICE to make tradeoffs visible across reach, impact, confidence, and effort. Show judgment at two moments: when you override the formula, and when you say no.

What interviewers actually test for

At Google and Stripe specifically, interviewers check three things: (1) do you anchor on the goal before touching the backlog, (2) do you name what you are not building, and (3) do you treat the score as a conversation tool rather than a decision machine. At AI-native companies (Anthropic, Cursor, OpenAI), expect a follow-up on how compressed engineering effort has changed your rankings.

A junior answer gives the formula. A senior answer owns the tradeoff publicly, names the stakeholder whose request went to the ‘not now’ list, and can explain what confidence threshold triggers a spike rather than a commitment.

Confidence: the most underused lever

Most candidates use RICE but skip confidence or treat it as decoration. It is the most important variable. A feature with 40% confidence should not sit on a roadmap alongside a feature at 85% confidence as if they are comparable. A strong answer names a threshold: below 60% confidence, the item becomes a time-boxed spike to gather signal, not a scoped commitment.

The classic confidence failure looks like this: a feature scores 420 on RICE (reach 60K users, impact 3x, confidence 70%, effort 3 person-weeks). It looks solid. But the 70% confidence was generous because the team was excited, not because there was evidence. Post-launch, the feature hit 20% of projected reach. If confidence had been scored honestly at 40%, the RICE score drops to 240 and the spike-first decision is obvious. Naming this failure pattern in your answer signals that you have been burned by it and learned from it.

A worked example: when the formula does not decide

Imagine two backlog items. Item A: a bulk export feature requested by five enterprise accounts (reach 5K seats, impact 2x, confidence 85%, effort 1 week). RICE score: 850. Item B: a new onboarding flow redesign (reach 40K users, impact 2x, confidence 55%, effort 4 weeks). RICE score: 1,100.

Item B wins on the formula. But before committing it to the roadmap, a senior PM asks: why is confidence at 55%? If the answer is “we have not run a single user test on the new flow,” that item should become a spike, not a sprint commitment. Item A, with high confidence and a specific, named user need, may be the right build even though it scored lower. The score surfaced the conversation. The PM made the call.

This is what “the score is a discussion-starter, not a truth machine” actually means in practice.

The 2026 shift: effort has compressed, viability is the real denominator

In 2023, effort was often the binding constraint. A four-week engineering project sat below the line because the team could not absorb it. In 2026, AI-assisted development has compressed many of those same projects to one to two weeks. Items that previously scored too low on RICE resurface when you rerun the numbers. If you are not recalculating quarterly, your backlog rankings are stale.

More importantly, the real question is no longer “can we build it?” With AI tooling, the answer is almost always yes. The question is whether the outcome is viable: will users pay for it, will the market sustain the cost of building and maintaining it, and is the problem real enough that they return? The second question is whether it is lovable: with AI raising the baseline UX floor, average execution is table stakes. Prioritize things that will make users feel something, not just complete a task. See feasibility is free and lovable, not just usable.

AI tooling in the prioritization workflow

Productboard AI, Linear Pulse, and GitHub Copilot Workspace can now auto-group backlog items, remove duplicates, and suggest initial RICE scores based on ticket history and usage data. A PM who ignores these tools looks out of touch. A PM who defers entirely to them fails the judgment test.

Use AI-generated prioritization suggestions as a first pass: they are good at pattern matching and surfacing items that cluster around the same user need. They are poor at viability calls, stakeholder tradeoffs, and strategic bets that require context the tool does not have. When an AI tool surfaces a high-scoring item you plan to deprioritize, you need to be able to name why. That gap between the model’s score and your decision is where your judgment lives.

The ‘not now’ list as a communication tool

Most PM prep resources treat the ‘not now’ list as a personal tracker. It is not. It is a stakeholder communication tool. The format that works: item name, the requester, the tradeoff accepted (what you are building instead and why), and a note on what would have to change for this to move up.

When a stakeholder sees their request on a named, reasoned list rather than a silent queue, they understand the trade. They may disagree, but they cannot say you ignored it or forgot. That is how you build trust in a prioritization process rather than just managing a backlog. Related: prioritize-backlog-two-execs covers what happens when two executives disagree about which item belongs on that list.

Cost of Delay (for infrastructure PMs)

If you work on a platform or infrastructure product at a company like Stripe or Databricks, WSJF and Cost of Delay are worth naming alongside RICE. RICE misses urgency: a platform investment that enables three downstream features has a compounding cost of delay that a static impact score will not capture. Cost of Delay surfaces this. You do not need to recite the formula, but naming that you distinguish between urgency and impact signals genuine infrastructure PM fluency.