产品经理三大忌：瞎猜自嗨和傲慢

Posted 2020-09-22

本文和大家分享的主要是产品经理的三大禁忌，期望能帮助各位产品小伙伴们解决你们遇到的类似问题，或者避免类似问题的发生。

   昨天，有一个入行不久的产品小伙伴，咨询了这样我一个问题：

自己在思考问题和提炼需求的时候，总是会自诩站在用户的角度去看问题，最终通过多次思考、梳理，提出自认为有效的针对性解决、实现方案，或者灵机一动想出一些点子觉得可以讨好用户，就非常高兴的排期实现了。

结果上线一段时间后，使用率很低，甚至有用户觉得是产品经理在自嗨。这让我觉得很沮丧，但是又无法反驳——因为即便是大公司，在做出来用户认为是自嗨的功能时，也会招致用户的吐槽，例如【支付宝在六一儿童节把用户的昵称后加上了“宝宝”还不允许修改】。

可是，我又不忍心把这些大家辛辛苦苦做出来的功能下线，因为没有足够的用户数用数据来证明或者证伪这些功能的价值，让我没办法做最终决定。

而且，我还总想着说不定是在推广时策略存在问题、导致没有打中用户内心的诉求点，导致用户认知产生偏差，所以还总想着再优化一次试试看。可如果最终还是没有起色，那等于又一次浪费了我们的投入成本。

我现在该怎么办？怎样才能解决这个问题？以后又该如何避免这种情况呢？

这位小伙伴提出的问题，我觉得是各位产品小伙伴们在从业期间的任何阶段都可能会发生的问题，而且无论是资深产品还是新手产品都一样。所以，有必要认真思考一下，并将我的反思结果分享出来。期望能帮助各位产品小伙伴们解决你们遇到的类似问题，或者避免类似问题的发生。

一. 由该问题反映出的【产品三大忌】

针对这个问题，我从中总结出了三个关键词：瞎猜、自嗨、傲慢。

瞎猜：“瞎猜”是“需求挖掘与收集”中的一种不负责行为。

需求挖掘与收集，是指产品经理从个人已有经验、惯性认知的角度出发，尽力去解读用户提出的需求、用户反馈的信息、产品的使用数据，通过综合分析和理解，最终明确地定义出【受众人群的特征】、【需要解决的问题】、【用户的使用场景】。

而瞎猜，则是指在需求挖掘与收集的过程中，产品经理只凭借主观判断来定义需求，忽略了结合【用户调研回访】、【数据采样分析】、【另请他人校验】等方式，来确保需求定义的合理性。

自嗨：“自嗨”是“方案构思与设计”中的一种不健康行为。

方案构思与设计，是指产品经理在明确定义了需求之后，从自己对于用户和产品的理解出发，找出并确定用于满足该需求的最佳实现方案。

而自嗨，则是指在方案构思与设计过程中，产品经理过分解读、延伸需求，或在过程中过分关注某些需求细节和操作方式、忽略甚至违背了需求的核心关注点。

傲慢：“傲慢”是“产品迭代尤其是后期复盘”时的一种非理性行为。

在产品迭代尤其是后期复盘时，产品经理需要根据实际运行数据，来验证自己的需求实现方案是否被用户认可或者接受，以及自己的初期猜想是否正确。

但如果在这个阶段，产品经理过分对自己的判断迷之自信，不能听取来自用户、市场、运营、技术同学的意见建议，并结合现状进行分析和判断，那就是犯了“傲慢”的毛病。

这三个产品经理在产品迭代时出现的错误，其实是非常常见的错误。

这种错误，多发于产品迭代进入瓶颈期的阶段，或者产品处于迭代节奏非常紧张的时期，或者产品经理需要干的事情太多、严重占用自己的产品思考时间的情况下。

我自己也曾经在不同的从业阶段，都多多少少犯过类似的错误，而且也对自己和产品的发展造成了一些负面影响。

二.【瞎猜】的成因、结果和应对方法

1. “瞎猜”的成因

前面已经说过：瞎猜，是指在需求挖掘与收集的过程中，产品经理只凭主观判断来猜测和定义需求，忽略了结合【用户调研回访】、【数据采样分析】、【另请他人校验】等方式，来确保需求的合理性。

由此可知，瞎猜的最初成因，其实是“产品经理在需求挖掘、收集时，使用了猜测需求的办法”。而“猜测需求后未进行任何校验”，则是导致“猜测”成为“瞎猜”的原因。

2. “瞎猜”的结果

如果产品经理长期不负责任的“瞎猜”，这对于产品、公司、用户和自己的负面影响，都是很大的。

· 对用户： 长期上线一些不符合用户期待的功能，而用户真正想要的功能却迟迟没有出来，导致用户对产品失去兴趣，认为产品不尊重他们的真实需求，进而放弃产品。

· 对产品： 为产品增加了很多用户并不需要的东西，影响产品的原有口碑形象，并且增加了产品的复杂和功冗余程度，无形中提升了产品使用和后期迭代门槛。

· 对公司： 造成人力和资源的持续浪费，影响公司的正向发展。

· 对自己： 养成了不负责任、随意遐想的产品习惯，并且在持续做出无效功能和产品的同时，影响了自己的信誉度和口碑。

3. 猜测需求的好处

既然如此，那肯定会有人问，既然知道“猜测需求”可能导致“瞎猜”，并且造成这么多负面影响，那为什么还要去猜测需求、而不是咨询用户呢？难道没有听过“需求应该来源于用户”吗？

任何解决办法都是利弊共存的。想弄清楚这个问题，我们要搞清楚的，其实是这个问题——相较于直接与用户沟通，猜测需求有哪些好处，让大家愿意承受可能变成“瞎猜”的风险。

（1）“猜测需求”是合理的做法，不合理的是没有依据和支持的揣测。

因为，“需求来源于用户”讲的是一个需求来源的问题。而猜测用户需求，则跟咨询用户一样，本身是一种获取需求的方式。

只要猜测需求能够有合理数据和用户反馈作为支撑，那需求的本质来源还是用户，二者并不存在冲突。但是如果在猜测需求时没有合理依据作为支持，这种猜测就会沦为“不负责任的主观、片面的遐想甚至瞎想”，变成了“需求来源于产品揣测出来的用户”，这就违背了“需求来源于用户”的本质。

（2）直接与用户沟通，其对于“需求挖掘、收集”的价值未必如你所期待。

这个话题，有很多例子，想必大家都已经耳熟能详了：福特汽车诞生前的初期用户调研时，用户说自己想要的是跑得更快的马；用户说想要黄色的PSP，却在访谈结束后，不约而同的拿走了黑色的奖品······

这些例子，都是为了说明一个事实：用户嘴上说的想要的，未必是他真正内心需要的；用户随口一提的实现方案，未必是真的能够满足他的最好方案。

因此，直接与用户沟通，其对于“需求挖掘、收集”的价值量，是需要打一个问号的。其间，还需要产品经理的深度思考和反复确认，才能够产生出真正合理的用户需求。

（3）相较于直接与用户沟通，“猜测需求”是一个涉及方更少、更可控、实操行更好的办法。

首先，大部分产品经理在很多时候并不能直接接触到用户，而是通过运营、支持、客服、销售人员的反馈，来间接的了解到用户的反馈和需求。在用户和这些人员的沟通中，无论这些人是否专业、是否足够了解产品和用户，需求和反馈在“一次传递”过程中，就已经可能产生理解偏差、遗漏、主观判断；而在这些人和产品之间额“二次传递”的过程中，信息又会出现“再次失真”的情况。期间到底发生了什么变异，你是不知道并且很难确定的。

当然，这其实反而说明了“直接跟用户沟通、收集反馈”的必要性。但同时也说明了“多方参与的需求协同传递”的风险。

其次，直接跟用户沟通或者做用户调研，都是需要时间和计划安排的，在产品持续迭代的阶段，产品经理可能并没有足够的时间来做用户沟通和调研。尤其是在创业公司，产品经理要做的事情非常多，就更加没有时间分配到用户调研上去了。

然后，无论是用户调研还是用户沟通，需要持续的进行一段时间或者与多个用户沟通，才能得到足够的数据和足以覆盖各种用户的反馈，来作为需求合理性的支撑。

这个过程，涉及方比较多（产品、运营、市场、用户），而且进度和时长都存在不可控因素。如果是在创业公司，产品经理可能并没有这种“让多部门愿意配合协同、为产品需求收集提供帮助”的团队资源。

最后，如果是产品持续迭代的阶段，产品经理可能需要在很多时间内就明确产品接下来要做什么、做成什么样，因此并没有足够的时间等待用户调研和用户沟通的结果出来，才决定下一步要做什么。

以上，是产品经理在【挖掘、收集需求】的过程，更愿意采用“猜测用户需求”的原因。

4. 猜测需求的弊端

但与此同时，“猜测需求”也是有弊端的。例如，让产品经理逐渐远离用户、习惯闭门造车······而其中最大的弊端，是可能会导致片面、非客观的需求判断，甚至导致“瞎猜”的可能。

因为，任何人都是以自己的身份、等级和视角来感知世界、观察他人的。即便是产品经理，也无法摆脱这一“个人身份和视角”的局限。

产品经理猜测的需求，首先代表的是“自己所设设想出来的那么一群人”，其次代表的是“自己对于这批设想出来的人的需求猜想”。这期间，有太多误判、误解的可能。

5.如何合理“猜测需求”并且避免瞎猜

在知晓“猜测需求”的好处和可能导致的负面影响后，我们就要客观、合理的使用“猜测需求”的手段。

（1）时刻保持头脑清醒，提醒自己“猜测需求”是利弊共存的

作为产品经理，无论做什么产品、什么功能，都一定要有清晰的认知——我通过“猜测需求”发现的需求、找到的痛点、构思的方案，很可能只是满足我自己或者我所假定的用户人群和需求场景的。

有这样清楚的认知后，你在最终确认需求时，也会更加的清醒和警惕。

（2）“猜测需求”和“用户沟通、调研”结合使用，做好预研、数据分析和复盘

在“猜测需求”的同时，结合做一些小范围的“用户沟通、调研”。这样既能有效控制精力和时间投入，同时也能通过“与用户沟通、了解情况”，对自己猜测出来的需求进行从用户角度的“需求合理性”的初步校验。

其次，在确认需求、最终落地时，一定要做好预研、数据收集、数据分析、后期复盘。通过这样多验证几次，你就会知道：哪些猜测需求是用户真的认可的，哪些真的是用户的需求，哪些是自己的瞎猜……

慢慢的，你就会积累出一种判断经验，很多瞎猜、强行构建需求的方案或功能，你稍微想深一点，就会觉得不靠谱儿。

这种经验，是真的要通过不断经历“前期预研、中期小范围试错、采集分析数据、后期复盘”的完整验证过程，才能逐渐获得的，没有一个牛逼的产品经理，不是这样逐步走过来的。

所以，如果是偶尔的“有数据或用户反馈支撑、却最终被用户使用行为和数据证伪的需求”，放宽心就好，不要过分苛责或者计较。但必要的承担责任和复盘总结，也绝对不能少，并且要从中总结原因、吸取教训，尽量避免做一些臆想的需求。

支付宝“宝宝”事件的一些个人想法

最后，关于【支付宝在六一儿童节在用户昵称后加上了“宝宝”还不允许修改】，下面是我的看法：

支付宝的“强加宝宝并且无法修改招致用户愤而开喷”，其创意本身是没错的，错的是实现方式。

创意：

在六一儿童节，通过给用户贴上“宝宝”标签，来迎合节日气氛。这个创意，虽然并没有什么新意，但是确实能起到迎合节日氛围的效果，而且很贴合“人们在六一总会不由怀念童年欢乐时光”的节日感性触发点。

实现方式：

强行改用户昵称，并且不允许用户修改回来。想出这种实现方式的人，不管是产品、运营还是市场童鞋，都绝对没把这个当回事儿，更没有带脑子。

要知道，昵称这种个性用户信息的编辑权限，在可感知范围内，必须是用户自己的。就算产品经理明知道这只是一个后台数据库中无关痛痒、随时可操作的字段，也不能表现出自己可以随时调整，更不能真的随意去修改。而且，只有在出现问题或者客服为用户提供支持时，并且是用户主动提出或者表示接受的场景下，才能帮助用户调整。作为一个互联网人，这一点，应该是基本常识吧。

更何况，支付宝的用户主流认知，就是一个电子钱包，一种互联网支付工具。你敢在用户的钱包里随意改用户的签名，还不给用户改回来的权限，用户当然会觉得：卧槽，你今天能随便乱改我的昵称，明天是不是就敢把我钱包里的钱转到别人的账号里了？你通过改昵称这件事，变相的让用户认为你能随意动他的账号，那用户还能不把你往坏处想？不喷你喷谁？

你哪怕是在六一当天，用户首次打开支付宝时，推动一个“今天，我们都是宝宝”的h5页面，然后给用户随机推送一些宝宝勋章，比如“乖宝宝”、“好宝宝”、“萌宝宝”，勋章会展示在昵称旁边，再配合一些“当天购买玩具产品享受某类优惠”的营销活动，这样是不是也行啊？

所以说，支付宝的“宝宝事件”，就是一个功能实现过程中没有人带脑子的节日运营活动。并不算是瞎猜、自嗨，更不是灵机一动……脑子都没带，哪来的灵机？

 

来源：人人都是产品经理