当产品发展到一定阶段，当社区达到一定规模，会出现各种用户的声音，也会有各种各样的反馈，那这时候如何判断用户反馈的优先级？如何处理用户反馈？而且在运营沟通成本有限的情况下，如何有效的和用户沟通？这些都需要有相应的方法。下面就简单聊聊个人对“用户反馈”的看法和处理方法。

题图来自Unsplash，基于CC0协议

首先，谈谈目前一些产品经理和运营人员工作中经常面临的误区：

1.盲目做功能（需求）产品经理

“做产品经理，而不是功能经理”，这句话坊间传言是阿里逍遥子说的，但不管是谁说的，指的是现在周围太多的产品经理日常工作就像是在做一名功能需求经理，不停的在接产品功能需求。

产品缺乏新功能，找个竞品抄一下；产品缺登录，设计一个登录框；产品没有数据，找平台打通一下……

然后不停实现产品功能，日复一日，年复一年这样循环。

这样的场景我们或多或少我们都见过，功能经理，每天都很忙，每天关注还有多少需求在后面排队，需求方是否得到满足。

而用户体验到底如何，这个功能是否真的真有价值，是否还可以更加完美，他们则很少关心。

2.把大量的时间浪费在没有意义的用户身上

作为一个合格的运营人员，需要关注用户的体验，真正关注用户的反馈，关注数据的质量，关注每一个细节。

但是依旧有很多运营人员，看似整天都在围绕用户，想法设法解决每一个用户的问题，天天加班，结果效果不理想，往往是因为把大量的时间浪费在没有意义的用户身上。

绝大多数都是在盲目地沟通，停留在跟用户毫无目的的闲聊上，聊完之后并没实际的产出或者结论，完全不考虑具体的投入产出比。既没有帮助业务提升，每天还被用户各种问题所捆绑，深陷工作迷茫之中。

以上这些我们或多或少都见过，或者亲自经历过。

运营或者产品总是在被动地做事，工作中做任何一件事都不思考背后的逻辑，缺乏结果导向意识，既锻炼不到我们的能力，也让自己变得迷茫起来。

下面就分享个人对“用户反馈”的看法和处理方法。

一、  用户反馈如何驱动产品

1.重视用户反馈

①用户就是客户，客户就是上帝，他们代表了所有用户对你产品的看法。

腾讯吐个槽是一款用于收集处理用户反馈的工具型产品，主要集中收集并处理用户反馈，提高团队在处理用户反馈这方面的工作效率。

那在大公司或者一款成熟产品中，非常有必要收集和整理用户反馈的。只有用户不断反馈，才能驱动产品不断迭代，留住用户。

我们重视用户反馈的目的，就是为了产品能够活得更好更持久，尽可能放大产品的覆盖用户量和延长产品的生命周期。如果一款产品都没有用户反馈，估计这款产品离死也就不远了；

另外记住用户永远都是大爷，不及时处理和解决问题，会容易失去用户；

在日常工作中，我见过各种用户，有靠1小时直播就挣几十万的大v，也有靠短短15秒视频获得千万播放的KOL，还有一晚豪刷数万、百万任性的土豪爸爸，当然见到最多的就是那些天天求着作品上推荐，询问官方如何涨粉，为什么掉粉，帐号是否正常诸如此类的千千万万普通用户。

对于前几类用户，工作花的时间最多，也是我们想法设法解决他们的问题。

你想想，由于直播的一个小小故障，可能就影响某个大v一晚几十万的收入；还有你的一项功能没有很好解决用户的拍摄问题，会慢慢的流失一些用户；还有那些整天哭着闹着不涨粉的用户，你也需要了解，他/她为什么不涨粉？他近三个月，近半年数据是否明显下降？为什么下降？是他自身的问题还是整个平台的问题，如果没有有效的解决用户的问题，可能也会慢慢流失，所以一定要重视用户的反馈；

另外，基于腾讯吐个槽产品，用户反馈问题要形成一个闭环，问题是否解决，提的建议是否采纳，如何给用户一个正向反馈都需要有一套机制去实现。

在反馈后台后期还需要引入评价体系，对于工作人员解答的问题是否让用户满意，为什么不满意，可以通过评价体系来衡量，也可以衡量业务人员的工作表现。

②不要骂用户笨

我见过身边太多人在吐槽这个用户怎么这么笨，这个功能这么简单都不知道，真傻，真笨这类吐槽。

在工作中，我也见到某些产品新功能上线，业务人员以为新功能可以受到用户的喜爱，但是往往事与愿违。其实原因往往在有的功能上线了，未能引导用户去体验到产品功能的核心价值或者服务，还有一开始功能设计的就很复杂，用户根本不知道怎么使用。

用户都是很懒的，而且是缺乏耐心的，真正一款好的产品，不需要过多复杂的功能，如果一款产品连小白都可以使用，那至少在功能上、用户体验上是成功的。

所以不要骂用户笨，这么简单的功能都不知道如何使用，你需要的是如何正确引导用户去体验到产品功能的核心价值或者服务。

③不要担心被用户骂，要骂的话说明他还是想使用你的产品。最担心的是用户骂都不骂你就卸载了。

2.制定用户反馈优先级

以bug为例，一般公司主要以优先级或者严重程度分类。

优先级指一个bug相对于其他bug对于公司的影响，以及解决bug的及时性。

根据问题反馈的类型，需要制定急-高-低等级；

严重程度：指一个bug对于用户造成的影响，它所带来的风险和可视性。

根据问题严重程度，分为紧急-非法高-高-中-低等级；

以腾讯吐个槽产品为例，每天有大量用户反馈，就需要机器识别和相应应对机制。

此外为了应对春节、国庆期间可能出现的用户反馈爆发问题，需及时优化用户反馈流程，提高机器识别的准确率，将适宜自动回复的问题通过系统自动回复，客服可按需设置。

3.如何对需求进行分类&挖掘、验证用户需求

不管是产品经理、运营人员或者是战略分析者，都需要了解和分析用户需求，那这里分享一个卡诺模型。

卡诺模型（KANO模型）是对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

在卡诺模型中，将产品和服务的质量特性分为五种类型：

⑴ 必备属性；

⑵ 期望属性；

⑶ 魅力属性；

(4) 无差异属性；

(5) 反向属性。

此外卡诺模型还可以通过对功能属性归类的百分比，计算出Better-Worse系数，表示某功能可以增加满意或者消除很不喜欢的影响程度。

增加后的满意系数  Better/SI=（A+O）/(A+O+M+I)

消除后的不满意系数  Worse/DSI=-1*（O+M）/(A+O+M+I)

Better-Worse系数，表示某功能可以增加满意或者消除很不喜欢的影响程度。

Better，代表某功能增加后的满意系数。better的数值为正，表示提供某种功能属性的话，用户满意度会提升；数值越大，用户满意度会提升越快。

Worse，代表功能消除后的不满意系数。其数值通常为负，表示如果不提供某种功能属性的话，用户的满意度会降低；数值越小，用户满意度会下降越快。

根据better-worse系数，对系数绝对分值较高的功能/服务需求应当优先实施。另外根据better-worse系数值，也可以制作将散点图划分为四个象限。

当然网上有很多关于卡诺模型的文章，这里不过多阐述。

说完需求分类，再谈谈需求挖掘和验证。

产品经理侧重于从产品整体角度（包括业务目标、功能逻辑、技术资源、用户体验）去考虑问题，并排列优先级；运营人员侧重（业务目标、运营目标、用户体验、用户行为）考虑问题，设计师侧重于在既定优先级判断基础上从用户角度考虑界面设计。

太过考虑业务目标，难免忽视了用户体验；而太过于考虑用户体验，短期内又很难达成业务目标。如何有效在两者之间达到平衡，这里是判断一个业务人员能力高低的体现。

没有完美的产品，特别是当一个产品的用户量到达上百万上千万的时候。用户的喜好千差万别。任何一个产品，无论产品经理推出多么好用的功能，都会有人不喜欢。

不应该简单满足用户需求，而应该思考把用户需求提炼成产品需求。当一个产品的用户有上百万上千万的时候，产品需求的理解和提炼，就相当重要。

那围绕用户需求，可以简单分为三个步骤：

第1步：发现需求

第2步：分析需求

第3步：解决需求

简单的梳理就是发现问题，分析问题，然后是解决问题。

对于每一个需求都要对应深层次的逻辑和思考，一定是围绕一定的目的来进行的，一定不要急于满足/回避用户需求，要考虑思考的深入性，思考的系统性。

① 反馈问题思考的深入性。对于每一个需求都要多问几个为什么？做这个需求最终目的是什么？做这个需求的效果如何去衡量？对目标能够产生多大影响？投入产出比是否合理？是否存在更优需求？

如何更好的收集用户的想法，进而转变成产品需求；如何快速推送新功能给用户？怎样分类不同的用户意见和意见？如何评估用户不同建议的优先级？是否需要一定转化成产品需求？怎样转化等等。

以短视频直播平台为例，某个需求是否有助于提升用户创作发布视频的频率，是否有助于提升平台DAU，是否有助于提升直播收益，如何影响……这些在日常需求思考中都需要注意。

当然，这一个公司中，很多同事会给你提出各种他们的需求、建议，但是要具体分析，因为很多时候他们并不是真正的用户，要格外注意。

② 反馈问题思考的系统性。运营/产品工作绝不是单点或者单线性质的，不能把运营/产品工作割裂开来，所做的每一项工作之间都存在一定联系的，因为它最终都是落脚于目标的达成。

要考虑业务目标、当前公司的核心任务、影响因素、关键策略、具体手段，以及对人、事、财、物（资源）、时间的合理协调和安排。要学会以目标为导向，做思路拆分，只有这样在思考的时候才能更全面更系统。

除了自身在日常工作中通过实践经验并不断的总结思考之外，运营/产品人员都需要加强对行业的了解和对业务的理解，对用户的了解，对用户需求的精准把握。

二、如何正确和用户沟通

聊完需求后，再聊聊如何和用户正确的沟通，这也是运营人员最频繁的日常工作。

大家都听过“二八法则”，对于用户运营者而言，甚至要把用户运营工作的80%的时间，放在金字塔顶端的20%的用户身上；我们每天做的工作，其实都是将金字塔底端的用户，不断的促使他们往顶端转化的过程。

即使和核心用户沟通，但是为了维护大V所要付出的成本，所花费的精力并不是你想象的那么简单。

这里分享一个“150定律”，又被称为邓巴数字， 最开始是由英国牛津大学人类学家罗宾•邓巴提出的”，指的是人类智力将允许人类拥有稳定社交网络的人数是148人，四舍五入大约是150人。

扎克伯格之前说过，当用户在注册Facebook时，人们最初通常会与150名朋友交流，但是随着时间推移，他们朋友圈就会越来越大，超过这个数量会导致信息过载。

那作为运营人员，在运营中跟千千万万用户产生过沟通，但很多用户可能只是一次性沟通，真正能够长期保持有效沟通的用户不超过150个。

而且这150个大部分就是你的核心用户。那在做运营过程中，一定要抓住这150名的关键用户，要考虑这批用户的结构组成，长期跟他们保持联系，建立信任关系，这对你做运营是非常有帮助的。

记住一下子去理解所有用户是很难的，但是分而治之，则会容易很多。

在和这些核心用户沟通，往往也会陷入误区，至始至终只跟头部高活跃度用户保持着长期的沟通和较好的关系，这样很容易导致你所做的运营手段，产品功能或者实现需求更多的可能只是代表了这几个活跃用户的需求。

那这时候你就需要看看公司的目前整体业务情况，通过相应的数据手段或者和其他业务同事多沟通，了解对方在做什么，切勿在某一小范围用户中陷入太深。

一般我们跟用户沟通有三个目的：

1、  用户需求挖掘

2、  用户情感维系

3、用户状态了解

那如何正确和用户沟通，这里分享几个技巧：

1、多与用户进行沟通。

要多跟不同类型的用户进行沟通，并且把这项工作作为常态。

2、了解用户的喜好，尝试了解并熟悉。

比如现在的高中生、大学生用户大部分比较喜欢短视频的东西，那么作为运营人员就要去学习和了解这些东西。像手势舞、滤镜、特效这些，都需要去了解。

我们很多人都不是公司创始人员或者是产品从0-1的经历者，用户远远比我们了解产品，如何拍摄视频，如何编辑，他们可能反而比我们要熟悉的多，用户是老师，所以要多和他们沟通，多向他们请教。

3、关注用户的行为以及消费习惯。

如果是一款读书类产品：阅读类型喜好、常见阅读时间、阅读频次、收藏的书和书单、喜欢的作家、是否付费…..都是需要自己了解的；

如果是一款直播类产品：平均观看直播时长、常观看主播类型，用户看直播频次、是否打赏、是否在直播间评论互动，你也必须关注；如果是一款短视频产品，用户常浏览类型，刷视频频次，是否互动也都需要关心。

我特别喜欢和平台上一些土豪用户沟通， 了解他们的需求和想法，比如有的土豪近期不刷礼，不消费了，我就会问他为什么不刷了，土豪可能会说由于主播和粉丝互动性下降了，那土豪可能只和你说这一点，但是你需要了解互动性下降背后的原因是什么？

不管是游戏直播平台还是其他秀场直播平台，最核心的部分还是内容，而且是用户能实时参与互动的内容。内容是由主播提供的，有好的主播就会有好的内容。

土豪愿意刷礼，除了单纯支持主播以外，其实就是主播提供好的内容，那根据土豪的需求你需要分析刷礼下降的原因是主播直播内容下降了？是主播和粉丝互动少了？还是平台的原因？围绕直播互动，那需要结合用户相应行为路径与运营目标的联系——制定精细化运营策略（提升用户直播评论、加强主播在直播间互动）——然后进行数据监测&迭代。

4.不用把你以为的你以为的就是认为用户以为的。

“不用把你以为的你以为的就是认为用户以为的”这句话看起来很绕口，其实就是告诉我们日常在和用户沟通中，不要把自己的想法强加给用户，也不要用自己的想法推断用户，不要用自己思维去理解用户。千万不要凭借自己的主观臆测判断用户需求和喜好。

我看到很多人，在做用户调研或者用户沟通中，把对方的想法用自己的理解，传递给领导或者相关业务负责人，结果基于用户需求上线新的策略或者功能发现效果并不理想。

做了大量分析研究，回头才发现用户的原本想法并非是你认为的那样，这就大大影响公司的业务和同事的效率。另外在做用户访谈、用户调研一定要客观，切勿加入自己的主观因素。

我们在做运营/产品工作，在制定一些策略的时候，经常会发现某些策略无论是在思路上，还是逻辑上看似是合理的，预期很有效但是实际往往缺乏效果， 归根结底还是在于我们没有充分的了解的用户，不能够很好的熟悉用户的想法和需求，还不能真正做到想用户所想。

运营的最高境界就是把自己变成用户，了解用户的想法，但做到这一点又谈何容易？必须是建立在对大量用户的沟通了解和长期积累的基础之上的。

最后附上我个人很喜欢的一句话“纸上得来终觉浅，绝知此事要躬行”。

作者：德鲁大叔

本文为「人人都是产品经理」社区和腾讯吐个槽联合主办的“腾讯吐个槽产品测评大赛”中的获奖作品，未经许可，禁止转载。

有关产品测评大赛合作事宜，请联系邮箱：denis@woshipm.com