5

功能下线的艺术 | 人人都是产品经理

 1 year ago
source link: https://www.woshipm.com/operate/5735471.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

功能下线的艺术

2023-01-26
0 评论 975 浏览 1 收藏 14 分钟
释放双眼,带上耳机,听听看~!
00:00
00:00

一个产品在其生命周期中总会有错误的决策,需要在过程中随时调整,所以学会删除下线功能是让产品蜕变的必经之路。如何让产品正确下线呢?一起来看一下吧。

gRK5BkfnVoeEMLdQJBJl.png

功能下线向来像是一件难以启齿的事,看似会成为产品生涯的“污点”,加上论功行赏的结果导向,增加、完善新功能往往更能得到回报与肯定,更能直接影响产品核心指标。

功能下线是在承认自己的失败,难以取得团队的支持和配合,担心引起老用户不满,被视为低优先级,少被提及的事情,不产生客诉的问题就不算是真正的问题。所以很多恶心的功能会被一直挂在产品上,需要不断投入服务于寥寥无几的用户。

一个产品在其生命周期中总会有错误的决策,哪怕如微信也走了很多的弯路。正如盖尔定律所说的,“复杂系统由简单系统演化而来,不能从零开始设计一个复杂系统。复杂系统必须随着时间推移慢慢成长,相互依存关系和变量太复杂,无法第一次就正确猜测。”

在复杂化的过程中需要保持着走一步看一步的试探心态,正确方向上大步迈进,错误方向及时重返正轨。产品设计本身就是一个逐步验证消除不确定性的过程,重点在于如何收集尽可能多的有效信息作出更有把握的决策判断,获取完备信息很难,每次都是绝对正确的判断基本不可能。

所以学会删除下线功能是让产品蜕变的必经之路,避免模糊战略定位、产品变得臃、损害用户使用体验,实事求是而不是自圆其说强势“佐证”自己的决策和付出。

01 为什么应该下线该功能

1. 难以转化成具体场景

1)需求不成立

这些需求往往是空想出来,再靠纯逻辑推导,如果自洽,就去迭代试错,也是大多数伪需求产生的原因,脱离了实际用户,未找到对应利基。

2)需求成立,解决方案不成立

基于调研确实存在潜在机会点,但处理方式无法解决实际问题,或解决方法不如竞争对手。简单系统一般只是单一功能流程的解决方式是否合理,对于复杂系统则还需考虑配套功能是否完善,与其他模块间的依赖关系,如果相互依赖功能未完善,用户完整任务路径无法走通,单一功能做得再好也无济于事。

微信曾推出过“不常联系朋友”清理功能,这一功能出发点本身没太大问题,确实大多数人都想清理下自己的好友,但好友的划分本身是一个很复杂的事情,很难仅依靠互动频次的机械规则去判断,常联系的朋友基本就是固定的几个,大多数都是泛泛之交,暗恋许久的对象没有任何互动,却有极高的分量。

3)满足猎奇尝试,缺少持续动机

这一情况是产品在推出时得到了良好反响,需求和解决方案都验证可行,但大多数用户喜欢猎奇尝试,一旦过了兴头,基本就很少继续使用。

在工具型产品上更为常见,产品理念很好,用户也乐意接受,但就未能形成习惯导致弃用,缺少真实触发使用的动机点,空有大愿景形成不了个人推动力,诸如时间管理、知识管理相关的功能。

这一情形容易被前期现象蒙蔽,不会轻易放弃一个有“前景”的功能,会试图多次迭代拯救,难点在于区分是定位问题还是迭代能解决的问题。

2. 妨碍用户使用体验

使用体验是能最直接表现出来的问题辨别方式,用户使用不顺畅则加以改进,重点需要考虑新功能提升了哪部分新体验又影响了哪部分旧体验,新体验提升的价值是否足以抵消旧体验的降低。如果严重影响到主流程的使用体验,就得三思后行。

微信推出朋友圈表情包评论,尽管引起了极大的轰动,提高了趣味性和互动活跃度,但带来了过载的评论信息,内容过多导致用户信息疲劳,严重影响动态阅览体验,破坏了原本祥和的社区氛围,该功能也就仅存活两天。

3. 维护成本过大

成本包括处理BUG的技术成本、算力运算的服务器、带宽占用成本、投入人力维持秩序的运营成本等,投入产出不对等,只能考虑将资源投入到更有价值的事情上,也能使系统更聚焦在核心功能上,提升产品竞争力。

成本是一个极其重要却容易被忽视的问题,有太多难以量化成本,如运维、客服的额外工作量以及之间的沟通成本,在手头多任务同时进行时,很难区分出单任务具体投入多少时间,况且每个人处于流程中的一部分,很少有人能完整考虑总体成本,需要有高级别决策人推进评估。

4. 与战略定位冲突

1)边界限制

系统做大后自然都会去尝试探索新领域,对原本的产品定位做适当延伸,试探新方向是否能与现有系统相兼容,产品边界在哪,如果新业务方向用户不买单就得及时止损。

微信圈子是微信向内容社交电商的发力尝试,仅仅只是从社交互动激发购买欲望,无法完成整条消费链路,缺乏电商配套基础建设,也难免草草收场,因此也流传有“腾讯没有电商基因,只有电商土壤”。

2)环境演变

部分功能会因为环境演变、战略调整中被淘汰或荣誉退休。像微信附近的人和漂流瓶这两大功能在微信初期发挥重要作用,在用户好友数量不多的情况下,作为好友拓展的重要途径,而在产品知名度上来,定位更加清晰后,固然与熟人社交核心定位不相干的功能会逐步放手,从这一角度看附近的人、漂流瓶功能也算是功成身退。(陌生社交滋生的涉黄、广告是另一方面,这基本上是所有社交平台都需要经历的宿命,存活下去需要重运营投入去维持秩序)

功能下线的艺术

来源:https://www.reforge.com/blog/unshipping-features

02 是否应该下线该功能

是否应该下线该功能,需要采用与需求分析不同的思考方式,不应该想做了会怎样,应该思考没有会怎样,避免依靠逻辑自洽来说服自己,为躲避损失厌恶而让功能得以保留。

1. 功能影响面

一般情况下通过上线后的活跃用户数、关键任务完成情况指标来衡量功能的健康程度。当数据表现不理想,需要先调研清楚为何用户没有使用起来,再去调查功能是否有存在的必要性,所有的使用动机缺失可拆分为三种:

  1. 不知:用户不知道有这一功能的存在(加强功能引导);
  2. 不会:明白功能利弊但由于操作复杂没去使用(提升使用体验);
  3. 不愿:知道功能利弊和操作,缺少触发使用场景(发掘动机场景)。

从以上三个方面考虑是否还有迭代拯救的余地,倘若该功能用户增长已到达瓶颈,并处于一个入不敷出的状态,就需要针对功能使用用户展开调研,不直接简单询问是否需要该功能,而是问没有该功能对产品的满意度(不影响还是导致减分),这样能够更好识别出用户对产品的真实依赖,避免用户说功能有用但实际压根并不怎么使用的情况,毕竟看起来“功能强大”能够更好满足欲望。

功能下线的艺术

这里还需要注意区分TOB和TOC,TOB产品还需要从管理视角考虑,管理者为了控制业务开展、规避风险、控制结果需要采取一些管理措施,部分功能需要管理层从上往下推进使用,使用用户对功能本身可能有抗拒心理,更希望没有该功能来减少自身工作量。

2. 是否与主体业务相关

用户量少不一定意味着应该放弃,还需要结合产品业务体系综合考虑,单一功能点相对薄弱,但一旦与其他配套功能结合恰当会呈现出1+1>2的效果,成为下一阶段方向发展的起点奠基,部分当前支线流程会随着产品逐渐成熟后纳入主体业务。

如果是与主体业务关联较大,则不能单纯从用户侧考虑,更倾向结合系统业务发展评估,该功能将如何为产品短中长期做出贡献。

业务流程一般可分为三大类型:

  1. 主业务流:用户主体诉求;
  2. 变体业务流:主体流程中可能引发特殊情况的独立业务流程;
  3. 支撑业务流:提供一些边缘、辅助的业务支持,锦上添花的业务。
功能下线的艺术

(其中房内消费、会员体系当前看是非重点功能,但在客户增长出现拐点的时候,就会被纳入重点)

03 如何成功下线

1)对团队内部

  • 明确产品战略定位,贯彻战略思想,审视功能和战略的匹配度;
  • 聚焦提升核心功能质量,降低多功能、多并行任务的“负债”压力;
  • 决定要现在,止损要及时,拖延决策后续投入成本会越来越高,像债务一样积累;
  • 总结从中的得与失,避免同个地方二次犯错,重新建立信心。

2)对用户

  • 开诚布公对外告知决策的原因和规划,致力提升核心业务使用体验,如有可替代解决方案一并告知(无论是本产品的其他功能还是其他产品);
  • 给予用户迁移周期和回旋余地(例如保留老用户使用,新用户不可见);
  • 限制用户使用该功能(例如先加深功能入口路径,不容易被新用户发现,提升老用户使用成本)。

承认出错,下线功能并不丢人,就像QQ邮箱的阅读空间、邮件订阅功能虽然一直不温不火,但探索了很多阅读和社交的产品形态,为公众号、朋友圈的诞生奠定了基础,这就是探索的意义。

不及时止损,导致债务积累更加不负责任,开发技术人员也不会想维护一个没什么人使用的功能,一坨乱哄哄的代码。产品不是简单的功能叠加,加法容易,减法更难,我们应该寻找足够强壮的少数功能,并使这些功能之间形成乘法效应,提升核心竞争优势。

参考文献:

《删除功能的意义及艺术》

《Upsides to Unshipping: The Art of Removing Features and Products》

《有效需求分析》

作者:一丁,“数据人创作者联盟”成员。

本文由@一个数据人的自留地 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏,鼓励TA抓紧创作!

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK