何时该砍掉产品功能，以免它拖垮你的路线图

一个功能可以单凭内部情绪存活多年。创始人曾经要求过它，某个大客户曾提过一次，工程团队为其架构感到自豪，销售说它或许能帮忙促成交易——这些都不是保留它的理由。

懂得何时该砍掉产品功能是产品管理工作中不太体面的一环，而这恰恰是企业回避它的原因。发布新功能会带来看得见的活动量；移除某样东西则需要承认，时间、金钱和政治资本被押在了错误的赌注上。在人工智能、数据和基础设施类产品中，这种回避会迅速变得代价高昂。每一个低价值的能力，都会扩大需要支持、记录、保障安全、定价、销售和解释的范围。

路线图不是你公司所有良好意图的博物馆，它是一份资本配置文件。请以此对待它。

功能不等于产品

大多数功能臃肿始于一个归类错误：团队把“某项能力的存在”误当成了“产品价值的证据”。一个模型可以生成一个答案，一条数据管道可以暴露另一项指标，一个区块链系统可以支撑另一种工作流——这些都没问题。真正的商业问题是：某个具体客户是否会因此改变行为、支付更多费用、延长留存，或更深度地采用产品。

演示几乎无法回答这些问题。演示只能证明，在感兴趣的观众面前，一个受控的流程序列可以被做出来正常运转。它不能证明用户理解该功能、愿意将重要工作托付给它，或者在新鲜感消退后还会回来使用。演示催眠仍然是为无人需要的待办事项清单筹集资金的最可靠方式之一。

对于技术类产品，这种错误常常因为一种信念而被放大：可选性本身就有价值。“我们能支持那个”变成了“我们应该暴露那个”。但对公司而言的可选性，可能变成对买家而言的模糊性。如果潜在客户无法迅速理解你的产品是做什么用的，那么多余的能力就不是战略资产，而是迷雾。

何时该砍掉产品功能：证据门槛

不要因为有人不喜欢某个功能就砍掉它，而要因为证据已不再支撑保留它的成本。这份证据应当结合客户行为、商业影响和运营负担。

单纯的使用量是必要条件，但不充分。某个功能有点击量，可能只是因为它被摆在显眼位置、是某个工作流的必经步骤，或者被一小群战略意义重大的高级用户所使用。真正有用的问题是：它的使用是否与有意义的结果相关联？它是否帮助客户更快获得价值？它是否降低了流失风险？它是否提升了扩展收入？它是否消除了真实存在的部署障碍？

如果你无法用证据回答上述任何一个问题，那你管理的就不是一个功能，而是在保存一件文物。

最典型的退役候选功能通常同时具备以下几个特征：

• 在公司意图服务的客户群体中，采用率持续偏低。
• 客户仅在评估阶段使用过一次，却从未进入常规的生产工作流。
• 它出现在销售对话中，却从未改变成交率、订单规模或销售周期长度。
• 它产生的支持工单、安全义务、可靠性风险或文档工作量，与其价值完全不成比例。
• 该功能需要持续的模型调优、数据维护或基础设施支出，却没有任何一个客户愿意为此付费。

单一信号可能具有误导性，但一种模式却很少如此。正确的决策往往不是“立即砍掉”，而是“停止投入，衡量后果，再移除”。这个顺序不那么戏剧化，却更站得住脚。

从客户群组入手，而非总体使用量

总体指标会美化弱势功能。一万次表面上的互动，可能掩盖了一个事实：你最优质的客户没有一个依赖这项能力。反过来，一个仅被六个客户账户使用的功能，如果这些账户恰好代表了你的理想客户画像、一种可复制的扩展模式，或一个战略价值巨大的垂直领域，它可能就是核心所在。

把数据按客户成熟度、合同规模、部署阶段和使用场景拆解开来。对于一个人工智能工作流功能，不要只看提示词数量或生成输出的多少——客户是否采纳了输出结果？它是否缩短了处理时间？它是否成为了生产流程的一部分，还是说用户在试点结束后悄悄回到了电子表格和人工审核？

对于数据平台而言，一个仪表盘视图可能很受欢迎，只是因为人们喜欢看它，这和它真正支撑决策并不是一回事。对于区块链基础设施而言，一项受支持的集成可能在架构图上看起来很亮眼，却从未产生持续的交易量。系统不应因“技术上可用”而获得加分。

算清生存的全部成本

肉眼可见的构建成本，通常只是一个功能全生命周期成本中最小的一部分。一个看似简单的能力，可能会在工程、客户成功、安全、法务、解决方案架构和销售等各个环节形成一项永久性的税负。

这一点在人工智能功能上尤为明显。一个使用率不高的助手，可能仍然需要评估集、护栏机制、可观测性、回退策略、模型供应商管理、隐私审查，以及在其于错误时刻失效时大量不舒服的人工干预。把这样的功能称为“已经建好了”，不过是一种会计幻觉。

不妨问一个直白的问题：如果今天重新创办这家公司，以你现在所知的一切，你还会再建这个功能吗？如果答案是否定的，举证责任就已经转移了。这项功能需要靠自己赢得一席之地，而不仅仅是避免尴尬。

团队保留烂功能的四个原因

功能很少是因为数据令人信服而被保留下来的，它们之所以被保留，是因为组织已经让删除它的决定在情感上变得代价高昂。

首先，是“沉没成本剧场”。团队为几个月的工作辩护，仿佛删除功能就等于删除了从中获得的学习。事实并非如此。学习本身才是资产，代码只有在客户从中获得价值时才算得上资产。

其次，销售制造了一种“人质局面”。潜在客户问产品是否支持某项能力，这个回答在任何人检验这位潜在客户是否真实、是否有预算、是否具有代表性之前，就已经变成了路线图上的承诺。这正是一家公司变成披着SaaS外衣的定制开发作坊的方式。

第三，一个声音响亮的客户被误认成了整个市场。某个大客户要求的功能或许值得去建，但前提是这个客户会为此付费、会使用它，并且指向一个可复制的细分市场。否则，就该把它当作定制工作来定价，或者干脆拒绝。当收入把产品扭曲成了其他任何人都不想要的形状时，这笔收入未必就是好收入。

最后，管理者把“移除功能”和“客户流失”混为一谈。事实往往恰恰相反：一个核心工作流更清晰、范围更窄的产品，更容易部署、更容易让人信任，也更容易续约。客户不需要另一份菜单，他们需要的是一个结果。

退役功能，但不要引发客户的反弹

砍掉一个功能应当是一项经过管理的商业决策，而不是一条让人措手不及的发布说明。首先要找出近期实际使用过该能力的每一个客户账户，而不是技术上拥有访问权限的每一个账户。与依赖它的用户交流，你要分辨清楚，这究竟是不便，还是真实存在的工作流风险。

如果该功能为一小部分客户支撑着有价值的工作流，你还有别的选择：把它放到付费层级之后、用更窄的工作流替代它、提供导出或迁移路径，或者在明确的商业条款下暂时维持它。错误的做法，是因为弃用对话让人不舒服，就假装一个边缘功能是核心产品战略。

设定一个下线日期，并清楚地告知客户。解释清楚会有什么变化、客户应当改用什么、过渡期间会提供哪些支持。不要在诚实的解释其实是“这个功能不值得继续投入”的时候，编造一个含糊的“产品演进”故事。成熟的买家能够接受一个有原则的权衡取舍，但他们不太能容忍含糊其辞的说法，因为那会让他们怀疑还有什么其他东西也不稳定。

在内部，要在从代码库中移除功能之前，先把它从定位说明、销售资料和实施手册中移除。否则销售团队会继续推销一个工程团队已经决定放弃的东西——这不是协同一致，而是正在实时制造一个未来的续约问题。

砍掉之后该建什么

被移除的功能会腾出产能。不要立刻把它花在房间里嗓门最大的人提出的下一个请求上，而应利用这个空间去强化那些真正能建立信任和创造收入的产品行为。

这可能意味着缩短获得首次价值的时间、强化可靠性、让模型输出可审计、减少部署摩擦，或理清围绕核心用例的商业包装方式。这些事情看起来或许都不如演示里再加一个人工智能按钮那么令人兴奋，但当买家正在决定是否从试点扩展为企业级承诺时，它们通常更有价值。

能在拥挤市场中存活下来的公司，靠的不是最长的功能清单，而是能够用证据说清楚：自己比其他选择更擅长完成哪项工作，又拒绝为哪些干扰项投入资金。如果一个功能帮不了你做出这样的论证，那就给它一个体面的退场，把资源投到客户能真切感受到差异的地方。

您的领导方式在哪里有效，又在哪里正在消耗公司？

这个博客讨论的多数问题，最终都回到创始人如何经营公司这一点上。藤架领导力诊断把它拆成六个维度共24道行为锚定题：约12分钟，即时出结果，自助版免费。

开始藤架领导力诊断 →

想了解兼职高管或顾问合作？预约探索性通话 →