▍这个需求很简单，具体实现我不管，明天上线
觉得自己霸气侧漏比美国队长还酷？童鞋你这样会横尸街头的。对技术要有基本的尊重，甚至敬畏之心。技术从业者相当于旧时代的匠人，每一行代码每一个功能逻辑相当于产品的生命，抚养一个孩子的成长自然是件极其辛苦的事，所以，千万不要说这个很简单那个很容易，难的是背后的逻辑，是从一纸黑字变成交互功能。
▍你连这个都不会吗
“这么简单的小动效你都做不到？”怎么会有这么不会说话的产品经理，呵呵，你下次还想提需求？
▍提需求时瞎BB，毫无专业度
天马行空随意随意提需求，提需求的依据是：“凭感觉，我觉得，我认为…”、“用户在这种情况下…会这样”口中有用户，心中无用户，研发反问后立马断片儿，这些表现在产品工作上可说是毫无专业度可言。
那么专业度体现在哪里呢？
扎实的基础功底。如：能一句话说明问题，简洁清晰的需求文档，一目了然的原型。
理性的分析。如：完整的调研结果，充分的数据支撑，详细的案例支持。
严谨的工作流程。如：相关变动文档是否及时更新，有新的变动是否及时周知相关人员等。
避免以下情况：
需求无任何支撑。“凭感觉，我觉得，我认为…用户会”，研发会让你滚蛋；
提供不确定的方案。提供了A方案/B方案，两种都可以，到底要做哪个？
产品上线无任何反馈。产品上线后相关数据变化、用户反馈等没有及时告知研发，研发会对自己做的事情毫无成就感。
▍连自己都表述不清楚的逻辑就和研发对需求
没有流程图，口述也表述不清，程序员一反问：“在这个地方你有没有想过…”、“这里怎么会有三个结果呢”、“这里怎么没有输出呢？”….逻辑完全经不起考验，立马跪了。
产品经理在和程序员沟通需求时，能清晰表达需求的业务逻辑，并且必须是具体和明确的，不能天马星空。
逻辑要做到：
简洁。无论是用户操作逻辑，还是实现逻辑都要足够简洁，大部分产品经理做不到这点，见过太多产品经理把一个产品的逻辑搞得臃肿和混乱；
正确。逻辑必须是正确的，如：某产品的逻辑竟然没有返回上一页的逻辑，点击返回就退出，这种诡异的逻辑，产品经理也可以去死了；
清晰。逻辑足够清晰，怎么做到清晰呢？建议产品经理在梳理逻辑时，先用笔和纸画3遍，3遍不行画10遍，直到逻辑足够清晰，不至于有出现过于混乱的逻辑。
完整。逻辑完整，即是你的逻辑必须是完整不缺的，是否考虑到异常逻辑？是否形成闭环？是否走进了死胡同？
▍不行，这需求还是做回前一个版本吧
临时变更需求意味着程序员要推倒重来，意味已经辛辛苦写的代码被delete掉，删除只需要1秒钟，但敲出来需要半天甚至几天。这和产品开发完成即将上线，boss说这个功能不上，立马回滚到原来版本一样，所有心血都毁于一旦，还反复变化，你会被砍的。研发撸出的代码，就像他们播下的种子一样，会在他们心里生根发芽。
这里说的是谨慎，但不代表不可以变更。另外一种说法是，一旦需求不变更意味着产品经理停止了思考，这对整个团队来说是毁灭性的。
如果产品经理从来不变更需求，或者总变需求，公司一定出问题了。
一旦需求出现变更也要有严格的流程：
▍连基本技术原理不懂就和研发讨论技术实现方案
请问这种图里有几个名词你是懂的？有几个基础原理是了解的？没有吗？赶紧补课，别瞎逼逼技术实现方案了，还提什么需求。
举个例子：前端与后端是如何配合的？在浏览器输入一个网址后，浏览器和服务器之间发生了什么样的数据交互？浏览器中执行交互中用到哪些前端技术？HTML ？ CSS ？ JavaScript ？后端的服务器端又执行了什么？如下图是前端和后端的配合原理你看懂了吗？
▍你这里技术实现方案有问题，我看微信不是这样的
尼玛，技术怎么实现你还管，你还不上天呢？避免和研发讨论技术实现方案，避免自作主张定技术实现方案，哪怕你是技术出身的产品经理，技术是研发的核心能力，哪怕你再懂，也不要在他前面卖弄，专业的事情交给专业的人做。这和研发改你的需求文档是一个原理的，相当于改了你的需求。
▍对不起，这黑锅我不背
产品经理不懂技术、不懂运营、不懂设计…连黑锅都不背，你还能做啥？产品经理作为产品团队的整个领头羊，除了做整个团队的后盾，还得做顶梁柱，一旦天塌下来立马顶住。当产品发生任何问题时，理应第一时间担起责任，再去寻找原因和提供解决方案，和团队站在一起去思考问题的解决方案。
哈哈，以为完美避开八大傻叉行为就能不被程序员打了？错！最好的招数还是不断用知识武装自己！提高抗击打能力！产品、运营、设计、商业模式，一样都不能拉下！来PMCAFF互联网产品经理社区，和150000+产品经理一起碰撞观点，磨炼大脑，成为产品经理中的极客！
来源: PMCAFF产品经理社区
