产品经理

结构：定位（几年经验、什么领域——B 端/C 端/策略/增长）→ 代表作（背景与指标、你的角色、关键决策、量化结果）→ 方法论沉淀（你做产品的独有习惯，如需求三层拆解、灰度节奏）→ 与目标岗位的连接。产品面试官最想听「决策过程」：为什么做这个、为什么不做那个、数据与用户洞察怎么支撑判断。避免功能罗列式介绍（做了 A 功能 B 功能），要讲「问题—判断—结果」的完整故事。

分层作答：先辨需求来源（用户反馈、数据异动、业务目标、老板拍板），不同来源可信度与验证成本不同；再挖本质——用户说的永远是方案不是问题，用场景还原（什么人在什么情境下遇到什么障碍）、5 Why 追问、对比行为与言语的差异（看数据做什么比听用户说什么可靠）；然后评估——频次×强度×覆盖面判断真伪与优先级（KANO 或 ICE 皆可，重点是说明权重为什么这么设）；最后用最小成本验证（原型、假门测试、灰度）。加分：举一个被你砍掉的需求及理由。

STAR 但重点在「洞察链条」：信号是什么（漏斗某步转化异常/客服高频抱怨/留存曲线分叉）→ 你怎么归因（分群下钻、用户访谈、假设排除）→ 得到什么判断（如「新用户首日没感受到核心价值」）→ 方案与取舍（为什么做引导而不做内容池）→ 结果（次留提升 X%）→ 迭代与边界（什么场景不适用）。这题是产品岗的核心区分题，讲不出归因过程的「我做了一个功能然后数据涨了」会被判定为执行者而非产品负责人。

先理解再判断：老板的信息量比你大，先弄清他看到了什么（业务压力？竞品动作？老板的老板要什么），很多「不认同」源于信息差。仍有分歧时用数据与场景说话：把两个方案的假设、成本、风险摆出来，提最小验证方案（花两天做个灰度/假门），让事实仲裁而不是立场对撞。若时间不允许验证且老板坚持：明确表达过风险后坚决执行，同时约定观察指标与回退条件。禁忌：当面不说背后抱怨、消极执行、或直接「你说啥我做啥」放弃专业判断。

好 PRD 的标准是「开发看完不用来问你」。结构：背景与目标（为什么做、成功指标是什么——这是最重要的部分，开发理解目标才能给出更优实现）→ 用户故事与流程图（异常流比主流程更重要）→ 功能详述（字段、状态、边界、埋点）→ 非功能需求（性能、兼容、权限）→ 灰度与上线计划。写作习惯：一需求一文档不搞大杂烩、变更留痕并同步影响面、提前评评审（拉上测试与核心开发过异常流）。加分：谈你如何处理评审时的分歧与 PRD 的「过时」问题（活文档 vs 版本化）。