2018-01-04我见过的产品同学被怼，通常逃不出下面两点诱因[偷笑]
1. 需求变更其实没什么，之前没想清楚就说没想清楚，千万别拿用户和体验当幌子，把自己摆在道德高点，让变更变得理直气壮。
2. 永远不要和开发说这个需求你也不想做，都是老大们让做的; 或者说你这个功能不是我要的，是业务部门要的。开发通常会觉得你没担当，而不是理解你的无奈。 原则上不能守护好产品特性的产品经理，与不能守护好代码完整性的开发，都是很难获得尊敬的。展开作者回复: 对，要有担当，敢承认自己错了
27
2018-01-19我也是开发专产品。
理解痛点，技术难点。这有时候是好事，有时候会拦住我的想法。
好的一面，我的产品文档，大家愿意看。不好的一面，每次想方案，都会被这个好实现么，拦住脚步。作者回复: 是的，这是个问题，我也会受到影响
5
2018-01-03二爷聊的这个确实是一个不错的选题，建议可以做成一个系列，把产品跨职能沟通过程中遇到的坑分享和分析一下，应该是比较有意思的系列作者回复: 好主意～
4
2018-09-15作为开发，最烦产经说的一句话，“你去网上搜搜，肯定有现成代码”。
第一，这让开发感觉被看轻。好像开发连基本的检索能力都不具备，还要你产经来提醒。
第二，既然开发提出了代码可能达不到预期，就代表项目里可能出了问题。产经根本听不懂，只是一味强压。
还有一点儿，开发提出图片不合适需要修改，产经来了句“反正下次要改版，先凑合用就行。”那反正要改版，我代码是不是也不写你的新需求了？展开 3
2018-01-04＃我与开发沟通日常经验得到
1.好好说话达成共识，彼此工作目的服务于上级，实现价值。
2.了解彼此，提好需求，同开发技术哥讲清楚为什要做这个功能，最终要实现的结果是怎样的；同时要去了解怎么去实现，过程是否会遇到问题及开发成本。
3.多一起吃工作餐多交流，绝大部分问题都可在此化解。
4.态度一定要好，关于技术相关知识不懂的，多问一句，私下自己多补一点。展开作者回复: 最好还是服务一个目标，而不是一个人
3
2018-01-09作为后台产品经理，我天天跟开发厮混到一起，可以充分了解开发自己对产品的需求，其实很多开发并不是只单纯想怎么做，很多时候他们会关心为什么做，做的好处是啥，是否是可以复用的？然后在充分了解需求后，好的工程师甚至会给你提供多种实施方案，和产品一起讨论最终得出最优方案。
必要的沟通，就是给开发工程师的尊重，让开发能倍感尊重，开发出的代码质量都会好不少。作者回复: 我做后台的时候也是天天跟开发厮混，哈哈哈哈哈
2
2018-01-02面对功能的第一反应，我是从用户、场景与问题入手，从第一要点来看，二爷是先考虑业务需求吗？
关于与开发沟通，我最深的感触就是，要讲清楚为什么，以及这件事情与整个产品的关系，开发不会单独为了某个需求而改变架构，要让他们理解这是产品的分支，而不是另辟蹊径。
还有就是，真的需要提前花时间沟通，而不是现场冲突，很多想法在开会时其实不见得容易问出来，就像二爷说的，每个人都有防备心理，毕竟这是工作，不是闲聊，有些事情不提前搞定，后续再开会就十分难看了。作者回复: 业务需求也来源于对利益相关者和其利益的分析，而用户通常就是最重要的利益相关者。
2
2018-06-27大家都是有一致目标的：让一个产品活的更好，活得更久，所以产生对立的情况，是由于双方共享信息不够透明及时，信息不对称导致猜疑和矛盾。主动沟通，弥补对方的信息短板，市非常好的沟通法则。学习了，产品把“why”讲明白，是在讲，用户场景需求，工程师把相对通俗易懂的“how”讲懂，双方共同决定“what”的方向。 1
2018-01-10作为产品经理，与开发沟通时，其实也应该把他们当成用户，站在他们的角度分析其真正的需求是什么，关心的是什么，然后以诚恳的态度加强沟通。 1
2019-04-201、思维不同：产品经理是“为什么这么做”，研发是“怎么做”。交织点是“做什么”。
要互通有无，产品经理需要讲自己思考“为什么这么做”的过程，适当地告知研发，增进理解；研发也可以把“怎么做”告知产品，增进理解；
2、产品经理，时刻关注团队内部成员之间的关系变化（开小会、用词用语等）；
3、专程讲述，平时闲聊/吃饭/散步时，主动厚脸皮聊你对产品的思考。刚开始会显得神经病，但慢慢地对方会感受你是真的在沟通，也是真心的在对产品进行思考。而后，在需求分布会时，研发可能会发自内心地配合你了。
2019-03-11我觉得除了自己做好以外，也只能多沟通，多吃饭，多洗脑了，深受研发“简单实现”之苦