一句话总结
你在面试中回答“优先修bug还是做新功能”时，90%的人给出的答案会让面试官直接判你出局。正确的判断不是“看情况”，而是“你必须在30秒内展示出对技术债务、用户价值、工程效率三者的量化权衡能力”。面试官要的不是你的选择，而是你如何用数据让这个选择变得显而易见。
如果你正对着面试邀请不知道怎么准备——上面只是冰山一角。完整的判断框架和追问应对都在《PM面试通关手册》里。
适合谁看
这篇内容针对三类人。第一类：正在准备FAANG或同等层级科技公司PM面试的候选人，尤其是产品经理、产品负责人、技术产品经理岗位。第二类：已经拿到面试机会，但不确定如何在“优先级权衡”这类经典题目中做出差异化回答的候选人。第三类：在面试中多次被问及“bug vs feature”但总是感觉回答流于表面、没有深度的人。
如果你以为“先修bug再开发新功能”或者“看业务优先级”这种通用回答能过关，那么你很可能已经在面试中被默默标记为“初级PM”。如果你已经有过两次以上面试失败经历，且每次都被问到类似问题，那么问题不在你的经验，而在你的回答框架。
面试官到底在考察什么？不是你的选择，而是你的权衡逻辑
面试官问“如何优先处理关键bug修复与新功能开发”，表面上是让你做个选择题。但实际在debrief会议上，面试官会向hiring committee解释的是：“这个候选人是否能在资源有限的环境下，做出有数据支撑的、可复现的决策。”
不是A： “我会评估bug的严重性和新功能的价值，然后选择优先级更高的那个。”
而是B： “我会将bug和feature都映射到同一个价值-成本坐标系中，用三个维度——用户影响范围、收入风险、工程时间成本——做量化评估，然后看哪个选项在单位工程时间内产生最大的净现值。”
具体场景：在一次Google的onsite面试中，面试官抛出一个场景——“你负责的搜索功能有一个关键bug，导致1%的用户在特定查询时看到空白页。同时，团队计划在下个季度上线一个AI驱动的推荐新功能，预计能提升5%的点击率。你只有两个工程师，一周时间，怎么选？”
候选人A回答：“我会先修bug，因为用户体验第一。”面试官追问：“如果这个bug只影响0.1%的用户呢？”候选人A卡住了。
候选人B回答：“我需要三个数据点。第一，这个bug影响的1%用户中，有多少是高频付费用户？第二，空白页导致的流失率是多少？第三，AI推荐功能的工程预估是两周还是四周？如果bug影响的用户中付费用户占比低于0.5%，且空白页流失率低于10%，而AI功能能在两周内交付并带来5%的点击率提升，那么我会选择先做新功能。同时，我会把bug修复放进下一个sprint，并在当前版本中加入一个fallback页面，减少用户损失。”
不是A： 面试官需要你给出一个“完美”的答案。
而是B： 面试官需要看到你如何在信息不完整的情况下，通过提问来补全决策所需的数据。
这个问题的核心不是“你选什么”，而是“你为什么这么选”。如果面试官继续追问“如果工程师说新功能需要三周，而bug可以在一天内修好”，你的回答必须能动态调整。一个合格的PM应该能当场画出一个2x2矩阵：横轴是工程时间（短/长），纵轴是用户影响（小/大）。bug和feature分别落在不同象限，然后根据公司当前目标（用户留存vs收入增长）做出选择。
> 📖 延伸阅读：Bolt产品营销经理面试真题与攻略2026
如何用量化框架让bug和feature变得可比？不是靠直觉，而是靠归一化
不是A： “我觉得bug更重要，因为用户会生气。”
而是B： “我把bug和feature都归一化为‘每工程天产生的用户价值’，然后加上风险权重。”
具体框架：使用“用户影响分 × 频率 ÷ 工程天数”作为基础公式。
- 对于bug：用户影响分 = 受影响用户比例 × 每次影响的程度（1-10分，例如空白页=10分，加载慢=3分）。
- 对于feature：用户影响分 = 预期使用率 × 每次使用提升的价值（1-10分）。
- 然后除以工程天数，得到每工程天的“价值产出”。
举例：
- 关键bug：影响1%用户，每次影响程度10分，工程1天。价值产出 = 0.01 × 10 / 1 = 0.1。
- 新功能：预期使用率20%，每次提升价值5分，工程20天。价值产出 = 0.2 × 5 / 20 = 0.05。
这时bug的每工程天价值是新功能的两倍，所以优先修bug。但如果bug只影响0.1%用户（价值产出0.01），而新功能使用率提升到40%（价值产出0.1），那么新功能就反超。
不是A： 这个框架是万能的。
而是B： 这个框架只是一个起点。面试官真正想看的是你是否会加入“时间衰减”和“机会成本”这两个维度。
比如，一个bug如果今天不修，下个季度用户流失率会从2%涨到5%。而一个新功能如果现在不做，竞争对手会在两个月后上线类似功能，导致我们的市场份额损失3%。这时你需要引入“延迟成本”的概念——把时间因素量化成具体数字。
具体对话场景：在Amazon的bar raiser面试中，面试官说：“你只有两个工程师，一个bug和一个feature。bug不修会导致下季度用户流失率上升2%，feature不做会导致竞争对手抢占5%的市场。你怎么选？”
普通候选人会开始比较2%和5%哪个更大。但高级候选人会反问：“用户流失的2%对应多少ARPU（每用户平均收入）？市场占有率的5%对应多少收入？这两个数字是否可以直接比较？”然后追问：“bug修复后，用户流失率能立刻降到0吗？还是只能降到1%？”这个追问暴露了bug的真实影响——很多时候修复只能缓解，不能根除。
不是A： 面试官在测试你的分析能力。
而是B： 面试官在测试你是否知道“数据永远不够，但你必须做出决策”。
一个好的回答会包含：“我会在30分钟内收集这三个数据点。如果收集不到，我会基于历史数据做最坏情况假设。比如假设bug修复只能降低50%的用户流失，而feature上线后能抢占2%的市场（悲观估计）。然后计算两者在三个月内的净收入影响。如果两者接近，我会选择工程时间更短的选项，因为这样可以更早验证假设。”
面试中常见的3种错误回答，以及为什么它们会让你被筛掉
错误1： “我永远优先修bug，因为用户体验是第一位的。”
为什么错： 这暴露了你不懂成本权衡。如果每个bug都优先，你的产品永远不会推出新功能。在面试官的debrief笔记里，这会被记录为“缺乏战略思维，无法在资源约束下做决策”。
错误2： “我会看bug的严重性和新功能的价值，然后根据经验判断。”
为什么错： “经验判断”是面试官最不想听到的词。这意味着你的决策不可复现、不可量化，也无法被团队挑战。在FAANG的hiring committee上，这种回答会被标记为“无法规模化”。
错误3： “我会让工程师来决定。”
为什么错： 这是自杀式回答。PM的核心职责就是做优先级决策。把决策推给工程师，意味着你无法承担产品方向的责任。面试官会直接认为你不适合做PM。
不是A： 这些错误是因为候选人不够聪明。
而是B： 这些错误是因为候选人不理解面试官在“看”什么。面试官不是在评估你的产品知识，而是在评估你的决策框架是否可以被复制到其他场景。
> 📖 延伸阅读：20-zh-pinduoduo-pm-interview-questions
如何在30分钟内构建一个让面试官点头的回答？不是背模板，而是用“决策树”
你不可能提前知道面试官会出什么具体场景，但你可以准备一个可复用的决策树。这个决策树有四个节点：
节点1：影响范围。 这个bug影响多少用户？这些用户是核心用户还是边缘用户？如果是付费用户，优先级自动提升。如果是免费用户且数量极少，优先级下降。
节点2：影响程度。 这个bug导致用户完全无法使用产品（崩溃/空白页），还是只是体验下降（加载慢/样式错乱）？完全无法使用的情况，无论用户数量多少，都应该优先修复——因为这会破坏信任。
节点3：工程成本。 修复这个bug需要多少工程时间？如果只需要半天，而新功能需要三周，那么即使bug影响很小，也应该先修——因为低成本高回报。反之，如果修bug需要两个月，而新功能只需要一周，那么应该先做新功能，同时给受影响用户提供workaround。
节点4：时间敏感性。 这个bug是否会在下个版本中被自然修复？这个新功能是否有关键deadline（比如配合营销活动、合规要求、竞争对手上线）？
不是A： 这个决策树会给你一个确定答案。
而是B： 这个决策树会帮你向面试官展示你的思考过程。面试官不是在等答案，而是在看你会不会问这四个问题。
具体话术：“在回答之前，我需要先了解四个关键信息。第一，这个bug影响的是哪个用户群？第二，影响程度是崩溃级别还是体验降级？第三，修bug和做feature分别需要多少工程时间？第四，这两个选项是否有时间窗口限制？如果你能给我这些信息，我可以给出具体建议。如果信息不完整，我会基于最坏情况假设来决策。”
这个回答本身就展示了你是一个系统性的思考者，而不是一个凭感觉做决策的人。
准备清单
- 量化框架练习： 每天找两个产品决策——一个来自你的工作，一个来自行业新闻——用“用户影响分 × 频率 ÷ 工程天数”公式算一遍。坚持两周，直到你能在30秒内脱口而出。
- 面试话术打磨： 准备三个版本的优先级回答——一个偏向用户保留（适用于增长期产品），一个偏向收入（适用于变现期产品），一个偏向速度（适用于初创期产品）。每个版本都要包含具体数字和假设。
- 反向面试问题： 在面试最后提问环节，问面试官：“你们团队最近一次做出‘先修bug还是先做feature’的决策是什么？当时用了什么数据？”这个问题能让你了解公司的决策文化，同时展示你的专业度。
- 模拟debrief会议： 找一位朋友扮演面试官，给你一个随机场景（比如“你的支付系统有个bug导致0.5%交易失败，同时有个新功能预计提升10%转化率，但需要三周开发”）。计时10分钟，练习你的决策树对话。录下来复盘。
- 系统性拆解面试结构： PM面试手册里有完整的“bug vs feature”优先级权衡实战复盘可以参考——包括Google、Meta、Amazon三个版本的标准答案，以及面试官在debrief会议上实际使用的评分标准。这不是模板，而是让你理解“面试官到底在听什么”的底层逻辑。
- 构建你的“决策文档”： 写一个包含以下内容的A4纸：你的量化公式、三个假设场景、两种极端情况（所有bug都优先 vs 所有feature都优先）的后果。面试时带在身上（纸质或平板），作为思考辅助。面试官看到这个，会直接认定你是一个系统性的PM。
常见错误
错误1：回答“看情况”却不展开。
BAD：“这取决于bug的严重性和新功能的价值，我会看情况决定。”
GOOD：“我需要三个数据点。第一，bug影响的用户比例和付费情况。第二，新功能的预期收入提升。第三，两者的工程时间。如果bug影响1%付费用户且工程耗时1天，而新功能需要20天才能带来5%收入提升，我会选择先修bug。但如果bug影响的是0.1%免费用户，我会选择先做新功能，同时给受影响用户发补偿邮件。”
错误2：只谈用户不谈商业。
BAD：“用户体验最重要，所以我会先修bug。”
GOOD：“用户体验和商业目标需要平衡。如果这个bug导致核心付费用户流失率上升3%，那它的商业影响可能超过新功能带来的收入增长。我需要计算两个选项的净现值。比如bug修复能避免流失3%的付费用户（假设每个用户年收入$1000，1000个用户就是$30,000），而新功能预计带来$50,000增量收入但需要三个月才能上线。那么bug的即时影响更大，我会优先修。”
错误3：低估工程师的成本。
BAD：“修bug很快，所以先修bug。”
GOOD：“我需要知道修bug和做feature的工程时间。如果修bug需要两周，而做feature只需要三天，那么我会优先做feature。因为工程师的时间是稀缺资源，我们不应该用两周的时间去修复一个影响0.5%用户的bug，而应该用三天去做一个影响20%用户的新功能。同时，我会在feature上线后，把bug修复排进下一个sprint。”
FAQ
Q: 面试官问这个问题时，我的回答应该偏向技术还是商业？
A: 偏向商业，但必须包含技术约束。面试官想看到你能在技术现实（工程时间、依赖关系、风险）和商业目标（用户增长、收入、留存）之间做翻译。一个纯商业的回答（“看ROI”）会被认为不懂工程，一个纯技术的回答（“先修bug因为技术债务”）会被认为不懂业务。正确做法是：先用商业框架定性，再用技术数据定量。比如：“从商业角度看，这个bug影响的是我们的核心付费用户群，所以优先级应该高。但我们需要工程师评估修复时间，如果修复需要三周，而一个新功能能在两周内带来双倍的用户增长，那么我会重新考虑。”
Q: 如果面试官说“没有足够数据，你必须凭直觉选”，怎么办？
A: 这本身就是陷阱。面试官在测试你是否能在信息不完整的情况下做出结构化决策。不要真的凭直觉。你可以说：“即使没有精确数据，我也可以基于历史经验做最坏情况假设。比如，假设这个bug影响的是5%的用户（行业平均），每次影响程度是7分（中高水平），工程时间假设为3天。而新功能预期使用率10%，每次提升价值5分，工程时间15天。那么bug的每工程天价值是0.05×7×0.05/3=0.058，feature的价值是0.1×5/15=0.033。所以bug优先级更高。这个假设框架可以随着数据更新而调整。”这个回答展示了即使在没有数据的情况下，你也能做出可追溯的决策。
Q: 这个问题的回答在debrief会议上会被怎么评估？
A: 面试官会用四个维度打分：决策框架的完整性（是否考虑了用户、商业、工程三个维度）、数据驱动的程度（是否用量化而非直觉）、沟通清晰度（能否让非技术听众理解）、可复现性（如果换一个场景，你的框架是否仍然适用）。如果你的回答只覆盖了其中两个维度，就会被标记为“部分通过”。如果你能覆盖所有四个维度，并且展示出你可以在30秒内完成这个思维过程，那么你会被标记为“强通过”。在hiring committee上，“强通过”意味着你不需要额外讨论，直接进入下一轮。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。