How would you decide whether to build a feature or fix a bug (assuming both take the same engineering effort)?
Product Strategy Interview Question: If you had one sprint slot left — would you fix that long-standing bug or ship a shiny new feature? Here’s how seasoned product managers decide
It’s Monday morning. You’re mid-sprint planning. Your team has just one engineer-day left unallocated — and staring at you from the top of your backlog are two stories:
A feature request from Sales that customers have been asking about in every demo call. It unlocks a promised commitment to a prospective client.
A long-standing bug that causes the app to crash under a specific but recurring condition. Support has flagged it twice this week. A few users have even tweeted (loudly) about it.
Both items are estimated at equal engineering effort. One will delight. The other will reduce pain.
So what do you pick?
This is one of the most common yet high-stakes decisions a product manager has to make. And while the tradeoff might sound tactical, it often reveals your product values, user empathy, and business judgment.
1. How to Think Like a PM
The right answer isn’t "always fix bugs first" or "always prioritize features."
The right answer is: "It depends — but I have a framework to decide."
Here’s a 5-factor checklist I use to evaluate whether to prioritize a feature or fix a bug, assuming both require the same effort:
1. User Impact
Who is affected? Is this impacting all users, or just a niche edge case?
How severe is the impact? A visual glitch isn’t equal to data loss.
Feature Angle: Will this feature meaningfully improve core workflows or unlock a new use case?
2. Business Value
Does the feature tie to a revenue opportunity, OKR, or strategic bet?
Is the bug hurting conversion, retention, or reputation?
Will the bug cause churn or NPS drops among high-value cohorts?
3. Frequency & Visibility
How often does the bug occur? Is it a 0.1% edge case or a daily blocker?
Will users even notice this feature? Is it discoverable and relevant to their jobs-to-be-done?
4. Momentum Multiplier
Is the feature a foundation for future work? (e.g., V1 of a modular capability)
Will fixing this bug unblock other engineering work?
5. Trust & Perception
Is this bug eroding user trust in the product?
Would this feature make the product feel more modern, intuitive, or competitive?
Using this lens, I create a quick impact-effort scorecard and discuss tradeoffs with engineering and stakeholders — not just to decide, but to bring everyone along in the “why.”
3. Examples in the Wild: When to Choose What
Let’s make this real with a few examples: