我该怎么做才能让你满意(从用户满意度层面聊需求筛选)

Posted 2023-05-26

篇首语：更羡慕街边咖啡座里的目光，只一闪，便觉得日月悠长、山河无恙。本文由小常识网(cha138.com)小编为大家整理，主要介绍了我该怎么做才能让你满意(从用户满意度层面聊需求筛选)相关的知识，希望对你有一定的参考价值。

我该怎么做才能让你满意(从用户满意度层面聊需求筛选)

在产品工作中，我们能够遇到各种各样的问题，产品需求池里累积了各类需求，不知道从何做起。这时候，就需要对需求进行分类管理，进行需求筛选。那么，当我们以用户满意度为主要考量标准时，该如何对现有需求做出合理科学的选择？

在产品经理的工作过程中会遇到这样的情况，在自己的产品需求池中积累了很多待做的需求，一时之间不知道该从哪个需求开始做起。这个时候就需要考虑该如何从众多的需求中找出更值得做的那个了，也就是产品管理过程中的需求筛选。

需求筛选的方法肯定是有很多的，我们也会根据不同的状况选择不同的方法来应对，有的时候情况比较复杂甚至还需要用到多种方法组合使用的情况，最终得到最为合理且有说服力的需求筛选结论，这里先不展开。今天我们重点聊聊，当我们以用户满意度为主要考量标准时，该如何对现有需求做出合理科学的选择。

一、用户满意度与需求类型划分

先来说说这个前提条件，为什么用户满意度可以作为筛选需求的一个重要的考量标准。首先，从商业角度上来说产品就是为了给用户提供服务的，在为用户提供的过程中通过各种手段产生经济效益从而达到盈利的目的，所以在需求管理阶段考虑用户的感受，自然也就天经地义了。

其次，用户满意度几乎可以直接决定用户忠诚度，你让用户满意了，用户就会持续用你的产品，你让用户非常满意，用户可能不仅自己用你的产品还会推荐身边的亲戚朋友也来用你的产品，而你让用户不满意了，用户就会减少使用你产品的频率或者考虑寻找别的替代产品，你让用户非常不满意，用户不仅自己坚决摈弃你的产品再也不用，而且可能你以后开发的所有产品他都不用，更有可能到处去宣传你的产品多么不好，让别人也不要用。所以你可以看到，让用户满意是一件多么重要的事情了。

然后就是从用户满意度出发去思考需求要不要做的问题了，这里有个成熟的模型可供参考，是由东京理工大学教授狩野纪昭(Noriaki Kano)发明的KANO模型，KANO模型的核心理念就是根据需求对用户满意度的影响，来排定需求的优先级顺序，可以反映需求和用户满意度之间的非线性关系。

根据KANO模型可以把影响满意度的需求分为五种类型，按优先级排序后分别为：基本型需求（必备型需求）、期望型需求（意愿型需求）、兴奋型需求（魅力型需求）、无差异型需求、反向型需求（逆向型需求）。下面我们就分别讲一下，每一种需求类型与用户满意度之间的对应关系。

二、基本型需求

从用户角度看，基本型需求就是用户认为产品必须要有的功能或属性，是用户对产品的基本要求。从产品经理角度看，基本型需求就是解决用户痛点的需求，是必须要满足用户的。

当基本型需求被满足的时候，用户不会因此而觉得更加满意，因为他潜意识中觉得基本型需求被满足就是理所应当的事情，被满足才是正常情况。但是当基本型需求不能被满足的时候，用户的满意度会大大降低，也就是说用户会因为基本型需求得不到满足而表现得很不满意。

当产品经理无法正面判断一个需求是否属于基本型需求的时候，就可以用用户满意度来判断。提出假设如果这个需求不做，用户会不会很不开心，会不会对产品很不满意。如果是，那这个需求就属于基本型需求了，赶紧给用户安排起来就对了。

还有一个特点是，用户不会因为你把基本型需求做得很好而觉得很满意，对用户来说这种类型的需求属于有就可以了，你花很多时间做到很好，也并不能得到用户的更多好感。所以基本型需求，产品方面也就基本做做就好了，确保基本功能就可以没必要消耗太多资源去把它做到非常好的程度。

三、期望型需求

从用户角度看，期望型需求也是用户主观很想要的需求，虽然不像基本需求一样具有必备属性，但是是用户希望得到的，一般情况下，在用户自己描述需求的时候，他所表达的往往都是期望型需求。从产品经理角度来看，期望型需求就是满足用户痒点的需求，这类需求虽然不是像基本需求一样必须要满足的，但是很明显满足这类需求可以让产品获得更多的认可。

在用户满意度方面，期望型需求跟用户满意度完全是正相关的，满足了这类需求用户满意度就会增加，而且满足地越好，越超出用户期望，用户满意度就越高。而不满足这类需求，用户满意度就会降低，甚至是满足了但没有达到用户的期望值，用户满意度也会降低。

考量一个需求是否为期望型需求的时候也可以像前面一样做假设，如果这个需求不做，用户满意度是不是会明显下降，如果这个需求做了，用户满意度是不是会明显上升，这个需求是不是做的越好，用户就越满意，如果同时满足以上几个条件，那这个需求基本就可以归类为期望型需求了。

由于期望型需求跟用户满意度的强相关属性，这类需求往往可以成为产品跟竞品拉开差距的内容，在期望型需求的表现上比竞品表现好的话，可以让用户更加倾向选择我们的产品。

四、兴奋型需求

对于用户来说，兴奋型需求属于意外之喜，是用户自己本来没有想到的，但是你帮他把这个功能做出来了，他就会很开心。对于产品经理来说，兴奋型需求就是用户的爽点，是需要挖掘的隐藏需求，用户可能没提到这一点，但是你做了用户一定会拍手称快。

在满意度方面，满足兴奋型需求用户的满意度会大大提升，用户会觉得你在真正为他考虑问题，做出了他自己都没想到的功能。而没有满足兴奋型需求的话，用户满意度也不会降低，因为用户可能本来也没意识到这个需求，你不做的话用户是无感知的。

通过满意度判断一个需求是否为兴奋型需求的话，可以假设做了这个需求用户是不是会感觉很惊喜，满意度是不是会突然上升，同时如果不做这个需求的话，用户是不是也没什么怨言，也能接受，并不会因为不做这个需求而感到不满，如果同时满足这两个条件的话，这个需求基本就是兴奋型需求了。

兴奋型需求是需要产品经理主动去挖掘的需求，如果一家公司能够接连为用户提供满足兴奋型需求的功能，那这家公司一定会大受用户喜爱，从而在行业中脱颖而出快速超越同行的竞争对手。同时满足兴奋型需求可以让用户的忠诚度大大提升，让用户对你产生信赖感，有利于公司长久发展。

五、无差异型需求

对用户来说，无差异型需求是用户关注点之外的需求类型，这种需求是否满足用户都不关心。对产品经理来说，无差异型需求是无法让用户明显感知到的需求类型，或者是不影响用户使用体验的一种用户类型。

不论是否满足无差异型需求，用户的满意程度都不会产生任何变化。

同样，判断需求是否属于无差异需求也只要看用户是不是对这个需求的实现完全没有任何情绪波动。用户对需求表现出这种状态的时候，这个需求基本就可以判断属于无差异型需求了。

无差异型需求并非完全没用的需求，只是不会在用户那边产生明显影响。但是对产品经理来说，有可能是一些有潜在作用的需求，当判断是无差异型需求后产品可以大胆去做相关需求，来达到自己的目的，而不用担心因此会影响用户体验。

六、反向型需求

对用户而言，反向型需求是用户所不愿意看到的需求，或者是少数用户想要的功能，而别的用户会反感的功能。对产品经理而言，反向型需求是可能会影响产品被接受程度的，是可能有风险的需求类型。

做反向型需求，用户满意度是会降低的。不做的时候用户无感知，不会因为你不做就满意度上升。

判断是否为反向型需求也只要看，用户是不是会因为这个需求对产品产生不满。如果是的话，这个需求就可以划分为反向型需求。

如果产品经理要做一个反向型需求，就要权衡能不能接收因此带来的负面影响了。并不是说所有的反向型需求都不能做，只是要看这个需求的必要程度，比如一个工信部要求的内容，那即便判断是反向型需求，该做也还是要做的。

七、需求类型应用

通过用户满意度变化的情况将需求划分为上面这五种类型，然后再根据五种类型的重要级排序，基本就可以筛选出哪些需求要做了。当然，我们这里只是针对用户满意度这一个维度来判断的，这虽然是需求筛选过程中的一个重要参考依据，但也不是唯一依据，具体的工作过程中还会加入其他维度的考量，来最终决定是否要做这些需求。

而且需求的筛选还要跟产品所处的生命阶段关联，引入期以基本型需求为主，稳扎稳打先把该有的基本功能都做了；成长期可以适度增加期望型需求，以获得用户更高的评价，逐渐跟竞争对手拉开差距；成熟期则可以多做一些兴奋型需求，以刺激用户产生新鲜感，对产品忠诚度逐渐增加。

还要注意尽量不要在引入期和成长期做无差异型需求和反向型需求，一方面可以确保将人力资源投放到更有价值的需求开发中，另一方面也是为了尽可能减少用户对产品的负面情绪，确保产品积累更好的口碑。

实际工作中一般判断需求为无差异型需求或者反向需求的时候，基本就已经把这些需求排除在待做范围之外了。这个从这两种需求类型的命名中就能看到，一种是做了没什么用，一种是做了还会有反作用，所以除非是还有别的非做不可的理由，比如公司战略考量、管理层要求、法律要求等，不然的话这两种需求都是可以排除的。

同时还要注意，前面提到的五种需求类型，并不是固定不变的。也就是说我们给一个需求划分的需求类型其实是有时效性的，各种需求类型之间可能会出现流转。比如在微信刚出现的时代，语音消息可能是一个兴奋型需求，但是随着时代发展、竞争对手的跟进、技术的普及、用户使用度的提升，这个需求会逐渐演变成期望型需求、基本型需求。

所以在判断需求所属类型的时候一定要考虑当前的时代背景，并且做到及时更新认知，确保需求类型划分正确。切不可直接套用前人划分好的需求类型，在整理历史需求的时候要重新确认一下，原来划分的需求类型在当前时段是否依然适用，然后再根据需求类型做筛选判断。

作者：多云转晴，公众号：互联网从业笔记

本文由 @多云转晴原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。