产品在日常工作中，需要与开发进行沟通交流，在产品协作过程中，总会遇到一些问题与摩擦，面对这些问题，产品人员该如何应对比较合适？作者分享了一些他的看法，希望对你有所帮助。

今天重温了一下老书，一时间入了迷。想起了当初第一次看这本书时候我的状态，想起了我工作快两年来遇到的一些问题。有感而发，临时想写一篇文章来记录一下，记一下我对产品工作的认识以及产研之间矛盾的看法。

一、先来简单说说我认可的产品和产品经理的定义

1. 什么是产品？

解决某类需求的商品或者服务。说白了，就是可以满足需求的载体。

比如满足你刷牙需求的牙刷，出行需求的共享单车，外卖需求的饿了吗等等。这些从虚拟到实体都可以统称为产品。

2. 什么是产品经理？

俞军说：企业通过“产品”这个关键媒介，以创造“用户价值” 的方式，有选择地和用户进行价值交换。

那么企业需要的这个媒介的创造者就可以称为产品经理。

举个不是很恰当的例子，如果现在大家洗澡洗的不爽，洗不干净。这个需求被某个人或者某个企业发现了，那么负责解决洗澡洗不干净的人就是产品经理。

• 也许这个企业会有个部门，一些人创造出了肥皂，用户洗澡的时候用肥皂就能比之前洗的更干净。那么这个部门也许会叫做产品部，这群人就叫产品经理（肥皂这个商品）。
• 也许这个企业有个部门，一些人发现搓背这个行为能有效的解决洗不干净的问题，于是制定了一套搓背服务流程，搓完比不搓洗的更干净。那么这群创造这个服务的人就叫产品经理（搓澡这个服务）。

其实产品经理也就是创造“肥皂”，发现“搓背”服务的人。无非是这个肥皂可能叫做滴滴，这个服务可能叫做出行。或者是叫做美团/外卖，微信/社交。

二、为什么需要我们这些“产品”？

听起来这个岗位好像也没有很高的门槛，没有很高的标准，那为什么有着较高专业知识门槛的研发不能顺便“兼顾”一下看似轻巧的产品经理的工作呢？

个人理解，在以下的几个方面的差异导致产品工作需要精心对待而不是随意应付：

1. 岗位定义的不同

这个在各个求职软件上的招聘要求都有，五花八门，总的来说产品处于信息的上游，研发处于信息的下游。一个负责设计，一个负责实施。在同一条河里，但是不在同一条船上。我简单总结了一下。

pm：负责发现/收集/创造和定义需求，将需求通过具体的产品功能设计呈现为用户可用的产品。

研发：从技术角度评估产品方案，设计技术方案，最终将产品设计实施落地为用户可用的产品。

2. 岗位考核的不同

产品岗位的考核其实很清晰，与岗位最初赋予你的责任其实是对应的。能否高效准确的将各方需求转化为产品需求，然后将需求转化为产品方案，并确保产品方案顺利落地并实施。简单来说就是：把产品搞好。

简单提一嘴，我觉得把产品搞好我觉得有几个关键节点。

1. 需求的收集与反馈：作为需求的第一承接人，所有需求需要记录下来。将需求的关键属性诸如场景，提交人，紧急程度等等记录。然后这些需求的状态变更（如从需求池到产品设计阶段，如进入研发阶段，上线时间已定等等），及时通知关联人员。避免出现大家会经常来问 需求怎么样了到哪一步了上线了吗 此类信息不对称问题。
2. 产品方案的高质量设计：这个无需赘述，产品最需要做好的工作。
3. 版本的稳定上线：通常每个上线任务都有deadline，不要交给研发之后就不闻不问了，要常常跟一下进度，做到心中有数。如果有任何意外，需要及时调整时间和通知上级。
4. 上线后的持续跟进：上线不是终点！上线不是终点！上线不是终点！重要的话说三遍，在此我想引用一下丘吉尔的”The End of the Beginning”演讲上的一句话来表达观点：“ 这不是结束，甚至不是结束的开始，而可能只是开始的结束。”

pm：承接好各方需求，并准确高效的转化成产品方案并推进落地。

研发：在紧迫的时间内优质的完成产品方案的落地。

3. 思维的不同

因为岗位的定义和考核不同，所以决定了思维大概率就会不同。梁宁说过，我们都活在角色里，被角色驯化。角色化的人在思维上自然也会变化，所以大家和人打交道的时候可以很明显的看到这个人角色化的痕迹。我们来分析下产研两个角色上的思维差别。

我们把研发的思维叫做“工程思维”，工程思维往往是理性的逻辑思维，从实现的难易程度和系统的角度去定义产品和设计产品。

这么做有一个比较大的弊端，就是容易脱离实际。这个实际不是说的技术实际，而是需求和实际场景。研发拿到需求时，第一时间考虑技术方案和架构。这没有什么不对，但是换个角度看，一个需求的价值不在于实现时的技术和难易程度，而在于有没有为用户解决问题。

产品经理的思维叫做“产品思维”，产品思维是一种结合工程思维，功能思维和商业思维的综合思维模式，包含对商业目标，目标用户和用户场景的理解。

我们来举个例子，“在这个河上建一座桥”，听到这句话的时候，这两个思维会如何进行思考呢？

• 工程思维：建什么桥，水泥桥还是石桥，水流湍急程度，什么时候完工….
• 产品思维：建这座桥是为了做什么？需求方是谁？预计带来的商业价值有哪些？现在需求方是如何进行操作的（划船？），频率是多少…..

pm：产品思维

研发：工程思维

三、想象一下没有产品经理的世界

首先，有产品就必然代表有需求。这个需求大概率是直接由用户提出来的，不加思考的需求（很少有用户能够清晰地描述自己的需求。直接问他们使用产品的感受，大都倾向于关注产品的次要功能或者弥补缺陷的小窍门）。

这些未经思考，过滤，筛选的需求通常和用户真正期望的需求关系不大。再简单将这些需求转化成产品队列，然后期望用复杂技术编配优雅产品出来其实是不切实际的。

开发人员会直接决定构造产品的过程，也决定构造什么样的产品。但是开发人员的任务诉求与产品最终用户的诉求很大可能完全不同。且矛盾的地方在于优秀的开发人员关注的是解决技术难题带来的挑战、如期完成任务。

他们收到的信息往往不完整、缺乏远见、有时甚至相互矛盾，还要在极为紧迫的时间内且不了解人们将如何使用产品的情况下，被迫做出事关用户体验的重要决定。

因此，最直接负责创造产品的人员如果很少考虑或者没有时间和精力去考虑到真实用户的目标、需求或动机，那么产品大概率是失败的（你应该想象面对刺猬形或者圆形的还洗不干净的肥皂和面对搓背体验很差的师傅是什么样的感受）。

归根结底问题很简单。人无法每次都战胜人性，选择那条更“艰难而准确”的道路。

一个产品的实现和设计之间必然存在冲突。研发会经常在易于编程和易于使用之间做选择，但是考核他们的却是编程效率和能否在紧张时间内完成编程任务，你就可以预见产品的最终模样了。正如在法庭上我们绝不能让原告来裁定案件一样，产品也应该确保设计师和开发人员不是同一批人。即使程序员有足够的设计能力和设计意愿，也无法有效地兼顾用户、商业及技术各方利益。

四、该如何与研发相处

研发和产品不是同一批人，甚至思维方式都截然不同。但是都是为同一个目标去努力的，研发和产品是无法完全切割开来的。

举个例子：在宣讲时不能只讲最终方案不讲需求场景。虽然两个岗位职责不同，但是大家是同一个团队，都是围绕着需求，功能，产品来进行展开工作。了解整个通路对协同有很大帮助。

在讲解产品设计时讲一下这个产品的 需求场景 等上游信息，其实对开展工作也是有比较多的帮助。

1. 其一：研发会有参与感和被信任感，他会觉得这个产品方案我也有提供一些建议，也有贡献。谁都希望自己的建议能够被采纳，自己有足够的存在感。这对研发同学“快乐”的写代码可能也会有帮助～。
2. 其二：研发如果用工程思维考量你的方案时候，也可以基于你表述的场景给一些建议，而这些建议往往就会产生意想不到的效果。

最后给一些正在承受“与研发针锋相对的关系”新人产品经理几个小tips。

• 我们虽然有着“经理头衔”，但我们只能管理自己。
• 和研发的沟通要虚心，弱小和无知不是“被怼”的那个point，傲慢才是。
• 价值的传递。站在他人角度考虑。认同他们的付出，经常同步他们产品上线后的结果，包括数据结果、用户反馈、使用感受等等都可以，让他们觉得在做有意义的事情。

五、写在最后

在我的产品生涯不长，但和研发battle的次数却不少。

在争的面红耳赤的时候，在会议结束自己一个人坐在空无一人会议室的旋转椅上的时候，在夜晚默默参照会议记录修改产品方案的时候，我时常问我自己：这样子有价值吗，有存在的意义吗？

这些在后来的过程里都有了答案，我既知道了“君子和而不同”，也知道了只要你期待你的产品能给公司带来效益，能给用户更好的使用体验，能给世界多一份美好。那么你正在从事的，坚持的东西就是有价值的。

且不论过程是怎么样的艰难。但行好事，莫问前程，不忘初心。坚持那颗做好产品的心吧，把自己的价值打包成产品交付给世界，那世界就会给你一个happy ending。