从其他行业转向产品经理时，会经历哪些心理变化和职场技术差距？在这篇文章中，作者对自己从“程序猿”调到产品经理的这段旅程做出了一定的结论，你可以看看。也许能产生共鸣。

很久没有写《程序员变形金刚产品》系列了。最近有点感慨，我想谈谈变形金刚经理在10个月内发生了什么变化。

第一，技术熟练程度下降

1. 「程序员」的知识被动归档

产品变形后没有写代码。偶尔看一眼也没用过。

最近要自己写SQL来处理一些数据，我想我差不多忘了函数是怎么用的了。幸运的是，搜索一下还能想起。

之前有几个读书会产品经理(拳王)合伙人写的小bug，请帮我查一下接收代码时可能有问题的地方。但是不知道确切的是什么。我也是在搜索了几个知识点后才记住的。

因此，对于与程序员相关的知识和技术，实际上不需要被动存档。

10月份没有碰过，代码技术只是存档，但几个月后存档文件也会越来越小。最后只剩下逻辑框架。

2. 如何留住这些技能呢？

是的！我真心想珍藏，但这么贪心。

所有的技术只用了10年就积累起来了，真是多亏了遗忘！

以下是我最近在实践的方法，可以保持效果不差的技术思维。

1)继续在开发群潜水，不定期地八卦一下，看看有没有新的动态。

过去认识很多程序员，但大部分都很安静，几乎没有活力，所以无法从朋友圈那里获得任何知识。

最有用的是“微信军”，不用天天看，产品工作麻烦，看技术军就能“换头”。只要看是否有新技术和新动态就行了。

这样做有以下好处：

心理层面上不掉队毕竟是技术出身，就算真的和老朋友聊天也不会太虚妄。现在可以为合作的技术团队提供注意，必要时提供参考建议。2)与现程序员交流。

在这一点上我有一些优势。我的树洞老师是程序员，所以平时听他的会议，偶尔聊聊遇到什么难题，什么紧急bug要加班。

偶尔一起吐槽，或者在做产品设计的时候，有没有技术上的困难，和他交流。

不写代码，但每天、每周都在和程序员沟通，很难忘记代码。

除了亲朋好友之外，还可以和团队里的程序员进行更多的对话，和程序员对话的方法也可能是需要运动的技术。

偶尔使用小工具

6月份想捣鼓视频号码的时候，需要大量生成一些视频，为了提高效率，用python换了别人的小工具。

当时的感觉是，不做程序员技术也能有帮助。真的很好~

但是要注意的是，不要陷入代码中。只是为了完成自己的需求，不需要追求代码的可扩展性、可重用性和可移植性。

第二，“产品技术”熟练程度提高了。

这里之所以强调“产品功能熟练程度”，在我看来，工作的这10个月还不是产品能力的提高，而是更多产品技术的运用。

总之，这10个月来，越来越熟练的是这几项技能，在熟练的过程中也积累了自己的见解。

1. 撰写 PRD

产品要求文档。

刚开始做产品的时候，完整地写一篇PRD对我来说很痛苦。

为了写好PRD，浏览了“产品之星”的所有PRD相关资料，浏览了“所有人都是产品经理”的20篇相关文章，但不知道该怎么写。

因为我脑子里有两个矛盾。

要参考前辈们的方法，写专业、详细、准确的PRD。那些文章很好，很详细，但开发“看不懂”(看不懂)。我开发的时候不喜欢读写满文章的PRD，所以觉得浪费时间。相反，还不如明确列出所有功能体系结构，使可交互原型清晰直接。

因为不理解，我们队人员少，沟通能力也没有问题，所以写PRD也没有实施。原型流程图可以完全满足项目管理要求。

差不多做了6个月产品的时候，我才开始写PRD，主要原因是人员变动。

球队人员变更后，发现没有PRD是不行的。因为口头沟通的需求没有证据，中间有问题，不能及时得到反馈，开发过度自我发挥，发挥完以后也不记得自己为什么这么做了。

所以我开始用PRD来限制和维持产品需求。

2. 制作原型

我个人比较喜欢可视化相关的工作，所以画画。

说起来也惭愧，在现在的单位，接触不到更深层次业务相关的需求，所以只能通过分析简陋的PPT、老板简短的语言转述，把需求转化为功能架构图、原型跟老板来沟通细节。

在我来之前，我们单位主要是通过 UI 直出设计稿跟客户沟通，所以在开发过程中发现逻辑漏洞，频繁返工的现象比较多。

现在定稿的操作原型，能避免 90% 逻辑不通的现象，所以，现在我至少能确定，在原型方面老板是满意的。

之前有已经做产品的小伙伴问我，平时做原型有什么参考网站，我才意识到，产品前辈们已经熟练到忽视的工具，很多刚刚入行的小白是不知道的。

借着回答朋友问题，分享一下我正在使用的原型工具：

1）Axure RP—— 产品经理必会的原型工具；搜的话有很多交互素材可用，也可以直接使用「axureux」，有必要的话花 299 成为终身会员，能够提高效率。

2）墨刀—— 在线一体化产品设计协作平台；墨刀可以做出来特别漂亮的原型，素材广场也有很多作品可以直接借鉴和使用。不需要考虑托管工具，可以直接在线预览，小公司对工具没要求的话推荐使用，对产品经理友好。

关于产品原型，在搜索如何画好原型图的时候，我看到了这样一条评论：

“点到为止，恰到好处就好。我就反对那些叫嚣着要出高保真原型图的人。

产品经理没必要出高保真原型图。因为高保真原型图直接影响设计师的第一印象，会左右和限定设计师的理解力或者创造力。

另外，对于程序员来说，你啪啪啪几个相框图他们就知道怎么做了。我很担心那些刚入门的孩子，最后产品经理的核心价值和作用没理解，真正的本领没学到，倒成了精通某一个或多个原型制作工具或平台的人才。

以为掌握了足够好的原型制作技术，写出漂亮的产品文档就是能力的体现，那真的很耽误孩子们的青春。”

这位朋友应该是基于自己的经验提出的见解，我同意他说的“点到为止，恰到好处就好”。但是基于我的个人经验，有些不同的看法。

工欲善其事，必先利其器。

我认为，画原型、写文档是一名合格产品经理的最基本的技能，就像中国人想吃好饭需要先学会用筷子，不学也行，吃饺子、面条就不那么地道。不学也行，用得不好也行，可能不影响生活，但用好了绝对会有更好的体验。

先说原型对程序员的重要性。

程序员和产品经理的想法很难完全一致，如果产品经理真的只是啪啪几个相框图给过来，逻辑能力好的程序员能明白大概要做什么，但是可以预料到的问题是：缺少逻辑校验、最终页面效果和产品经理想的有差距。

而且在做的过程中，如果是积极主动的程序员，遇见细节问题会跟产品沟通。但要知道，并不是所有程序员都是积极主动的。

早期在确认需求阶段，通过线框图沟通是没问题的，但是进入开发阶段，作为程序员我希望原型越完善越好，交互越完整越好。工期紧急的情况下可以理解，不紧急的时候用相框图交付给程序员，会认为你在偷懒、或者能力也就这样了。

尤其是做出来之后，产品经理再来挑交互上的问题，将很难说服程序员。

再说原型对UI设计师的重要性。

高保真原型会影响设计师的第一印象，或许的确如此，但那又怎样呢？

作为一款产品的第一负责人，这个产品的第一印象应该是怎样，产品经理应该是其决定性作用的人。给出高保真原型，设计师认为太丑了，就有的沟通了，最终应该是设计师和产品共同设计出一款符合自己产品调性的设计图。

3. 撰写交付 & 宣传文档

我现在在负责一个 B 端的产品，偏交付，所以产品手册、技术说明，宣传册等文档都是必须的。

刚开始写这些文档的时候感觉好难，所以一直拖延，拖延到临近 DDL 才交付。

现在如果再有一个新产品让我写这些文档，可能还是会感觉到痛苦。但是，应该不会特别排斥了，因为已经有自己经验可以借鉴了。

说来惭愧，工作将近一年，最有进步的的确就是以上这些操作技能。

像更重要的产品分析模型、用户画像分析方法、行业分析等技能，在实际的产品工作中并没有得到加强和锻炼。

主要原因是——没有用到，因为我目前只负责了一个项目的 0-1 跟进，而且是专业性比较强，产品还没有真正地投递到终端用户手里，也就是快一年了我的产品还没有上线，更别提有新的产品推进了。

三、职场软技能进一步得到提升

现在的单位是一家偏传统的单位，所以一些职场软技能的要求会更高一些，比如：沟通能力、搜索能力、办公软件的熟练度（算吗？）、截图能力……

这里我把除了本职工作外，偏琐碎的工作能力统称为了职场软技能。

也许你会好奇，截图能力算什么职场软技能？有什么用？

在偏传统或科研的单位，这些很多时候会比一些专业工具更有用。

因为很多传统行业的老板、客户们现在的主要沟通工具仍然是：纸笔、Word、Excel等，并且没几个老板愿意学习在线协作文档。

他们出差不会在包里随身带电脑，有时候就是一部手机行天下，所以，要让老板能在小小的手机屏上看到清晰的资料，截图再合适不过。

关于沟通能力，更多的是学会了倾听和收敛，但我清楚自己还缺一些主动，待提升。

四、心态变化

而现在，傲慢什么的已经快磨没了，甚至变得有些卑微和不自信了。

卑微体现在跟老板和团队开发的沟通方面，不自信源于对一线客户资料掌握得不够。

之前写过两篇关于跟老板和研发的沟通文章：

• 《老板不回消息，不用玻璃心》
• 《当研发知道产品经理有技术背景之后…》

主要分享的是转型过程中，关于的心态转变的心得。

还好，幸亏我还是一个相对外向的人，遇到问题沟通解决，一步步解决掉才会更有成就感。

五、关于职业规划

我从来没有后悔过从程序员转型为产品经理，一天都没有。

产品经理的工作比较琐碎，一天中能够踏踏实实做自己事情的时间有限，有时候也会感觉比较烦，也会跟我的树洞吐槽，他会开玩笑地调侃：

“看，还是程序员单纯吧，写好代码就行。”

但是，我还是更喜欢每天都跟不同人沟通的感觉，更喜欢把“几乎为 0 的想法”一点点梳理成 “看得见可能也摸得到的产品” 的成就感。

所以，至少在主业上，保守来看，未来的 3~5 年我应该不会再调整方向了。

前段时间我们老板问我未来的职业规划是什么：

1. 留在办公室管理好所有的产品设计；
2. 把一个产品从前到后，从产品设计到项目管理、交付、运营整体把控起来。

我选择了后者。

我的理解是，只坐在办公室没办法更深入地了解用户，必须要跟自己的潜在用户接触、交流，去体会市场的变化。而大多数的单位，不会愿意多花一份人员成本单独带着一名小产品做旁听。

虽然对于现在的我来说，同时承担起一整个产品的任务很难，但是能干。

在产品成长阶段，我想升级了，我想要有行业分析、用户调研、商业分析的实战机会。

六、写在最后

受Scalers老师《学习的学问》那本书的启发，未来我会给自己建立一份产品概念台账。

1. 每个概念，要有一个编号。唯一的、不重复的。
2. 每个概念，要有基本的定义。可以直接摘录自某本书、某个学科领域。
3. 每个概念，要写出自己的理解。
4. 每个概念，写出你能想到的案例应用。
5. 写出你认为可以与之关联的其他概念。触类旁通、打开思路。

我也想通过我的经历鼓励一些跟我一样刚刚转型为产品经理的朋友，不适应是一定会有的，积极面对、积极寻求解决方法就好。

想象得到的难，也许能撬动想象不到的未来，继续加油。

作者：leamo；公众号：Leamo的花圃

本文由 @Leamo 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。