转型产品 2 个月，我还没去掉程序员的傲慢

2 个多月前，我还是一名正儿八经的程序员，以往前端、后端、团队管理都做过。在过去的两个月，我切实体会到了产品经理与程序员，在思考方式、做事方法上的区别。

2019 年的时候，我有一个机会在公司内部从程序员转岗产品经理，当时我向业内大佬们请教，具体应该注意什么，其中有一个反馈是 “别傲慢”。

当时我是真的慌了，以为是自己发布消息的内容语言使用不对，生怕给别人一种 “我很傲慢” 的感觉。

现在回过头来想，我当时的反应恰恰证明了自己作为程序员的 “傲慢”。

看到评论的那一刻，我第一反应是站在自己的角度，发出了“我不傲慢”的反驳，没有换位思考，更没有意识到那只是个非常中肯且重要的建议。

做产品经理 2 个半月，我感觉自己正在慢慢摆脱傲慢思维。

也想来总结一下，从程序员转岗到产品经理，有哪些优势，以及可能会踩到的坑。

一、技术转型产品的优势

在互联网产品团队中，程序员是核心的角色之一。

从程序员转型的产品经理的人，最大的优势可能就是我们对程序员的工作方式和习惯更了解，对后续的协作、产品管理有比较大的助力。

结合 2 个多月的实际经验，我想来总结下这个阶段，我理解到的技术背景产品人的优势。

首先，不会低估程序员的“怀疑能力”。

程序员的怀疑能力是指在新需求来的时候，对产品经理抱有的“不信任感”。

尤其是对刚开始合作的产品经理，这个不信任不是对人，而主要来源于程序员的行业背景和工作习惯导致的思维方式相对更严谨。

产品经理每天思考的，是如何产品创新、如何满足客户需求、如何满足老板要求，体现出个人价值。所以，产品经理更偏重全局观，对于有时候会忽略一些细节问题。

而程序员思考的是：这个需求能不能实现、用什么技术可以实现、多久可以实现，目前的任务排期是什么，手里还有没有其他任务，需不需要加班、公司有没有加班费，以及这个项目加不加绩效。

所以，他们更在意每一个影响工作量的逻辑细节，也会跟产品经理抛出很多的问题，尤其是在产品需求会上。

需求会是一个特殊的场景：一个产品经理、一群开发 + 测试。

如果需求准备得不那么充分，程序员和测试一个一个问题抛过来，会营造一种“围攻”的感觉。尤其当他们抛出技术方案相关的问题时，紧张感会更明显。

而且，有些程序员同学的语气会不自觉地带有攻击性，产品经理很容易陷入被怼的情绪里。

对于我来说，在做产品设计的时候，我会不自觉的代入技术思维来给自己抛出问题，最大程度完善逻辑细节。

即便是没有落实到PRD和原型上的问题，被程序员提出来了也不会慌，总是可以从过去的工作经验中找到解决方案。

所以在做产品的前 2 个月，我没有出现过被技术围攻的感觉。

其次，更清楚程序员需要的空间。

基于我之前的经验，经常会有产品经理因为进度催得太急把程序员惹毛，这种现象很常见。

站在产品经理的角度，同步完需求之后，后续产品能不能做出来，能不能正常使用，主要取决于程序员。频繁地问，其实也是为了把控产品进度。但是，如果掌握不好问的时间、频率，在程序员的角度就变成了“催”。

程序员的工作需要时间和空间，比如在需求会上，有经验的程序员是不会当场给出开发周期的，他们需要花时间来评估技术可行性，1天、1周都有可能。

肉眼看到的需求不是需求，短时间给出的承诺，要么真的是非常牛，要么就是对产品和自己的不负责。

程序员接收到需求必须经过自己的大脑，定下来技术方案、研发成本、可能存在的坑，才算是确认了需求。当然，他们会给自己预留出一部分时间，来和需求方进行博弈。

所以，在做产品经理的这段时间，我没有要求过程序员当场给出时间，而是给出明确的评估范围，到节点跟进是否有想要的结果就好。

但是作为产品经理，要给自己一个预期——程序员的时间评估不一定每次都准确，具体还是要看程序员的工作经验，如果经验不足，最好跟他的上级确认一下。

需要强调的是，如果在跟程序员沟通中，他说出了这句话：“产品一句话，恨不得第二天东西就出来了”。

有两种可能：

1. 产品经理催的太急了，他烦了；
2. 他的工作有很大可能会延期，程序员对时间不自信了。

产品经理可以通过查看过程进度，来判断是哪种情况。

如果是第 1 种情况，其实可以跟程序员确定一个固定的时间进度，给程序员留出自己的心流时间专心编码。

如果是第 2 种情况，无论是不是程序员的责任，都建议别扯皮，先稳住。让你的程序员同学先集中精力完成工作，最后再做原因复盘。

第三，不会忽视程序员的每一个小问题。

相对于产品经理来说，程序员是不善言辞的。绝大多数程序员，能写代码解决的就不愿意交流，大多数时间都更愿意自己干活。所以，一旦他们抛出了问题，那一定是不能忽视的。

总结下来，从程序员转型产品经理的优势，目前我体会到的是：

1. 做需求的时候能够调动技术思维，在需求上思考的相对比较详细，所以对研发进度更有把控感。
2. 能跟程序员同频，更能理解程序员提出的问题，也能清楚什么原因更能触发他们的小情绪，该哄就哄，该批评就开诚布公的找上领导一起复盘。
3. 在产品研发过程中，程序员抛出的问题也能结合自己过去的技术经验，给出方案建议，无形中增加了他们的信任感。