致血气方刚的产品经理：如何不被程序员嫌弃
如何做一个让程序猿讨厌的产品经理
可能对方会说——很多事情，在开始的时候是谁也不知道的，应该大家在一条船上同舟共济，这就是“接力跑”和“踢足球”在交棒/传球之后的区别。
你可以回：我不管我不管我不管；实施过程中【做了一半改需求】，scrum里的表现就是sprint内的「非受迫需求变更」，太狠了，技术同学肯定很难忍受，特别是产品经理自己没想清楚，而导致的劳动浪费，俗话说“没有变更就没有伤害”，碰到性子烈的就直接要干架了，汪们，这时候要注意保护自己；【开发过程中消失】，你可以多安排点出差、多开开会，注意尽量手机关机，不要响应技术的问题，要不然，责任就回来了。
让他们为了进度照着自己的想法做下去，关键是，验收的时候跳出来说“这不是我要的”，再次，注意人身安全；【过度关注实现细节】，帮技术决定技术方案，也是技术出身的产品经理应该很容易做到这点，变着法儿的越俎代庖，把他们全部从积极主动小伙子，打击成一个纯打工形态的「资源」，哎，又用这个厉害的词了；产品发布之后【发布后没有反馈】，技术人员也需要从市场、用户那里获得反馈，从而知道自己做的事情产生了价值，提升成就感，我们要做的就是，做完发布，马上石沉大海，不告诉大家任何结果，甚至庆功会都忘了他们，紧接着赶紧继续安排他们干活；【无节奏感】，让技术人员忙一阵闲一阵，发布之后再忙着研究接下来做什么，一会儿让技术人员有着干死干活的高强度，我就是要结果，deadline，死命令，之后突然不知道做什么——你们也一起来讨论下业务吧，或者培训培训做做团建什么的；全过程都可以做的【优柔寡断无决断】，能表现出这个品质就最棒了，就是在已经讨论完毕后，大家都等着你拍板的时候“你说吧，往哪儿走我们就跟着办”，这时候你说“啊，那个，各种方案各有利弊啊，我也不知道怎么办啊，你们有什么好想法……”；【报喜不报忧】，藏着掖着一些信息，比如“老板在考虑干掉这个项目”这类信息，表面打死不承认，但让大家通过其他途径知道，很容易就把互信完全打破，这时候他们可讨厌你了；【不要把他们当人】，这点，最狠了，不关注成长，只关注结果，不能再说了，我们只是要做一个程序猿讨厌的产品经理，不是要做一个被砍死的产品经理……还有啥招，欢迎补充。
产品经理吐槽开发的话术
产品经理吐槽开发的话术1.虽然我提供了清晰的需求文档，但是开发人员总是不明白我的意思。
2.我已经反复强调过这个功能的重要性，为什么开发人员还是不重视？3.开发人员总是拖延完成时间，是不是不想尽快交付产品？4.每次跟开发人员沟通都感觉像在说天书，他们的话术太专业了让我晕头转向。
5.开发人员为什么总是忽略用户的真实需求，照搬规范？6.开发人员对于产品的创新想法总是持怀疑态度，太保守了。
7.让开发人员理解一个简单的设计改动都需要费尽口舌，真是累死人。
8.我提供的界面设计稿明明很清楚，为什么开发人员总是无法按照要求实现？9.开发人员总是不愿意尝试新技术，一直停留在过去的开发框架上。
10.产品经理和开发人员的语言总是不通，每次沟通都需要翻译才能明白对方的意思。
11.开发人员总是强调技术难度，而不是思考如何解决用户问题。
12.每次产品迭代都需要进行大量的修改，在开发人员眼里简直就是一场灾难。
13.开发人员不理解产品的商业逻辑，总是只关注代码是否符合标准。
14.开发人员总是偷懒，不愿意进行足够的代码测试，导致线上出现频繁的bug。
15.开发人员一点都不关心用户体验，只关心技术实现的细节。
16.开发人员总是追求技术的纯粹性，而不注重产品的实际效果。
17.每次开发人员都喜欢提出各种冷门技术方案，而不是注重产品的实用性。
18.开发人员总是喜欢抱怨需求变更，却不思考如何更好地适应变化。
19.开发人员总是把问题归咎于产品经理，却不检视自己的开发流程是否有问题。
20.开发人员总是找借口推诿责任，不愿意主动解决问题。
21.开发人员对于产品定位和市场趋势的理解总是片面而模糊。
22.开发人员总是拒绝参与用户交流和产品测试，导致产品质量难以保证。
23.开发人员总是过分追求代码的优雅性，而忽视了产品的实用性。
24.开发人员经常抱怨需求变更频繁，却不愿意去理解背后的用户需求变化。
25.开发人员总是只看到眼前的技术难题，却不思考如何更好地解决用户问题。
产品经理应该如何与程序员打交道
产品经理应该如何与程序员打交道产品经理与程序员之间的矛盾冲突，并不特殊，它是一个系统性风险问题。
那么，产品经理应该如何与程序员打交道？与程序员打交道，是产品经理的日常工作之一。
从网上流传的各种商品轶事与技术起冲突的段子可以看出，产品经理与程序员之间的关系，总的来说，并不十分融洽。
我相信，有相当多的同行朋友，都为之苦恼过，我也不例外。
这几年下来，被程序员怼得多了，渐渐地也就变得波澜不惊了。
虽然技术对产品有诸多不满，产品也对控制技术有各种意见，但是，这里我并不想回来大书特书双方的矛盾。
在讨论“如何与程序员打交道”之前，我想先对这种矛盾定个调。
我认为，产品经理经理与程序员之间的矛盾冲突，并不特殊。
如果关注设计师圈子，你会发现，甲方与设计师相互之间，也有类似的“恩怨情仇”。
其实，在任何协作网络中，处于对接工作的上游和下游之间，普遍存在类似的矛盾关系紧张。
它是一个系统性症结，贴切地将之归因为某些人的某些错误，是一种思想上的懒惰。
从某种程度上讲，我们无需过度关注与程序员的矛盾，等闲视之，做好自己的工作即可。
产品销售经理的工作是围绕着“需求”进行的。
在与技术部门负责人进行对接时，产品经理需要关注的，始终是“需求”。
产品明星很容易在这上面可能犯错。
因为外界夸大歪曲了产品与技术之间的矛盾，导致产品会不自觉地把自己工作的重心，放在“不惹程序员生气”上面。
在与程序员打交道的过程中，为了避免被怼，过度关注脚本语言的情绪，想方设法地“讨好”程序员，与程序员“交朋友”。
而另一方面，却忽视了“需求”，导致融资需求传达得不清不楚。
这其实是不专业的表现，在与技术部门对接时，我认为，产品总经理的核心任务，是“及时准确地阐明需求”。
这里面有3个要点：2.1 核心目的是传达“需求”目标是什么，要实现什么效果，产品经理需要将这些“需求”传达给技术部门。
这里面容易犯错误的错误是，混淆了“需求”与“技术实现方案”。
比如说：我要做一个“统计订单总数”的功能。
产品经理们,坐冷板凳怎么办？
作为中国产品经理最多的社区，不在上面回答过个赞同过百的问题，是很过意不去的。
另外，通过回答别人的问题的同事也可以审视自己的问题，通过看别人的答案也可以看到自己的视野的狭隘
四、多研究公司的其他产品
说不定哪天就要接手公司的其他产品，在坐冷板凳的时候，可以静下心来研究下产品，资源都是现有的，可以将自己的想法和其他同事进行交流，这其中也是很好的积累。
五、不要忘记自己的产品
产品的后期，或许公司不会投入再多的资源，但是如果产品还在，用户还在，就还是有可以进步的空间，有资源就有用资源的做法，没有资源就有没有资源的的做法，不是么？甚至在现有产品的基础上迭代出新的产品让老板看到希望也是有可能的。
六、尝试做一些内部分享
一个team中，产品可能是最全面的那个人，也应该是最乐与分享的那个人。
将自己的经验能力见解梳理形成PPT，然后分享出来，定期做一个产品的分享会，这个将会让你又可能向更高的层面进行进步
七、享受生活
工作不是全部，不忙的时候多关心关心父母，老婆。
多多锻炼身体，关心自己，身体是革命的本钱。
人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。
程序员最讨厌的5种产品经理，其中一种叫程序员哭笑不得！
程序员最讨厌的5种产品经理，其中一种叫程序员哭笑不得！程序员+产品经理=世界上最遥远的距离。
对程序员来说，技术是手段，需求是目标。
对产品经理来说，需求是手段，用户是目标。
对老板来说，用户是手段，盈利是目标。
看问题的角度不同，定位不同，也就导致了各种矛盾。
特别是产品经理和程序员，他们经常会有摩擦。
今天w3cschool 就来盘点一下，程序员最讨厌的5种产品经理。
1、频繁改需求如果项目经理想要整死程序员，频繁改需求是最快的办法。
特别是做了一半硬是改掉需求，scrum里的表现就是sprint内的非受迫需求变更，太狠了，技术同学表示不能忍。
2、拿老板和运营做挡箭牌不说清需求价值，当技术童鞋问“为什么要做”的时候，支支吾吾，或者说“老板要的、运营要的”。
最绝的就是说，这个功能老板说必须要做，那个功能老板说明天就得上……3、扮用户程序员会产品经理沟通的时候，比较经常就是听到，“关键字是用户不会这么觉得，如果我是用户。
”这种产品经理通常关注点会有问题，比如更多的时候讨论的是这个按钮是这么颜色，应该放在哪里，文案应该怎么写等，如果把这些问题当做核心，那难免会让人啼笑皆非。
4、口头禅——不就是xxx有些产品经理口头禅：不就是xxx，这也引来一些程序员的反感。
比如“这个问题不就是在数据库里加个字段就可以解决了吗?你要是没时间，我给你写个SQL 语句，你执行一下吧。
”结果程序员一脸懵逼。
其实，如果是在你的非专业领域里，最好少用这种「不就是XXX」这样的句型为妙。
5、不懂装懂特别是对技术一窍不通的产品经理，会不停让程序员加班赶工。
“开发大哥，我代码写的不多，你可别骗我，这么简单的需求，明明一下午可以搞定，你跟我说一个星期?”此时，想必程序员口袋里50米大刀已经饥渴难耐......这种产品经理叫程序员哭笑不得。
最后，哪种产品经理是你所不能忍的呢?。
产品经理产品设计-写给产品经理十条建议帮你与程序员建立天长地久的友情
写给产品经理十条建议帮你与程序员建立天长地久的友情产品经理与程序员，一个是消费需求提出方，一个是需求受理方，由于工作内容的差异性以及有时的沟通当，极易出现矛盾，这些问题该如何避免呢？产品经理从出生那一刻开始，似乎就决定了与程序员之间的敌对关系，一个是需求提出方，一个是需求受理沃洛韦齐区，伴随着相爱相杀，产品经理与程序员之间的矛盾由来已久。
作为一个产品经理，每天打交道最多的就是程序员，不管是IOS程序员还是安卓程序员，不管是java程序员还是PHP程序员，在产品经理每天的工作过程中都会忙于提需求、解答问题、改需求、再解答问题。
坦诚讲，刚开始入门产品经理的时候，对于这些程序员心理还是有点发怵的，因为他们一个个都非常不好打交道。
这些成天对计算机程序着电脑看着代码的人，你都不知道他们到底在想些什么，甚至你都不知道哪相信一句话会得罪了他们。
但是其实产品经理大可不必同学自己放在程序员将的对立面，因为究其本质还是人与人的相识，哪来调和那么多绝不能调和的矛盾。
那么，产品经理应该怎样和程序员友好地合作呢？无论是什么样的程序员，他都希望自己对接的产品经理能够把需求提清楚，我每到一个公司的时候，都会先跟程序员同事确认他们什么样风格的需求，的答复基本都是只需要把需求写明白提清楚就可以了。
所以，产品经理一定要学会把需求协会提清楚。
你可以尝试所绘高保真原型，把一些比较复杂的交互使用动态效果表现出来，这样做的目的不是为了炫技，而是为了减少不必要的沟通，提高研发效率。
要知道，很多时候，产品业务经理的需求多写销售经理一句话，就有可能让一回程序员少返工一次。
遇到不了解的逻辑怎么办？大胆去问，不要不怕程序员认为你不懂技术，也不用回答担心问他们会丢面子，术业有专攻，你要做的是给出可以执行控管的需求，如期完成研发管理工作上线发版上线，面子什么的不非常重要，都是自家哥们，何必纠缠繁文缛节。
大部分的程序员唯技术论，他们认可一个人的重要指标是这个人的技术能力如何，IT界有一句名言是“Talkischeap，showmethecode”，大致的意思就是“会说称不上本事，把你的代码拿给我看看”。
产品经理如何跟程序员友好相处？教你3个技巧!
我们经常在网上看到各种段子，程序员与产品经理互相嫌弃，其实这种情况比较普遍，那么产品经理应该如何跟程序员友好相处呢？教你3个技巧！1.尝试寻找解决方案真的有产品经理对程序员提出了要求APP的主题颜色可以根据外壳自动调整的要求？这个我不清楚。
但我们常说的技术可行性确实是产品需求的硬前提条件之一。
在计划之前，程序员需求的可行性。
程序员不一定深入研究、有空或沟通良好。
直接案例的实现效果，实际情况，技术框架或系统未必适用；凭直觉和经验，产品经理更倾向于独立思考，直接。
我曾经在一个项目重构中提出过优化ES搜索规则，但是搜索结果的权重并不理想，程序员让我接受现实：涉及全文检索，列表显示的结果不能完全精确，一时僵局，后来在CSDN中找到了类似的案例，发送了解决方案的，程序员的解决思路就通了。
因此，在梳理需求时，我们可以提炼可预测的技术难点，并学会寻找可解决的方案：如果是小程序、、企业生态系统的产品，我们可以多逛逛开发社区，了解开发、运营文新的内容，了解开放规则。
假如是自主开发的系统，还可以逛CSDN，简书，或者直接带问题去百度。
记住要有场景才能找到解决办法，而不是沉浸式的理解学习，毕竟我们是为了解决问题，而不是做一个懂技术的产品经理。
2.试着说明业务背景你为什么这么设计？你的需求是为了什么？看不懂你写的A和B的关系？程序员这三个问题不是很熟悉？经常问是不是让人语塞，或者反复解释逻辑，还是有代沟，很正常。
在回忆我们的需求链之前，经常有许多复杂的业务问题和业务流程。
许多需求需要产品经理进行深入研究，整理出一套标准化的系统架构。
如果不是像电子商务这样的ToC产品，我们可以在日常生活中理解到位的操作流程，程序员更难通过一次评估、一份文件或零碎沟通来理解。
所以除了原型，需求文档，我们还会配套输出业务流程图，产品流程图，帮助他们了解业务背景，但是还不够。
通过以下方式，我们可以尝试向程序员说明业务背景：在谈论产品计划之前，带上业务同事代表或我们额外整理一些业务示例，如数据图表或业务文档，帮助程序员了解业务日常工作中的痛点，以及一些专业演讲实际上与哪些信息对标。
程序员喜爱的产品经理养成计划
如果不是妹子，请来一只对开发有基本了解的！如果有开发经验的产品经理实在太贵！老板你一定要找一只会吹牛的！可以愉快的搅基！这不是我说的，这是某资深产品经理说的：交给他基本的开发原理这有两个好处：1. 你们会更好沟通。
2. 会让他感受到他智商的边界，从此每天看你都星星眼。
像这样：让他了解产品和开发的矛盾本质是什么知乎上有大牛说“认知不同，定位不同也就有了矛盾。
”对产品来说：用户是目的，需求是手段。
对开发来说：需求是目的，技术是手段。
然而这都没有什么卵用，最重要的还是给老板赚钱。
认识到这一点，你们可以愉快的去喝酒了。
恩，产品请客。
培养他用图说话的能力让他用三张图把话说清楚。
第一张，逻辑图：前端所有页面的相互关系。
第二张，交互图：第一张图里每个提到的页面里放那些信息，按钮排布。
第三张，描述表：第二张图里每个元素的解释。
不要让他习惯于给你长长的文档或是QQ上留言说“hi，我要加个功能巴拉巴拉巴拉。
”要像这样：和他经常沟通也要培养他经常和你聊天的意识。
想要一个功能的时候，先和你商量一下这个有没有实现的可能。
设置 deadline 的时候让你估计一下。
如果让他习惯了不考虑你的实现能力就提需求，他以为你是蓝胖子吗？如果……当然如果产品团队像我司一样。
前面几条就都无所谓了。
你看开发都自觉跪着吃饭的。
以及最重要的：让他领悟到卖萌的力量。
领悟容易学习难。
来源：扣钉Coding人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。
产品经理产品设计-产品经理怎么跟程序员相处
产品经理怎么跟程序员相处
坊间流传编程很多产品线经理和程序员之间的段子，大部分的主题都是产品销售经理被黑(谁让程序员数量更多呢)。
而前段时间的这则新闻把这种关系推向了最高潮：
当然，这件事情的流传跟事情本身是有出入的，但明显反映出“程序员讨厌产品经理”的社会认知。
作为产品经理，如果得不到程序员的开发者协作配合，工作将难以顺利进行。
想要处好这个矛盾，必选先弄清为什么程序员讨厌产品经理。
你挤占了我的时间
你伤害了我的自尊
所以实际上工程师其实是崇尚高效，权威和专业领域的人群。
相处之道就要从他们的和讨厌的事情当中提炼。
总结完毕！还是以自己的经历作为基础的交换。
坚信能跟更多同学交流~现在流行说一个好的经理应该具有“无授权领导力”。
这就是跟工程师友好共处的下要一个进阶。
产品经理产品设计-产品经理跟程序员友好相处的3个技巧
产品经理跟程序员友好相处的3个技巧产品经理很重要的一项日常工作就是与程序员打交道，我们不难从网上流传的各种段子中看出，产品经理与程序员的关系并不是十分融洽。
但是只有在融洽的氛围下开展工作，才能有效推动工作进度，本文我分享了产品经理跟程序员友好相处的3个技巧，希望对各位产品经理和程序员总监有所帮助。
在几年前的这场面试，对方问我：“有没有和程序员吵过架？”当时的我颇稚嫩，岂图想在面试中体现自己的完美，回答道：“没有”，对方皱眉头嘀咕：“真的没有吗？”后来考试结果不了了之。
现在回想起来，再说产品跟程序员共事长时间共事，并不是没有过争执，只不过不管大吵小吵，最终我们依旧回归到工作上，一起打磨产品。
本文不教请客吃饭人情世故，而是从产品经理专业领域角度，提出几个可以跟程序员友好相处的技巧；当然，本文提到的几个技巧已经过本人实践，有过泪水和笑声，如有雷同纯属巧合。
了解背景：我们的处事立场有何不同首先，我们先了解一下程序员与产品经理做事出发的立场有什么不同：日常组织工作流流程简述为：整体上，程序员的工作事项都围绕着需求，需求正来自产品经理，因此程序员但凡对需求有任何想法或疑问，即使得和产品经理商量，某种程度从属关系在这种上很容易陷入主观和客观相互关系的抽离。
再结合目前，存在产品经理专业能力参差不齐的现象，如果遇到需求碰到来源复杂身不由己，说不清道不明，相处关系自然会贴上所“对事不对人”的标签。
程序员日常看原型、评审需求、分析文档和梳理逻辑框架，对需求抱着一个中心思想那就是：这个融资需求能不能做，能做就能做，不能做就不能做，不存在凌磨两可，凌磨两可也只是时间问题。
不难发现，我们常爱调侃程序员是直男，实际上与他们常年工作的思维模式有着密切关系，写程序是直线思维，一般来说比较严谨的，产品经理口中的使用者体验、产品质量、交互效果，在他们眼里都是：我要怎么实现这个资金需求。
这段背景秉承开尝试让产品经理个头去理解程序员的思考逻辑，再以此为基本概念之中贯彻到我们工作常见的几个场景里，对应训练方法可以是哪些。
产品经理如何与RD(研发)有效沟通-产品经理入门指南第二课
产品经理如何与RD（研发）有效沟通-产品经理入门指南第二课·导读·上节课，我们感性认知了产品经理真实的24小时。
然后发现，在每天杂乱的工作中，产品经理的沟通能力尤为重要。
这也是老生常谈的话题，特别是产品经理和RD（研发/程序员）之间的沟通。
很多时候，我们是“沟”了但没有“通”。
今天，我就来为你解读一篇非常有趣的文章《如何与RD沟通，写给那些血气方刚的产品经理》，带你更真实地了解：1、产品经理和程序员有哪些沟通问题？2、产品经理为什么会被程序员嫌弃？3、产品经理应该如何与程序员沟通？·正文·《如何与RD沟通，写给那些血气方刚的产品经理》（作者：X小姐）是一篇幽默逗趣又不失污点的文章。
这篇文章真实记录了产品经理和程序员之间的爱恨情仇。
作为产品新人，我们肯定/绝对/100%会遇到类似的沟通问题；只有找到了背后原因，才能更好推动产品工作。
一、产品经理和程序员有哪些沟通问题？接下来，我将引用X小姐文章里的7处内容，并进行解读，带你了解产品经理和程序员之间的沟通问题。
引用1:最近有位刚做PM（产品经理）的小伙跑来跟我控诉，说公司技术部的RD们（程序员）个个不给力。
需求过了千百遍还是理解错，或者就是简单回一句“做不了”，表情如死灰。
解读——“需求虐我千百遍啊，千百遍，千百遍了还是错。
”这是产品新人都会遇到的问题（我过去做产品，有时候也恨不得把技术给**）。
引用2:这位PM血气方刚，张牙舞爪，脑子里总有一千万个新产品需求的想法扑腾着。
解读——“脑子里万马奔腾”，这是产品新人最大的一个问题：想法很多，能落地的很少。
慢慢我们就会更现实；一开始大家都很理想化，喜欢不停抱怨。
引用3:面对他，我的心突然惆怅起来。
几年前的自己也差不多是这个模样，懵懂如白纸……身为一位女性PM，我至今为止并肩合作过的RD团队超过8组共200多人（动荡曲折的职业生涯啊）……所谓人艰不拆，希望大家看完后能更理解彼此“都不容易”的立场。
产品经理沟通技巧：产品经理如何和程序员打交道
产品经理沟通技巧：产品经理如何和程序员打交道产品经理沟通技巧：产品经理如何和程序员打交道在产品经理和程序员因为思考方式、关注范围、职能职责的差异，导致了沟通上的困难这是在很多产品研发体系下都会出现的问题。
如何更好的与程序员建立起一座畅通的桥梁也是每位产品经理需要思考的问题。
一般情况下，产品经理和程序员沟通困难大概的原因：1、得到信息不对称产品经理得到的信息一般集中在：商业需求、商业策略、战略方向、产品规划、运营数据、整体营收、目标任务等方面。
产品经理往往在根据公司现阶段的情况，以及市场的竞争情况，做一些产品策略或者一些产品的方案的策划、发起、实施。
所以这个过程中，产品经理扮演的角色是翻译：“市场需求、商业需求”，成为：“产品需求”，所有的信息全部围绕需求本身。
为什么要做需求?怎么做需求?先做什么需求、后做什么?基于怎么样一个思路去推送产品进行实施、从一个利益平衡获得空间增长指标后达到另外一个利益平衡。
程序员不一样，很多时候程序员得到的信息是：有一个需求，可能是小需求、产品需求、或大到项目需求，然后得到一系列需求列表，然后产品经理会让程序员看：“需求”哪些通过code改改就可以实现，哪些是需要开发可以实现，哪些是技术或构架或因为成本的原因不能实现。
所以在这个过程中，程序员扮演的角色是翻译：“产品需求”，成为：“技术语言”的评估，所有的信息全部围绕开发需求本身。
如何开发这些需求?是沟通数据库增加字段?调用接口?开发新的接口?需要开发组件?重新构架引擎?来实现满足或支撑这些需求?那这个时候问题来了，很多情况下我们只是把程序员当做一个写代码，通过编程语言来操作计算机完成需求的工具了。
2、沟通语言不对称说到两者沟通的语言，这肯定是困扰产品经理本身的。
产品经理的语言是：“描述“、”形容“，我也见过很多产品经理，很多人的需求文档就是漫天飞舞的文字，一整段的描述+描述，不要说程序员看不清，可能过段时间连自己都看不清楚。
产品经理被技术总监反咬一口？我教你个办法
1. 记录的事情不分大小沟通的形式很多样，开会算是沟通，吃午饭时随口跟工程师提了一句也是沟通。
但不管怎样的沟通，一定一定要记录。
原来的故事可能是：在电梯里碰到工程师小明，说老板提到有个文案要改掉，小明说好嘞简单得很，然后你就没再放心上。
过了几个月，老板又跟你发火，说看到文案没改，你找到小明，小明说：啊？你说过这事儿？老板说你办事不力扣了你半个月奖金。
改正后的故事是：在电梯里碰到工程师小明，说老板提到有个文案要改掉，小明说好嘞简单得很，然后你就没再放心上。
你下午回到工位，发了一封邮件给小明，抄送他的上司，以及老板。
邮件就几句话，说明了改文案的情况。
过了几个月，老板又跟你发火，说看到文案没改，你找到小明，小明说：啊？你说过这事儿？你翻出邮件来，白屏黑字，小明没得狡辩。
老板扣了他半个月奖金。
2. 记录的内容要翔实可信如果本来讨论清楚的事情，因为记录时随手敷衍，同样是没有意义的。
比如记成『下午会议大家达成一致，按照老张的说法做』，等半个月后，大家都忘了老张的意见时，那老张就真的是说什么就是什么了，指当时的鹿为现在的马也没关系。
一件事情，不要因为追求速度就说不清楚，也没必要写成格式化文档，只需要确定，当你不了解当时的任何信息时，还能通过你的记录得到有价值的信息，这样就行了。
3. 根据记录的种类做记录的格式，防止缺漏有时候，想到的未必就是够全面的，所以我习惯把记录的信息进行分类，格式化记录。
记录有这么几种：工作任务事项，包括翔实的工作内容、负责人和时间节点，比如刚才说的修改，『小明会在下个版本（3.6.2）修改页面的 XXX 文案，改成 XXX 文案』；事情的记录，包括发生的具体场景、情况和结论，比如『老张说目前数据结构的状态不适合完成方案 XXXX，因为会导致 XXX 的错误，所以暂时停止』；意见，包括谁表达了什么观点，认可还是否决，比如『老张说目前数据结构的状态不适合完成方案 XXXX，因为人手不足，所以暂时停止，但老板表示去你妈的赶快给我实现，最后结论是老张配合 HR 尽快招人』；备忘录，包括各种头脑风暴的想法，使用各种 APP 的体验等等。
产品经理从被客户狂怼的方案中,我学会了这4点
编辑导语：产品经理一定会经历输出产品方案的过程，产品方案很复杂，并一个人或者几天就可以完成的，需要团队的协助和磨合。
本文作者通过之前被团队和客户否定的产品方案的经验，为大家总结了四点反思教训，希望能给新人产品经理一些启示。
团队确定了一个新方向，目标是解决头部2B客户纵深、复杂业务领域的问题。
该领域在学术和实践中，多停留在理论上，没有成功的产品案例，所以我们是前赴后继的开创者。
做为新到岗的产品经理，我内心很骄傲，认为自己有能力做别人做不到产品，同时也需要成果在团队立足，所以踌躇满志，准备大展拳脚。
初步了解业务脉络后，我加班加点在1周内完成了包含15个页面的产品方案，团队其他同学看到方案后表情有些惊讶。
我私下请教师兄，为什么惊讶？师兄说：你太牛了，1周时间，画了15个页面。
这是全新的业务领域，现在业务逻辑都说不清楚，你怎么画出这15个页面的？每个页面都很复杂，团队里没人能看懂，产品给人强烈的压迫感，都想逃离，你又是怎么做到的？师兄的反馈，我不服气。
我这么辛苦出了方案，大家就这态度？但大家似乎挺照顾我情绪，跟我说，要不你找几个用户看看？于是，我拿着方案和客户当面沟通。
客户皱着眉头，快速扫了几眼。
客户说：你这方案又大又全，像满汉全席，可我不需要满汉全席，我只要2-3个菜。
你们整这个，第一我买不起，第二我消化不良，第三浪费。
你们的资源也是宝贵的，有这资源，还不如帮我们解决其他问题。
我只关心需要我去解决的问题，难道你要我从满汉全席里，一个个自己挑出来我要的吗？客户说到这里，我感觉师兄说的是对的，但心里还憋着那股气。
客户又接着说：功能多了，反而让我无从下手。
那些我不需要关心的，就不要做了，或者弱化。
我只要看到，我们公司哪里有问题，怎么去解决问题就好了。
现在这么大的方案，我连看的时间都没有。
我说：收到，后面我们做调整。
抛开功能，您觉得我们做的事情有价值吗？客户说：如果能把重点问题和方案给出来，当然有价值，因为能解决我们的实际业务问题，但产品一定要简单。
产品经理产品扫地僧,对中级们的6条寄语
编辑导读：不同于初入职场的小萌新，中级产品经理在职场上摸爬滚打了数年，他们面对的事情更加复杂也更加棘手。
本文作者在一次聚会中，对中级产品经理遇到的问题进行了梳理，分析他们现在面临的困境，并总结了大佬对中级产品经理们的一些建议，与大家分享。
继上篇《》中提到：一群中级产品经理，头发越来越稀疏，在各自的困顿中煎熬。
于是大家请膜拜的产品大佬来给大家讲讲，高山流水的产品之音。
大家原以为大佬至少会礼节性听大家的吐槽、哭诉，好歹释放下压力。
结果扫地僧大佬一来，根本没给大家说话的机会，直接开讲。
1、大家的苦我都知道，我也是这么过来的。
数据产品、平台产品、业务产品、商业产品我都干过，我们是一起打过仗的兄弟，所以就不说这些了，说了也没意义。
有时候，团队开会，让大家吐槽下，只是因为知道大家心里苦，需要有个发泄的场，让大家知道，老板们知道大家心里的苦。
2、产品经理是一帮偏理性的人，吐槽不解决任何问题。
我想跟大家说的是，大家不要只盯着眼前的蝇营狗苟，觉得痛不欲生。
我们要跳出来，产品经理在职场生态链中，是处在顶端的，不是处在底端的。
所谓处在生态链顶端，可以选择做什么，不做什么。
3、选择做什么，不做什么，就是我们的商业判断。
我们到底解决谁的什么问题，这个问题的解决有什么客户价值、公司价值、社会价值。
如何解决这个问题，团队怎么搭，节奏怎么走，先做什么，再做什么，谁是朋友，谁是敌人，谁是合作伙伴，产品经理心理一定要有这张图。
大家手上的事情很多，被业务死命催，被老板死命催，技术也难搞。
产品经理就是事事都要操心，还没有权力，所以大家才会掉发、秃顶、压力肥、焦虑。
但是我们可以选择，做什么，不做什么，而后跟团队沟通清楚，相信在座大部分人还是有选择权的。
产品经理不像技术，技术被派了活，想不想都得干，但你们可以选，这就是生态链的顶端才有的权力。
4、一旦做了选择，就要对结果负责，成、败都要担着，这是产品经理的判断力和担当。
不是今天选这个，明天选那个，失败了就换一个，成功了就是运气爆棚。
产品经理如何避免被程序员打？
知乎上有个问题，产品经理如何避免被程序员打，我觉得很有意思，就来探讨一下这个话题。
首先，这个问题问的就有问题，问题的表述就把产品经理和程序员放在对立面了，当你把一个人视为敌人，放在对立面的时候，心理必然会对他的所作所为有抵触情绪，这样本来没有矛盾也会产生矛盾，我更愿意把产品经理和程序员视为同一个团队不同的两个职位，为了同一个目标而通力协作的好伙伴。
只有当你有这样的一个认知，再去学习技巧才能事半功倍，否则认知错了，学了再多的技巧也无用。
首先，程序员并不讨厌产品经理，而是讨厌那些乱提需求，专业能力不强，让他们做很多无用功的产品经理。
我曾经在一个创业团队干过，当时的产品总监是从ui设计师转过来的，思考方式都是设计师思维，导致文档逻辑漏洞百出，后来我加入团队没多久，帮助他梳理业务流程、撰写产品功能需求文档，每一份输出物，我都尽量考虑周全，因为我知道考虑的不周全，肯定会被喷。
那个时候，我对产品经理抱有极大的热情，下班了，当公司的人都走了，自己还在加班，反复的看自己的需求有没有写全，因为自己当时也是新人，也怕评审的时候被DISS，我甚至写好文档以后，找比较好的技术人员帮我把把关，当他说没啥问题的时候，我才放下心。
当我能把产品收集到的需求梳理的井井有条的时候，那个产品总监也就走人了。
后来我和技术团队相处也比较融洽，一起吃饭、一起打球、一起开黑，他们似乎没有为难过我，我们相处的也很愉快。
所有，当有了这个正确的认知以后，我们再来谈技巧：1、提升自己的专业能力我们想不被技术人员DISS，首先就要提升自己的专业度。
比如能否画出专业的流程图？能否写出逻辑不遗漏的PRD文档？能否用xmind的梳理清楚产品的结构？能否划分清楚需求的优先级？能否协调好团队需要的资源？当你很专业的时候，别人就找不到喷你的点了。
2、懂点技术懂技术有两个好处，一个是懂得技术语言，这样和技术沟通的时候，更容易理解彼此，但技术也不用太精通，有技术思维（所谓的技术思维，就是你知道产品功能实现的大概逻辑）就行了，不需要你可以自己写代码。
产品经理被老板打昏住院了附《PM保命十条》
编辑导语：相信大家最近都有看到一张流传的截图，即产品经理和老板因为“四月再造一个抖音”一事起了肢体冲突。
究其事件背后，反映的其实是需求处理的问题。
那么，作为产品经理，当遇到上级提出的需求时，可以从哪些方面解决问题，合情合理、专业地处理上级的业务需求呢？今天镜同学正在各大产品群学习产品知识（划水），突然看到群消息被一个图片刷屏，仔细一看是产品经理和老板争吵，结果被老板打昏住院了。
我嘞个天，这是增加新技能了啊，一直以来，产品经理日常工作都聚焦在和开发撕逼，能和老板干起来，这也算是开山鼻祖了。
起因是什么呢？说是老板让四个月再造一个抖音，产品经理直接说不可能，后来沟通分析升级，导致了上述后果。
这应该不是一个段子，按理说，现实中发生这种情况应该概率极低，毕竟，都说产品经理和老板是穿一条裤子的。
镜同学假装认真思考了下：问题关键好像在于怎么定义“再造”？很多产品同学都觉得如果是类似于抖音的短视频平台，那这样对资源的要求并不会特别离谱，4个月的周期也并非不可实现。
其实，仔细一思考，还是流程问题。
产品经理需求处理不规范，工作汇报不规范，这样做出现这样情况只是时间问题。
当然，这也有个前提，如果老板不是上来就人身攻击或者过于无耻，假如只是由于需求沟通分歧，沟通逐渐火热，最后导致冲突升级的话。
如果是这样的背景下，直接发生争执，导致上述冲突，那镜同学觉得，产品经理那确实是草率了，因为完全没有必要啊。
其实，首先要把老板当做需求来源，认真、细心、冷静，全面地了解下老板的需求，只靠站立沟通短时间内，很难梳理清楚所有的需求。
而且，老板很多时候都是高层级的，有时候只是一句话，有时候只是随口一说，没有深度思考，那产品经理应该怎么做呢？咱觉得，我们是做工作的、做需求的，就聚焦在需求本身就好，通过我们的专业能力，输出一个预判结果，这就需要在冷静分析后，有系统化的支撑。
有时候，认真对待、专业应对，有很强的说服力。
比如说，老板提出这个需求以后，就回答说：好的，我先按照您的需求做下需求方案，接着再定性研究，围绕老板的需求做可行性分析，需求描述清楚，需要什么资源考虑到位，有哪些困难也想清楚，预期收益也思考下，围绕着需求所有的调研都书面化，清清楚楚，然后打印出来，或者PDF发送老板，再组织评审或当面汇报。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
脑子了吧？！这么做有数据依据吗？！做过市场调研吗？！老用户会因此流失吗？！能保证上线后不再改了吗！？@$%^^%%$$@% #$%^^% ” 真的是没法儿做朋友啊！
曾经有一个自以为很牛掰但其实能力已经跟不上时代的RD总监，在kickoff会议上把我所有的需求都推翻了，让我差点在十几个老男人面前哭鼻子。
话说人在经历苦难后，要么变乖，要么变坏。
这种迫切想要搞定RD，让他们听命于我的心情，实在太强烈，于是我学会了通过非正规途径收买RD 的心－－比如请他们吃KFC啦，陪他们聊黄色笑话啦，穿低胸装秀黑丝大腿啦。
在这些努力之下，我和RD的关系改善很多，他们开始敞开心扉，解释他们对于新需求的负面情绪到底从何而来：有时是因为实在忙不过来，有时是因为实在无法理解这个功能有什么意义（至少他们自己肯定不会用），有时是因为PM不但不调解现有项目的优先级，反而还每天做梦，想些有的没的，让他们极为
恼火。
而负面情绪最大的根源，则是他们对这个项目失去了信心，觉得反复改版却一直没有大的
突破，老板和PM都应该去吃shi。
正当我沾沾自喜，认为自己靠美胸美腿赢得了这场战役时，一个Ruby程序员幽幽的跟我说 “我好喜欢你的门牙。
” （鸦。
你们果然是无法沟通的生物。
）
RD眼里的PM也分成两种：有脑子的，和没脑子的。
后者占90％。
（呵呵呵）
没脑子的PM，RD们是打心底森森嫌弃你的。
嫌弃你的理由可能有以下三点，欢迎对号入座，我们一起舔伤口：
嫌弃理由1：你没有自己的想法。
听清楚哦，我说的是RD们“认为”你没有自己的想法。
这个话题实在很辛酸，哪个PM会没有自己的想法呢，就是想法多的溢出了脑门儿才跑来当PM的啊魂淡！！但是PM的生存环境无比艰辛，很多决定都身不由己（尤其当你有一个心思活络的老板时）。
于是，有些PM选择推卸责任，两手一摊 “老板说必须做” ，急着撇清关系强调只有老板是傻逼哦我不是哦。
此言一出，你在RD心里的形象全毁。
PM必须是产品的灵魂，无论老板决定闹哪样，你都要把这个决定翻译成大家能接受的理由，建立你自己的口碑和信任。
在跟RD沟通的时候，不要说“我和老板争论了很久他就是不听我的”，这样更凸显你的无能；也不要撒谎说“其实我觉得老板的想法挺好的”然后硬掰些白痴的理由，这样显得你特别虚伪。
比较好的应对方式是开诚布公，说你自己真实的想法，如果你觉得老板真是玩过火，也要解释下老板为何会有这样的执念（是被投资人逼的，还是被老婆逼的，还是看到竞争对手做的什么事情眼红了想抄袭），然后安慰体恤下RD们的辛苦，并表现出和他们同甘共苦的决心。
嫌弃理由2：你风花雪月没有逻辑。
都说能做出牛逼产品的PM要感性和理性兼备，因为牛逼的产品能直戳人性，满足用户多层次的生理和情感需求，这就要求PM对生活细节敏感，情感丰富。
可是情感丰富的PM通常思维比较跳跃（艺术家嘛都这样），情绪波动幅度巨大，郁闷时会在阳台发呆抽一下午的烟，兴奋时连坐在马桶上都拿着手机写文档，这样的节奏RD们真心吃不消。
他们觉得你丫的赶紧吃点儿脑残片吧！（插播吐槽：我的上一篇文章发布后，就有人建议我服食脑残片！）因此
，论起PM的自我修养，你必须有收放自如的情感，还得有理性的逻辑思维去支撑起每一次的灵感乍现。
你可以问自己三个问题：一、这个功能是否服务于产品的主线业务，比如一个听歌的软件是否要有日间／夜间模式切换？如果只是锦上添花，使用场景不足整体的10％，那劝你还是等自己学会写代码以后在家做着玩吧；二、这个功能的技术实现成本有多大，如果用工时或天数来预计工作量不够直观，请去HR部门问一下RD全员每天的工资总额，再乘以所需要的开发时间，哈，这个金额应该足以让你好好思考“需求性价比”这件事了！（这招在创业公司尤为实用）三、这个功能的效果是否能被评估，这样至少你能检验自己的判断是否正确，无论如何都能积累宝贵的经验。
嫌弃理由3：不信任RD的能力。
呵呵呵呵呵呵，说起这个真是百感交集。
每一个有血有泪的日子里都在重复上演这样的剧集：PM问RD这个功能要做多久，RD说至少3周，PM于是去问自己做技术的好基友 “真的需要3周吗？”，基友拍桌子说 “这有什么难的，换了我3天就搞定！” 然后两人忿忿不平的拍案皱眉，开始讨论公司里的RD们到底是能力差还是在偷懒。
我曾经也这样，因为不懂技术害怕被骗，于是勾搭各种民间技术大牛让他们给我做狗头军师。
军师们为了维护自己伟岸的形象，通常会拍胸脯各种夸大各种装逼。
更糟糕的是，军师们也变相破坏了我和RD之间原本就已经很稀薄的信任。
（哦多么痛的领悟～～～）
最后，RD眼里的RD，只有一种：比自己牛的人。
剩下那些能力不如自己的，他们的存在早已消失散尽在雾霾里了。
……………………………………..我是口沫横飞的分割线…………………………………….
让RD觉得你很优秀的方法…
1.眼观四路耳听八方，知识渊博，掌握行业内的各种动态，分析市场趋势，没事就盯着友盟的数
据看，各种国外新推出的牛逼产品统统用起来。
RD们会觉得你什么都知道，那你的判断八成是靠谱的。
2.混对圈子，积攒几个牛逼人脉，难得和大人物有饭局的时候一定拍照发朋友圈，时不时去知乎回答些问题，去各种活动刷脸，撮合各种合作，尽一切可能把公司推到聚光灯下，这样也更容易招聘到优秀的程序员，产生良性循环。
RD们大多不喜欢抛头露面，所以他们会觉得你的付出无可取代（不然他们老觉得PM每天看看文章聊聊天，简直是悠闲的废物）。
3.无论是口述的需求还是撰写的文档，文字和原型图的呈现都要有逻辑，有条理，最好用写代码的思路来写产品文档，功能细节上的逻辑处理无一遗漏，实乃RD们的心头好。
4.在老板责问为什么还没上线的时候，冲上前去说，“都是我的错，前几天又改了个需求”。
5.在RD们被各种部门的需求同时袭击的时候，为他们安排最合理的优先级，并承诺担起一切后果（包括被某部门主管批斗责骂等）。
6.招到漂亮的实习生妹子给RD们养眼。
7.给他们加薪，给他们加薪，给他们加薪。
文章的最后，我想对所有还在拼搏的产品经理们说，就算你的行业环境不断限制你的创新和畅想，就算你身边的程序员总是打压你的积极性，攻击你的决策和判断，就算你觉得全世界都没有人肯定你的努力，没有人理解你的无奈，你都不可以放弃。
勿忘理想，勿忘初心。
你们是美好未来的希望。
转自：36氪
人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。