笔者总结了产品经理的三大禁忌，分享给大家。希望能帮助各位产品伙伴解决类似问题或者避免类似问题。
昨天一个新产品合伙人问了我一个这样的问题:
在思考问题、提炼需求的时候，我总是站在用户的角度思考问题。最后，经过多次思考和梳理，提出了我认为有效的针对性解决方案和实施方案，或者说我灵机一动，想出了一些我认为可以取悦用户的想法，我很高兴实现了进度。
结果上线一段时间后使用率很低，甚至有用户觉得产品经理在自说自话。这让我觉得很郁闷，但又无法反驳——因为即使是大公司，在做出用户认为自我满足的功能时，也会招致用户的吐槽。比如【支付宝在儿童节给用户昵称加了“宝宝”，但不允许修改】。
但是，我不忍心把大家辛辛苦苦做出来的这些功能下线，因为没有足够的用户数据来证明或者证伪这些功能的价值，所以我无法做最后的决定。
更有甚者，我一直认为可能是推广策略出了问题，导致错过了用户内心的诉求点，造成了用户认知的偏差，所以一直想着再优化一遍。但是如果最后没有改善，那就是对我们投入成本的又一次浪费。
我现在该怎么办？怎么才能解决这个问题？以后怎么才能避免这种情况？
这位小伙伴提出的问题，我觉得是所有产品朋友在从业过程中任何阶段都可能遇到的问题，无论是资深产品还是新手产品都是一样的。所以很有必要认真思考，分享一下我的反思成果。希望能帮助各位产品伙伴解决类似问题或者避免类似问题。
一.由该问题反映出的【产品三大忌】针对这个问题，我总结了三个关键词:瞎猜，自满，自大。
瞎猜:“瞎猜”是“需求挖掘和收集”中不负责任的行为。
需求挖掘和收集是指产品经理从个人体验和习惯认知的角度，尽力解读用户的诉求、用户的反馈信息和产品使用数据，通过综合分析和理解，最终明确【受众特征】、【需要解决的问题】、【用户的使用场景】。
瞎猜是指在需求挖掘和收集的过程中，产品经理仅仅依靠主观判断来定义需求，而忽略了通过【用户调查和回访】、【数据抽样和分析】、【请别人来查】的结合来保证需求定义的合理性。
自我满足:“自我满足”是“方案构思与设计”中不健康的行为。
方案构思和设计是指产品经理在明确需求后，从自己对用户和产品的理解出发，找出并确定满足需求的最佳实施方案。
自我满足是指在方案构思和设计过程中，产品经理对需求进行过度的解读和延伸，或者过于关注某些需求细节和 *** 作方法，而忽略甚至违背了需求的核心关注点。
傲慢:“傲慢”是“产品迭代期间，尤其是复盘后期”的非理性行为。
在产品迭代过程中，尤其是后期复产，产品经理需要根据实际运营数据，验证自己的需求实现方案是否被用户认可或接受，自己最初的猜测是否正确。
但在这个阶段，如果产品经理对自己的判断过于自信，听不进用户、营销、运营、技术同学的意见和建议，基于现状做出分析判断，那就是“自大”问题。
这三个产品经理在产品迭代上犯的错误，其实都是很常见的错误。
这种错误往往发生在产品迭代进入瓶颈期，或者产品处于迭代节奏非常紧张的时期，或者产品经理需要做的事情太多，严重占用了自己的产品思考时间。
我在职业生涯的不同阶段都犯过类似的错误，也对自己和产品的发展造成了一些负面影响。
二.【瞎猜】的成因、结果和应对方法1.“瞎猜”的成因如前所述，瞎猜是指在需求挖掘和收集的过程中，产品经理只根据主观判断对需求进行猜测和定义，而忽略了通过【用户调查和回访】、【数据抽样和分析】、【请别人来查】的组合来保证需求的合理性。
所以盲猜的初步原因是“产品经理在挖掘和收集需求时，使用了猜测需求的方法”。而“不经过任何验证就猜测需求”就是“猜测”变成“摸黑猜测”的原因。
2.“瞎猜”的结果如果产品经理长期不负责任的“在黑暗中猜测”，对产品、对公司、对用户、对自己都有很大的负面影响。
对用户：长期上线一些不符合用户期待的功能，而用户真正想要的功能却迟迟没有出来，导致用户对产品失去兴趣，认为产品不尊重他们的真实需求，进而放弃产品。对产品：为产品增加了很多用户并不需要的东西，影响产品的原有口碑形象，并且增加了产品的复杂和功冗余程度，无形中提升了产品使用和后期迭代门槛。对公司：造成人力和资源的持续浪费，影响公司的正向发展。对自己：养成了不负责任、随意遐想的产品习惯，并且在持续做出无效功能和产品的同时，影响了自己的信誉度和口碑。3.猜测需求的好处在这种情况下，肯定有人会问，既然知道“猜需求”可能会导致“瞎猜”，造成那么多负面影响，为什么还要猜需求而不是咨询用户呢？没听过“需求应该来自用户”吗？
任何解决方案都有优点和缺点。要搞清楚这个问题，我们需要搞清楚的其实就是这个问题——猜测需求相对于直接和用户沟通有什么优势，让大家愿意承担可能成为“瞎猜”的风险。
(1)“猜测需求”是合理的做法，而没有依据和支持的不合理猜测。
因为“需求来自用户”讲的是需求的来源。猜测用户需求和咨询用户一样，本身就是一种获取需求的方式。
只要猜测需求能够得到合理的数据和用户反馈的支持，需求的本质来源还是用户，两者并不冲突。但是，如果没有合理的依据支持对需求的猜测，这种猜测就会沦为“不负责任的主观、片面的遐想甚至盲目的想象”，变成“需求来自于已经猜到产品的用户”，违背了“需求来自于用户”的本质。
(2)直接与用户沟通，其对于“需求挖掘和收集”的价值可能并不如你预期。
这个话题有很多例子，我想大家都很熟悉:在福特诞生前最初的用户调查中，用户表示想要一匹更快的马；用户说他想要黄色的PSP，但是面试之后，他拿了黑色的奖品...
这些例子都是为了说明一个事实，用户说他想要的，未必是他内心真正需要的；用户随便提的实现方案，不一定是真正能让他满意的最佳方案。
所以直接和用户沟通，需要对“需求挖掘和收集”的价值打一个问号。其间需要产品经理的深度思考和反复确认，才能产生真正合理的用户需求。
(3)与直接与用户沟通相比，“猜需求”是一种参与方更少、可控性更强、实践性更好的方法。
首先，大部分产品经理很多情况下无法直接接触用户，而是通过运营、支持、客服、销售人员的反馈，间接了解用户的反馈和需求。在用户与这些人的沟通中，无论这些人是否专业，是否对产品和用户足够了解，在“一次传递”的过程中，需求和反馈可能已经存在误解、遗漏和主观判断；在这些人和产品的“二次传播”过程中，信息会再次失真。你不知道也很难确定这期间发生了什么变异。
当然，这其实也说明了“直接与用户沟通，收集反馈”的必要性。但同时也说明了“多方参与需求协同传导”的风险。
其次，直接和用户沟通或者做用户调研，是需要时间和规划的。在产品不断迭代的阶段，产品经理可能没有足够的时间做用户沟通和调研。尤其是初创公司，产品经理有很多事情要做，没有时间分配给用户调研。
然后，无论是用户调研还是用户沟通，都需要持续一段时间或者与多个用户沟通，才能获得足够的数据和足够的反馈，覆盖各类用户，才能作为需求合理性的支撑。
这个过程涉及多方(产品、运营、市场、用户)，进度和时长存在不可控因素。如果在创业公司，产品经理可能没有“让多个部门愿意合作，帮助收集产品需求”的团队资源。
最后，如果是产品持续迭代的阶段，产品经理可能需要在很多时间里明确产品下一步要做什么，要做成什么样子，所以没有足够的时间等待用户调研和用户沟通的结果，再决定下一步做什么。
以上就是产品经理在“挖掘和收集需求”的过程中，更喜欢“猜测用户需求”的原因。
4.猜测需求的弊端但同时，“猜需求”也有弊端。比如让产品经理逐渐远离用户，习惯闭门造车...最大的弊端是可能导致片面、不客观的需求判断，甚至有“瞎猜”的可能。
因为每个人都是以自己的身份、等级、视角来感知世界、观察他人的。即使是产品经理也无法摆脱这种“个人身份和视角”的限制。
产品经理猜测的需求，首先代表“自己想象出来的一群人”，其次代表“他对自己想象出来的这群人的需求的猜测”。这期间有太多误判和误解的可能。
5.如何合理“猜测需求”并且避免瞎猜知道了“猜需求”的好处和可能产生的负面影响，就要客观合理地使用“猜需求”的手段。
(1)时刻保持清醒的头脑，提醒自己“猜测需求”是一种利弊共存的情况。
作为一个产品经理，无论你做什么产品，做什么功能，你都要有一个清晰的认识——我发现的需求，我发现的痛点，通过“猜需求”构思出来的方案，很可能只是为了满足我自己或者我假设的用户群体和需求场景。
有了这样清晰的认识，当你最终确认自己的需求时，你会更加清醒和警觉。
(2)结合“用户沟通和调研”使用“猜测需求”，做好前期调研、数据分析和审核工作。
在“猜测需求”的同时，结合一些小范围的“用户交流和调研”。这样既能有效控制精力和时间投入，又能通过“与用户沟通，了解情况”，从用户的角度初步检查“需求的合理性”。
其次，在确认需求并最终落地的时候，一定要做好前期调研、数据收集、数据分析、后期复盘等工作。这样验证几次，你就会知道:哪些猜测是真正得到用户认可的，哪些是真正的用户需求，哪些是你自己的猜测...
慢慢的，你会积累一种判断经验，很多在黑暗中拍摄，强行构造需求的方案或功能。想深一点，就会觉得不靠谱。
这种经验只有通过“前期预研、中期小范围试错、数据收集分析、后期复试”的完整验证过程才能逐步获得。没有牛逼的产品经理，事实并非如此。
所以，如果是偶尔的“有数据或用户反馈支撑，但最终被用户行为和数据证伪的需求”，放松就好，不要太苛刻，也不要太大意。但完全有必要承担责任，全面检讨，并总结原因，从中吸取教训，尽量避免提出一些想象中的要求。
支付宝“宝宝”事件的一些个人想法最后，关于【支付宝在儿童节给用户昵称加了“宝贝”，但不允许修改】，下面是我的看法:
支付宝“强加宝贝又不能修改导致用户愤怒”的想法本身是对的，错的是如何实现。
创造力:
儿童节，用户被贴上“宝贝”的标签，以迎合节日气氛。这个创意虽然没什么新意，但确实能迎合节日气氛，而且很符合“让人忍不住怀念六一快乐童年时光”的情感触发点。
实施模式:
强行更改用户昵称，不允许用户改回来。想出这种变现方式的人，无论是产品、运营还是市场童鞋，都没把这个当回事，更别说动脑子了。
要知道，个人用户信息，昵称的编辑权限，一定是用户自己在可感范围内的。即使产品经理知道这只是后台数据库中一个无伤大雅、可 *** 作的字段，他也不能表明自己可以随时调整，他也不能真的随意修改。而且只有出现问题或者客服给用户提供支持，用户主动提出或者接受的情况下，才能帮助用户调整。作为一个互联网人，这应该是基础知识。
更何况支付宝用户的主流认知是电子钱包，一种互联网支付工具。如果你敢随意更改用户钱包里的用户签名，又不给用户改回来的权利，用户当然会觉得:卧槽，你今天可以随意更改我的昵称，明天你还敢把我钱包里的钱转到别人的账户上吗？你通过改昵称，让用户觉得你可以随意动他的账号。那么，用户能不把你往坏处想吗？如果没有，你喷谁？
甚至在6月1日，用户第一次打开支付宝，就推送一个“今天，我们都是宝贝”的h5页面，然后随机推送一些宝贝勋章给用户，比如“好宝贝”、“好宝贝”、“可爱宝贝”。奖牌会陈列在昵称旁边，再配合一些“当天购买玩具产品，享受一定优惠”的营销活动。这样可以吗？
所以支付宝的“宝贝事件”是一个在功能实现过程中没有人动脑子的节日运营活动。不是瞎猜，来自嗨，更不是灵机一动...我的脑子没带，哪来的脑波？
以上是一些个人想法，不喜勿喷。
写在最后：原计划是一篇一篇分析“三忌”。分析完【瞎猜】，发现不知不觉写了这么多。看来我的废话确实不少~尴尬。
由于时间限制，我打算分成两篇，在下一篇文章中继续详细分析【自嗨】和【自大】。没到的请谅解。
对于【产品迭代过程中产品经理的臆测、自鸣得意、狂妄自大】，大家有什么新的看法或想法吗？欢迎对此感兴趣的童鞋，或者想一起交流探讨的朋友，来评论交流。
文章作者是@亚伦暖尘。未经许可，禁止转载。
注:阅读相关建站技巧请移至建站教程频道。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）