2023年和研发“battle”完一位产品的深思

和研发“battle”完，一位产品的深思今日重温了一下老书，一时间入了迷。想起了当时第一次看这本书时候我的状态，想起了我工作快两年来遇到的一些问题。有感而发，临时想写一篇文章来记录一下，记一下我对产品工作的熟悉以及产研之间冲突的看法。

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

1.什么是产品？

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

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

2.什么是产品经理？

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

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

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

或许这个企业会有个部门，一些人制造出了肥皂，用户洗澡的时候用肥皂就能比之前洗的更洁净。那么这个部门或许会叫做产品部，这群人就叫产品经理（肥皂这个商品）。或许这个企业有个部门，一些人发觉搓背这个行为能有效的解决洗不洁净的问题，于是制定了一套搓背服务流程，搓完比不搓洗的更洁净。那么这群制造这个服务的人就叫产品经理（搓澡这个服务）。其实产品经理也就是制造“肥皂”，发觉“搓背”服务的人。无非是这个肥皂可能叫做滴滴，这个服务可能叫做出行。或者是叫做美团/外卖，微信/社交。

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

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

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

1.岗位定义的不同

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

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

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

2.岗位考核的不同

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

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

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

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

3.思维的不同

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

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

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

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

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

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

研发：工程思维

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

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

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

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

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

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

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

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

四、该如何与研发相处

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

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

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

其一：研发会有参加感和被信任感，他会觉得这个产品方案我也有供应一些建议，也有贡献。谁都盼望自己的建议能够被接受，自己有足够的存在感。这对研发同学“欢乐”的写代码可能也会有关心～。其二：研发假如用工程思维考量你的方案时候，也可以基于你表述的场景给一些建议，而这些建议往往就会产生意想不到的效果。最终给一些正在承受“与研发针锋相对的关系”新人产品经理几个小tips。

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

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

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