产品经理面试：如何决定是否下线一个功能？

题干与适用场景

你负责一款 B2B 数据分析 SaaS。旧版“定时 PDF 邮件”功能只有 3% 的活跃工作区每月使用，但实际使用者包括 14 家企业客户，合计占公司 ARR 的 18%。其中 9 家将在未来 6 个月续约。这个功能依赖旧渲染器，每季度约消耗 3 人月维护，并产生 22% 的报表类支持工单。

公司已经上线新的仪表盘订阅功能，可以覆盖旧功能约 80% 的工作流，但暂不支持自定义品牌和附件投递。请决定应当 继续维护、重新投入、停止新增用户，还是最终下线旧功能，并说明需要验证的数据、迁移方案、沟通节奏、成功指标与 暂停条件。

题目中的数字都是面试假设，不是行业基准。3% 的使用率不能直接推出“应该删除”，18% 的 ARR 也不能直接推出 “永远保留”。候选人要识别低采用率背后的依赖强度，比较保留与迁移的完整成本，并把一次不可逆的删除拆成可以 验证、可以暂停的决策阶段。

2026 年的产品经理面试题库仍会直接询问候选人应改进哪个产品、取消哪个产品；产品面试评分资料也直接要求说明如何 基于数据下线功能、区分低使用与小众高价值、处理阻力并降低用户中断。本题归类为 product，因为核心考察能力是 产品组合取舍、客户分层、生命周期决策和跨职能执行。

面试官考察点

第一，是否会先检查数据定义。强回答会追问“3%”的分母是否为所有活跃工作区、具备该套餐权限的工作区，还是已经 完成配置的工作区；还会检查邮件是否通过 API、管理员代发或其他未被埋点覆盖的路径触发。错误分母或漏数会让整个 结论失效。

第二，能否区分采用率与依赖价值。每月只发送一次的合规报表可能频率很低，却是客户完成审计或董事会汇报的关键 步骤。需要按工作流关键性、替代难度、账户价值、合同承诺和续约时间分层，不能只看平均使用次数。

第三，是否比较多个真实选项。答案不应只有“保留”或“删除”：

• 继续维护现状；
• 投资修复或重做旧功能；
• 进入维护模式，停止新客户启用但继续服务现有依赖者；
• 通过迁移桥接补齐替代方案缺口；
• 分阶段下线，并为极少数客户设置有期限的例外。

第四，是否把迁移当成产品交付。宣布日期不等于完成迁移。高质量回答会定义替代方案的能力差距、客户负责人、数据 导出、迁移工具、通知确认、支持路径、分批关闭和回滚门槛。

第五，能否处理商业与产品完整性的冲突。14 家客户占 18% ARR，说明立即硬关闭风险很高；但它每年消耗约 12 人月维护，还阻碍新报表栈收敛。候选人需要给出当前建议和改变建议的证据条件，不能用一句“客户重要”或 “技术债太高”结束。

回答前需要澄清的问题

• 3% 的分母和埋点可靠吗？ 若只统计 UI 点击，却漏掉计划任务、API 或管理员配置，必须先修正数据再决策。
• 客户用它完成什么任务？ 合规归档、对外客户交付、内部周报和偶尔试用的中断成本完全不同。
• 14 家企业客户的依赖深度如何？ 需要区分真实持续使用者、偶尔使用者和已经可以迁移但尚未行动者。
• 18% ARR 是相关收入还是可归因收入？ 客户使用该功能不代表全部合同价值都由它驱动，要确认取消意向、续约

风险和合同承诺。

• 替代方案缺少的 20% 是什么？ 若自定义品牌和附件投递是关键合同要求，80% 覆盖不能支持下线；若能用短期

迁移桥接解决，结论会改变。

• 旧功能的完整成本是什么？ 除 12 人月年度维护外，还要看事故、支持、安全、无障碍、基础设施和阻塞路线图

的机会成本。

• 是否存在安全、合规或数据完整性风险？ 严重风险可能要求加速关闭；普通维护成本则不能跳过合理通知和迁移。
• 合同和客户通知有什么约束？ 续约、服务条款和采购承诺会决定公告日期、例外和最终关闭节奏。

30 秒回答框架

“我不会根据 3% 使用率直接删除，因为使用者包含占 18% ARR 的企业客户，而且替代方案还有关键能力缺口。我会 先验证埋点和分母，再按工作流关键性、迁移难度、合同与续约风险对 14 家客户分层。

按当前信息，我会立即停止向新客户销售和启用旧功能，让它进入维护模式；同时用 4 周左右的依赖审计和迁移试点 确认品牌与附件缺口能否补齐。只有替代方案通过关键工作流、数据导出、可靠性和合同审查，并且高依赖客户达到预先 定义的迁移门槛后，我才宣布最终下线日期。

执行上会为 9 家近期续约客户安排一对一方案，分批迁移并设置暂停门槛。若关键缺口无法合理补齐，或者预期流失与 迁移成本高于可释放的维护和机会成本，我会保留受限版本或重新评估重做，而不是按原日期硬关。”

分步骤深入解答

第一步：把“低使用”拆成可验证的依赖。

先建立账户级清单，而不是只看一张总体仪表盘：

还要访谈没有采用的客户，确认原因是没有需求、功能难发现、配置失败，还是体验不足。若低采用来自可修复的发现或 可靠性问题，而用户需求仍强，重做可能比下线更合理。

第二步：定义硬门槛，再比较选项。

最终关闭前至少要通过以下门槛：

1. 使用数据覆盖了所有真实触发路径，没有明显漏数。
2. 合同、法务、合规和数据保留要求已经审查。
3. 高依赖工作流有可接受的替代方案或经客户确认的迁移路径。
4. 用户可以导出所需历史数据，且团队实际演练过导出与恢复。
5. 替代方案的可靠性、权限、无障碍和支持能力达到生产要求。
6. 每个受影响企业客户都有负责人、状态和升级路径。

安全、严重可靠性或数据完整性问题可以缩短时间线，但仍要清楚说明原因与迁移办法。某些公开 API 政策会规定明确 通知期；例如 Atlassian 对公开云 REST API 的一般规则是至少保留原形式 6 个月，并对关键安全、可靠性或数据 完整性问题设置例外。这是具体政策示例，不是所有产品功能都必须照搬的统一期限。

第三步：比较维护、重做、维护模式和下线。

AWS 的公开生命周期定义提供了有用的语言：维护阶段停止新增和增强，但继续支持现有用户；sunset 阶段要求现有用户 迁往替代方案，并有明确结束日期；最终关闭后不再提供服务。面试回答可以借用这个阶段模型，避免把“宣布弃用”和 “立即删除”混为一个动作。

按题目当前证据，建议先进入维护模式，再以迁移成功为条件推进下线。原因是 3% 的总体采用率和每年约 12 人月维护 支持减少长期投入，但 18% ARR、9 家近期续约客户和 20% 能力缺口使立即关闭不可接受。

第四步：用可逆动作验证结论。

在宣布最终日期前先做四件事：

1. 停止新客户启用，移除销售材料中的旧功能承诺，避免依赖继续增长。
2. 让 14 家企业客户完成工作流核对，标记品牌、附件、数据留存和权限缺口。
3. 选择不同依赖程度的客户做迁移试点，实际跑通配置、历史数据导出、投递和支持流程。
4. 在项目启动前写下迁移门槛与暂停条件，防止团队为了既定日期忽略失败证据。

试点不只测“新页面能打开”。需要对照同一任务检查投递成功、收件人体验、附件与品牌正确性、权限、审计记录、 失败重试、支持工单和完成时间。若替代方案只覆盖简单客户，80% 的说法仍没有被验证。

第五步：给每个群体不同的迁移路径。

可以把账户分为四组：

• 已无真实使用：停止展示，保留公告与数据导出入口；
• 低依赖且替代完整：提供自助迁移和提醒；
• 高依赖但缺口可桥接：由客户成功和产品团队共同迁移；
• 受合同或关键缺口阻塞：进入有期限例外，明确补齐、续约或退出决策日期。

公告需要说明发生什么、为什么、最后使用日期、替代方案、迁移步骤、数据获取方式和支持渠道。高价值客户不能只收到 群发邮件；负责人要确认客户已理解影响，并记录是否接受迁移计划。若功能包含 API 或自动化入口，还应在接口响应、 变更日志和开发者文档中提供可检测的弃用与结束信息。

第六步：设置阶段门和暂停条件。

一个可执行的节奏是：

暂停条件包括：关键工作流无法完成、数据导出不完整、替代方案可靠性不合格、支持负担显著超出计划、客户取消意向 超出预设风险边界，或出现未解决的合同与合规问题。暂停不等于无限期保留；团队要重新选择补齐缺口、延长某一批次、 提供有期限例外，还是改变最终建议。

第七步：比较完整经济性。

保留侧至少包含每年约 12 人月维护、22% 报表类支持工单、旧渲染器的基础设施与事故风险，以及工程团队不能投入 新报表栈的机会成本。下线侧包含替代能力开发、迁移工具、客户成功与支持投入、短期双轨运行，以及可能的折扣、流失 或合同补偿。

18% ARR 不能全部记作“下线损失”。需要估计哪些客户会因为缺口取消、哪些会迁移、哪些只需要协助。也不能把 12 人月全部记作“下线收益”，因为新方案仍有维护成本。用情景区间比较：

• 关键缺口能否低成本补齐；
• 多少相关收入真正存在流失风险；
• 双轨运行持续多久；
• 释放的工程能力将投入什么更高价值工作；
• 有期限例外会不会让旧栈成本无法下降。

第八步：用迁移结果验收，而不是用关闭日期验收。

主指标应围绕依赖工作流迁移完成率，而不是公告发送率。可以跟踪：

• 真实依赖账户和计划任务的迁移完成率；
• 新方案上的投递成功率与关键任务完成率；
• 旧功能剩余活跃使用和未确认账户；
• 报表类支持工单、迁移求助和升级事件；
• 受影响客户的续约、取消意向与合同风险；
• 历史数据导出成功和数据保留完成情况；
• 旧栈事故、维护人月和最终释放的工程能力。

最终关闭后还要删除后台任务、入口、权限、功能标记、文档、销售承诺、支持手册、监控告警和不再需要的数据副本， 并按既定保留规则处理历史数据。只隐藏按钮却保留全部运行责任，没有实现下线的主要价值。

高质量示范回答

“我会先挑战 3% 这个数字。分母应该是具备权限并有相关报表需求的工作区，还要确认 UI 之外的计划任务和 API 触发有没有漏数。然后我会把 14 家企业客户按工作流关键性、替代难度、合同承诺和续约日期分层，因为每月一次的 合规报表频率低，但可能非常关键。

按当前信息，我不会立即关闭。这个功能占用每季度 3 人月并产生 22% 的报表类工单，长期保留有明显成本；但使用者 占 18% ARR，9 家即将续约，而且替代方案缺少品牌和附件能力。我的建议是先进入维护模式：停止新客户启用和销售 承诺，只修复严重问题，同时启动依赖审计与迁移试点。

我会先确认品牌和附件是不是合同或关键任务要求，再让不同依赖程度的客户实际迁移。试点要验证投递、权限、审计、 失败恢复、历史数据导出和支持流程，而不只是功能列表。每个企业客户都有负责人，近期续约客户采用一对一方案。

最终日期只会在替代方案通过关键工作流、合同与合规审查完成、数据可导出，而且高依赖客户达到预设迁移门槛后公布。 执行时先迁移低风险账户，再处理企业账户；出现关键任务失败、导出不完整、可靠性问题或不可接受的取消风险时暂停 下一批。

经济上我会比较保留旧栈的 12 人月年度维护、支持、事故和路线图机会成本，与补齐替代方案、迁移、双轨运行和潜在 流失成本。18% ARR 不是全部都会流失，12 人月也不会全部变成净收益，所以会用区间和客户证据更新结论。

如果关键缺口可以合理桥接，我会推进分阶段下线；如果缺口是无法替代的合同要求，或迁移导致的预期损失持续高于 释放价值，我会保留受限版本或重新评估重做。关闭后还要清理任务、代码、文档、销售材料、告警和数据责任，确保团队 真的退出旧栈。”

常见错误

• 看到 3% 就决定删除 → 分母、频率与工作流关键性可能被误读 → 先验证数据，再按依赖强度分层。
• 看到 18% ARR 就永久保留 → 相关收入不等于可归因收入，且技术与机会成本会持续累积 → **验证真实取消风险并

比较完整经济性。**

• 把 80% 覆盖当成可以迁移 → 缺少的 20% 可能正是合同或合规阻塞项 → 逐个工作流验证，不用功能数量替代。
• 只给保留或删除两个选项 → 忽略维护模式、迁移桥接和有期限例外 → 把不可逆删除拆成阶段决策。
• 先公布日期再设计替代方案 → 团队会被日期绑架并忽略失败证据 → 先定义门槛、试点与暂停条件。
• 给所有客户发送同一封邮件 → 高依赖企业客户需要确认影响、负责人和升级路径 → 按依赖和商业暴露设计沟通。
• 用公告发送率衡量成功 → 客户可能收到消息却没有完成迁移 → 跟踪工作流迁移、任务成功和护栏指标。
• 关闭 UI 后停止项目 → 后台任务、代码、数据、文档和销售承诺仍会产生责任 → 完成全生命周期清理与复盘。

追问及应对

追问 1：最大客户表示下线就会取消合同，怎么办？

先验证这是明确的取消条件、谈判立场，还是对迁移风险的担忧。拆出客户真正不可替代的工作流、合同条款和收入暴露， 再比较补齐缺口、提供迁移服务、有期限例外或保留受限版本的成本。单个大客户可以改变节奏，但不能自动获得无限期 例外；任何例外都要有价格、支持边界、负责人和结束条件。

追问 2：旧渲染器出现严重安全漏洞，还能按原迁移节奏吗？

不能机械沿用原时间线。安全负责人先评估能否隔离、修补或限制暴露；若风险无法接受，应停止新任务、缩小可用范围， 甚至加速关闭。同时仍要提供数据导出、替代流程和明确解释，并记录为什么通知期被缩短。紧急风险改变节奏，不会 消除客户迁移责任。

追问 3：替代方案长期只能覆盖 80%，应该放弃下线吗？

先判断缺口对应多少真实依赖工作流，以及补齐方式是否会形成另一套旧系统。若品牌与附件可以通过窄迁移层解决， 仍可继续下线；若缺口涉及不可替代的合规或核心交付，建议会转向保留受限版本、重做关键能力或选择其他替代方案。 “80%”本身不能决定方向。

追问 4：使用数据不可靠，但工程团队急着删除旧代码，怎么推进？

先停止扩大使用面，并用日志、计划任务、API 调用、支持记录、客户成功信息和账单账户交叉核对。可以在低风险账户上 做可恢复的隐藏或迁移试点，但不能在依赖未知时永久删除。若短期仍无法建立可信清单，应把数据不确定性作为阻塞项， 而不是把“没看到使用”当成“没人使用”。

追问 5：有两个客户要求永久保留旧功能，是否建立专属版本？

比较专属版本带来的收入与长期分叉成本，包括安全修复、基础设施、值班、测试和人员知识。优先提供标准替代、付费 迁移或有期限例外。只有合同价值和战略意义能够持续覆盖独立运行责任，而且公司愿意把它当成正式产品承诺时，才考虑 长期专属版本；不能把临时例外悄悄变成无期限遗留系统。