前言/导语
做技术这几年，见过最离谱的不是BUG，而是那些“光怪陆离”的产品经理。每一位都能写进职场故事集，今天就来分门别类，聊聊这些年遇到的奇葩产品经理。
（本文不是针对谁，只想为新晋打工人避雷，也给技术人添点谈资。）
三大伪产品经理特征
- 不画原型
-
- “只会PPT、不会流程图，页面原型全靠嘴巴比划，‘我以为你懂’”
- 需求模糊
-
- “一开会就‘你们懂的’，写需求像在做禅修，功能随心变、实现靠玄学”
- 推锅能力MAX（责任漂移型）
-
- “所有BUG都是‘开发理解错了’，产品方案从不留底稿，出了问题‘都是别人没跟上我的思路’”
- 或者“不会做文档，不写说明，凡事一句‘看下微信’、‘群里说过’，最后能全推开发就全推开发”
具体类型以及应对方案：
一、文盲类
“有需求写不明白、UI看不懂、交互不会用，自己是产品经理，却比客户还不会写邮件。”
正所谓大千世界，无奇不有，文盲也是可以做产品经理的。
故事1：
写了两年的项目，写到一年半的时候，对了一下合同，发现是要写用户管理功能的。
然后就是“团结一致，共同加班”，把功能给补齐。
应对策略：从一开始就要到合同，对合同内要求的功能有所了解，多的可以battle，少的可以及时提醒产品经理没画，不要影响验收。
建议话术：这个功能我看合同里有写，方便我们拉一份详细清单吗？后面验收的时候也好一一对应，省得大家遗漏。
故事2:
写项目到中期验收了，开发参与演示，然后客户看了，说跟当初说要的功能不一样。（还是很好说话的客户，就是有点到bug，都不会说的那种。神仙）
追根溯源，产品经理根本没好好做会议记录，也没有理解客户要的功能。
应对策略：虽然很烦人，但遇到这种，建议就是参与一下每次的客户会议，起码可以知道一下具体开发的内容，可以录音备份，防止产品原型画出来与客户要求不一致。
建议话术：方便的话我们开发可以一起旁听下会议，如果有什么功能，我们这里可以评估一下可行方案和大致工期，这样也可以控制成本。
故事3:
拒绝画原型细节，不懂交互逻辑，但非爱嘴上讲讲。让工作群里写清楚，非说写不清楚，要面对面讲才行。
你品，又不是什么情感类节目，有什么产品设计是画流程图，加文字和原型不能解释的。
而且文字写不清楚，讲讲就能讲清楚了吗？逻辑上走不通啊。24k纯没想明白，要开发自己猜个能跑通的。
产品经理pua话术：要多当面沟通，你怎么会这么理解这个功能呢？我不是这个意思呀。
应对策略：录音发群里（硬刚版本），坚持要求文字记录。如果是试用期的兄弟，可以选择录音，然后整理一版文字发在群里。然后一个个功能要求产品经理确认具体方案，确认清楚再开发。不建议太在乎人情，先兵后礼，保护自己才是真的。
建议话术：嗯嗯，那么介意我这边录音吗？因为没有文字记录的话，我们这边后续开发可能会漏掉的。放在群里，大家各开发和测试也可以同步一下信息呢～
故事4:
自己菜，说你讲话太专业，他/她听不懂，就说你态度不好。那基本ui/ux，交互逻辑自己不学，公司标品什么功能都不知道，怪我咯。
问要做什么功能，就说按照公司标品首页做。问具体什么功能，说不出来的。
应对策略：专业是我的个人素养，听不懂可以自己百度，或者打断我问我。可以直接说首页有多少种功能，让产品经理自行挑选。
建议话术：嗯嗯，那什么地方我说的太专业呢，我也可以仔细解释的。但是开会毕竟是用来聊进度的，可以会后再单独说吧。以及公司标品其实有很多功能的，请具体到某个功能。按照项目需求和工期，我们也不可能把整个标品都嵌入到当前产品里的呢～
二、没礼貌类
“一上来就‘你帮我赶下这个页面，反正也不难吧？’没有请，没有谢，催活全靠喊。”
真·打工皇帝，开发很多时候并不是在伺候客户，而是这帮狐假虎威的产品经理
故事1:
细节死抠到1px上下，只按自己的屏幕上显示为准，不考虑客户屏幕。出了ui图之后，还要按照自己的审美反反复复改。
关键也没有审美，这里想提醒所有非开发人员，如果界面丑，但是跟ui一致，那就100%是产品经理不行。
反直觉，甚至是答辩交互逻辑，但是产品经理自己认为正确的不行。
应对策略：首先，设计问题，开发人员不背锅。但是所有风险都要声明，包括垃圾设计导致的技术债，1px上下的改动。使用表格记录每次更改，都非客户要求。在日报周报和群聊中贴入链接，这样等到时候爆雷回溯的时候，锅不会落到我们开发头上。
建议话术：嗯嗯，好的，马上就改。我这边记录一下，方便测试和其他开发人员同步信息哈。
故事2:
虽然有技术背景的产品经理在业内真的算凤毛麟角，但是真的不懂技术的产品经理，只是不想学罢了。一旦懂了确实有技术边界，就没有办法接受自己真的没用，真的不能从设计角度或者客户沟通去化解问题的事实。
遇到过的离谱问题：1.前端为什么不能画出跟后端一样的图？ 2.为什么xx框架做不出yy框架的功能？
应对策略：让产品经理自己百度，或者问大模型。可以怀疑我们开发骗人，但百度和大模型没有理由骗人吧？带prompt词一起发过去，总没有什么疑问了吧？
建议话术：那这样，我怕我回答的不够完善，这里附上大模型的解释。如果还有疑问，可以自行再深入探索一下哈。
故事3:
第二天上午就要演示了，上午出了修改方案（没有原型），下午又出一个新方案（仍然没有原型）。
关键刚改完就来下一版本了。或者下午就要演示了，上午还在让改新版本。
我们开发也不是神仙，挥一挥手，代码就写完了的。
应对策略：声明边界，有什么要改的一次说完，预估好工期，不想演示翻车，大家一起挨骂的话，就别作。
建议话术：嗯嗯，那这边建议如果还有什么修改建议的话，一次性提出哈。我们这边修改的话，也是需要时间开发和自测的，这样也是为了给客户演示的时候，尽量不出错。谢谢配合。
（未完待续，敬请期待）
