面试讲功能取舍时，怎么避免只讲“我做了什么”？

一位开发者复盘自己做的桌面编码应用时提到，他曾相信“规划”会成为用AI构建软件最重要的部分，于是围绕这个信念把产品做了出来。但早期用户对结构化规格文档的兴趣出乎意料地低。他后来认为，最大的错误是把计划变成了一个产物，而不是设计一个改善人类理解的过程。

这段复盘对产品岗面试很有参考价值。被问“你做过什么功能取舍”时，很多人会从需求评审讲到上线数据，听起来完整，却听不出判断力。更有效的讲法是把它当成一次假设验证：当初假设用户需要什么，实际信号是什么，你从哪个信号判断假设不成立，最后怎么调整或砍掉。 延伸阅读：产品经理面试常见问题解析

怎么判断一个功能是“用户需要”还是“团队想做”？

上面那位作者区分了 planning 和 plan：用户需要的是思考过程，不一定是团队产出的那份文档。这个区分放到面试里，比讲功能细节更有说服力。

假设你负责一个AI写作助手，团队花两个月做了“结构化大纲生成”，结果用户打开率很低。你可以这样讲：我们假设用户卡在“不知道写什么”，所以把大纲做成可导出的文档；但观察发现，用户更常在大纲页停留几秒就跳回正文，说明他们要的是边写边理清思路，而不是先产出一份规格。

注意，这是模拟场景，不是真实项目。面试里讲自己的经历时，数字和结论必须来自你实际记录过的数据，比如[实际记录]的打开率或访谈原话，不能临场编。

复盘失败功能时，怎么讲得让面试官觉得你有判断力？

不要只讲“我们做错了”。要讲清楚三件事：你从哪个具体信号发现假设不成立，当时有哪些替代选择，你最终怎么调整判断框架。

比如你可以说：发现大纲导出率低之后，我们讨论过两个方向，一是继续优化大纲模板，二是把大纲拆成写作过程中的提示。我们选了后者，因为用户的行为信号指向“过程”而不是“产物”。这个取舍不一定对，但它来自用户实际怎么用，而不是团队想做什么。

面试官想听的，往往不是你成功上线了什么，而是你能否说清一次判断为什么改变。准备时，挑一个你真正参与过的被砍功能，写下当初的假设、你看到的信号、你放弃的替代方案。哪怕结果不漂亮，只要信号和推理是真实的，就比包装过的成功故事更可信。 延伸阅读：字节跳动AI产品经理早鸟通道简历范文：如何用项目经历打动面试官？