码了六年代码，我为什么选择转岗做产品经理？

本文主要是介绍码了六年代码，我为什么选择转岗做产品经理？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

过去一年，我完成了迄今职业生涯最大的一次职业转变，从熟悉的开发转岗到了陌生的产品。身边不少朋友都表示不理解，毕竟已经码了六年代码，为什么不继续深耕技术，而选择转岗。

其实我也认真思考过这个问题，但之所以决定转岗，是因为我发现自己遇到了职业生涯的瓶颈：随着年龄的增长，精力不如以前，而技术革新的太快，需要随时学习新的技术，所以我这才有了转岗的打算。

而最终下定决心转岗成一名产品经理，是我结合自身情况做出的重大决定：

相比每天持续敲代码，我更喜欢并擅长与人打交道
开发转产品具备天然优势
产品经理后期发展上限较高，甚至能为后期自主创业打下一定的基础

但是，转岗后的生活并没有我想的简单，有过挫败，有过迷茫，有过无助，但所幸都找到了解决方法。这一年来我的心态和思维都不断地在发生变化，所以，我也想将自己的转型过程分享出来，希望能够为计划或正在转型的朋友们提供一些参考。

技术优势，不言而喻

开发转型做产品经理，优势不言而喻。

首先是逻辑思维能力，至少我接触的大部分技术，逻辑思维都比较强。往往在实际的研发过程中，技术能够指出一些产品经理没有考虑到的边界情况以及逻辑漏洞。毕竟作为程序员，逻辑思维不强，做出来的功能一定是一堆bug，所以这也可以算是一种“职业病”。

另外一点优势就是懂技术的产品经理工作起来会更加游刃有余，一方面能更顺畅地和开发人员沟通，另一方面在进行设计产品时就会考虑实现某个功能的难度和周期，不会给自己和团队乱接需求。

正是因为有这两点优势，能让我在日常工作中不断积累信心，从而顺利度过转型的阵痛期。

转换思维模式

转岗后，我发现之前的想法过于简单了。在这一年中，我的思维不断地被打破、重组。总结起来，我经历了三次思维转变：工程思维——功能思维——产品思维。

当我的身份切换成产品经理后的一个月，我就发现自己陷入了工程思维的漩涡。为什么这么说，因为当我在设计产品时，第一出发点是技术实现层面，通过实现的难易程度去定义和设计产品。这么做最大的弊端在于脱离了现实，脱离了用户需求和实际场景，变成了为了实现而设计。比如，在设计一个电商项目时，我首先考虑的是高并发和支付安全等技术细节，很容易忽视了用户的体验，导致整体体验不太流畅。

当解决了这个问题后，我又进入了第二个阶段，功能思维。因为之前总爱站在技术的角度看产品，这时当我开始从用户的角度来设计产品时，我又开始陷入了一个功能设计的怪圈，始终纠结于产品功能的本身，而忽略了其业务目标和业务价值，导致我设计的产品实用性并不强。

而后的半年中，我开始逐步站在业务的角度去思考产品，我会认真考虑：在实现一个正确功能的前提下，这个功能背后的业务目标是什么，怎样设计才能保证最终产品是具备可用性的。于是，我进入了第三阶段，产品思维。

其实这个阶段才是一个真正的产品经理应该有的思维方式，需要在充分理解企业战略的前提下来完成产品定义和设计，并且以围绕业务场景来提升产品的可用性和易用性，从而提升用户的整体体验。

我用了整整一年的时间来转换思维，现在的我仿佛打通了任督二脉，对产品有了更深的理解。

摸索一条适合自己的产品学习之路

在这一年中，我慢慢摸索出一条高效的产品学习之路，我分为两点介绍，其一是就产品经理自身的专业技能而言，其二是积极与团队配合，共同推进项目落地。

深入业务场景

在规划产品时，产品经理需要对业务流程进行全盘分析，只有深入业务场景后，才能保证项目在后期运营中，能实现资源的最大价值。

比如，客户突然提出需要追加消息社区功能，仅因竞品中存在这个功能，但是你亲自去线下门店了解调研并访谈了大量用户后，发现目前最紧急且必要的功能是上线商城页面，如若还要加入消息社区，不仅会分散资源，还会影响上线进度。基于这个原因，最终你说服了甲方暂缓这个功能。

这就是产品经理在深入业务场景后，对产品功能提出的专业性建议。

锻炼自己更强的沟通与协调能力

这一点算是产品经理需要具备的软技能。众所周知，产品经理除了需要跟老板/甲方保持沟通外，还需要和设计、开发、测试等岗位协调配合。在这样的环境中，产品经理务必要锻炼自己的沟通与协调能力，成为推动项目成功落地的动力。

于我的经验而言，我发现将整个协作流程放在线上更能高效的推动项目前进，使每一步流程都更加具体、透明。使用专业的协作平台能很好地辅助我的工作，市面上的协作平台我都有尝试使用，最近用的比较多是摹客协作平台。通过借助摹客，不仅能让我清晰的了解当前项目的进度，而且能与UI设计师和技术的沟通更加高效简洁。从整体体验来说，摹客相较其它平台，功能更加全面。