本文作者从自己的亲身经历出发，总结了从程序员转岗到产品经理会有哪些优势，以及那些可能会踩到的坑。推荐给想要转型的程序员或者刚转型产品的前程序员们，千万别错过这篇文章哦。

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

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

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

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

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

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

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

一、技术转型产品的优势

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有两种可能：

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

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

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

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

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

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

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

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

二、技术思维的坑

除了优势，我也发现了程序员思维，在产品管理过程中带来的问题。

第一，不自觉地憋大招。

做程序员的时候，大多数时间就是拿到需求，自己还是做技术调研、做规划、出方案，遇见问题也主要靠搜索来解决，直到完成产品开发提交给测试验收为止。

在这 2 个月的产品工作中，我会不自觉地代入这个习惯——确认完客户需求之后，开始一个人做需求分析、产品设计，直到功能架构、信息架构、原型图全都做完，甚至已经和程序员做完需求沟通了，才把结果汇报给老板。

这个过程就出了问题，由于做原型过程中老板太忙了，虽然把内容发给了他看，但是没有得到明确的反馈。

所以，MVP 版本开发完成后，老板看到产品，才提出缺少他想要的功能，要求必须加上，这个过程也导致了程序员修改表结构。

其实，如果我能在需求设计阶段，多跟老板沟通并跟进结论，而不是自己闷头干活，可能就不会出现这种问题。这是一种思维定式，总不愿意麻烦别人。

做程序员没有问题，毕竟遇见技术问题，更重要的还是自己能想明白并且解决。但是，产品经理不能这样，在需求分析阶段，切换到不同视角，多和各种相关角色沟通是基础要求。

第二，太依赖过去的经验，导致认知偏差。

我之前做过 8 年多的程序员，经验还算丰富。在产品规划的初期，会本能地依据自己的经验，来判断技术是否可行，包括版本排期，也会根据个人经验来预估。

但是，每个技术团队的工作方式和技术栈是不同的，每个人的能力水平也不相同。

所以，在技术可行性和时间评估方面会跟我的预期有偏差。刚开始做产品工作的时候，因为这个问题，也和程序员们做了几次磨合。

除了技术，还有和用户的沟通上，总是会出现“全世界和我一样懂，全世界和我一样不懂，全世界的脑袋都和我一样”的想法。过度使用“以己度人”的方式理解用户。

以上两个坑，说起来可能都懂，但是确实是技术思维容易跳的坑，以后尽量小心一些。

三、一个小建议

前面总结了我自己从程序员转型产品经理的这两个月的一些心得体会，我想最后再一次拿出程序员时期的傲慢，斗胆给一点技术都不懂技术的产品经理们提个建议——学一门技术。

无论跟设计师沟通还是跟程序员沟通，如果明白那个领域的底层通识，以及他们普遍的思维方式、工作立场，对于后续的工作展开会很有帮助。

有些时候，程序员之所以傲娇，也是吃准了产品不懂技术。他们抛出比较常见的技术问题，产品接不住的时候，难免会在心里暗爽。

互联网产品经理懂点技术，我个人觉得是非常有必要的。

学习技术不仅能让我们更了解程序员的工作，同时也能锻炼到逻辑思维，提高学习效率，这是我的亲身体会。

我本人一直是个学渣，逻辑思维锻炼得少，而且性格偏感性，经常跟着感觉行事。但是在做技术的这 8 年，我明显感觉自己的理性思维被锻炼到了。

所以，如果可以的话，我非常建议产品经理学习一门技术。

不用太难的，喜欢可视化的可以学一下前端，像html、js、css、nodejs，这些还可以在搭建个人网站的时候用到，后续跟前端沟通会比较顺畅。

本身逻辑性强的同学，也可以学一学python，或者简单的数据库脚本，产品经理如果写出来一个小爬虫，那还是很值得炫耀的。

当然，我的这个建议也不一定准确，毕竟很多不会技术的产品经理做得也很好。

但是，我还是认为不会≠不懂，如果能不学就能懂一些也是可以的。（有点矛盾，不学怎么能懂呢？）

四、写在最后

我的一些浅显的经验总结，希望能给同样有转行想法的朋友一些帮助，也希望能给非技术背景的产品经理们一些参考。

在《启示录》第二版里有提到，产品经理是一个团队里最像 CEO 的人，也是发展潜力很大的一个职业。所以，我很庆幸自己从程序员成功转型为产品经理。

互联网产品团队，产品经理、程序员应该是最亲近的人，如果能长期奋斗在一个产品线上，会是一件非常幸运的事情。

作为产品经理，虽然我还是个新手，但是我坚信以后能跟设计、程序员、测试同学们处得很好，一起做出更好、更有价值的产品。