How would you decide whether to build a feature or fix a bug (assuming both take the same engineering effort)?
- Jane Winfred
Clarify:
- Type: does the feature/bug address security or privacy vulnerabilities
- Was the bug introduced recently and how long it has been when we discovered the bug
- Are the bug/feature serve internal performance/system impacts or are they customer-impacting (platform Vs consumer)
- Is there a quarterly theme that the company is focused upon e.g. experience, retention, revenue
Assuming that the bug was recently discovered and both bug and feature are customer impacting.
I would like to assess the reach, impact and confidence level for both the bug/feature.
REACH: Do we have the quantitative data for number of customers that the bug is encountered or new feature that would be exposed to
IMPACT: I would look at some external and internal factors
- External:
- Competition: may also launch such feature and we want faster time to market for early bird advantage and retain/attract more users
- Regulatory: new gov. policy/requirement (e.g. GDPR) with a deadline
- Marketing: new promotions for upcoming sales event such as prime day, black Friday to improve sales/GMV
- Customer feedback: from our superfans (B2B) or internal employees (B2C)
- Internal
- Synergy: Does the bug/feature helps in building other features.
- Data: Does the bug/feature provide helps in capturing more data to understand behavior and minimize risk of our decisions
- Dependancies: third parties, customer training
- Risk(rollback effort)
Based on this information, I will assess the impact from low (1), medium (2), high(3)
Confidance: if we have quantitative data available for both reach and impact, would term confidence as High (1), Medium (0.8) and Low(0.5)
I would compare Reach*impact*confidance to decide whether to fix bug or build feature (based on higher magnitude)
Security, regulatory, PII, PHI concerns would trump the reach factor. I would work with legal partners to understand the risk.

Meta