文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

几乎所有人都知道,一个产品拥有大量冗杂的功能并不是什么好事。关于有效的产品管理和为什么反对产品功能过多变得如此重要这样的话题已经有成百上千片文章报道过了。

如果你的公司恰恰像我的公司HubSpot一样的话,那你们拥有超棒的产品团队,集聚了既聪明又有很强目标性的团队成员,他们关心消费者,心思缜密,对产品管理中的经典的公平交易考虑周全。

所以,随着时间的推移,为什么会有如此多的产品变得功能过多呢?我们自己应该怎么做才能点减少掉进这个陷阱的几率呢?

作为一个思考题,我认为我可以用简单的5个“为什么”来分析产品功能过多的原因以及我们应该走哪条路。

第 1 段(可获 1.73 积分)

1.为什么我们会有功能过剩?

因为我们会定期增加新功能但很少删减功能。最终结果是,随着时间的推移,产品积累了越来越多的功能。这只是简单的算术。我们增加的功能比我们删减的要多。

2.为什么我们定期地增加功能但却很少会移除它们呢?

因为增加功能很简单。作为产品的领导者,我们的工作是构建好的产品并提高用户体验。用新功能去提升产品是个常用的方法。我们大多数都有一长串的提升产品的想法,这些都是有用户,潜在用户,销售团队,市场营销团队,客户团队,创建者等提出的。我们大多数的时间都花费在根据潜在影响和可用资源来找出哪种功能适合添加——然后添加这些功能。作为产品领导者,我们可能时不时就会因为我们选出的主意而挨批评,但却不会因为选出一些主意而被批评。我们被期待着去提升产品性能并增加用户所需要的功能。

第 2 段(可获 2.18 积分)

我认为我还没有见过一个产品团队会因为运行太多新功能而挨批。

所以,以相对固定的速度,我们一直在增加产品功能。

但是,更有趣的是:为什么我们很少删减功能?

因为删减功能的难度是增加功能的指数倍级。

3.为什么删减功能如此困难?

因为很难证明已经删减了功能。通常,没有人要求设计者们去删减东西。带着想法,总有人迫切地想要推动某些功能的实现。他们在倡导,在游说,在送你纸杯蛋糕和曲奇。

但是,我敢跟你赌一美元,没有人会用烘焙食品来引诱你去修剪某一特定功能。很有可能的是,如果你在努力地删减一种功能,而这种功能的时代又已经来临,那你就可能像孤独的英雄一样进行这场高贵的战斗,而且与很多孤独的英雄一样,你不可能得到因为你勇敢的努力而得到名声,荣誉和纸杯蛋糕。事实上,很有可能你将在公司内部就与某些因为担心这个举措会影响关闭交易的可能性而不希望你移除任何东西的人开战(例如你的销售团队)。

第 3 段(可获 2.55 积分)

4.为什么很难证明删减一种功能是正当的呢?

因为很难判断移除一种功能是否值得。

一些地方的一些用户使用这种功能。一些用户可能甚至热爱这项功能。一些人可能是因为这项功能才购买产品。如果你不保留这项功能,有人还会叫嚣着要取消交易。

这也是为什么产品管理会如此困难。你必须去尝试平衡不同成员在不同的时间跨度的不同需求。有些事情在长期上来说起着决定作用,但短期上就难以解释。

 

第 4 段(可获 1.24 积分)

5.为什么难以判断移除一项功能是否值得?

因为移除功能的回报需要一段时间才能体现,但是移除它所带来的痛苦必须现在承受。

此外,删减功能的原因不太可能是该功能不好。潜在的想法是这项功能积压一段时间了。它被从一长串其他可行的想法挑选出来。如果一项功能被添加了,那肯定是出于某种原因,也是出于迎合某些地方一些人群的需求。

为了得到实施,雏形想法必须在资源争夺的激烈的战争中存活。数百个想法进入,少数能存活。

此外……

因为我们认为花费在增加功能上的资源是沉没成本。我们根据一路所学认为,沉没成本已经沉没,我们不应该再让其影响我们的思考。

第 5 段(可获 1.73 积分)

因此,既然我们对发生了什么有了一个理论认识,我们该如何解决这个问题?

关于这个问题的一些想法:

作为产品的领导者,  我们只有我们工作时的有限资源数据。我们竭尽所能地用伟大的“工作比率”理论来筛选想法(这理论是用最少的工作赢取最大限度的顾客回头率和满意度)。我们根据我们当时所拥有的数据和资源来做决定。但是我们的选择并不总是正确的——起码并不总是能起到预期效果。

所以,第一件要做的事就是接受这个事实……

我们都会犯错误,一些我们添加的功能将会是失败的。

第 6 段(可获 1.55 积分)

此外,因为通常我们并不能肯定地预知哪些功能会失败,我们要怎样通过后面的验证来找出它们呢?(不要对我的拉丁文印象深刻——我是查词典才知道的)

回答:利用数据!如今我们生活的这个时代,大多数产品领导者都有数以亿计数据统计,能了解到我们的用户实际上会有我们建造的产品做些什么。我们会测试我们添加的功能(尤其是新添加的那些)并分析它们在用户心目中的真实用途是什么。

举个例子,你知道设置,我们都知道设置。

设计者们会展开一场关于设置该以何种方式运行的讨论,直到每个人都厌倦了争吵,最终选择让其仅仅作为一个设置来添加到产品中。把决定权交还给用户。

第 7 段(可获 1.71 积分)

我打算拒绝痛骂为什么大多数的设置都是平庸的妥协。但是假设你在你的产品中增加新的设置,让用户自行配置[X]。设置将很有可能有一个“系统默认”,然后会有一些可行操作去修改默认值。

有些数据你应该进行测量:基于队列(在设置功能被添加后),有多少用户曾经修改设置,将系统默认变为其他什么自定义的东西吗?慷慨一点来说,是10%。事实上并没有10%,但先定为10%吧。正如我刚才所说,我们慷慨地放大了数据。这就意味着,每一个曾想过要修改系统默认值,以此来希望获得一些价值认同感的用户,在另外9个用户眼中,我们复杂的生活仅仅是他们生活中很小的一部分。更不用说在团队里,所有人都要写文档,为设置提供技术支持和进行故障排除(因此就更少人会理会如何费心去修改系统默认值了)。

第 8 段(可获 1.96 积分)

长期来看,这值得吗?很有可能是,可能并不值得。

但是,我们因为我们想着“嘿,这是沉没成本……我们应该继续生活”就把它丢下。

但这是一个很大很大的谬论。

一项功能的大部分成本并不是用在其最初开发上的,而是用在功能推出后的很长一段时间内的(反馈维修调整)。

Feature_Bloat_Graph.png

这就是我认为你该做的事。

为每一项功能都设定一个“用户/价值最低限”,到达了最低限的功能才能起到该功能的作用。如果一个新功能在一段时间内还是不能成功到达最低限,那就停了它。

当删减是有意义的时候,支持这些为删减所作出的努力。承认删减功能会带来短期的痛苦,但从其长期效应来看,这很值得。

创建这样一种文化,奖励这些像增加功能那样艰苦奋斗地去删减功能的英勇的努力。

好好庆祝这种胜利!

第 9 段(可获 1.96 积分)

文章评论