1704233070
1704233071
这个半定量的公式是：性价比 = 价值/成本
1704233072
1704233073
按理说应该先做那些性价比高的功能，但这太理想化了，实际操作中，还需要考虑功能的分类和其他的实际情况。
1704233074
1704233075
6.1.4 功能分类：KANO模型
1704233076
1704233077
表面上看，只要从功能列表中找到性价比最高的功能先做，就不会有问题。但事实上并非如此。你会发现，有一些非常基础的功能，比如一个电商网站的交易、支付等功能，是非做不可的。如果这些功能需要投入较大工作量，则性价比不会很高。这与之前性价比高者优先的结论有些矛盾，要想正确看待和理解这一矛盾，需要引入KANO模型[3] 。不过，由于KANO模型并不是专门针对产品经理而设计的，此处对其说法进行了一些相应的转化，用它来对功能进行分类。
1704233078
1704233079
先来解释一下图6-5。图中横轴指的是产品功能的实现度，用来表征一个功能有没有做完。最左侧的一点代表功能实现尚未开始，最右侧的一点则代表功能实现已经很完善。纵轴指的是用户满意度，越靠近下端表示用户越不满意，越靠近上端表示用户越满意。
1704233080
1704233081
1704233082
1704233083
1704233084
图6-5 针对产品经理语境优化的KANO模型
1704233085
1704233086
不同类型的功能，对应图6-5中的不同曲线，下面逐一加以说明。
1704233087
1704233088
第一类，基础功能
1704233089
1704233090
第一类功能对应的是如图6-6这样的一条曲线。
1704233091
1704233092
由图6-6可知，当这类功能没有实现时，用户对产品是“极其不满”的。但是，这个功能做得再好，用户也认为“理所应当”。于是，把这种功能叫作基础功能，英文中的说法是Must Have。基础功能是必须要实现的功能点，但无法带来满意，只会消除不满。
1704233093
1704233094
1704233095
1704233096
1704233097
图6-6 基础功能曲线
1704233098
1704233099
比如，对于手机来说，如果只可以有一个基础功能的话，就是打电话。基础功能不具备，用户根本就不会用我们的产品，所以在回答其对应的Which问题时，没有必要再看性价比，唯一正确的做法就是留足资源先把它搞定。
1704233100
1704233101
那么，怎么判断一个功能是不是基础功能呢？主要靠领域知识。一个产品经理做某个领域的产品，就得知道该领域有哪些基础功能。比如，要做一个美图的应用，就必须知道它要能拍照，还要有几种基本的滤镜和一些类似拼图这样的核心工具，用来处理拍完的照片。
1704233102
1704233103
如果领域知识不够，无法做出正确判断，还可以通过问用户两个经典问题来补救：
1704233104
1704233105
►如果产品没有功能A，你觉得如何？请从很满意、一般满意、无所谓、不太满意、很不满意（或5.4.3 、2、1）这五个评价选项中选出一个来作答。
1704233106
1704233107
►如果产品有了功能A，你觉得如何？同上给出相应的答案。
1704233108
1704233109
然后，在KANO模型图中将以上两个答案对应的点之间连线，就能看出这一功能所属的类型。这个方法对接下来要讲的几类功能同样适用。
1704233110
1704233111
之所以首先强调领域知识，而不是直接建议向用户提问，是因为有些特别基础的功能，不适于提出这样的问题。比如，“如果我们的下一款车没有刹车，你觉得如何？”这样的问题，就颇显尴尬。
1704233112
1704233113
第二类，亮点功能
1704233114
1704233115
第二类功能的曲线与基础功能的曲线看上去正好相反，如图6-7所示。
1704233116
1704233117
1704233118
1704233119