How do you prioritize a P1 bug versus a sales-driven feature request?

WHAT THIS TESTS: This question evaluates whether you can make high-stakes trade-offs between stability and growth without relying on gut instinct or organizational politics. The interviewer wants to see if you understand that prioritization is a business decision, not just an engineering severity rating, and that the same effort can have wildly different returns depending on context. They are looking for product maturity: do you gather data, apply a framework, and communicate risk transparently.

A GOOD ANSWER COVERS: First, name a concrete framework such as an impact-effort matrix or weighted scoring model. Second, decompose the P1 bug beyond the headline one percent figure by asking whether those users are on a paid tier, whether the OS is approaching end-of-life, and whether the crash correlates with high-value accounts or churn risk. Third, pressure-test the sales request by asking for the contract value, the probability of close, whether the feature is a hard blocker or a nice-to-have, and if the customer is strategic for the roadmap. Fourth, factor in product stage: if you are pre-market and need referenceable logos, the sales feature may carry disproportionate weight, whereas if you are in a retention-focused growth phase, a crash that erodes trust could be more expensive. Fifth, outline how you would socialize the decision, including a clear rollback or mitigation plan for the deprioritized item.

COMMON WRONG ANSWERS: A red flag is automatically choosing the bug because it is labeled P1 without business context. Another is rubber-stamping the sales request because it came from leadership. Candidates who frame the decision as purely technical or purely political miss the point. Saying you would just split the team or do both simultaneously is also weak because the prompt states effort is similar, implying resource contention. Avoid answers that ignore the older OS sunset timeline or dismiss the one percent as negligible without checking revenue concentration.

LIKELY FOLLOW-UPS: The interviewer may ask what you would do if the sales deal falls through after you ship the feature, or how you would mitigate the crash if the bug is deprioritized. They might also probe whether your framework changes if the bug affects a new OS instead of an older one, or if the sales request came from a single voice versus validated demand. Be ready to discuss how you would instrument telemetry to validate the one percent figure and how you would communicate the trade-off to customer success and support teams.

ONE CONCRETE EXAMPLE: Suppose the crash affects one percent of users on Android 9, which is two percent of your user base and trending toward zero adoption, with no overlap in your top revenue accounts. The sales feature is a SSO integration requested by a prospect representing three hundred thousand dollars in annual contract value with an eighty percent close probability and a Q2 deadline. Using a weighted scoring model, the bug scores low on reach and revenue risk while the feature scores high on strategic value and certainty. You would sequence the feature for the current sprint, ship a temporary kill-switch or downgrade path for the affected OS, and schedule the bug fix for the next maintenance window with a clear SLA to the support team.

Source: singlemindconsulting.com