题干与适用场景
你负责一款 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 家近期续约客户安排一对一方案，分批迁移并设置暂停门槛。若关键缺口无法合理补齐，或者预期流失与 迁移成本高于可释放的维护和机会成本，我会保留受限版本或重新评估重做，而不是按原日期硬关。”
分步骤深入解答
第一步：把“低使用”拆成可验证的依赖。
先建立账户级清单，而不是只看一张总体仪表盘：
| 维度 | 需要回答的问题 | 对决策的影响 | |---|---|---| | 资格分母 | 多少工作区真正有权限并完成配置 | 修正 3% 是否被错误稀释 | | 使用深度 | 计划数量、成功投递、收件人和持续月份 | 区分试用者与真实依赖者 | | 工作流关键性 | 不投递会带来不便、收入损失还是合规失败 | 决定迁移优先级和通知期 | | 替代难度 | 新订阅、手工流程或第三方工具能否完成目标 | 决定迁移成本 | | 商业暴露 | ARR、续约日期、合同条款和取消意向 | 估计真实收入风险 | | 产品成本 | 维护、支持、事故、安全与路线图阻塞 | 估计保留的完整代价 |
还要访谈没有采用的客户，确认原因是没有需求、功能难发现、配置失败，还是体验不足。若低采用来自可修复的发现或 可靠性问题，而用户需求仍强，重做可能比下线更合理。
第二步：定义硬门槛，再比较选项。
最终关闭前至少要通过以下门槛：
- 使用数据覆盖了所有真实触发路径，没有明显漏数。
- 合同、法务、合规和数据保留要求已经审查。
- 高依赖工作流有可接受的替代方案或经客户确认的迁移路径。
- 用户可以导出所需历史数据，且团队实际演练过导出与恢复。
- 替代方案的可靠性、权限、无障碍和支持能力达到生产要求。
- 每个受影响企业客户都有负责人、状态和升级路径。
安全、严重可靠性或数据完整性问题可以缩短时间线，但仍要清楚说明原因与迁移办法。某些公开 API 政策会规定明确 通知期；例如 Atlassian 对公开云 REST API 的一般规则是至少保留原形式 6 个月，并对关键安全、可靠性或数据 完整性问题设置例外。这是具体政策示例，不是所有产品功能都必须照搬的统一期限。
第三步：比较维护、重做、维护模式和下线。
| 选项 | 适用条件 | 主要代价 | |---|---|---| | 继续维护 | 工作流关键、替代不可行、收入风险高于保留成本 | 技术债、支持与机会成本持续存在 | | 投资重做 | 用户问题重要，需求广泛但旧实现拖累采用 | 新投入可能重复建设新报表栈 | | 维护模式 | 现有客户仍依赖，但不应继续扩大使用面 | 需要明确支持期限，避免永久拖延 | | 迁移后下线 | 替代方案可靠，缺口可补齐，长期收益明确 | 迁移工具、客户沟通和短期双轨成本 | | 有期限例外 | 极少数高价值客户受合同或关键工作流约束 | 容易形成长期分叉，必须有负责人和终止条件 |
AWS 的公开生命周期定义提供了有用的语言：维护阶段停止新增和增强，但继续支持现有用户；sunset 阶段要求现有用户 迁往替代方案，并有明确结束日期；最终关闭后不再提供服务。面试回答可以借用这个阶段模型，避免把“宣布弃用”和 “立即删除”混为一个动作。
按题目当前证据，建议先进入维护模式，再以迁移成功为条件推进下线。原因是 3% 的总体采用率和每年约 12 人月维护 支持减少长期投入，但 18% ARR、9 家近期续约客户和 20% 能力缺口使立即关闭不可接受。
第四步：用可逆动作验证结论。
在宣布最终日期前先做四件事：
- 停止新客户启用，移除销售材料中的旧功能承诺，避免依赖继续增长。
- 让 14 家企业客户完成工作流核对，标记品牌、附件、数据留存和权限缺口。
- 选择不同依赖程度的客户做迁移试点，实际跑通配置、历史数据导出、投递和支持流程。
- 在项目启动前写下迁移门槛与暂停条件，防止团队为了既定日期忽略失败证据。
试点不只测“新页面能打开”。需要对照同一任务检查投递成功、收件人体验、附件与品牌正确性、权限、审计记录、 失败重试、支持工单和完成时间。若替代方案只覆盖简单客户，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：有两个客户要求永久保留旧功能，是否建立专属版本？
比较专属版本带来的收入与长期分叉成本，包括安全修复、基础设施、值班、测试和人员知识。优先提供标准替代、付费 迁移或有期限例外。只有合同价值和战略意义能够持续覆盖独立运行责任，而且公司愿意把它当成正式产品承诺时，才考虑 长期专属版本；不能把临时例外悄悄变成无期限遗留系统。