都说快速迭代反馈，问题是你的反馈真有效吗？

英文原文：5 MISTAKES WE ALL MAKE WITH PRODUCT FEEDBACK

译/天地会珠海分舵；微信公众号：TechGoGoGo / @techgogogo 

大家有做过产品的话，无论是成功还是失败，应该都深有感触：往往我们无论什么情况都去综合考虑所有的用户反馈，其实这是不现实，也不正确的。而去满足所有用户的请求更是一个非常愚蠢的行为。

当你在开展一个新的项目，特别是当你在接手另外一个产品的开发的时候，往往我们都倾向于先去对所有的用户进行调研，以便找出产品功能该怎么去定 位。而我们的做法往往却是往着错误的方向前行的。事实上我们获取用户反馈的过程中反反复复犯的错误就有那么 5 个。当前很多成熟的工具都能让我们快速的得到用户的反馈(比如 Intercom)，结果我们往往就会因为反馈来得太容易而有点得意忘形而乱开枪，为每个用户的诉求都去提供实现。

下面我们就好好看下这 5 个我们常犯的错误以及对应的解决方案。

1.  细化反馈获取对象

上图的英语按从左到右再从上到下的顺序是这样的：

• 所有用户
• 新用户
• 最近潜水用户
• 正在尝试 Beta 版本的用户
• 长期忠实拥趸
• 跟所有用户进行交谈获取反馈是没有必要的

当你过于发散的对所有的用户一起进行调研的时候，往往你就会丢失掉重点。你往往就会把昨天才刚刚注册的用户和一直伴你的产品成长的客户混为一 谈；把那些每天都在使用着你的产品的用户和那些只是偶尔造访的用户一视同仁；把那些只用了你的产品的某个功能的用户和使用了全部功能的用户相提并论。

解决方案: 其实你应该把不同类型用户的反馈给区分开来，以下就是一些方法

• 如果你想要的是增加新客户，那么去访谈那些新客户就好了。
• 如果你想要的是增强某一个功能，那么跟使用该功能的用户交流就足够了。
• 如果你想要知道为什么你产品的某个功能很少人使用，那么就去跟那些不使用该功能的人群沟通就可以了。
• 如果你想找出你的产品有哪些不足的地方，那么就去咨询下那些活跃的用户的看法就解决了。

2. 获取反馈不应是一次性的

我们对获取反馈往往存在一个先入为主的想法：在需要的时候才会去寻找用户的反馈。但这也就意味着往往你需要等上将近一个星期才能获得想要的用户 反馈。在这种情况下，你通常就会临时抱佛脚的开始广撒大网 - 开始主动的找所有的用户来问各种不同的问题，这你又重新犯了上面的第一条错误了。

这个错误的做法其实带来了双倍的害处：

• 首先是当你真正需要有反馈给你进行分析的时候你却两手空空如也；
• 其次是你只有在决定主动找用户调研的时候你才会得到有关你的产品的反馈。这就意味着你对你的产品就算已经逐渐被市场淘汰也一无所知了。

解决方案：周期性的跟用户进行交互。最简单且有效的做法就是在投放市场后的 30 天，60 天，120 天，1 年这些时间点去找用户拿反馈。一个更高级的做法是去根据产品/功能点的使用情况去获得用户使用反馈。比如，假如你的产品有个日历的功能点的话，你可以在某 些用户使用该功能的第 1 次，20 次，50 次的时候来获取相应的反馈。当一个用户习惯了某个产品的时候，他们的反馈才会趋逐渐向于成熟和理性。往往用户第一次使用的时候的反馈是关于该功能如何让他 困惑之类的，第 20 次使用时候会抱怨该功能让人沮丧，第 50 次时就会抱怨该功能哪些地方需要增强了。

3. 免费和收费用户应分而治之

上图描述的是关于免费用户和收费用户不同的反馈，免费用户通常会不断的索求新功能：

• 请提供与...同步的功能。
• 这可以放在我自己的主机上面运行吗？
• 这支持 Atom 协议的 Feed 吗？
• 请和下面这些...进行集成。
• 可以提供用 Dropbox 作为数据存储端的功能吗？
• 请增加一个日历功能。
• 你如果能提供...功能的话，我就会购买。

而收费用户跟多的是要求对已有功能进行改进：

• 请改善邮件邀请团队成员加入的功能。
• 请提升搜索性能。
• 请改善团队协助的功能。
• 请提供更好的检索工具。
• 请提供任务完成通知功能。
• 请改善任务安排功能，让其更简单。
• 请为检索加速。

如第 1 点所言，我们往往错误的把所有的用户的需求一视同仁，而没有考虑到他们究竟是付费用户还是免费用户。当然，如果细分的话你还要去区分究竟是 50 块钱的付费用户还是 500 块钱的付费用户，但大处着墨，我们首要区分开来的就是免费和付费的用户。长期免费使用你的产品的用户往往只能给你提供如何改进你的免费功能的建议反馈，而 这往往不应该是你的生意应该优先关注的部分。我们提供免费的功能的目的是去把用户给先粘住，然后慢慢的想办法让他们去掏钱购买付费的功能，同时也提高自己 产品的知名度。所以这里你就要注意了，你此时不应去相信那些充满欺骗的假设性的反馈：“如果...的话，我就会掏钱购买了"， "当...的时候我就会付费了“。这种带有欺骗性的假定性的反馈往往都是虚无缥缈不足取的，不能兑现的，我们需要的是实实在在的反馈。

解决方案：

• 如果要为你的的付费用户解决付费功能的话，去找付费用户拿反馈。
• 如果要勾引那些免费用户掏钱购买付费功能，去找那些掏了钱的客户谈谈。
• 如果要改进你的免费功能点，请那些免费用户喝喝咖啡吧。算了，我建议你还是别跟他们去喝咖啡了，直接免费的邮件咨询算了。因为我相信他们的反馈必然是想要更多的功能，免费的功能。

4. 偶发并不代表必然

俗语有云，偶发并不代表必然。当然，这并不能说一些偶发事件一点都不值得关注了。有些偶发事件其实跟容易去验证其可行性，我们去快速验证下就好了。

但，当有一天你发现有 5 个用户同时给你反馈说想在你的日历功能中增加一个事件提醒功能的时候，你不要立刻拍脑袋就去组建人员开始立项。你首要去做的是去确定这 5 个用户是否代表了所有其他的用户，你要去跟其他经常使用日历功能的用户进行交谈，听听他们是怎么说的。

解决方案：先把偶然发生的请求当作一个假设，别急着去实现它，先去验证它是否真存在价值。一旦你发现它真的是一个痛点的时候，也别急于立马去“实现满足用户请求的方案”，你需要再挖深点。这就到了我们下面将要谈的最后这一点了。

5. 用户往往表达不清楚想要什么

图左的对话是这样的：

团队成员们好，

功能需求：你们是在打造一匹快马吗？如果是的话，该马可以在预期计划中造出来吗？

此致敬礼，Dave

Dave,

你好啊。

我们已经把你的反馈需求纳入计划中了，我们将会在 2015 年第一季度把该更快的马交到您的手上。下图是该马的原型。

图右的对话是这样的：

团队成员们好，

功能需求：你们是在打造一匹快马吗？如果是的话，该马可以在预期计划中造出来吗？

此致敬礼，Dave

Dave，

你好啊。很感谢你提出对马的速度的重要性非常感兴趣，你还有其他需要我们可以改进的吗？

团队成员，

速度当然是很重要的一点了，但总的来说可靠性和耐力也同样的重要了。一匹可以让我一天能从甘肃跑到北京的马对我来说就最好不过了，不然我要运到北京卖的切糕就过期了...

“信息传递的过程中很容易产生失真！”，一个很生动的诠释这种情况的例子就是：“当客户用手指指着月亮的时候，我们天真的产品经理往往就会伸出 自己的中指好好观察，沉思该用户想表达的究竟是他的手指出了什么问题呢还是客户在伸出中指对自己进行侮辱。而事实上用户真实想要的是月亮”。

上图的“快马故事”常常被用来描述那些没有认真倾听客户反馈的情况。当中说明了，如果一个客户告诉你他想要一个更快的马的时候，他给你传递的信 息就是仅仅告诉你“速度”是马进行运输过程中一个很重要的他想要的功能。然后你就会先入为主的围绕速度这个点展开漫长的开发。返回我们上一点所提到的日历 这个例子，如果那几个用户同时提出来说该日历的已有事件功能过于复杂了，你可能就会耗费几个月的时间重新去打造一个流畅用户体验的事件表单功能给这些用户 重新体验，几经改版后，最终你发觉其实问题并没有解决。最终你再去找其他所有使用该日历功能的用户获取反馈的时候，你发觉痛点原来并不是来自这些事件表单 的复杂度，而是在这些事件的可复用性上面。所以你最终的解决该痛点的办法其实只需要 1 个星期的时间来提供事件循环和事件复制的功能就完事了。

解决方案：请清楚认识到，客户提出的功能需求其实掺杂着他们自己对设计的理解，对你的产品的熟悉程度，以及 他们对自己所认为的痛点的理解。他们其实并不清楚你的产品的愿景是什么，你正在完善功能的方案是怎么一回事，以及什么样的技术是最可行的。所以这就是为什 么你往往需要在用户的需求上再做一层到两层的抽象提炼，直到发现真正的用户痛点，这样才能让所有的用户都受惠。

当然，在一些已经成为共识的功能点上面，我们并不需要每次都检查上面的几点用户反馈才能行动，比如在我们中国，你一个日历工具加上个农历功能我相信没有多少用户会反对的。

但，在其他需要用户协助才能确定的功能上面，请你还是按照上面的几步跟你的客户好好互动并获得有效的反馈进行分析，这会让你的行动变得更理智，更聪明，更敏捷。