产品经理能不知道这点儿事？（一）

作为一个曾经在战场上玩命的“伪产品经理”，近一年时间我参与了很多产品的讨论和制作，有的正在孵化中，有的现在已经开始，有的已经上线了，有的仍然在不靠谱阶段。

在过程中，我发现参与的人都不约而同的犯一个病：一坐在会议室正式讨论，就天南海北，以说痛快了为主；在饭桌上，说起产品经理的修养以及产品的陷阱，头头是道。

我没有说反。

这是因为：自己做产品是一个话题，产品经理的修养是另外一个话题，互相没关系。这中间有断层，没有把尺子往自己身上比划。

我原来也有这个毛病，一遇到具体的事，理论和指导思想就都忘的一干二净了。现在我尽量把持住自己，这篇儿我就列举一下都在哪些方面把持。

分四个方面，

用户篇

1、用户的根本需要

谁都知道不论做To C还是To B，都要先分析Persona，找到用户是谁，然后分析他的需求。

这话没毛病吧？错了，其实有大毛病，“分析他的需求”这句话就有毛病，为什么呢？用户是没有需求的，用户提的需求都是根据他的环境和见过的东西想象的解决方案。作为项目组的产品经理，你应该提出解决方案的，而不是用户。

在讲课的时候，我经常说一个笑话：假定你的客户是一群大猩猩。大猩猩看见鸟在天上飞，想去哪里直接翅膀一张就去了。就跟项目组说，你要让我能飞。项目组很牛的，会基因改造，立马答应了，不过要把大猩猩的肌肉量减少80%，骨头变成空心儿的。大猩猩一听急了：“这不连猴子都打不过了么？不行，我要又能飞，体型、肌肉、骨头又要和现在一样”。项目组也急了：“再见，祝您生活愉快”

为什么会出现这种情况？因为大猩猩经常看到鸟飞，他只有这一个方案，这就是他的需求。

怎么解决？只需问一个问题：您为什么想飞呢？

大猩猩们会回答：我想飞到树上摘香蕉吃，这种傻问题还用问？

结果不言而喻，项目组做了一个梯子。

看，需求和需要是多么的不一样？那么应该找需求还是需要？

但是这仍然不是这部分的主题，这部分的主题是“根本需要”。即使产品经理询问客户需要了，客户也会说出很多，比如我有一个朋友做“学校招生”的项目，询问了招生的老师和主任以后，得到一堆需要：要招生快，要能够让学生自主选择专业，要帮助推广学校品牌，要给招生老师计算分成，要学生能二次分享，要能提醒尽快支付学费。。。

这些都是需要。每一个都有意义，项目组的产品经理当时踌躇满志的，发心立誓的一定这次做一个牛X系统。要走的时候，校长拉着我们的手说：你看我们6月、7月份就是主要的招生季节了，你们能不能今年让我们用上？

当时刚放完劳动节长假。。。项目经理一下就瘪了。

不过后来我们问了一个问题：您觉得所有刚才讨论的，哪个最重要？校长丝毫没有犹豫：让招生老师能拉学生报名。

你看，这就是根本需要。一个招生系统的根本需要可不就是“报名”么？

然后项目组的小伙子们真的只用了一个月做了微信小程序，给招生老师和第三方机构做的，学生用微信扫码，然后填写报名表，系统记录了这个学生谁招进来的，后台能导出一个Excel。就这点儿功能，一个月足矣了，然后上线了，然后就开始用了。

总结一下，当分析用户需要的时候，把着一个愿景做，找到根本需要，其余的以后再说。

2、怀疑一切，所有项目组自己提出来都叫“假设”，千万别当真。找最终用户聊。

不论一开始做多么严谨的需求调研，后续总有一些事情不确定，这时候产品经理就会自己做主，把自己当成用户。

本质上说，这是对的，要不然呢？总要继续做下去不是？

但是产品经理往往忘了一件最重要的事情：

把所有自己做的结论都当成假设，把所有假设列一个单子，找最终用户确认自己假设的对不对。

我有一次参与了一个项目，给渔民做App，具体功能跟简单，就是填写表单，然后提交。一共3个月的项目，需求讨论小一个月，所有的都想到了，就连在海上是不是有手机信号，离岸边多远就能连网了都想到了，我们都坐船下海做调研了。但是在第三次showcase的时候，还是几乎失败了。

产品经理是UX出身，产品流程和体验都做得很好。前两次showcase中，项目组每个人都试用了，渔业的官员也用了，大家都对用户体验赞不绝口。直到第三次Showcase，找了一个渔民试用，他一开始用，我们就知道：“完蛋了”。

你是不是猜“渔民不懂IT，不会用？”，你错了，人家天天填这个表，只不过不是在手机上，对于填表这一套比谁都熟练，连教都不用。

问题出在“手”上：渔民的手大！我的手就够大的吧，我们项目一240多斤大胡子的手比我还大，可是渔民的手比他的还大一号。

手大怎么了？手大手指头粗啊，手指头粗按钮按的不准啊。产品经理是按照正常的间隔和大小设计的输入框和按钮，谁用都没问题，但是渔民用的时候，需要点好几下才能“凑巧”给输入框焦点，填写最后一个输入框的时候，一不留神就碰到“提交”。海洋局有规定：提交了以后如果撤回，要发邮件说明理由，流程很麻烦。最后，人家渔民挺好说话的：The App is good, I'd rather use the paper one.

总结一下，怀疑一切，你自己想出来的，那叫”假设“，别把”假设“当真事。

3、加强用户反馈，用数据分析做支撑

用户反馈分为两个层面：反馈和信息收集。

先说信息收集，为什么说做一个App不是三两下就完事了，因为有很多的隐性工作，比如设计用户行为收集。不论什么样的App，如果不是做着玩的，总得知道人家怎么用吧？你就即使做两个功能，也得知道用户喜欢哪个是不是，直接问么？好，我经常遇到这种情况，做用户调研的时候，用户在问卷上填写经常使用功能A，但是我们死活看数据就是功能B被点的多。不是用户成心骗人，他真的认为功能A用的多，为什么？因为功能A是惊喜型功能，给用户留下的印象深，曾经给用户帮了大忙，而功能B是大众功能，谁用了都不会记得。

所以，”觉得用了“和”真用了“，是两码事。把用户的使用习惯收集起来，数据不会撒谎的。

再说反馈：反馈是两个作用，

第一，听到用户真实的声音；

第二，给用户一个发泄的渠道；有时候这一点比第一个更重要。举个例子，每次点充值的时候就闪退，害得用户买不了道具，谁需要发泄一下？重度使用的用户哇。不是重度用户就立马卸载你的App了。

重度用户好比情人，爱的时候是真爱，会帮你做很多免费推广，逢人就说你App好；可他恨你的时候也是真恨，逢人就说你的App骗人。这时候你要是提供了一个反馈的渠道，他到这里面说，即使你回复的不及时，大多数情况下他也是在这个渠道骂街，好比一个人恨你，他如果能指着你的鼻子直接骂，就不会跟别人说骂你的话了。直接骂多解气，气撒了咱再好好解决问题。

下次说：功能和内容篇