产品分析中，使用频率低的功能就该被删除吗？

在产品功能优化中，如果后台埋点显示有的功能使用率极低，你是否会直接删除这个功能？

很多产品经理的惯性思维是：使用率低表明用的人少，可以删掉这个功能，精简产品架构，降低研发运维的成本。

实际上真是这样吗？

一、高频≠核心，低频≠冗余

有哪些功能使用率很低却很重要？

比如账号注销，比如安全校验，再比如异常订单申诉这种小众功能。这些功能整体使用率极低。但对有需求的用户而言，如果缺失了这个功能，就无法完成关键操作，会直接引发不满、投诉甚至客户流失。可以说，这类功能是产品的体验底线。

再比如很多To B产品中，不少功能主要是为付费客户、企业大客户服务的，或是用于合规审计等等。大多数小公司或免费用户不会使用，却是增加产品商业价值的关键。

除此之外，还有一些适配小众用户的兼容功能，以及为了长期发展做的预埋功能等等，这些功能都是短期内看不到收益，但可以支撑未来的产品线升级。

当然，如果我们在迭代中只做加法，功能越堆越多，就会不断地增加产品架构的复杂度，加重研发运维负担。

我们还是要对一些功能做酌情删减。

当某些功能既解决不了用户的刚需问题，也无法给产品带来商业价值，还不能为长期的战略发展提供助益时，就可以考虑砍掉了。

另外，如果有功能常年占用大量研发和运维资源，便可以考虑做一个优化方案。

还有一些功能此前是为某类用户提供的，但可能现在对应的使用场景已经基本消失，不再有实际业务需求，那么此类功能便可以删除或合并。

当然，为了确保这种功能价值决策的科学性，对于存疑的低频需求，产品经理可以联合市场、研发、业务、运营跨团队做决策评审（类似于IPD的DCP业务决策评审）。这样结合各个岗位的业务视角，能更科学合理地校验低频需求的合理性以及长期价值。

二、如何合理处置低频功能？

第二个问题是：判断完功能价值之后，是不是只剩下保留和删除这两个选项？

可以根据功能定位，选择不同的处置方案。

第一类，兜底类功能，也就是上文说的产品体验底线。

像账号注销、应急申诉这类功能，我们可以保留最小化入口和手册说明，降低用户投诉率。这类功能不用投入大量研发资源做迭代，只需要做好基础维护，保证功能可用。

第二类，大客户专属功能。

这类能力可以做成独立功能开关。这样，普通用户打开产品看不到这个功能，只有签约的付费大客户，才可以单独开启。

不过这类功能如果要做下线调整，在下线前一定要盘点客户清单，和业务、客户经理确认，防止影响合同履约。

第三类，大客户专属功能。

这类功能如果使用频率很低，可以选择冻结迭代，放入产品路标。

原有的代码保留不动，不再新增需求开发。此后需要每季度复盘一次业务进展，如果业务长期无法落地，再重新评估做出新的方案。

第四类，确定冗余的功能。这类功能下线不能一键删除，要先观察至少两个版本周期，确认使用人群持续萎缩；再隐藏前端入口，保留底层代码，预留回滚方案；等待缓冲期结束，通知存量用户之后，在不影响当前用户体验的情况下再彻底下线。

三、如何更好地管控功能价值？

做完单次的功能甄别与优化调整远远不够，因为产品功能的价值不是一成不变的，会随着用户需求迭代、业务升级持续动态波动。

今天的低频刚需，也许明天就会变成业务增长的支点；当下看似火热的功能，也可能随业务迭代慢慢褪色。想要长期做好功能取舍，就不能只靠产品经理的个人经验拍板。

同样，很多团队在梳理需求时，零散需求散在聊天记录、文档里，一些小众场景需求很容易在迭代中被忽略，等到准备清理功能时，拿不出完整的历史背景，很难判断该不该保留。此时我们可以借助线上的需求管理工具，把分散的需求收拢起来做结构化管理。

拿禅道项目管理软件来说，产品经理可以把所有原始需求统一录入禅道需求池，完成需求归集与可视化，提前澄清需求背后的用户场景，明确每一个功能背后真实的业务价值。

在需求分析环节，团队还可以搭配KANO模型拆解需求属性，区分基础型、期望型、兴奋型需求，识别真正不可缺少的关键能力；再用MoSCoW模型完成需求分级，划分出必须实现、应该实现、可以实现、无需实现四类需求，叠加业务权重和长期战略等维度，让每一次功能取舍都有完整依据。

同时，在整个落地周期做好需求全程留痕。这样，后续复盘功能价值、评估功能下线或者迭代方案时，就可以做背景与价值的回溯。

对于需求的完整追溯与流转，有需要的产品经理们可以联系一下我们，详细地了解需求池的相关功能。

整体来讲，产品功能的取舍，并非不断做减法，应该持续在用户体验、研发成本与长期战略之间找到平衡点。一个产品是否优秀，也在于产品功能是否会在用户场景里，兑现自身的价值。