题干与适用场景
你负责一款 B2B 协作 SaaS，下个迭代只有 6 个工程周，却收到三项无法同时完成的请求：
- 销售提出 SSO，初步估算 5 个工程周；1 个现有客户表示上线后会扩容，销售另列出 12 个同类潜在客户。
- 客服提出“批量恢复误归档项目”，初步估算 3 个工程周；相关问题占近 4 周工单的 18%，涉及约 8% 的月活管理员。
- 平台团队提出存储迁移，初步估算 6 个工程周；当前版本将在 9 个月后停止支持，迁移、观察和回退至少需要 5 个月。
以上数字都是面试案例假设，不代表行业基准。你需要说明会核验什么、怎样比较不同类型的工作、选择哪一项，并向没有被选中的团队交代后续安排。面试官可能进一步改变条件，例如把存储停止支持提前，或发现 SSO 只服务一个客户，观察你是否会机械坚持第一次结论。
这是一道产品判断题，适合产品经理、产品负责人和需要参与路线图决策的技术负责人。2026 年公开面试材料仍直接把“在三个冲突功能请求中排序”列为产品题；DoorDash 的公开产品经理面试指南也把 Product Prioritization 设为独立环节，关注数据、取舍、艰难决策和开场时建立目标。
面试官考察点
第一项是能否先确定决策目标。没有目标时，收入、工单、平台风险和工程成本无法放在同一结论里。候选人需要问清当前周期究竟优先企业扩张、留存、支持效率，还是必须消除经营风险，并指出哪些护栏不能被目标覆盖。
第二项是能否识别硬约束。安全、合规、合同承诺、供应商停止支持和不可逆依赖可能构成准入闸门。一项工作若已到最晚安全启动时间，就应先保障它，而不应与普通机会一起算平均分。相反，“9 个月后停止支持”也不能自动等于“本周立刻做”；还要扣除迁移、观察、回退和缓冲时间，算出最晚安全启动日。
第三项是证据质量。销售给出的客户名单、客服工单比例和平台风险并非天然可比。强回答会核验客户承诺是否有合同条件、12 个潜客是否真正进入相同阶段、18% 工单是否由同一根因造成、8% 用户是否处于核心旅程，以及工程估算是否包含安全评审、上线和维护成本。
第四项是做出选择。只说“用 RICE、MoSCoW 或价值—成本矩阵”仍未完成题目。当前的产品实践材料也强调，单一框架无法覆盖性质不同的工作；RICE 的原始说明同样允许依赖项或市场准入项改变分数顺序。框架负责减少盲区，候选人仍要给出结论、机会成本和改判条件。
最后看沟通是否可执行。路线图决策需要留下证据、假设、负责人、时间点和复查触发器。给所有请求都承诺“尽快”只会制造三个隐性承诺，也无法检验候选人是否真的会管理预期。
回答前需要澄清的问题
- 本周期的唯一首要结果是什么？ 本题假设公司本季度优先提升企业客户扩张，同时不得错过存储迁移的最晚安全启动时间。
- 6 个工程周怎样计算？ 是一名工程师 6 周，还是多人并行的合计投入？是否已经扣除评审、测试、发布和事故值班？本题按可替代的总工程投入计算。
- 存储迁移最晚何时启动？ 9 个月是确定期限还是预警？迁移、双写、验证、回退和缓冲分别多久？本题假设平台负责人验证后，最晚可在 4 个月后启动，但必须在下个规划周期锁定容量。
- SSO 的商业证据有多强？ 扩容是否写入合同条件，12 个潜客是否都被同一缺口阻塞，预期价值和成交概率如何？本题假设现有客户条件已确认，12 个潜客中有 4 个完成技术核验。
- 客服问题是否值得做产品修复？ 18% 工单是否去重，8% 管理员的任务是否关键，是否存在培训、权限或流程根因？本题假设批量恢复能解决主要根因，但没有造成数据丢失。
- 三项估算的口径是否一致？ SSO 是否包含安全评审和企业配置，客服功能是否包含审计记录，迁移是否包含双写和回退演练？缺少这些内容时不能直接比较数字。
- 能否拆出低成本的风险验证？ 小型技术探索可以降低不确定性，但不能把三项工作都切成无法产生结果的碎片。本题允许先用 3 个工作日验证 SSO 的安全范围，且这部分包含在 6 个工程周内。
- 谁拥有最终决定权？ 产品经理应提出有证据的建议；涉及已签合同、监管或不可接受的技术风险时，要明确相应决策人与升级路径。
30 秒回答框架
“我先确认本周期目标与硬约束，尤其是迁移最晚启动日；再统一比较结果、证据、投入、延迟成本、依赖和可逆性，只给同类机会打分。题设下迁移可等一个周期，企业扩张优先，因此用 3 个工作日验证 SSO；总投入不超过 6 个工程周就做，否则转向批量恢复。迁移锁定下个周期容量，客服获得临时方案和复查日，全部假设与改判条件写入决策记录。”
分步骤深入解答
先把需求改写成结果，避免比较三个功能名称：SSO 希望解除企业扩张阻塞；批量恢复希望减少管理员返工和支持成本；存储迁移希望在供应商期限前消除连续性风险。然后写出本周期目标与护栏。本题假设目标是企业扩张，护栏包括数据安全、合同履约和不得错过迁移最晚启动时间。
第二步建立硬约束闸门。对每项请求回答四个问题：不做会不会违反法律、合同或安全底线；是否存在外部硬期限；现在是否已经达到最晚安全启动日；延迟后能否恢复。只要答案表明本周期必须开始，该项就先进入容量计划，剩余机会再排序。这里平台团队已经证明迁移最晚可在 4 个月后启动，因此本周期尚未触发闸门；这项结论必须有负责人和日期，不能停留在“以后再说”。
第三步统一证据口径。可以使用下面的决策表，但表中的数字只是当前案例快照：
| 维度 | SSO | 批量恢复 | 存储迁移 | |---|---|---|---| | 目标结果 | 企业扩张 | 减少返工与工单 | 降低连续性风险 | | 覆盖证据 | 1 个已确认扩容条件；4 个完成核验的潜客 | 18% 工单；8% 月活管理员 | 9 个月后停止支持 | | 证据强度 | 中 | 高 | 高 | | 总投入 | 5 个工程周，另有 3 个工作日范围验证，合计不超过 6 个工程周 | 3 个工程周 | 6 个工程周 | | 延迟成本 | 可能推迟本季度扩张 | 工单与返工继续累积 | 当前可等待一个周期，之后快速上升 | | 可逆性与依赖 | 安全范围不明时可停止 | 上线可灰度、较易回退 | 依赖多、回退成本高 |
“覆盖证据”不能只复制请求人的数字。销售名单要按机会阶段、合同条件和共同需求去重；客服数据要按根因、用户群和严重性拆分；平台期限要从最后日期倒推实际工作和缓冲。信息缺口本身也要影响排序。没有证据支撑的高影响估计应降低置信度，精确小数无法掩盖未知。
第四步选择合适的比较方式。若候选项都是同一目标下的功能机会，可以用 RICE 比较覆盖、影响、信心和投入；若关注时间损失，可以加入延迟成本；若是范围收敛，可以用 MoSCoW。混合了商业机会、体验修复和基础风险时，先分类与过闸门，再用较小的评分表比较剩余选项。分数是讨论输入，任何“必须做”的例外都应写明原因。
第五步必须作出单一决定。按本题假设，存储迁移尚未到最晚安全启动点，SSO 与当前企业扩张目标最一致，且存在一项已确认扩容条件和 4 个完成核验的同类机会。因此先进行 3 个工作日的安全与范围验证；验证确认总投入不超过 6 个工程周，就把本周期容量给 SSO。
这个决定附带两个明确的切换条件：若 SSO 完整范围超过 6 个工程周，或扩容条件与共同需求无法被证实，就停止投入并切换到 3 个工程周的批量恢复；剩余容量用于验证存储迁移，不临时塞入第三个半成品。切换条件使探索有上限，也防止团队因为已经投入几天而陷入沉没成本。
第六步处理没有入选的工作。平台迁移需要在路线图上锁定下个周期的 6 个工程周、负责人、启动日和风险复查；若供应商期限提前、验证发现迁移实际需要更久，或安全余量低于约定值，就立即重开优先级。客服团队获得批量操作的受控人工流程、工单标记和下一次评审日期，同时继续采集严重性与耗时，不能用临时方案无限延期。
最后定义结果与复盘。SSO 上线后观察被该能力阻塞的客户是否完成配置、扩容条件是否兑现、销售周期是否推进，并监控认证失败和支持负担。达到预先约定的证据窗口后，核对最初假设；若价值没有出现，记录误判来自覆盖、影响、信心还是投入估算。优先级能力包含纠正决策，不能只包装第一次选择。
高质量示范回答
以下结论基于题目给出的虚构案例数据。
“我会先把三个请求翻译成结果：SSO 解除企业扩张阻塞，批量恢复减少管理员返工，存储迁移控制连续性风险。然后确认本季度的首要目标是企业扩张，同时安全、合同和迁移最晚启动日属于护栏。
我不会直接把 1 个客户、18% 工单和 9 个月期限拿来算总分。平台团队需要从期限倒推迁移、观察、回退与缓冲；题设确认最晚可在 4 个月后启动，所以本周期还没触发硬闸门，但我会立即锁定下个周期的 6 个工程周和负责人。销售需要证明扩容条件，并核验 12 个潜客里有多少真的被同一种 SSO 能力阻塞；当前有 1 项已确认条件和 4 个完成技术核验的潜客。客服则要证明 18% 工单来自缺少批量恢复，并单独排除培训或权限问题。
在这些假设下，我建议本周期选择 SSO。它最贴合企业扩张目标，5 个工程周也在容量内。我会先做一个最多 3 个工作日的安全和范围验证，这段投入包含在 6 个工程周中。若验证后总范围仍不超过 6 个工程周，就继续交付；若超限，或者客户扩容条件和共同需求没有被证实，就停止并切换到 3 个工程周的批量恢复。
没有入选的请求也要得到可执行答案。迁移会写入路线图，明确下个周期启动、负责人和提前重排的风险触发器；客服会先使用受控人工流程，并在下一次规划前更新问题严重性与处理耗时。我会把目标、证据、假设、决定和切换条件写进一页决策记录，让销售、客服、工程和管理者看到同一套依据。
上线后，我会核对 SSO 配置完成、扩容条件兑现、销售机会推进以及认证失败和新增工单。到约定窗口后复盘估算误差。如果目标或硬期限变化，我会重新排序；初次决定不应成为永久承诺。”
常见错误
- 上来就套 RICE → 不同性质的工作被强行量化，硬期限可能被平均分掩盖 → 先分类并检查法律、安全、合同、依赖和最晚启动日，再比较机会。
- 谁声音最大就先做谁的需求 → 组织权力替代了用户与业务证据 → 统一证据口径，记录请求背后的结果、覆盖和置信度。
- 把“9 个月后停止支持”直接排第一 → 没有倒推迁移与缓冲，无法判断真实紧迫性 → 计算最晚安全启动日，并给出负责人和复查触发器。
- 把 12 个潜客都当成确定收入 → 机会阶段、成交概率和需求共性没有核验 → 检查合同条件、销售阶段和可复用价值，并降低不确定估计的置信度。
- 只统计工单数量 → 重复工单、低严重性问题和少数高频用户会扭曲判断 → 按根因、受影响用户、任务严重性和处理时间拆分。
- 把团队拆成三份同时开始 → 每项都缺少完成容量，产生三个半成品和更多切换成本 → 选择一个结果，只拆有明确时间盒与退出条件的验证工作。
- 所有请求都答应“下个版本” → 隐性承诺互相冲突，下一轮仍无法取舍 → 为未入选项给出明确状态、日期、负责人和重开条件。
- 给出分数却不做决定 → 面试官看不到候选人是否愿意承担机会成本 → 说出选择、放弃什么、为什么，以及什么证据会让你改判。
- 上线即宣布优先级正确 → 交付完成不等于预期价值出现 → 按最初假设观察结果，并复盘覆盖、影响、信心和投入估算。
追问及应对
追问一：CEO 明确要求先做某一项，还需要排序吗？
先确认这是信息输入、决策建议还是最终指令，并补齐 CEO 掌握而团队未知的目标或约束。若决定权确实属于 CEO，就记录决定与风险，团队负责执行；产品经理仍应提供机会成本、受影响承诺和验证方案。用一张评分表对抗明确的决策权没有价值，隐瞒风险同样失职。
追问二：三项数据都不完整，怎样避免一直研究？
找最可能改变排序的未知项，设置时间盒。这个案例中，SSO 安全范围和客户条件会直接决定它能否入选；存储最晚启动日决定是否触发硬闸门。先用 3 个工作日验证这些变量，其余使用范围估计，并提前写好“结果 A 选什么、结果 B 选什么”。研究要买到决策信息，不能追求全面资料。
追问三：一个大客户需求和很多小用户问题怎样比较？
把“大”和“多”拆成共同结果：可归因价值、覆盖、严重性、战略匹配、信心、投入与长期维护。检查大客户需求是否代表可复用的市场准入能力，也检查小用户问题是否阻塞核心任务。客户数量本身不负责结论；一项低频但阻断关键工作的问题，可能高于一项高频轻微不便。
追问四：技术债总在评分中落后，怎么办？
技术债需要翻译成故障概率、交付延迟、合规风险、人员成本或被阻塞的后续工作，并标出风险随时间怎样变化。达到不可接受阈值或最晚启动点后，它进入硬约束容量；尚未达到时，可以安排有限的风险验证和明确的保留容量。长期基础工作若只用短期收入评分，模型本身就不适用。
追问五：开发中途出现紧急需求，是否立即改优先级？
先用同一闸门判断它是否涉及安全、合规、重大客户损失或不可逆期限。未触发硬约束时，比较完成当前工作的剩余价值、切换成本和新需求的延迟成本。若改排，明确停止点、已投入如何处理以及哪些承诺被移动；若不改，也写出下一次复查时间。频繁插队需要单独统计，因为它可能说明目标不稳定或入口治理失效。
追问六：选中的 SSO 上线后没有带来扩容，怎样复盘？
按决策记录逐层核对：销售条件是否真实、潜客是否共享同一需求、客户是否完成配置、实现是否满足企业安全要求、观察窗口是否足够。然后区分判断错误与执行错误。若覆盖或影响被高估，更新今后的证据标准；若交付质量阻断采用，先修复体验再评价机会。复盘结果要改变下一轮估算，不能只写“市场不及预期”。