Two executives each want you to prioritize their feature. How do you decide?

A prioritization question that tests political navigation, evidence use, and conviction under pressure. Not framework recall.

"Two executives disagree on which feature to build. How do you decide?"

The question is not about picking a winner. It tests whether your prioritization holds when powerful people push on it, whether you can say no to a VP without burning the relationship, and whether you know the difference between resolving a disagreement and avoiding one. Candidates who build a RICE table and then quietly pick the more senior exec’s feature have demonstrated exactly what interviewers fear most.

What the interviewer is actually testing

Three things, in order of weight. First: does your prioritization philosophy shift under stakeholder pressure, or does it stay anchored to evidence? Second: can you structure a disagreement so both execs understand the tradeoff, even the one who loses? Third: do you know how to be wrong gracefully, meaning can you name what would cause you to revisit the decision?

RICE was created at Intercom specifically because stakeholder pressure, not data, was driving feature selection. Sean McBride’s original framing: if a feature scores low, the framework gives you a tool to push back in a more reasoned way. That is the exact use case this question is testing.

The two sub-types

Before answering, identify which scenario you are in.

Two execs with different user hypotheses. One believes users want feature A; the other believes users want feature B. Resolution path: which hypothesis has better evidence? User research, usage data, and conversion signals adjudicate this, not seniority.

Two execs representing different business units or revenue lines. One exec owns enterprise; the other owns self-serve. Resolution path: which feature maps better to the product’s current OKR? This is not a user question, it is a strategic direction question, and you need the OKR to have a principled answer.

Name the sub-type in your answer. It signals that you have thought about the structure of the disagreement, not just the surface conflict.

Structure a strong answer

Anchor on the north star before touching either feature. Name the product’s current OKR or primary metric. Then run both features through the same scoring criteria: Reach (how many users in the next quarter), Impact (effect on the north star metric), Confidence (what data backs the estimate), and Effort. In 2026, effort is often low for both features because AI-assisted development has compressed build time significantly, so weight Reach and Impact heavily. If RICE does not cleanly separate them, make the judgment explicit: state which exec’s underlying user hypothesis has stronger evidence and why. Then give the losing exec something concrete, a specific signal or milestone that would trigger reconsideration of their feature. Close with the metric you would track in the first 30 days.

strong

"Before I touch either feature, I anchor to our north star: weekly active merchants completing at least one transaction. That metric is the filter everything else runs through. I run both features through the same RICE criteria using the same time horizon. In 2026, effort is rarely the deciding factor since AI-assisted development has compressed build time, so I weight Reach and Impact heavily. If the scores are close, I go back to the user hypothesis each feature rests on and ask which one has better evidence. One exec believes enterprise users want deeper reporting; the other believes self-serve users need a faster onboarding path. I look at support tickets, session recordings, and conversion drop-off data to see which problem is more acute. I pick one, state the rationale in plain terms both execs can repeat to their teams, and then I tell the exec whose feature I didn't pick exactly what metric movement or research finding would cause me to revisit the decision. I track the chosen feature against a 30-day leading indicator so I can own the outcome either way."

weak

"I'd build a phased roadmap: start with one feature, then move to the other once the first ships." This reads as conflict avoidance, not prioritization. There is no criterion connecting the phases to a success signal, no explanation of why the order is right, and no actual commitment to a tradeoff. A close second: choosing the more senior exec's feature because "they have broader context." Both answers demonstrate that stakeholder pressure, not evidence, drives your decisions. That is the primary signal interviewers are looking for, and this fails it directly.

When the framework gives you a tie

RICE sometimes produces similar scores for both features. This is not a failure of the framework; it is where judgment is actually required. If Reach and Impact are comparable, the tiebreaker is Confidence: which estimate is backed by harder data? A reach estimate based on actual usage data beats one based on a VP’s intuition, even if the numbers are identical on paper. If Confidence is also similar, go to time-criticality. WSJF weights cost of delay, which is useful when one exec’s request is tied to a market window, a competitor launch, or a contract renewal. That gives you a legitimate path to prioritizing one feature without implying the other is unimportant.

Do not pretend the framework gave you clarity when it did not. Acknowledge the tie, name which user hypothesis has stronger evidence, and state the call as a bet: “Given the support volume around onboarding, I’d back this hypothesis. We’ll know in 30-day activation if that was wrong.” That is the senior answer.

The 2026 shift: effort is not the constraint

In 2023, “we can’t do both” was often true. Engineering capacity was the binding constraint, and RICE’s Effort denominator did real work. In 2026, AI-assisted development has compressed many features from six weeks to days. That changes the calculus: if both features are buildable in the same sprint, the question is no longer which one fits in the roadmap. The question is which one has a stronger claim on user attention and market demand.

Viability: will users pay for it, and is the problem real enough that they return? Lovability: does it meet users where they are, or does it require them to change behavior to get the benefit? A candidate who anchors their argument on effort is already behind. The strong 2026 answer pivots the exec conversation from “what do we build” to “which user problem has stronger evidence of demand.” See feasibility is free and lovable, not just usable.

Companies like Stripe and Shopify depoliticize exactly these conversations by tying roadmap decisions to a single north star metric. When both execs argue against the same metric, the debate stops being about which exec wins and starts being about which feature has better evidence.

The follow-up you must prepare for

Interviewers reliably ask: “The exec whose feature you didn’t pick was unhappy. What did you do?” Candidates who ace the framework and skip this behavioral component still fail the question.

The answer has three parts. First, you gave the losing exec a concrete path before the decision was final: a named signal or milestone tied to reconsideration, not vague reassurance. Second, you followed up with data once the chosen feature shipped and shared the 30-day results with both execs, not just leadership. Third, if the chosen feature underperformed, you revisited the decision openly and did not wait for the unhappy exec to raise it. The follow-up is where the interviewer checks whether you can manage the relationship after the decision, not just during it.

The worst answer is silence. The second worst: “I escalated to my manager.” Escalating when you have data, a framework, and a recommendation is not a senior move. It is the answer of someone who picked the exec’s feature because of seniority, realized it, and needed cover.

Related: how do you prioritize your backlog covers the solo version of this question. Two metrics in conflict covers the analytical version where the disagreement is in the data, not the room.