How Would You Prioritize Competing Feature Requests?

Prompt and Applicable Scenarios

You own a B2B collaboration SaaS product. The next iteration has only 6 engineer-weeks, but three requests cannot all fit:

• Sales proposes SSO, initially estimated at 5 engineer-weeks. One existing customer says it will expand after launch, and Sales lists 12 similar prospects.
• Support proposes bulk restore for projects archived by mistake, initially estimated at 3 engineer-weeks. The issue accounts for 18% of tickets in the last 4 weeks and affects about 8% of monthly active administrators.
• The Platform team proposes a storage migration, initially estimated at 6 engineer-weeks. The current version loses support in 9 months, while migration, observation, and rollback require at least 5 months.

All numbers are interview-case assumptions, not industry benchmarks. Explain what you would validate, how you would compare different kinds of work, which request you would choose, and what you would tell the teams whose requests were not selected. The interviewer may then change a constraint—for example, moving the storage end-of-support date forward or revealing that SSO serves only one customer—to see whether you cling to the initial conclusion.

This is a product-judgment question for product managers, product owners, and technical leads who participate in roadmap decisions. Public 2026 interview material still lists prioritizing three competing feature requests as a direct PM question. DoorDash's public PM interview guide also gives Product Prioritization its own round and looks for data, trade-offs, tough decisions, and an explicit north star at the start.

What the Interviewer Is Evaluating

The first signal is whether you establish the decision objective. Revenue, tickets, platform risk, and engineering cost cannot produce one conclusion until the team knows whether this cycle prioritizes enterprise expansion, retention, support efficiency, or a mandatory risk reduction. A strong candidate also identifies guardrails that the objective cannot override.

The second signal is whether you recognize hard constraints. Security, compliance, signed commitments, vendor end-of-support, and irreversible dependencies can form an eligibility gate. Work that has reached its latest safe start date deserves capacity before ordinary opportunities are scored. At the same time, “support ends in 9 months” does not automatically mean “start this week.” You still need to subtract migration, observation, rollback, and contingency time to calculate the latest safe start date.

The third signal is evidence quality. A sales pipeline, support-ticket ratio, and platform risk are not naturally comparable. A strong answer verifies whether the customer commitment is contractual, whether the 12 prospects have reached a comparable stage, whether the 18% of tickets share one root cause, whether the 8% of users are blocked in a critical journey, and whether each estimate includes security review, launch work, and ongoing maintenance.

The fourth signal is a decision. Saying “I would use RICE, MoSCoW, or a value-effort matrix” does not finish the prompt. Current product-practice material also warns that one framework cannot compare every kind of work. The original RICE guidance allows dependencies and market table stakes to override score order. A framework reduces blind spots; the candidate still owns the recommendation, opportunity cost, and conditions that would reverse it.

Finally, the interviewer looks for operational communication. A roadmap decision needs evidence, assumptions, an owner, dates, and review triggers. Promising every team “soon” creates three hidden commitments and provides no evidence that the candidate can manage expectations.

Clarifying Questions Before Answering

• What is the single primary outcome for this cycle? This case assumes the company prioritizes enterprise expansion this quarter, subject to the latest safe start date for the storage migration.
• What does 6 engineer-weeks mean? Is it one engineer for 6 weeks or fungible effort across several people? Does it already include review, testing, release work, and on-call duty? This case treats it as fungible total engineering effort.
• When is the latest safe start for the migration? Is 9 months a firm deadline or an early warning? How long do dual writes, validation, rollback, and contingency take? This case assumes the platform owner verifies that work can start as late as 4 months from now, but capacity must be reserved in the next planning cycle.
• How strong is the commercial evidence for SSO? Is expansion written as a contract condition? Are all 12 prospects blocked by the same capability? What are the expected value and close probability? This case assumes the existing customer's condition is confirmed and 4 of the 12 prospects have completed technical validation.
• Does the support problem deserve a product fix? Are the 18% of tickets deduplicated? Is the task critical for the 8% of administrators? Could training, permissions, or workflow design be the root cause? This case assumes bulk restore addresses the main cause and no data has been lost.
• Are the three estimates scoped consistently? Does SSO include security review and enterprise configuration? Does bulk restore include audit records? Does the migration include dual writes and a rollback drill? Estimates with different boundaries cannot be compared directly.
• Can a cheap risk test reduce uncertainty? A small technical spike can buy information, but splitting all three requests into fragments produces no outcome. This case allows a 3-business-day SSO security spike inside the 6 engineer-week budget.
• Who owns the final decision? The PM should make an evidence-backed recommendation. Signed contracts, regulatory duties, or unacceptable technical risk may require a named decision owner and escalation path.

30-Second Answer Framework

“I would confirm the cycle goal and hard constraints, especially the migration's latest safe start date. Then I would normalize outcome, evidence, effort, cost of delay, dependencies, and reversibility, scoring only comparable opportunities. Here, the migration can wait one cycle and enterprise expansion leads, so I would spend 3 business days validating SSO. If total effort stays within 6 engineer-weeks, I choose it; otherwise I switch to bulk restore. I would reserve next-cycle migration capacity, give Support a workaround and review date, and document every assumption and reversal trigger.”

Step-by-Step Deep Dive

Start by rewriting requests as outcomes instead of comparing three feature names. SSO aims to remove a blocker to enterprise expansion. Bulk restore aims to reduce administrator rework and support cost. The storage migration aims to eliminate continuity risk before a vendor deadline. Then state the cycle objective and guardrails. In this case, enterprise expansion is the objective; data safety, contractual obligations, and the migration's latest safe start date are guardrails.

Second, build a hard-constraint gate. Ask four questions for every request: Would delay violate law, contract, or a safety boundary? Is there an external hard deadline? Have we reached the latest safe start date? Can the damage be recovered later? If the answers make work mandatory this cycle, reserve that capacity before ranking ordinary opportunities. Here, the platform team has established that the migration can start as late as 4 months from now, so the gate has not fired. That conclusion still needs an owner and date; “later” is not a plan.

Third, normalize the evidence. The following table is only the current case snapshot:

“Reach evidence” should not merely repeat the requester's number. Deduplicate the sales list by stage, contract condition, and shared need. Segment support data by root cause, user group, and severity. Work backward from the platform deadline through the actual work and contingency. Missing information should lower priority confidence. Precise decimals cannot make an unsupported impact estimate reliable.

Fourth, choose a comparison method that matches the work. RICE can compare reach, impact, confidence, and effort when the candidates are feature opportunities serving one objective. Cost of delay helps when timing matters. MoSCoW can help converge on scope. When commercial opportunities, experience fixes, and foundation risk are mixed, classify and apply the gate first, then use a small scorecard for what remains. A score is an input to discussion, and every “must do” exception should have a written reason.

Fifth, make one decision. Under this case's assumptions, the storage migration has not reached its latest safe start date. SSO aligns most directly with enterprise expansion and has one confirmed expansion condition plus 4 technically validated similar opportunities. Run a 3-business-day security and scope check. If it confirms that the complete work remains within 6 engineer-weeks, allocate the cycle to SSO.

Attach two explicit switch conditions. If the full SSO scope exceeds 6 engineer-weeks, or if the expansion condition and shared market need cannot be verified, stop and switch to the 3-engineer-week bulk restore. Use the remaining capacity to validate the storage migration instead of starting a third unfinished feature. The switch rule bounds discovery and prevents sunk-cost reasoning after a few days of work.

Sixth, handle work that was not selected. Reserve 6 engineer-weeks, an owner, a start date, and a risk review for the storage migration in the next planning cycle. Reopen prioritization immediately if the vendor deadline moves forward, validation shows a longer migration, or contingency falls below the agreed buffer. Give Support a controlled manual bulk procedure, ticket tagging, and the next review date. Continue measuring severity and handling time so that a temporary workaround does not become an indefinite deferral.

Finally, define the outcome and retrospective. After SSO launches, check whether blocked customers complete configuration, the expansion condition is fulfilled, qualified opportunities progress, and authentication failures or support load remain acceptable. At the agreed evidence window, compare outcomes with the original assumptions. If value does not appear, identify whether reach, impact, confidence, or effort was misestimated. Prioritization skill includes correcting a decision, not merely defending the first call.

High-Quality Sample Answer

The recommendation below uses the prompt's fictional case data.

“I would translate the requests into outcomes first: SSO removes an enterprise-expansion blocker, bulk restore reduces administrator rework, and the storage migration controls continuity risk. I would confirm that enterprise expansion is the quarter's primary outcome while security, contracts, and the migration's latest safe start date remain guardrails.

Combining 1 customer, 18% of tickets, and a 9-month deadline into one score would be premature. The Platform team needs to work backward through migration, observation, rollback, and contingency. The case says work can safely start as late as 4 months from now, so the hard gate has not fired this cycle. I would still reserve 6 engineer-weeks and an owner for the next cycle now. Sales must verify the expansion condition and determine how many of the 12 prospects are blocked by the same SSO capability; the current evidence is 1 confirmed condition and 4 technically validated prospects. Support must show that the 18% of tickets result from missing bulk restore and separately rule out training or permissions.

Under those assumptions, I recommend SSO this cycle. It best matches enterprise expansion, and its 5 engineer-week estimate fits the budget. I would first run a security and scope check capped at 3 business days, included in the 6 engineer-week budget. If total scope still fits within 6 engineer-weeks, we continue. If it does not, or if the expansion condition and shared need are unverified, we stop and switch to the 3-engineer-week bulk restore.

Requests that are not selected still need executable answers. The migration goes onto the roadmap with a next-cycle start, named owner, and risk triggers that can pull it forward. Support gets a controlled manual process and updates severity and handling-time evidence before the next planning review. I would put the objective, evidence, assumptions, decision, and switch conditions in a one-page decision record so Sales, Support, Engineering, and leadership see the same rationale.

After launch, I would review SSO configuration completion, fulfillment of the expansion condition, sales-opportunity progress, authentication failures, and new support tickets. At the agreed review window, I would examine estimation error. If the objective or hard deadline changes, I will reprioritize; the first decision is not a permanent promise.”

Common Mistakes

• Applying RICE immediately → Unlike work is forced into one score, and a hard deadline can disappear into an average → Classify first; check legal, security, contractual, dependency, and latest-start constraints; then compare opportunities.
• Following the loudest stakeholder → Organizational power replaces user and business evidence → Normalize the evidence and record the outcome, reach, and confidence behind each request.
• Putting “support ends in 9 months” automatically first → Without working backward through migration and buffer, urgency is unknown → Calculate the latest safe start date and assign an owner and review trigger.
• Treating all 12 prospects as certain revenue → Stage, probability, and common need have not been verified → Check contract conditions, pipeline stage, and reusable value, then reduce confidence for uncertainty.
• Counting tickets alone → Duplicates, low-severity issues, and a few frequent users can distort the result → Segment by root cause, affected users, task severity, and handling time.
• Splitting the team across all three requests → None has enough completion capacity, creating three unfinished efforts and more switching cost → Choose one outcome and split out only time-boxed validation with an exit rule.
• Promising every request for the next release → Hidden commitments conflict, and the next cycle inherits the same problem → Give every unselected item a status, date, owner, and condition for reopening.
• Producing a score without a recommendation → The interviewer cannot see whether you will own the opportunity cost → State the choice, what you are giving up, why, and what evidence would reverse it.
• Calling the prioritization correct at launch → Shipping does not prove the expected value appeared → Observe the original hypothesis and review reach, impact, confidence, and effort estimates.

Follow-Up Questions and Responses

Follow-up 1: The CEO explicitly orders one item first. Do you still prioritize?

Clarify whether this is new information, a recommendation, or the final instruction, and surface any objective or constraint the CEO knows that the team does not. If the decision right belongs to the CEO, record the decision and risks and execute it. The PM should still present opportunity cost, displaced commitments, and a validation plan. A scorecard cannot overrule explicit authority, and authority does not justify hiding risk.

Follow-up 2: Evidence for all three requests is incomplete. How do you avoid endless research?

Identify the unknowns most likely to change the order and time-box them. In this case, SSO security scope and the customer condition decide whether SSO is eligible; the storage latest-start date decides whether the hard gate fires. Spend 3 business days on those variables, use ranges for the rest, and write the branch in advance: if result A, choose X; if result B, choose Y. Research should purchase decision information, not comprehensive knowledge.

Follow-up 3: How do you compare one large customer's request with many small-user problems?

Translate “large” and “many” into attributable value, reach, severity, strategic fit, confidence, effort, and maintenance burden. Test whether the large-customer request represents a reusable market-access capability, and whether the small-user problem blocks a core task. Customer count alone does not decide priority. A low-frequency problem that prevents critical work can outrank a frequent minor inconvenience.

Follow-up 4: Technical debt always loses the score. What would you do?

Express technical debt as failure probability, delivery delay, compliance exposure, labor cost, or downstream work it blocks, and show how that risk changes over time. Once it reaches an unacceptable threshold or latest safe start date, reserve hard-constraint capacity. Before then, fund bounded risk validation and explicit future capacity. A short-term revenue model is unsuitable for long-horizon foundation work.

Follow-up 5: An urgent request arrives mid-development. Do you reprioritize immediately?

Apply the same gate: security, compliance, major customer loss, or an irreversible deadline. If no hard constraint fires, compare the remaining value of finishing current work, switching cost, and the new request's cost of delay. If you reorder, document the stop point, treatment of work already done, and commitments that move. If you keep the plan, set the next review time. Track repeated interruptions separately because they may reveal unstable goals or broken intake governance.

Follow-up 6: SSO launches but produces no expansion. How do you review the decision?

Audit the decision record layer by layer: Was the commercial condition real? Did the prospects share the same need? Did customers complete configuration? Did the implementation meet enterprise security requirements? Was the observation window long enough? Then distinguish a judgment error from an execution error. If reach or impact was overstated, tighten future evidence standards. If delivery quality blocked adoption, repair the experience before judging the opportunity. The retrospective must change the next estimate; “the market underperformed” is not enough.