Kano 模型是狩野纪昭教授发明的对用户需求分类和优先排序的一种工具，与产品经理的贴合度非常高，于是这样一个非产品行业的教授所发明的工具，成为了产品经理们的方法论。
Kano 模型的起源
什么是 Kano 模型
简单来讲，Kano 模型是狩野纪昭教授发明的对用户需求分类和优先排序的一种工具，与产品经理的贴合度非常高，于是这样一个非产品行业的教授所发明的工具，成为了产品经理们的方法论。
具体的介绍，由于篇幅有限就不再赘述了，可以自行百度“ kano 模型” 务必要输入完整的关键词，否则会出现“卡农”的搜索结果。
狩野纪昭（Noriaki Kano)是谁
1940 年出生的老人家，日本教育家，作家，咨询顾问，1982 年担任东京大学的教授，2006 年退休。是的，狩野纪昭和互联网、和产品经理没有什么关系。
Kano 模型的诞生背景
在 20 世纪 70 年代末 80 年代初，狩野纪昭和他的同事以客户满意度为模型设计了一种新的方法论，用于提高企业服务，这个方法论最终以他本人的名字命名 ，换言之 Kano 模型的正统名字是：狩野模式 （Kano model）
20 世纪 70 年代末是什么时候呢？大概在 1979 年，80 年代初也就是 1981 年，我们将范围扩大，Kano 模型的实际诞生时期应该在 1976 年至 1985 年中间的某段时间。
在当时的背景下，互联网尚处于开荒阶段，还未抵达应用阶段（我国在 1994 年实现了与 internet 的全功能连接）这还是那个你所了解并依赖的“Kano模型”吗？ 就是这样一个看似与互联网没有关联的 狩野模式 ，现在成为了互联网产品经理的“圣经” 。
Kano模型的定义
现在，你已经知道了，Kano 模型并不是为互联网量身定做的，更不是为产品经理量身定做的方法论，那为什么不把他用在其他地方？
毕竟，这样才会让我们熟练地掌握这个方法，也只有熟练掌握，对 Kano 模型有更深刻的认识时，我们才能在互联网，在我们的产品里，更有效的去应用。
Kano 模型里，将人们对某物的需求定义成了五个层次，包含：基本需求，期望需求，兴奋需求，无差异需求，反向需求。
所谓的兴奋需求，便是我们所谈及的“超出预期”这部分的需求。
来看一下每个层次的定义：
基本需求
也是基础性需求，理所当然的需求，也是用户认为“必须要有”的功能。
简单的来讲，如果“没有”，用户就会很不满意，如果“有”，用户也不会为此感到满意，毕竟，此类型需求属于“理所当然”的需求。
比如说，需求文档，对于产品经理而言，就是这样的基本需求，如果不会，那你的 leader 大概会对你极为不满，如果你会，他也不会为此表扬你。
期望需求
此类型需求与基本需求相反，简单的来讲，就是这么一个意思，如果有，则用户会感到满意，如果没有，用户也不会感到失望。
比如说，需求管理，对于我们来讲，就是属于期望需求，作为产品经理而言，将我们的需求管理的越好，我们的 leader 会越满意，反之，即使你不会管理需求，他也不会对你有所不满，大概就是表现平平之类的吧。
兴奋需求
兴奋需求某种含义上是期望需求的升级版本，有时候我们会提到的超越用户预期，以及 挖掘表面需求背后隐藏的需求，便是指期望需求和兴奋需求的关系。
就以表面和背后来讲，期望需求是指用户表面的需求， 兴奋需求则是指背后的真实需求。
我们仍然以需求文档来举例。
管理需求文档是我们表面的需求，通过对需求文档的管理，让团队效率更高，有更多的需求可被复用，以及需求尽可能少的变更，始终让团队的战斗力发挥有效价值，这个便是让 leader 兴奋的需求。
作为产品经理而言，需求反复，需求变更，遗漏需求，相信大家都不陌生，不仅仅是我们的 leader，即便是对于我们自身而言，如果真的能减少反复，减少变更，同样也会让我们感到兴奋的，难道不是吗？
无差异需求
无差异需求是指有没有都无所谓的这部分需求，不论提供或者不提供，对用户体验无影响，换言之，即使不做，也不会让客户不满意。
这部分需求，往往是我们要避免的 “多余动作”，虽然是这样说，但在工作上，我们却极为容易做出这样的事情。
这个案例算是很经典了，“登录”与“登陆” 当我们在文章里 写到了“登陆”时，如果产生了情绪，这就代表我们在工作中，会经常性的为了无差异的事情耗费时间，毕竟，这样的错别字，并不会影响用户体验。
我需要强调，我们所谓的用户，是指使用某产品的人，以需求文档为例，他在开发过程中起到指引，排查的作用，而不是阅读一篇文章，因此文档里的错别字，在一定范围内是被允许且接受的。
避免无差异需求的原因在于，其会占用我们宝贵且不可再生的资源。
反向需求
是指少数派需求，我们在做需求分析时，需要考虑需求的使用面积，并且在做优先级划分时，也需要按照影响面积来考虑，以满足大部分人的需求为首要目的，与这个原则相反的，便是反向需求，只满足少部分的需求。
反向需求同时也是无差异需求的升级版本，我们所谓的无差异需求，是做不做都没影响，反向需求恰恰就属于，做了就会产生负面影响。
比如，在需求评审时，我们在会议上讨论某文案内容，或者说某参数的设定，这种便是反向需求。
在我们的 team 里，大部分的成员其实不关心文案也无须关心文案，只有少部分成员会关心这个问题。
正确的处理方法是在评审会议里，讨论大部分人关心的议题，比如功能的业务逻辑，或者说为什么要做某功能。
对于一些少部分人关心的问题，类似于文案，可以在会议结束后，单独沟通。
以上五种需求类型，便是我所理解的 Kano 模型的五层需求。
我们以基础需求为原点，向正面挖掘，以期望需求或者兴奋需求为目标来要求自己，并且尽量规避反向需求，无差异需求的误区。
无差异需求虽然是做不做都没有影响，理论上，应该是以无差异需求为原点，而实际上，如果我们真的做了无差异需求，就表示会消耗我们的时间，并且这部分被消耗的时间得不到何种汇报，因此 无差异需求被提出来时，本身就已经产生了负面影响了。
Kano模型对于产品经理
文章的开篇我已经告诉了大家，我们所熟知的 Kano 模型，并非互联网特有的一种方法论，实际上 Kano 模型的适用面积远远超过互联网和移动互联网的面积。
在我们讲述五层需求时，如果用某功能的案例，会让大家更容易理解，但这样却违背了我的初心，毕竟这篇文章的初衷是引导大家学习和成长方向，如果能促进大家的自省，那就太棒了。
用Kano模型来反思一下我们的工作：
基础需求：我们要输出需求文档
期望需求：我们要管理需求
兴奋需求：通过需求文档，提高团队开发效率，减少低效时间耗损？（想一想，我们现在所写的需求文档，属于哪个层次？）
无差异需求：写完需求文档后，反复检查三遍，确保没有错别字
反向需求：评审时，我们讨论提示文案应该怎么写
想一想，我们有多少时间耗费在了无差异需求和反向需求里。
最近似乎说了很多次差距产生的原因， 即便是相同的开始时间，相同的结束时间，相同的经历，也可能产生极大的差距。
同样是一年产品时间，并且做的是相同的事情。A 不断的做兴奋需求，而 B 不断的做基础需求，不妨判断一下，谁的成长更快，谁能抓住下一个机会呢？
切忌满足于做基础需求，这样只会耽误你的时间而已，任何一件事情，都有基础需求和兴奋需求，只是兴奋需求会比基础需求更难挖据，更难发现。
这就像游戏里的难度挑战一样，简易，普通，困难 ， 不同难度下，获得的经验和奖励也是不同的。
