放弃决策：产品经理如何系统性地判断一个功能不该做

一个常见的沉默成本陷阱

每次版本评审会，总有人提出一个“用户想要”的功能——看起来合理，技术上也不难，甚至竞争对手已经做了。于是排进待办，几个版本过去，开发完成，上线后发现日活几乎没有变化。运营问为什么不做推广？产品经理自己都答不上来当初为什么要做。

这不是个别现象。我在自己做产品、也看其他团队的过程中发现：多数产品死亡不是因为功能太少，而是因为功能太多，且没有人愿意主动说“不”。

“不”这个词的权重，在优先级排序中往往被严重低估。我们习惯用 RICE、WSJF 或者 Kano 模型去选“要做什么”，却很少有一张检查清单来系统地论证“是否应该放弃”。

为什么放弃那么难？

三个常见心理偏见在作祟：

1. 沉没成本谬误：已经投入讨论、设计甚至开发资源，现在放弃觉得浪费。但沉没成本不应该影响未来决策。
2. 确认偏差：团队里有人坚信这个功能能带来增长，你会下意识地只找支持证据，忽略反面信号。
3. FOMO（错失恐惧）：竞争对手有，我们没有，就会焦虑。但竞争分析只回答“别人在做什么”，不回答“我们应不应该做”。

放弃决策检查清单

我设计了一个简单的三道关卡，每道关卡回答“否”则建议放弃或至少推迟到有更多证据再启动。假设我们在讨论一个候选功能 F：

第一关：核心冲突

F 是否直接解决用户当前的核心未被满足需求？

判断依据不是用户“说”想要什么，而是用户“做”了什么。如果用户的行为数据显示大部分人卡在某个关键步骤，而 F 恰好能移除这个卡点，则通过。如果 F 只是锦上添花，或解决的是边缘场景（如 <5% 的用户抱怨），则否。

示例（假设案例）： 我们做了一款 AI 写作工具，帮助用户写英文邮件。用户反馈“想要更多的模板”，但埋点数据显示：大部分用户打开编辑器后第一件事是删除模板内容自己写。这说明真正未被满足的不是模板数量，而是用户不知道如何用 AI 生成符合个人风格的邮件。此时增加模板库是错误解，应该优先优化生成模型的个性化能力。

第二关：机会成本

如果做了 F，我们被迫不做什么？

资源是有限的。团队只有 4 个开发，每个版本只能完成 2 个中等功能。选择 F 意味着放弃候选 G、H。需要问自己：G 或 H 是否有更高的预期价值？如果 F 的预期价值不比 G 或 H 大一个级别，就应放弃。

这里可以引入一个简化的预期价值评分：价值 = (影响用户数 × 问题严重性) / (实现成本 + 维护成本)。如果 F 的分数低于当前待办中其他候选的平均分，放弃。

第三关：可跳过性

如果我们现在不做 F，三个月后用户会显著流失吗？

这一关最反直觉：很多功能即使不做，用户也不会立刻离开。他们会抱怨几句，但如果没有替代品，他们还是会用你的产品——只要核心价值还在。能够坦然接受“延迟满足”是产品经理成熟的标志。

组织如何落地“放弃”

光有检查清单不够，还需要团队共识。我的建议是在每周产品评审中固定一个环节：“放弃投票”。每个人可以提名一个现有待办任务或已上线的功能，提出“建议放弃”的理由。然后集体讨论，如果超过半数同意就正式将其移出路线图或标记为“不主动开发”。

实践中你会发现：大多数被放弃的功能，事后没有人怀念它。而省下来的时间，可以用在真正改变用户行为的事情上。

边界条件

这套检查清单不适用于：

• 合规需求（法律法规强制要求）
• 安全补丁
• 影响核心系统稳定的技术债

对于以上情况，即使检查清单全为“否”，也需要做。

写在最后

优先级排序的本质不是选什么做，而是选什么不做。学会主动放弃，比学会选择更需要勇气——因为放弃意味着承认之前的假设可能不对，意味着你愿意为更高的价值让路。

如果你下次再面对一个“还不错”的功能，先别急着排期，用上面的三关问一问自己。你会发现，大部分功能经不住拆解。

PaxLee