做个能和工程师和谐共处的产品经理
产品经理 部门协调
产品经理部门协调
产品经理在部门中起到重要的协调作用。
他们负责与各个部门合作，推动产品的开发和上线。
具体来说，产品经理的部门协调工作包括以下几个方面：
1. 与研发部门协调：产品经理需要与研发团队密切合作，确保产品按照规定的时间表和质量标准完成开发。
他们要与开发人员沟通需求和产品设计，解答疑问并提供需要的支持。
2. 与设计部门协调：产品经理需要与设计师一起工作，确保产品的用户界面和用户体验满足用户需求。
他们与设计师讨论产品的外观和功能，并反馈用户对设计的需求和意见。
3. 与市场部门协调：产品经理需要与市场部门进行密切合作，了解市场需求和竞争情况。
他们需要将市场部门的反馈和洞察融入产品设计和开发，以确保产品能够适应市场的需求。
4. 与销售部门协调：产品经理需要与销售团队合作，了解销售情况和客户反馈。
他们需要根据销售团队的反馈调整产品策略和功能，以提高销售业绩。
5. 与运营部门协调：产品经理需要与运营团队共同制定产品上线和运营计划。
他们需要与运营团队沟通产品目标和运营策略，并确保产品上线后的持续运营和改进。
总之，产品经理需要在各个部门之间进行协调和沟通，以确保产品能够顺利开发、上线和运营。
他们需要及时处理各个部门
之间的冲突和问题，并确保所有部门能够紧密合作，达成共同的目标。
产品经理如何协调跨部门合作中的冲突与分歧
产品经理如何协调跨部门合作中的冲突与分歧在协调跨部门合作过程中，冲突和分歧是难以避免的。
当出现这些问题时，产品经理可以采取以下措施来协调和处理：1.建立共识：首先，产品经理应努力使所有团队成员都了解合作的目标和共同利益。
通过加强沟通和宣传，帮助团队成员意识到合作的重要性和彼此之间的依赖关系。
2.充分沟通：有效的沟通是解决冲突和分歧的关键。
产品经理应积极推动各部门的沟通，确保信息畅通。
可以定期组织会议或工作坊，让不同部门的代表相互了解对方的立场和需求，从而促进相互理解和合作。
3.尊重差异：每个部门可能有不同的工作重点、目标和方法。
产品经理应尊重这些差异，并寻求共同点。
通过寻求共性，可以增强团队之间的合作，并减少冲突的可能性。
4.找到妥协点：当出现冲突时，产品经理可以协助找到妥协点，以满足不同部门的利益和需求。
通过寻求妥协，可以平衡各方的意见和需求，并推动合作的顺利进行。
5.借助上级领导：如果冲突无法在团队内部解决，产品经理可以向上级领导寻求帮助。
通过与上级领导沟通和协调，可以找到更好的解决方案来解决分歧和冲突。
6.制定调解机制：为了更好地解决冲突和分歧，产品经理可以制定调解机制，如设立调解委员会或调解小组。
这些机构可以帮助各方更好地沟通和协商，并找到解决问题的最佳途径。
7.培养信任关系：在跨部门合作中，建立信任关系至关重要。
产品经理应努力培养信任氛围，鼓励各部门之间相互支持和合作。
通过信任关系的建立，可以减少冲突和分歧的发生，并提高团队合作的效率和质量。
总之，协调跨部门合作中的冲突和分歧需要产品经理具备敏锐的洞察力和灵活的协调能力。
通过建立共识、充分沟通、尊重差异、找到妥协点、借助上级领导、制定调解机制以及培养信任关系等措施，可以有效地解决冲突和分歧，推动跨部门合作的顺利进行。
人工智能产品经理的技术要求与岗位职责
人工智能产品经理的技术要求与岗位职责在科技的快速发展中，人工智能成为了一个炙手可热的领域，越来越多的企业开始关注和招聘人工智能产品经理。
作为人工智能产品经理，需要具备一定的技术知识和技能，并承担一系列的岗位职责。
本文将介绍人工智能产品经理的技术要求和岗位职责，帮助读者更好地了解这个职位。
一、技术要求1. 人工智能基础知识：人工智能产品经理需要具备扎实的人工智能基础知识，包括机器学习、深度学习、自然语言处理等相关领域的知识。
了解人工智能的基本原理和算法，并能够应用到产品的设计和开发中。
2. 大数据分析：掌握大数据分析的相关技术和工具，能够利用数据分析方法进行产品需求分析、市场调研和用户行为分析。
对数据隐私保护和数据安全有一定的了解，能够合理地利用大数据进行决策和优化。
3. 编程能力：具备一定的编程能力，能够理解和阅读常见的编程语言代码，如Python、Java等。
能够与开发团队进行有效的沟通和协作，理解开发过程和技术实现，为产品的设计和开发提供技术支持。
4. 产品设计和UI/UX理念：熟悉产品设计和用户界面/用户体验的理论和方法，能够根据用户需求和市场变化设计和优化人工智能产品的界面和功能。
具备良好的产品敏感性和创新思维，能够从用户角度出发，不断改进产品体验。
5. 技术趋势和行业洞察：保持对人工智能领域最新技术趋势和行业发展的关注，了解市场上的竞争情况和产品动态。
能够针对市场需求和竞争状况，制定相应的产品策略和技术规划，保持产品的竞争力和创新性。
二、岗位职责1. 产品策划和规划：根据市场需求和公司战略，制定人工智能产品的发展规划和策略。
进行市场调研和用户需求分析，确定产品的定位和功能设计。
同时，考虑技术可行性和商业可行性，进行产品的规划和优化。
2. 产品设计和开发：与开发团队紧密合作，参与产品的设计和开发过程。
根据市场需求和用户反馈，进行产品界面和功能的设计和迭代。
与工程师合作，确保产品的技术实现和质量。
测试工程师的沟通技巧如何与开发者产品经理等有效协作
测试工程师的沟通技巧如何与开发者产品经理等有效协作测试工程师的沟通技巧如何与开发者、产品经理等有效协作在软件开发过程中，测试工程师起着至关重要的作用。
他们不仅需要熟悉各种测试技术和工具，还需要与开发者、产品经理等密切合作，以确保软件的质量和稳定性。
然而，在与其他团队成员进行协作时，测试工程师需要具备一定的沟通技巧。
本文将就测试工程师的沟通技巧如何与开发者、产品经理等有效协作进行探讨。
一、明确沟通目的和方式在与开发者、产品经理等进行沟通之前，测试工程师需要明确沟通的目的和方式。
例如，在与开发者进行缺陷交流时，可以先通过电子邮件或文档记录问题，然后设置一个会议来进行面对面的讨论和解决。
而在与产品经理进行需求确认时，可以选择面对面的会议或者使用专门的需求管理工具。
明确沟通的方式可以帮助双方准备好相关资料，并更有效地利用沟通时间，从而提高沟通的效果。
二、善于倾听和理解良好的沟通取决于双方的理解和共识。
作为测试工程师，除了表达自己的观点和意见外，还应该善于倾听和理解其他成员的意见和建议。
在与开发者沟通时，测试工程师需要仔细倾听他们对待解决方案的思考，并理解他们的技术角度和约束。
这样可以更好地理解开发者的需求，避免不必要的冲突和误解。
在与产品经理沟通时，测试工程师需要全面理解产品的功能和业务需求，并与其共同讨论测试的范围和重点。
通过充分倾听和理解，测试工程师可以更好地理解产品经理的意图，从而提出更合理的测试策略和建议。
三、准备清晰的沟通材料为了更有效地与开发者、产品经理等进行沟通，测试工程师需要准备清晰、简洁的沟通材料，以便让对方更好地理解和接受。
当与开发者交流缺陷时，测试工程师可以提供详细的缺陷报告，包括问题的现象、重现步骤和期望的行为等。
此外，还可以提供相关的日志文件、截图或视频，帮助开发者更好地理解和定位问题。
与产品经理进行需求确认时，测试工程师可以准备一份测试计划或测试用例文档，明确测试的范围和目标。
产品经理高效沟通指南
产品经理高效沟通指南产品经理们，沟通能力是关键1.产品经理懂技术，和程序员沟通更高效翔子：作为一个有一些技术能力的PM，我觉得还是有一些优势的。
跟开发开评审会议的时候，客户端和服务端的一些东西他们一说我也基本清楚实现方式。
但有技术基础的话，还要时刻记得不要妄图炫技，毕竟自己的技术实力已经很久没更新了，不要总用自己头脑的一些框框去限制开发。
哪个点能做，哪个点不能做，这个都要跟技术确认好。
懂技术是为了更好地沟通，避免一些鸡同鸭讲的尴尬，而不是说去充当一个开发经理的角色。
虫：其实有技术基础还有一点优势是帮助rd也跳出思维框架，比如有些偏research的RD会追求准确率到极致而忽略性能，或者只是不断的想通过算法优化去解决性能问题。
翔子：对，我大狼厂这样的RD太多了。
这其实是大家的成长方向不同，RD 需要新方案，需要技术创新点去成长（升职）。
但 PM 其实是要权衡时效和稳定性。
2.建立互利关系，统一目标翔子：PM一定要跟RD建立一种互利的关系。
我现在做变现嘛，然后有些东西的确是要速度出，但出来时有些粗糙的。
我就不断给RD 灌输理念，早出早赚钱。
大家利益都是一致的，后续快速迭代就好了。
虫：可以先哄哄RD「这只是折中手段，还能帮你累积用户数据」。
翔子：像@虫那样，就是站在对方角度去说话，挺好的。
3.在评审前把问题解决翔子：沟通阻碍最大的场景，我觉得就是改版。
改版的时候，会有一些需求真的是拍脑袋出来的，真的是没有数据支撑的。
RD抗拒改版的几个点：在PM看来很小的改动，可能引发后续产品的极大不稳定性懒，并没有数据支撑，多一事不如少一事首先是PM要多花些时间调研需求。
把这个改动可能牵涉到的功能都列出来，然后推演一下改前改后的操作路径。
自己想清楚了，再跟对应的RD过一遍，详细地一起讨论。
需求评审前一定是各个子需求都已经跟对应的RD聊过了，不要等到评审的时候再来看。
评审的时候，主要是解决各方面沟通配合的问题，能解决的具体实现问题比较少，因为大家很难在短时间里面面俱到。
产品经理产品设计-不懂技术,如何和工程师交流
不懂技术，如何和工程师交流上次我们聊了聊，工程师如何转变成为一个优秀的管理者；这次我们聊聊不懂技术的管理者如何同工程师再说需求。
管理者问我：“我不懂那些技术，有次跟工程师们交流时，都样子他们会因为我不懂技术纳米技术而暗自鄙视我，我应该怎么做？”很多管理者，在和工程师谈需求时，都费尽唇舌的想要解释清楚自己的想法，却总是被工程师以“这个实现不了”为理由拒绝。
如果再尝试沟通，一个“乱改需求”的帽子就铲到了头上。
如果管理者再不依不饶的话，最后就变成真人PK了。
我们平时最高者接触最多的工程师群体莫过于程序员了。
你看见过的开发人员往往是：现在，让我站在一个（曾经的）程序员的角度上，来谈一谈工程师工程师的个人个人爱好：工程师最开心的时候，莫过于解决了一个一般来说妥善解决问题所带来的成就感。
工程师希望能够从“看的见，摸得着”的事物中获得成就感，比如一台电机，一个软件，一组生产线。
让工程师来“测试发电机运行是否上佳”，他们肯定会极为开心。
而让工程师来“做空一个股票”，他们一定不乐意。
为什么？因为“测试发电机运行为何良好”只需要严格遵照手册规则，一步一步做下去，就非常大能测试成功。
而“做空一个股票”，可以有很多种工具，同时还可能有许多突发事件突发事件。
而这种不确定性，就是工程师最讨厌的部分。
当然，常年累月的“解决问题”，也技术员带给了工程师另外一个特点，强大的逻辑性。
有个关于程序员的笑话：一天，妻子跟程序员丈夫说：“你去菜场买两斤苹果，如果你看到了烧饼，就买一个回来”。
丈夫带着一个苹果回来了。
工程师的逻辑性强，是大家的一个共识。
这是各种各样工程师的优点，也是他们一个很大的阻碍。
你如果和工程师辩论，他们的逻辑都自成一体。
“你这个项目做不出去，因为以下几个原因……”。
里面混着一百多个专业术语，带着自信，不容你一丝反驳。
工程师平时的工作，又强化了他们对于他者逻辑性的追求：我们很难想象，一个随机分布的程序，或者一个随意加装的机械，会如何的运作。
产本一个好的产品经理如何与RD(研发)沟通更高效沟通？
一个好的产品经理如何与RD（研发）沟通更高效沟通？导读上节课，我们提到，作为团队枢纽的产品经理，优秀的沟通能力，是必要的能力与品质。
之所以用“必要的能力与品质”的定义，是因为产品经理只要稍不留心（特别是产品新人），就容易与其它同事产生沟通障碍，发生沟通矛盾；特别是与RD（研发/工程师）之间的沟通，“沟”了没“通”几乎会成为常态。
而因此引发的一切严重后果，都将由团队陪同产品经理一起买单。
各大产品经理社区、公众号、微信群类似沟通不畅爆发矛盾造成恶果的事例不胜枚举本节课会分享推荐一篇非常有趣的文章：《如何与RD沟通，写给那些血气方刚的产品经理》（作者：X小姐），通过文章中作者分享的事例，我们可以更立体地了解产品经理与工程师之间的爱恨情仇：1、产品经理和工程师有哪些沟通问题？2、产品经理为什么会被工程师嫌弃？3、产品经理应该如何与工程师沟通？正文作为产品经理，特别是产品新人，肯定/绝对/100%会遇到各种各样的沟通问题；与此同时，我们也更加需要学会找到导致问题的本质原因，根本解决问题并更好推动产品工作。
接下来，我们会对X小姐文章里7处具有典型代表的内容，进行解读，方便大家更好的理解。
一、产品经理和工程师有哪些沟通问题？原文引用1：最近有位刚做PM（产品经理）的小伙跑来跟我控诉，说公司技术部的RD 们（工程师）个个不给力。
需求过了千百遍还是理解错，或者就是简单回一句“做不了”，表情如死灰。
解读思考：这是所有产品新人都会遇到的问题（我过去做产品，有时候也恨不得把工程师们给**），但本质原因不外乎有两个：1、需求并没有按照工程师们的思维模式来表达，他们理解不了自然也就回复做不了（所以大部分时候他们说做不了真的不是在推诿骗你，而是他们真的没有理解清楚你在说什么）；2、需求没有优先级，工程师们无法明确研发节奏；大部分时候一股脑无定级的瀑布式需求，自然会遭遇一股脑的无视（就像有时候同事找你做事，一股脑的给你提了很多需求，也不说轻重缓紧，你也会瞬间懵圈）。
产品经理 沟通协作
产品经理沟通协作以产品经理沟通协作为标题，我们来探讨一下产品经理在工作中的沟通协作技巧和方法。
作为产品经理，沟通协作是我们工作中不可或缺的一部分。
我们需要与多个团队成员、利益相关方以及用户进行有效的沟通和协作，以确保产品能够顺利地开发和推出市场。
作为产品经理，我们需要具备良好的沟通能力。
沟通能力包括口头和书面沟通。
口头沟通是我们与团队成员和利益相关方进行交流的主要方式。
在口头沟通中，我们需要清晰明了地表达自己的想法和需求，同时也要倾听对方的意见和反馈。
在书面沟通方面，我们需要编写清晰、简洁的文档，以便团队成员能够理解和执行我们的要求。
我们还需要具备良好的协作能力。
产品经理通常需要与多个团队成员协作，包括开发人员、设计师、测试人员等。
在协作中，我们需要搭建良好的沟通渠道，确保信息的畅通和及时传递。
同时，我们还需要建立有效的工作流程和分工，明确每个人的责任和任务，以便团队协同工作。
在沟通协作中，还需要注意以下几点。
首先，我们应该学会倾听。
倾听是有效沟通的基础，只有真正理解对方的需求和意见，我们才能做出准确的决策和反馈。
其次，我们要善于解决冲突。
在团队中，难免会出现意见不合的情况，作为产品经理，我们需要及时发现和解决团队成员之间的冲突，以确保团队的协作效率和工作质量。
最后，我们要保持积极的沟通氛围。
积极的沟通氛围可以促进团队成员之间的合作和信任，提高工作效率和工作质量。
除了与团队成员的沟通协作，产品经理还需要与利益相关方和用户进行有效的沟通。
与利益相关方的沟通主要包括项目进展的汇报和需求的确认。
我们需要定期向利益相关方汇报项目的进展，以便他们了解项目的状态和进展。
同时，我们还需要与利益相关方沟通需求，确保项目的目标和要求得到满足。
与用户的沟通则主要包括用户调研和用户反馈收集。
通过与用户的沟通，我们可以了解用户的需求和痛点，从而指导产品的开发和改进。
在进行沟通协作时，我们还可以借助一些工具和方法来提高效率。
产品经理岗位职责说明书(13篇)
产品经理岗位职责说明书（13篇）篇1：产品经理岗位职责说明书1. 负责产品需求的调研与分析，完成产品功能规划及系统设计;2. 根据业务需求，完成产品的功能、流程、界面设计，撰写详细的产品设计文档和原型设计文档，协调设计资源完成UI 的设计，组织产品评审;3. 与研发、测试、设计、运营等部门有效沟通，确保其对产品充分理解，协调并推动产品迭代;4. 把控产品质量，对产品交付结果以及项目进度承担相应责任;5.基于数据分析和客户反馈不断优化产品，管理产品生命周期。
篇2：产品经理岗位职责说明书1. 负责数据产品的需求调研、需求分析、定义系统功能、原型界面制作、编写需求规格说明书2. 负责在项目推进过程中的跨部门协调沟通工作，能够协调以确保产品按时高质量完成并上线篇3：产品经理岗位职责说明书1. 负责公司信用/征信/B2B2C相关产品(&小程序)的市场调研、场景及需求分析、用户画像、竞品研究、产品规划、流程及功能的概念设计和原型展示;2. 与营销、运营、技术等跨部门沟通，参与统筹管理产品生命周期，配合完成产品的开发、测试、上线、迭代、质量及版本管理等相关工作;3.根据公司业务发展计划和日常数据运营监控，分析并提出改善用户体验的优化方案。
篇4：产品经理岗位职责说明书1、拓展维护供应链产品和优质供应商资源，并做到持续更新迭代;2、新产品、新材料供应商的寻找、资料收集及开发工作;3、掌握市场消费趋势，礼品行业经验优先;4、做好供应商的日常维护篇5：产品经理岗位职责说明书1、打造数据平台，为业务团队、数据分析团队、数据开发团队持续赋能;2、构建泛安全领域的大数据体系，包括埋点、存储、清洗、计算、分析、报表等，体系化的支持业务的发展;3、为运营端、商品端、用户端提供对应的数据分析能力，为业务的发展提供数据赋能;4.负责数据产品的生命周期，制定数据产品的后续计划。
篇6：产品经理岗位职责说明书1.负责所管辖区域金融产品挖掘以及后期签约回款等工作;2.协助交易管家以及集中签约经理完成推荐金融单后续操作流程;3.根据现有市场金融需求及时调整金融产品和营销策略;4.负责维护运营门店以及培训、赋能等动作;篇7：产品经理岗位职责1.1市场调研市场调研是指研究市场以了解客户需求、竞争状况及市场力量(market forces)，其最终目标是发现创新或改进产品的潜在机会。
产品经理的沟通与协调技巧
产品经理的沟通与协调技巧产品经理作为一个项目团队的核心成员，需要与多个部门和角色之间进行有效的沟通和协调。
只有通过良好的沟通和协调，产品经理才能确保项目的顺利进行并达到最终的目标。
本文将介绍一些产品经理在沟通和协调方面的一些技巧和方法。
一、倾听和理解在与团队成员和其他部门进行沟通时，产品经理首先要学会倾听并理解对方的观点和需求。
只有真正理解他们的意见和要求，才能更好地进行沟通和协调。
产品经理应该有耐心地倾听，并通过适当的提问来澄清对方的意图，确保自己理解准确。
二、清晰明确的表达除了倾听和理解外，产品经理还需要以清晰明确的方式表达自己的观点和需求。
在与团队成员沟通时，产品经理应该用简洁明了的语言表达自己的意见，避免使用模糊和含糊不清的词语。
清晰的表达可以帮助其他成员更好地理解并执行产品经理的要求。
三、建立有效的沟通渠道为了确保团队成员和其他部门之间的沟通顺畅，产品经理需要建立有效的沟通渠道。
这可以包括定期的团队会议、项目进度报告、工作日志等。
通过这些沟通渠道，产品经理可以随时了解项目的进展情况，并及时解决可能出现的问题。
四、灵活运用沟通工具随着科技的发展，现代工作中有很多有效的沟通工具可以帮助产品经理更好地与团队成员和其他部门之间进行沟通和协调。
比如电子邮件、即时通讯工具、在线协作平台等。
产品经理可以根据实际情况选择合适的沟通工具，并合理地利用它们来提高沟通效率和质量。
五、协调不同角色和部门作为一个项目团队的核心人员，产品经理需要协调不同角色和部门之间的工作。
这要求产品经理具备一定的领导能力和协调能力。
产品经理应该了解每个角色的职责和需求，并协调好不同部门之间的工作关系，确保项目按计划进行。
六、妥善处理冲突在项目进行过程中，可能会出现各种各样的冲突。
作为产品经理，需要能够妥善处理这些冲突，并尽量避免冲突对项目进展产生负面影响。
产品经理可以通过适当的沟通和调解，找到双方的共同利益点，并找到解决问题的方案。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
说的“产品还得求工程师干活”这句话有多少人觉得不对劲？
在我看来，这种“产品求着工程干活”的思想就是对工程师岗位的不尊重，这种思想看起来在提高工程师的地位，但实际上是将工程师工具化并排除在最终的成果之外。
尊重是应该从心里而来的，而不是在谄媚的行为和语言中（比如前面说的跪舔和各种甜言蜜语，但有时候请吃饭是必不可少）。
那么什么才是代表着尊重的关系呢？个人认为，产品经理应该把工程师当做最亲密的合作伙伴。
合作伙伴，就是大家有共同的目标，一起努力去完成目标，荣辱与共。
从项目角度来说，一个项目的成功，除了产品层面的内容，也需要技术上的完美无瑕，而技术问题的解决，是离不开工程师的积极心态的。
在建立这种可靠的合作关系中，产品经理有主动的责任，那么如何才能激发工程师们的主人翁精神，建立合作关系呢？这里有几个可行的建议：
多向工程师描述大愿景而不仅仅是去描述眼前的功能
让工程师了解更多的背景、目标、成果等，而不是只是告诉工程师要做什么
少说“我”，多说“我们”，不要说“这个应该很简单吧”
作为合作伙伴，你也需要避免自己在工程师被定义为竞对功能抄袭机器和领导训话传达者，认真对待自己的每个需求，能够很好的解释需求的意义和目标，提升自己的靠谱程度。
当然有时候，即使做好了自己，你也会碰到看不起产品经理的工程师（可能之前被我们不靠谱的同行伤害过而抱有
偏见），你自己的工作都不能得到应有的尊重，这种情况下，唯有你持续的专业表现才是唯一的
解药。
信任
这个应该要不了这么久吧？
相信大家都听到过（或说过）类似“这个怎么要做这么久？”这样的描述，产品和工程师之间的互看不爽很可能都是从这类话开始的，将心比心，这类不信任的话谁听了心里都不会开心。
做人啊，最重要的要始终做到善意猜测，即对任何人的任何行为，都要认为对方是基于一个积极的目的的。
落实到工作中，善意猜测就是要相信工程师的能力和品格，尽量对工程师给出的技术反馈（方案设计、估时等等）保持足够的信任，绝大部分情况下，应该也没有人会故意耍滑头。
如果你身边真的有这种工程师，我这边也建议先自省一下：有工程师朋友告诉我，他在估时的时候就习惯性的多估几天，因为产品总是在开发过程中有各种各样的需求变更。
如果你真的怀疑有诈的时候怎么办呢？我有两个建议：首先是增加自己对一些技术实现的了解，能够有自己的一些基本判断；二是在遇到有疑问时找其他的工程师朋友（别告诉我你把工程师都得罪光了[/吓]）帮忙确认，如果有问题时可以通过细化分解技术方案让一切花招显形，或者寻求升级
解决。
理解
不用这么复杂吧，我只要改一下文案就可以了啊！
在我看来，大部分产品经理对工程师的偏见，是因为不理解工程师的思维和工作方式造成的。
一个产品需求摆在面前的时候，大多数产品经理想到的是产品要完成的样子，也就是现在，而工程师必须要去考虑如何实现，要考虑到过去、现在和将来。
比如，一个文案的修改，产品经理看到的只是几个字的变化，而工程师要考虑现在文案的实现逻辑，文案的修改如何去完成，以及这种修改的方式在未来的拓展性。
经验表明，很多后来被证明为坑的需求，真的就是没有考虑过去和将来造成的。
所以我也坚持认为，真正牛逼的工程师和产品经理的组合，是完成当前的需求，填上过去的坑，不给未来留坑的CP。
悲哀的是，大多数只做到了完成当前的需求（更悲哀的是在现实中，解决这些隐形的问题于未然并不会给工程师和产品经理带来足够的肯定）。
如何才能理解工程师，让大家保持一致的步调呢？我认为最重要的是要有一些工程师思维，这里的工程师思维我指的是了解计算机程序如何工作以及大致的实现逻辑。
看过很多文章说产品经理不需要懂技术，这个观点我部分认同。
确实，产品经理不需要懂怎么编码怎么实现，但不能对计算机世界的逻辑一无所知。
在敝司我认为靠谱的产品经理或我的偶像中，无一例外都是逻辑清晰，能够描述出需求相关的逻辑实现和了解产品紧密相关的技术问题。
产品经理必须要了解的知识
根据工作时间，在策略产品经理的工作中，有几组我认为必须要了解的技术逻辑/思维/…（我也不知道叫啥）：
1.MVC
在我短暂的玩耍式的coding生涯中，我理解最核心的就是这个词啦，如果能理解这个词，也就能理解工程师的思维方式。
MVC全名是Model View Controller，是模型(model)－视图(view)－控制
器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码。
这个概念不重要，不用细究，但体现的是工程师的思维方式，通俗的来解释，就是让程序的每一步都去完成一个特定的功能，设计的宗旨是减少耦合方便改进优化和修改。
因此程序的逻辑是分层分块的，每一层每一块完成特定的功能，这样当需要修改某些特定的功能的时候，只需要修改很少的部分就能完成。
举个简单的例子，在这种程序设计下，删除评价内容在评价存储功能中处理，修改商品的评分在评分计算功能处理，修改评价的展示在客户端完成。
所以，当工程师在说这部分更适合xx部门来做的时候，千万不要吃惊，事实上，谁来做什么这类事情你最好提前考虑好。
2.存储、接口和展示
在现在的工程实践中，对数据的处理离不开这三个步骤，像我们以数据为命的策略产品经理，所有的需求也不可能离开三件事。
存储就是将数据存在数据库啦，一般有生产数据库和离线数据库，前者是需要和线上服务一起进行增删改查操作的数据库，后者可以认为是生产数据库的拷贝，一般会定时从生产库同步过来，因而是有延迟的，主要用于数据的加工和分析。
之所以这么做，是为了不给添加生产服务器增加无关的压力。
数据可能存在硬盘也可能存在内存，工程师会在性能和价格中做出平衡选择。
让正常的理解，在展示的时候，我们直接从存储中获取信息就够了，《数据结构和数据库》课中也是这么教的。
在数据量少的情况下，这是可行的，但现在可是大数据时代，那些数据库扛不起那么大的数据量，接口就是为了解决这个问题。
接口的作用就是“连接”，根据上层的需求，在底层中获取数据并通过一些逻辑计算，按照信息需求和性能需求将数据提供给上层。
接口有各种格式，在不同的“连接”处都有合适的接口形式，产品经理最熟悉的一类接口，我们常称为API（按定义讲API有更广泛的定义，我也解释不明白），这是后台的最后一层接口，作用是连接后台和前端，所有的展示信息基本上都是从这类接口中来的，因为这类接口往往是http格式，所以也是产品经理可以把关检验的一类接口，在需求验收和故障排查中经常会用到。
3.响应时间、缓存和QPS
已经有很多数据证明，页面加载速度回影响用户体验和转化率，加载速度是产品经理必须了解和关注的内容，也因此如何用合理的架构和存储方式保障性能也是后台工程师孜孜不倦的追求，也是工程师是否牛逼的检验标准。
前面在存储和接口中已经提到了性能问题，计算机的计算能力是有限的，当数据量大或运算复杂的时候，计算结果的时间可能会超出用户的忍受范围，这时候工程师往往会抛出缓存这样的解决方式。
缓存简单理解就是放弃实时计算，将需要的数据提前准备好。
它的坏处是牺牲了实时性，这个时候就需要产品根据产品特性，在实时性和性能之间做出平衡。
另外，QPS也是工程师经常会提到的名词，它的全称是Query Per Second（每秒查询率），这个值和性能紧密相关，后台结构的设计往往依靠对QPS的预估，一个qps10的功能和一个qps1000的功能对工程师来说完全是两回事。
产品经理在设计功能时，最好能将这个值的预估提供给工程师，以免上线之后还得下线重构，与此相同的表述还有每天请求量等等。
以上是我认为要理解工程师必须了解的一些概念和问题，了解他们可以避免和RD产生一些不必要的冲突。
当然，不同的产品岗位需要了解的常见技术知识是不一样的，但要记住的是不能对技术一无所知，尽量去理解工程师的话，平时多和工程师聊聊天，对于不了解的技术问题，把工程师当老师多问问。
如果你连钢筋都不懂，怎么建出高楼大厦呢？
总之，产品经理应该从心里有这样的新年：和谐一点吧，毕竟大家都是十二生肖！总结一下，要和工程师有和谐的沟通，不妨先做到下面三条：
尊重工程师的工作，把工程师当做伙伴
信任工程师的能力和品格，做到永远善意猜测
了解一些技术思维和知识，尽量去理解技术实现
作者@ hihipm
来源@策略产品经理讲堂（公众号ID；hihipm）
人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。