从程序员转产品经理，我踩过的几个真实坑

从2021年在公司内部转产品经理到现在，已经快5个年头了。前段时间考完 PMP，一直在想做点什么沉淀下来。突然想起以前做技术时，偶尔也会写写博客，最开始用 GitHub 写，结果现在账号都登不上去了，之前的内容也找不回来。不过也无所谓，基本都是些技术流水账，丢了就丢了。

又想起当年做海康摄像头相关项目时，在博客园写过一篇文章，试着登了一下老账号，居然还能上来！

虽然博客园主打技术交流，但整体氛围很包容，没什么门槛和偏见。索性就把这几年从技术转产品踩过的坑慢慢分享出来，如果之后也有小伙伴想从技术转产品，希望能给大家一点真实参考。

转职

在我转产品之前，我当时那家公司是没有产品经理这个岗位的，或者说，我们研发部人人都是产品经理，契机是什么呢？简单来讲就是完全不可控的开发节奏，做不完的需求，不知道是我老大还是老板，意识到了这个问题，想要做一些改变。

最开始，老大找我聊，想让我尝试一下，我当时坚持技术才是王道，后来找了我同事，结果情况不仅没好，反而更加严重，公司启动招聘产品经理，后来老板找我聊天，想让我试试看，最后说他想了很久，你的沟通能力、长相都比XXX（我同事）好，你试试嘛，如果可以，懂业务，懂技术，岂不是王炸。

（哈哈哈不是我自恋，是真的这么说的，不过我也有自知之明，长得一点也不帅）。

后来脑子一热就答应了，老板也是仁义，为了防止出现之前的情况，还给我报了一个产品经理的培训课，就这样我开始了产品的工作。

最开始主要是公司内部业务的需求梳理，后来开始接一些外包，期间设计了一个小程序，意外还成为了公司所有单一产品中，日活最高的，总体而言，其实还行，不过中间的过程，是真的难受，下面我来讲讲这其中的坑。

程序员思维思考问题

简单来讲，遇到一个需求，我最早的思维方式是“怎么做？大概需要多久？”，技术能实现？那行，出原型，然后递交给开发。

结果可想而知，依然是做不完的需求，导致研发部持续性的加班，每天都在赶工，却不知道自己做的需求到底能解决什么问题。

在这里我不得不感谢一些我之前的同事和领导对我包容，大家从来没有说过我什么，现在想到，都想给你们磕一个。

现在想来，这点是非常要命，作为产品经理，对于需求来者不拒，不仅仅自己不合格，也让研发陷入了严重的加班，而且也几乎无法创造价值。

忽略业务、人情

做程序出身的人，大多都有个通病：凡事必须逻辑自洽、环环相扣、严丝合缝。刚转产品那会儿，我把这个习惯原封不动带了过去。

设计一个流程，我会下意识追求：有没有漏洞？会不会绕？能不能做到百分百严谨？只要逻辑上不够 “干净”，我就浑身难受，一定要改到完美才行。

最后到了一个什么程度呢？权限分配，我甚至做到了字段级别的权限分配，也就是说，你可以直接去配置谁可以看哪些字段。（这里我说一下，可能某些场景下这样设计是合理的，但是我们当时的场景，没有那么高的保密度）

结果可想而知：整个后台其实巨难用，配置复杂、绕，稍微哪个地方配置错了，可能连最基本的工作都进行不了。

给客户做演示的时候，自以为非常专业，结果大家直呼太绕，根本操作不来。我当时还很不服气：明明逻辑没问题、非常严谨，怎么会用不明白？

后来才慢慢懂：产品的终极目标不是逻辑完美、严谨，而是解决业务问题。

用户不关心你的流程有多优雅、多严谨，他们只关心好不好用、快不快、习不习惯。更重要的是，产品工作不是一个人的逻辑秀，而是团队协作。你为了逻辑完美多堆几层判断，研发就要多加班几天；你为了流程闭环多加几个步骤，客户就要多适应很久。

一味死磕逻辑，会忽略两个更重要的东西：一是真实业务场景，二是团队里的人情与协作成本。

逻辑可以妥协，流程可以简化，需求可以取舍，但项目要推进、团队要顺畅、用户要能用，这些才是底线。

从那以后我慢慢改掉了这个习惯：先保证业务成立，再谈逻辑美观；

先让大家能跑起来，再追求严丝合缝。

不懂边界，给啥做啥

刚转产品的时候，我完全没有 “需求边界” 的概念。不管是老板提的、客户提的，还是研发随口顺带提的，只要是 “需求”，我基本都全盘接收，总觉得 “拒绝不太好”“多做一点总没坏处”。

最夸张的一次，是我们给学校做的一款产品。老师反馈说，用智能设备采集学生成绩有个麻烦点：成绩录入后修改起来很不方便，于是希望加一个“作弊” 功能，可以直接给某些学生加分，而不是在后台中一个一个手动去改。

这么明显不合理、甚至有点违规的需求，我当时居然还一本正经地梳理方案，然后丢给研发了。结果研发老大看完需求，很委婉地跟我说：“这个需求……逻辑上是能做，但我们真的应该做吗？”

那一刻我突然愣住了：原来不是所有需求，我都必须接。

从那之后，我才开始学着拒绝一些需求。当然拒绝也是有技巧的，不是直接硬怼说 “我不做”，而是用更温和的方式：

这个我先记下来，我们内部评估一下

这个可以做，但优先级不会太高

先把核心流程跑完，再来考虑这类优化

这个过程其实也痛苦了一阵子，不再是来者不拒，而是开始在内部和研发一起讨论：该删的删、该缓的缓、该排后的排后。但慢慢下来，项目明显走上正轨，无休止加班赶需求的情况大幅减少。

后来回头反思那段经历，我才真正认清一件事：产品经理的核心不是 “做需求”，而是 “筛选需求、定义优先级”。不懂拒绝、没有边界，不仅会把自己累死，还会拖垮整个团队，最后做出来一堆东西，没有一个能真正落地、真正产生价值。

沟通的能力

其实我本人之前不善于沟通，属于那种有些社恐的人，不过我自认为情商还是可以（以PMP中对情商的定义）。

很多人说，沟通能力是产品经理的硬实力，我对此其实有一点点保留态度 —— 先别杠，世界本就不是非黑即白的，一个人只要不是有社交障碍、口吃、哑巴这种极端情况，其实都有潜力做好产品岗。

很简单，商务那一套，公司的商务基本已经对接完了，产品出马基本上就是开始连接客户与研发了，这个时候，其实只要一个人具备逻辑思维能力、沟通能力，其实就可以把这件事做好。

当然，这点我知道，很多公司对产品的定位不同，同时，如果你想要转产品，同时想要一个更好的发展上限，沟通能力说是产品的一个硬实力，其实也不夸张。

如果你是一个喜欢怼人，习惯性反驳别人的人，那么产品这个岗位还是慎重。

关注细节，忽略整体方向

抠细节我感觉是一个程序员习惯性的思维，而且我记得有段时间，抠细节成为了那些成功人士的标配，各类CEO、明星产品经理特别喜欢强调自己像素级的抠细节。

怎么说呢？虽然我觉得很多时候有自我美化的成分在里面，虽然细节在有些时候也确实重要，但是在一个产品一开始就扣细节，我觉得是非常错误的，在实际工作中，不要沉迷于细节，而要分清主次，不然很容易在细节中迷失。

在刚走产品经理的时候，我也陷入过这样的情况，甚至在画原型的时候，我都要纠结上下左右有没有对齐，这其中浪费的很多时间不说，在很多时候，做着做着早就忘记了最初的目标是什么了。

指导技术人员

这个情况我没出现过，但是我发现有些技术转产品的人喜欢去干涉技术人员，曾经公司招进来一个技术转产品的人，当时我在外面和客户做沟通，两周后我回到公司，研发人员私下找到我，说这个产品太烦了，天天在那里纠我们的技术如何实现。

我找到那个产品问什么情况，他的理由也非常实际，说因为那几个工作时间比较短的研发使用的技术不是最优解，用他的方案更好，无论是安全性还是效率都要好很多。

那天我告诉他，我以前也是做研发的，但是自从我开始全职做产品后，我就默认自己不懂技术，因为术业有专攻，你没有全程参与代码的编写，不知道研发为什么要这么做，而且你这样干预研发，会导致研发的逆反心理，所以不如就放手交给研发，让他们自己去做，我们要的只是一个结果。

以上就是我这几年从程序员转产品，踩过的最真实的几个坑。没有什么高大上的理论，全是自己一步步试错、复盘出来的心得。后续我还会慢慢分享自己做产品的感悟、思考，也希望能和同样在产品路上的小伙伴，互相交流、共同成长。