Bug Fix or New Feature? A Product Prioritization Framework for Equal-Effort Choices

Quick Overview

A product prioritization question asking how to choose between building a new feature and fixing a known bug when both need the same engineering effort. It tests spotting gating issues such as security or data loss, comparing reach, impact and confidence, weighing non-engineering costs and the cost of delay, and making a clear call.

Bug Fix or New Feature? A Product Prioritization Framework for Equal-Effort Choices

Company: Meta

Role: Product Manager

Category: Product / Decision Making

Difficulty: medium

Interview Round: Other

As a product manager, you have to choose between two pieces of work: building a new feature or fixing a known bug. Either one would take the same amount of engineering effort, and you can only do one of them now. How would you decide? ```hint Hold effort constant, then look again Equal engineering effort does not mean equal cost, equal certainty or equal urgency. List what still differs between the two options once effort is set aside. ``` ### Clarifying Questions - What does the bug do: is it a security, privacy, data-loss or legal problem, or a functional or cosmetic defect, and how many users hit it and how often? - Which goal does the feature serve, and must it ship by a certain date because of a partner commitment, a competitor or a regulation? - Apart from engineering, what else would each option need, such as design, research, QA, marketing or support? - Is there a workaround for the bug today, and is it getting worse over time? ### What a Strong Answer Covers - Gating cases that settle the decision immediately, such as security, privacy, legal exposure, data loss or a broken core flow, checked before any scoring. - A comparison on a common basis: reach, impact on the team's goal metric and confidence, recognizing that the bug's impact is observed while the feature's is projected. - Costs beyond engineering, and the cost of delay for each option. - Ways to avoid a pure either-or, such as a cheap mitigation or a smaller first version. - A clear recommendation, the conditions that would flip it, and how it is communicated to stakeholders. ### Follow-up Questions - The bug affects only 1 percent of users, but they are your highest-paying customers. Does your answer change? - Leadership wants the feature because a competitor just launched something similar, and your analysis favors the bug. What do you do? - How would you keep this choice from coming up every sprint, for example with a standing share of capacity for quality work?

Overview: A product prioritization question asking how to choose between building a new feature and fixing a known bug when both need the same engineering effort. It tests spotting gating issues such as security or data loss, comparing reach, impact and confidence, weighing non-engineering costs and the cost of delay, and making a clear call.

Meta logo
Meta
Oct 27, 2024
mediumProduct ManagerOtherProduct / Decision Making
0
0

As a product manager, you have to choose between two pieces of work: building a new feature or fixing a known bug. Either one would take the same amount of engineering effort, and you can only do one of them now. How would you decide?

Clarifying Questions Guidance

  • What does the bug do: is it a security, privacy, data-loss or legal problem, or a functional or cosmetic defect, and how many users hit it and how often?
  • Which goal does the feature serve, and must it ship by a certain date because of a partner commitment, a competitor or a regulation?
  • Apart from engineering, what else would each option need, such as design, research, QA, marketing or support?
  • Is there a workaround for the bug today, and is it getting worse over time?

What a Strong Answer Covers Guidance

  • Gating cases that settle the decision immediately, such as security, privacy, legal exposure, data loss or a broken core flow, checked before any scoring.
  • A comparison on a common basis: reach, impact on the team's goal metric and confidence, recognizing that the bug's impact is observed while the feature's is projected.
  • Costs beyond engineering, and the cost of delay for each option.
  • Ways to avoid a pure either-or, such as a cheap mitigation or a smaller first version.
  • A clear recommendation, the conditions that would flip it, and how it is communicated to stakeholders.

Follow-up Questions Guidance

  • The bug affects only 1 percent of users, but they are your highest-paying customers. Does your answer change?
  • Leadership wants the feature because a competitor just launched something similar, and your analysis favors the bug. What do you do?
  • How would you keep this choice from coming up every sprint, for example with a standing share of capacity for quality work?