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
1704233220
6.2.1 尽可能多地放弃
1704233221
1704233222
产品界的主流价值观是“少做就是多做”、“完美不是无一分可增，而是无一分可减”。所以，这一步要确定“最小可行产品”，即MVP（Minimum Viable Product）。
1704233223
1704233224
MVP是指的是满足“用户愿意用、最好愿意付费”、“用户易于使用”、“团队有能力实现”的最小功能集合，有些可以直接作为最终产品使用，有些甚至只能用来演示。它的重点就是制作的成本要极低，但是却能展示最终产品的主要特色。当然，对MVP的解释也有争议，比如“可以人工跑通流程的业务模型”算不算MVP？但比起理解MVP的目的，这并不重要。
1704233225
1704233226
MVP 的功用就是让你拿着它接触客户，尽早根据客户的回馈来改进你的产品。用户需要的东西有时候并不难实现，但很容易被忽略。如果你不是一开始就跟用户接触，就很难知道这些内幕。典型的错误就是窝在家里做没人要的东西，却自以为很有成就。
1704233227
1704233228
和需求采集阶段“尽可能多地采集”不同，这一步要“尽可能多地放弃”。看似矛盾的理念，其实目的都是为了提供尽可能多的用户价值。可以通过表6-2以及图6-12来理解这个观点。
1704233229
1704233230
表6-2 A、B、C三个功能模块的用户价值与时间成本
1704233231
1704233232
1704233233
1704233234
1704233235
1704233236
1704233237
1704233238
图6-12 尽可能多的放弃，反而能提供更多价值
1704233239
1704233240
这是一个理想化的模型，假设功能列表里待开发的功能模块有A、B、C三个，价值和成本如表6-2以及图6-12所示。来对比以下两种做法。
1704233241
1704233242
第一种是传统做法，先做A和B，到第20天，可以发布一个用户价值为5.3.8 的产品。
1704233243
1704233244
第二种是新做法，先做A，再做B。这样，到第10天，就可以发布一个用户价值为5的产品，第20天依然可以发布一个用户价值为8的产品。
1704233245
1704233246
如果简单地把曲线下的面积理解成产品持续提供给用户的价值，那么可以从图中得出明显的结论：只要条件允许，“尽可能多地放弃”反而能提供更多的用户价值。这里的放弃不是要把更多功能丢掉，而是不要集中完成，分批次地迭代实现。
1704233247
1704233248
这样做的另一个好处是，可以提前10天开始获取用户和市场的反馈，而这就足以让我们能提前几天制定出更合理的产品策略。比如，在开始做C之前，发现价值为4的D模块，就可以改为先做D。
1704233249