16 | KANO模型：雪中送炭与锦上添花

之前也接触过 Must Have, Should Have, Could Have, Nice to Have 的需求优先级设定，但是没有像 KANO 模型这么清晰。 KANO 模型，一种对用户需求进行分析和优先排序的使用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的关系。 基础功能 Must Have，必须要实现的功能点，无法带来满意，只能消除不满。 不过我觉的如果还需要询问用户来判断基础功能的话，那么产品领域知识实在是过于的匮乏。另外一方面，基础功能与其他功能的分界线并不是那么明显，甚至也并不是一成不变的，所以我倒是觉得不需要去向用户询问，可以把沟通的机会留给更需要的问题。 亮点功能 Excited to Have，用户事先想不到的妙用，忠诚度、口碑传播的基础，“用户没见过”、“未经市场检验”、“如果被认可就能获得巨大回报”。 说到华为手机的拍照能力，如果说亮点大概就是 P30 的那个光学长焦镜头了，以前 OPPO 似乎也主打过柔光自拍之类的。单独说拍照能力，我觉的华为大致和苹果处于同样的水平（现在价格也快拉平了），有一些算法优化之类的部分，基本上属于审美的差异，而不是软硬件的差别。 从产品上来说，我不喜欢华为手机，主要是因为软件，也就是手机操作系统的原因。最近一两年华为手机的确声势惊人，但以后会怎么样，我觉的并不是完全没有风险。 很久很久以前，飞利浦手机主打待机时间，也曾经风光过短暂的时间。 期望功能 Nice to Have，少了用户不爽，多了感觉不错，先做性价比高的部分。 用户不会提基础功能，因为他觉得你的产品肯定会有；用户不会说亮点功能，因为他想不到；大多数用户能够表达的，是期望功能。 那么作为产品经理，产品的基础功能基本上就是基本功或者及格线，进而从期望功能出发，按照 Y 模型，刨根问底，挖掘用户心智，找出亮点功能。 手机拍照，现在应该已经不是亮点功能，即使是有更强大的远焦、暗光、美颜功能，这些已经逐步演化为期望功能或者是基础功能。那么手机的下一个亮点在哪里？ 无差别功能，这个似乎还不如基础功能，就是做了也没人用的功能，要尽量避免。 反向功能，不能不做，这个也会考验产品经理的平衡能力。比如产品可能需要较高的安全特性，但是这种安全特性如果干扰到了用户体验，那么就成了反向功能了，还记得 Windows Vista 么？ 我对于将痛点解释为基础功能，有些怀疑，基础功能用户基本上不会在意，文章的意思可能是说“不做，用户会痛”，而我的理解是，在没有用这个产品之前，用户遇到的问题或者感觉比较麻烦的地方，如果对应到功能划分的话，可能在基础功能之上，但又达不到零点功能。 如果一款产品能够解决用户的痛点，同时能激发用户的爽点和痒点，那么无疑应该就是一款好产品。 简单的分析一下最近在做的图书资料管理系统。 * 基础功能：图书资料的录入、管理、借阅登记 * 亮点功能： * 录入时的智能辅助，比如 OCR 识别之类（这个也是难点） * 抓取一些图书的评论信息 * 智能推荐 * 期望功能：图书资料的统计、图书荐购、图书评论 * 无差别功能：国际化支持 * 反向功能：备份 我之前可能把过多的时间精力放在了亮点功能上，而对于基础功能的投入不够。 顺便说一下我最喜欢的锤子手机 * 基础功能：早期的锤子手机拍照成为了用户“痛点”；供应链 * 亮点功能： * 第一代手机充电线上的 LED 灯，我的那个现在还能亮，但是想来对于锤子科技来说性价比不高 * 纯白色手机，漂亮，但是性价比低 * 一步 * 大爆炸 * 截图 * TNT * 期望功能：包装（性价比低） * 无差别功能：国际化，除英语之外的多语种支持 * 反向功能：这个锤子手机基本上没有太多，值得一提的大概就是无法刷 ROM 、广告比较少和随机安装的 APP 并不多（老罗的宣讲是不是也是反向的？） 现在看起来，锤子手机当年也是把重心放在了亮点功能上，但是受制于供应链和一些基础功能上的问题，加上老罗的招黑体制，所以…… 看到 @joe浅蓝的留言和作者的回复，如果在需求分析上引入太多的工具或者模型，确实在时间和管理成本上的负担比较大。需求评估适可而止就好，另外产品的亮点、痛点、爽点、痒点可能还是要依赖产品经理个人的经验和直觉。 不同类型的用户在 KANO 模型上的表现也不相同，大概只能以核心用户为主；到产品后期，可能也会针对某类用户，新用户或小众用户，进行新的 KANO 分析。

微信感觉就是个不错的例子，最早的产品满足了一些基本功能，如导入联系人，收发文字信息等。然后不断迭代，既推出了摇一摇附近的人，微信红包，朋友圈，公众号这种亮点功能，也完善了发送图片/语音以及视频通话这类的期望功能。同时也比较好地控制了朋友圈广告这种反向功能。

本节干货很足，做产品，首先需要搞清楚有哪些功能类型， 分别有什么特点， 在实现过程中如何取舍和迭代演进？ 1. 基础功能：用户认为必须有，无法带来满意，只能消除不满 --> 对应策略：留足资源； 2. 亮点功能：用户设想不到，所以没有时无感知，有了会大为惊喜 --> 对应策略：做成本低的（对更多创新产品而言）； 3. 期望功能：用户想得到且期望有的 --> 对应策略：看性价比，做好优先级排序； 4. 无差别功能：做和不做用户都无所谓 --> 对应策略：做好低成本验证，如果明确是无差别功能则果断停止投入； 5. 反向功能：越做可能对部分用户越有害 --> 对应策略：权衡好多方利益，确保让整个用户生态系统更健康。

时间维度确实是个好问题，经常因为忽略了时间维度而忽略需求属性本身的变化，关于KANO模型实际使用中并不是全能的，我们通常还会用从其他维度的四象限法协助KANO一起确定需求优先级，比如开发难度四象限，影响面四象限，成本四象限等等，这样才能更准确的评估需求优先级

如果再加上“开发资源量”这个维度呢？对于一些中小公司或团队，受限于开发资源和上线时间限制，怎么做取舍？

痛点 铁定优先安排，那一个爽点、一个痒点，假设开发成本大致相同，是不是先满足 爽点，对产品更有益？

@escray提到，“反向功能，不能不做，这个也会考验产品经理的平衡能力。比如产品可能需要较高的安全特性，但是这种安全特性如果干扰到了用户体验，那么就成了反向功能了，还记得 Windows Vista 么？” 借此联想到，iPhone出于对用户隐私安全的考虑，没有像安卓机一样设置通话录音功能，这种安全特性降低了部分用户体验，因为在某些特殊场景之下，用户会用到录音功能。

KANO模型应该也算是一种适用于多重分析的方法，我们可以利用这种方法去分析很多事物。产品技能迁移出来，不要局限于互联网，那将是很大一片天空，但迁移的契机比较难以遇到

我们正好在尝试采用kano模型来做需求管理。我对无差异属性需求的理解还不太一样，这种类型主要是各方面效果都不够明显的需求，更像鸡肋型，也有一定的意义，但非长期有益。现实情况下尤其是ToB的产品来说，面临客户和市场情况复杂时，有时候是部分客户受益，有时候有时间窗口意义。这时候往往只能选择尽量拒绝和少做，无法一棒子打死。

kano模型确实能让我们在产品权衡上做好决策。