转型产品经理10个月，我想升级了

当你从其他行业转向产品经理岗位时，你可能会经历哪些心路变化和职场技能落差？本篇文章里，作者便针对自己从“程序猿”转岗产品经理的这段历程做了一定总结，不妨来看一下，也许你会有所共鸣。

好久没有写「程序员转型产品」系列了，最近有些感触，所以想来聊一聊，转型产品经理 10 个月后我发生了哪些转变。

一、技术熟练度下降

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

转型产品之后，我就没有写过代码了，看还是偶尔会看一看，但是没写过。

最近需要自己写sql 处理一些数据，发现函数怎么用都快忘记了。还好，搜索一下还能想起来。

之前，读书会的产品经理（卷王）小伙伴写的小程序有一些小bug，让我帮忙看一看，拿到代码的时候知道哪里可能有问题，但是，竟然不知道正确的是什么了。也是搜索了几个知识点之后，才想起来了。

所以说，关于程序员相关的知识和技能，不用真的就被动归档了。

10月没碰，代码技能只是归了档，但是再过几个 10 个月，归档文件也会慢慢变小。最终只剩下一些逻辑框架了。

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

是的！我是真心想留住，就是这么贪心（最近这个词听的有点多，我发现自己确实贪心……）。

所有的技能是花了小 10 年好不容易积累下来的，真的忘记多亏得慌啊！

以下是我最近正在实践，并且效果还不错的可以留住技术思维的方法：

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

以往的工作中虽然认识不少程序员，但是大多都很低调，基本不发动态，所以没办法从朋友圈获取什么知识。

最有用的是「微信群」，不需要每天看，产品工作做烦了，可以通过看技术群“换换脑子”，只需要看有没有新技术、新动态即可。

这么做的好处：

1. 在心理层面上不掉队，毕竟是技术出身，真的跟老朋友们聊起来也不至于太抓瞎；
2. 为现在合作的技术团队留个心眼，需要的时候可以提供参考建议。

2）跟现任程序员交流

这一点我稍微有一些优势，我的树洞先生还是程序员，所以平时听他开会，偶尔聊一聊遇到了什么难题，遇到了什么紧急bug 需要加班。

偶尔一起吐吐槽，或者在做产品设计的时候跟他交流一下是否有技术难度。

虽然不写代码，但是每天、每周都有跟程序员沟通，也很难把代码忘光光。

除了自己的亲人朋友，也可以多跟团队里的程序员们聊天，如何跟程序员开启话题可能也是需要锻炼的技能。

3）偶尔写一写小工具

6月份尝试鼓捣视频号的时候，需要批量生成一些视频，为了提高效率，就用 python 改了别人的一个小工具。

当时的感觉就是，不做程序员技术也能帮得上忙，真好~

但需要注意的是：一定不要陷入代码里，你只是为了完成自己的需求，不需要刻意追求代码的扩展性、复用性、可移植性……

二、「产品技能」熟练度增加

这里之所以强调是 “产品技能熟练度”，原因是在我看来，工作的这 10 个月，还谈不上产品能力的提升，更多的是产品技能的运用。

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

1. 撰写 PRD

PRD（Product  Requirement Document）产品需求文档。

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

为了写好 PRD 我翻阅了「产品星球」里所有有关PRD 的资料，浏览了「人人都是产品经理」不下 20篇相关的文章，但依旧不知道怎么写。

因为当时我脑子里有两个矛盾点：

1. 我应该参考前辈大佬们的方法，写出一篇看起来专业、详细、正确的PRD。
2. 那些文章挺好的，很详细，但是开发“看不懂”（不会看）。

我在做开发的时候就很讨厌读满是文字的PRD，感觉比较浪费时间。倒不如把所有的功能架构都列清楚，给一个可交互原型清晰来得直接。

因为没想明白，再加上我们团队人比较少，大家沟通能力也都没问题，所以写 PRD 就一直没实施，我们通过原型+流程图完全可以满足项目管理需求。

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

团队人员改变之后，发现没有 PRD 是不行的，因为口头沟通的需求没有证据，中间有问题不及时反馈，开发会出现过度自我发挥，发挥完还记不得自己为什么那么做的情况。

所以，我就开始用 PRD 来做产品需求的约束和留档了。

2. 制作原型

因为我个人比较喜欢可视化相关的工作，所以画原型在我的产品进阶之路上一直不是难题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 撰写交付 & 宣传文档

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、心态变化

上一次写转型的文章，标题是《转型产品 2 个月，我还没去掉程序员的傲慢》。

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

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

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

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

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

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

五、关于职业规划

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

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

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

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

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

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

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

我选择了后者。

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

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

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

六、写在最后

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

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

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

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