1704233170
可能有人会觉得奇怪，怎么会有这样的功能呢？举个例子，某产品的某个二级菜单，从后台观察数据，从来没有人点击，这就是无差别功能。
1704233171
1704233172
1704233173
1704233174
1704233175
图6-10 无差别功能曲线
1704233176
1704233177
这样的功能怎么应对？当然是不要做。那么问题来了，如果不做，怎么知道它是无差别功能？所以，这里需要提一下低成本验证的概念，就是采取一些小投入的方案，来验证用户需求、验证市场，进而决定要不要做这个功能。对任何准备做的功能做取舍时，我都极力推荐低成本验证的方法。
1704233178
1704233179
美国有一个鞋类电商网站，叫Zappos，后来被Amazon收购了。它早在十几年前就在做网上卖鞋这件事情。最开始的时候，要回答的第一个问题就是“有没有人愿意在网上买鞋？”。当时没人知道这件事，毕竟对于买鞋，传统的想法还是要试穿的。如果先把电商的整个系统，包括网站、后台、供应链，等等都搭好，万一没有人愿意在网上买鞋，那损失的成本就太高了。
1704233180
1704233181
Zappos的创始人谢家华是这样做的：他先搭了几个简单的页面，当有人下单之后，他就去商场把这双鞋买过来，然后给对方寄过去。通过这样的方式把业务流程给跑通，然后才逐步做各种电商系统。
1704233182
1704233183
谢家华写过一本书，叫《三双鞋》，讲的是在用户每次购买一双鞋的时候，Zappos会给用户寄三双，挑中那双外的其他两双可以无条件退回。Zappos通过这样的方式，把用户不敢在网上买鞋的顾虑打消了。
1704233184
1704233185
IT系统作为狭义的产品，本来就是用于提高效率的。所以，先通过人肉跑流程来验证模式，使用量上来后再用IT系统来提升效率、实现规模化效益，是常见的操作方式。一个流程在效率可接受时，不一定非要做一个产品出来。千万不要因为我们是产品经理，为了刷存在感，就要把各种东西都做成IT系统。产品只是一种解决方案，人工服务也是，这里面的核心考量是投入产出比。
1704233186
1704233187
第五类，反向功能
1704233188
1704233189
如图6-11所示，第五类功能的线条呈现为一条反向的斜线，代表的含义是做得越多用户越讨厌，听起来是不是很奇怪？这类功能叫作反向功能。
1704233190
1704233191
1704233192
1704233193
1704233194
图6-11 反向功能曲线
1704233195
1704233196
既然用户讨厌，是不是不要做这种功能就好了？问题没这么简单。
1704233197
1704233198
比如百度的广告，对普通搜索用户来说，搜索结果页里广告越多，满意度就越差，但对投放广告的用户，肯定希望搜索结果中也里有自己的广告。
1704233199
1704233200
这是因为，KANO模型里的纵轴叫用户满意度，而一个产品的用户是多种多样的，不同用户的目标也各不相同，所以这里的“满意”，针对某一种用户可能是反向的，而针对另外一种用户却可能是正向的。
1704233201
1704233202
一个KANO模型，往往只针对一种用户，通常是核心用户。实际上，也可以针对不同的用户画出多个KANO模型。一般情况下，因为必要性不大，实操中很少有人这么做。
1704233203
1704233204
在评估反向功能时，要注意以下两种常见的用户属性。
1704233205
1704233206
第一种是用户的多边性，指多边型的平台产品[4] 里有完全不同类型的用户，他们之间可能存在的利益矛盾。比如同时有卖家、买家双方的交易类平台，往往卖家很喜欢的功能，对买家利益可能有损害，反之亦然。比如出行应用里，司机希望能够主动挑乘客，不希望被平台派单，而乘客也希望能主动挑司机，不希望被动接受，这里面就有冲突。而广义的多边，是外部用户和公司，他们之间的利益，也经常是有冲突的。
1704233207
1704233208
第二种是用户的多样性。同一类用户中，有一些人喜欢这个功能，有一些人不喜欢这个功能。举个例子，豆瓣每次改版后总有一些用户会不满意，然后产品经理被骂得受不了了，只好改回去。马上，另外一些刚才没说话的用户站出来说，你怎么又改回去了，我们挺喜欢新版的。这体现的就是用户的多样性。
1704233209
1704233210
反向功能很考验产品经理，我们需要在多种用户利益之间寻找平衡，而如何判断不同用户孰重孰轻，则又要回到“价值判断”的章节寻求答案。
1704233211
1704233212
1704233213
1704233214
1704233215
人人都是产品经理2.0：写给泛产品经理 [:1704229225]
1704233216
人人都是产品经理2.0：写给泛产品经理 6.2 功能打包，确定MVP
1704233217
1704233218
到这里，基本完成了功能细化的工作。接下来，就要回答How many这个问题，决定下一个版本到底要做到什么程度。这一节标题里的“功能打包”，就是从整个功能列表里，把下个版本打算做的功能点挑选出来，理清逻辑，安排实施的意思。
1704233219