一个产品在其生命周期中总会有错误的决策，需要在过程中随时调整，所以学会删除下线功能是让产品蜕变的必经之路。如何让产品正确下线呢？一起来看一下吧。
功能下线向来像是一件难以启齿的事，看似会成为产品生涯的“污点”，加上论功行赏的结果导向，增加、完善新功能往往更能得到回报与肯定，更能直接影响产品核心指标。
功能下线是在承认自己的失败，难以取得团队的支持和配合，担心引起老用户不满，被视为低优先级，少被提及的事情，不产生客诉的问题就不算是真正的问题。所以很多恶心的功能会被一直挂在产品上，需要不断投入服务于寥寥无几的用户。
一个产品在其生命周期中总会有错误的决策，哪怕如微信也走了很多的弯路。正如盖尔定律所说的，“复杂系统由简单系统演化而来，不能从零开始设计一个复杂系统。复杂系统必须随着时间推移慢慢成长，相互依存关系和变量太复杂，无法第一次就正确猜测。”
在复杂化的过程中需要保持着走一步看一步的试探心态，正确方向上大步迈进，错误方向及时重返正轨。产品设计本身就是一个逐步验证消除不确定性的过程，重点在于如何收集尽可能多的有效信息作出更有把握的决策判断，获取完备信息很难，每次都是绝对正确的判断基本不可能。
所以学会删除下线功能是让产品蜕变的必经之路，避免模糊战略定位、产品变得臃、损害用户使用体验，实事求是而不是自圆其说强势“佐证”自己的决策和付出。
1）需求不成立
这些需求往往是空想出来，再靠纯逻辑推导，如果自洽，就去迭代试错，也是大多数伪需求产生的原因，脱离了实际用户，未找到对应利基。
2）需求成立，解决方案不成立
基于调研确实存在潜在机会点，但处理方式无法解决实际问题，或解决方法不如竞争对手。简单系统一般只是单一功能流程的解决方式是否合理，对于复杂系统则还需考虑配套功能是否完善，与其他模块间的依赖关系，如果相互依赖功能未完善，用户完整任务路径无法走通，单一功能做得再好也无济于事。
微信曾推出过“不常联系朋友”清理功能，这一功能出发点本身没太大问题，确实大多数人都想清理下自己的好友，但好友的划分本身是一个很复杂的事情，很难仅依靠互动频次的机械规则去判断，常联系的朋友基本就是固定的几个，大多数都是泛泛之交，暗恋许久的对象没有任何互动，却有极高的分量。
3）满足猎奇尝试，缺少持续动机
这一情况是产品在推出时得到了良好反响，需求和解决方案都验证可行，但大多数用户喜欢猎奇尝试，一旦过了兴头，基本就很少继续使用。
在工具型产品上更为常见，产品理念很好，用户也乐意接受，但就未能形成习惯导致弃用，缺少真实触发使用的动机点，空有大愿景形成不了个人推动力，诸如时间管理、知识管理相关的功能。
这一情形容易被前期现象蒙蔽，不会轻易放弃一个有“前景”的功能，会试图多次迭代拯救，难点在于区分是定位问题还是迭代能解决的问题。
使用体验是能最直接表现出来的问题辨别方式，用户使用不顺畅则加以改进，重点需要考虑新功能提升了哪部分新体验又影响了哪部分旧体验，新体验提升的价值是否足以抵消旧体验的降低。如果严重影响到主流程的使用体验，就得三思后行。
微信推出朋友圈表情包评论，尽管引起了极大的轰动，提高了趣味性和互动活跃度，但带来了过载的评论信息，内容过多导致用户信息疲劳，严重影响动态阅览体验，破坏了原本祥和的社区氛围，该功能也就仅存活两天。
成本包括处理BUG的技术成本、算力运算的服务器、带宽占用成本、投入人力维持秩序的运营成本等，投入产出不对等，只能考虑将资源投入到更有价值的事情上，也能使系统更聚焦在核心功能上，提升产品竞争力。
成本是一个极其重要却容易被忽视的问题，有太多难以量化成本，如运维、客服的额外工作量以及之间的沟通成本，在手头多任务同时进行时，很难区分出单任务具体投入多少时间，况且每个人处于流程中的一部分，很少有人能完整考虑总体成本，需要有高级别决策人推进评估。
1）边界限制
系统做大后自然都会去尝试探索新领域，对原本的产品定位做适当延伸，试探新方向是否能与现有系统相兼容，产品边界在哪，如果新业务方向用户不买单就得及时止损。
微信圈子是微信向内容社交电商的发力尝试，仅仅只是从社交互动激发购买欲望，无法完成整条消费链路，缺乏电商配套基础建设，也难免草草收场，因此也流传有“腾讯没有电商基因，只有电商土壤”。
2）环境演变
部分功能会因为环境演变、战略调整中被淘汰或荣誉退休。像微信附近的人和漂流瓶这两大功能在微信初期发挥重要作用，在用户好友数量不多的情况下，作为好友拓展的重要途径，而在产品知名度上来，定位更加清晰后，固然与熟人社交核心定位不相干的功能会逐步放手，从这一角度看附近的人、漂流瓶功能也算是功成身退。（陌生社交滋生的涉黄、广告是另一方面，这基本上是所有社交平台都需要经历的宿命，存活下去需要重运营投入去维持秩序）
来源：https://www.reforge.com/blog/unshipping-features
是否应该下线该功能，需要采用与需求分析不同的思考方式，不应该想做了会怎样，应该思考没有会怎样，避免依靠逻辑自洽来说服自己，为躲避损失厌恶而让功能得以保留。
一般情况下通过上线后的活跃用户数、关键任务完成情况指标来衡量功能的健康程度。当数据表现不理想，需要先调研清楚为何用户没有使用起来，再去调查功能是否有存在的必要性，所有的使用动机缺失可拆分为三种：
从以上三个方面考虑是否还有迭代拯救的余地，倘若该功能用户增长已到达瓶颈，并处于一个入不敷出的状态，就需要针对功能使用用户展开调研，不直接简单询问是否需要该功能，而是问没有该功能对产品的满意度（不影响还是导致减分），这样能够更好识别出用户对产品的真实依赖，避免用户说功能有用但实际压根并不怎么使用的情况，毕竟看起来“功能强大”能够更好满足欲望。
这里还需要注意区分TOB和TOC，TOB产品还需要从管理视角考虑，管理者为了控制业务开展、规避风险、控制结果需要采取一些管理措施，部分功能需要管理层从上往下推进使用，使用用户对功能本身可能有抗拒心理，更希望没有该功能来减少自身工作量。
用户量少不一定意味着应该放弃，还需要结合产品业务体系综合考虑，单一功能点相对薄弱，但一旦与其他配套功能结合恰当会呈现出1+1>2的效果，成为下一阶段方向发展的起点奠基，部分当前支线流程会随着产品逐渐成熟后纳入主体业务。
如果是与主体业务关联较大，则不能单纯从用户侧考虑，更倾向结合系统业务发展评估，该功能将如何为产品短中长期做出贡献。
业务流程一般可分为三大类型：
（其中房内消费、会员体系当前看是非重点功能，但在客户增长出现拐点的时候，就会被纳入重点）
1）对团队内部
2）对用户
承认出错，下线功能并不丢人，就像QQ邮箱的阅读空间、邮件订阅功能虽然一直不温不火，但探索了很多阅读和社交的产品形态，为公众号、朋友圈的诞生奠定了基础，这就是探索的意义。
不及时止损，导致债务积累更加不负责任，开发技术人员也不会想维护一个没什么人使用的功能，一坨乱哄哄的代码。产品不是简单的功能叠加，加法容易，减法更难，我们应该寻找足够强壮的少数功能，并使这些功能之间形成乘法效应，提升核心竞争优势。
参考文献：
《删除功能的意义及艺术》
《Upsides to Unshipping: The Art of Removing Features and Products》
《有效需求分析》
作者：一丁，“数据人创作者联盟”成员。
本文由@一个数据人的自留地 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。