转载

为什么我们总在做加法,却很少做减法?

  每个人都知道产品有一大堆功能其实不是什么好事,也有几百篇文章在讨论产品管理,告诉我们为什么避免功能臃肿如此重要。

  你的公司也可能像我的公司(HubSpot)一样,有着一支优秀的产品团队,由一群智商过人、目标明确的同事组成,他们关心用户体验,对产品管理中的取舍问题有自己的见解。

  那么,为什么还有这么多的产品会出现功能臃肿的情况?我们又该如何降低自己陷入这种情况之中的可能性?

  我们可以分析一下关于臃肿功能的五个“为什么”,看看它到底是如何将我们带入死胡同的。

  1. 我们为什么会有臃肿功能?

  因为我们一直在添加新功能,却很少删除旧功能。随着时间的增长,产品累积了越来越多的功能。这是个很简单的数学问题:我们只做加法,不做减法。

  2. 为什么我们一直在添加新功能,却很少删除旧功能?

  因为添加新功能比较容易。作为产品部门,我们的任务是创造一个优秀的产品,吸引一批愉快的用户。给产品添加新功能是改善产品的一个普遍办法。我们之中大多数人都有一个单子,上面写满了来自用户、潜在用户、销售团队、营销团队、客户团队还有创始人的各种改进建议。

  大部分时间里,我们都在思考单子上的哪一个功能能够带来更多的影响和资源,接着就把它添加进去。产品部门总是在受到各种批评,批评我们采用了这个创意却没有采用那个。我们的使命似乎就是不断完善产品、添加功能,好让我们满足用户的期待。

  但似乎没有哪个产品团队会因为添加了太多新功能而受到批评。因此,我们不断地、匀速地添加新功能。但更有趣的问题是,我们为什么不删除功能呢?

  因为删除功能比添加功能要难太多了。

  3. 为什么删除功能这么困难?

  因为我们很难判断哪个功能该被删除。通常没有人会要求我们把功能删除,但总是有人在推荐某些特定的功能。他们表达支持、不断游说,还往办公室送来蛋糕和饼干。

  但我敢打赌,没有人会送你点心来劝你删除一个功能。如果你正打算删除一个大限将至的功能,你更可能会像是一个为荣誉奋战的孤胆英雄。和其它那些孤胆英雄一样,英勇的战斗并不会给你带来名声、荣誉和饼干。事实上,你还可能不得不和公司内部的成员(比如销售团队)决斗,出于对不良影响的考虑,他们是断然不会让你轻轻松松删除功能的。

  4. 为什么判断哪个功能该被删除这么困难?

  因为你很难判断删除这个功能是否值得。

  有些用户可能还在用着这个功能,有些可能还特别喜欢这个功能,有些甚至是冲着这个功能才买了这个产品。如果你要删除这个功能,有些人可能会扬言不再购买你的产品。

  这就是产品管理如此困难的原因。你得试着在不同的时期中平衡不同群体的不同需求。有些决定从长期来看是完全合理的,但从短期来看就很难解释。

  5. 为什么你很难判断删除这个功能是否值得?

  因为删除一个功能带来的好处需要过段时间才会显现,但这个行为带来的痛苦则是立等可取的。

  况且,这个功能也不能说是“不好”。毕竟这个功能背后的理念是从一长串备选中脱颖而出的。既然添加了这个功能,就有添加它的理由,它也确实能给一些人带来好处。

  为了能被实施,理念们必须经历残酷的竞争来争夺资源,可谓是千军万马过独木桥。

  同时,我们也会认为添加这个功能所用的资源已经是沉没成本了。我们也认为沉没成本既然已经“沉没”,就应该把它清除出我们的脑子。

  那么,既然我们已经得出了这样一套理论,我们要如何解决臃肿功能的问题?

  以下是我的一些看法:

  作为产品部门,我们手中的数据是不完整的。我们努力工作,为的是所谓的“惊叹率”(利用最少的资源获得了最多用户影响的工作比率)。我们凭借着当下手头的数据和资源做出选择。但我们的选择不一定总是正确的,也不应该苛求它永远正确。

  因此,我们首先该做的,是接受这个事实:我们都会犯错,我们添加的某些功能到最后其实是臃肿无用的。

  另外,既然我们无法预知哪个功能会沦为臃肿功能,我们要如何在之后的实施中发现这个事实呢?

  答案当然是利用数据!在这个时代,我们拥有无数的数据来分析用户行为,我们应该跟踪产品中的各个功能(特别是新功能),并且分析它们的实际使用率。

  举个例子。我们都知道“设置”的作用。当我们无法决定一个功能应该这样操作还是那样实施时,我们放弃无谓的争吵,把决定权交到用户手里,这就是“设置”的作用。

  且不评论设置的这种“妥协”性质。就假设我们已经为产品添加了一个新的设置值来供用户选择。这个设置值通常有一个“默认”属性,还有一些其它不同于默认的可调整项目。

  你应该判断的标准就在于:在一个统一的前提下(新设定已经添加),有多少用户会将它从默认值调整为其它数值?撑死了也只有 10%。当然并不会真的有 10%,但我们姑且就算它是 10%。这意味着,为了方便一个想要改变设定的用户,我们让其它 9 个用户的生活都复杂了一些。更别说在你的团队里,还有一大批人需要记录、支持、修正这一设定。

  从长期来看,这个行为是否值得?有可能值,更可能不值。

  但是我们就这样把它放着,想着“这是沉没成本啦,别管它了……”

  这其实是一个巨大的谬论。一个功能的大多数成本并非在于其开发早期,而是在于发布后那段长长的时光里。

为什么我们总在做加法,却很少做减法?
我认为,你应该做的有这些:

  确定一个“使用率/价值最小值”作为门槛,所有功能都必须超过这个门槛才能留下来,那些在一定时期内没能达到要求的新功能?删掉。

  只要删除合理,就要支持这个举动。要清楚虽然删除功能会带来短期的疼痛,但从长远来看是完全值得的。

  创造一个文化,鼓励“英雄”们像添加功能时一样奋斗于删除功能的战役之中。

正文到此结束
Loading...