为何大多数程序猿会转行做产品经理的？背后的原因有哪些？

为何大多数程序猿会转行做产品经理的？背后的原因森源有哪些？下面就我们来针对这个问题进行一番探讨，希望这些内容能够帮到有需要的朋友们。

“我是一名程序员，想转做产品经理，改行求业难度系数大吗？”小G在某互联网技术社交网络平台上提出问题。在程序员这一人群中，有小G这类念头的实际上并不在少数，大部分搞程序流程的人，除非是对程序编写真的是发自内心衷心的喜爱，要不然一定会在职业发展的某一个环节感觉产品经理是一个特别出色且相对性专业对口的发展方向。

还记得先前和一位程序员好朋友闲聊，他说道程序员想转产品经理汇总出来无非就四个原因：第一，做技术性又累又枯燥乏味，并不是真的喜爱写程序的人难以在这个行业有很大的造就；第二，觉得做技术性较为低贱，要被产品经理各种各样摸透；第三，爱慕虚荣作怪，产品经理好赖是个“主管”，程序员顶多便是个农民工；第四，自身掌握怎么写代码，了解要求完成的途径，往产品经理转有着先天性的优点。

写作到这儿，我迫不得已给诸位程序员朋友泼个水，千万别由于“主管”这两字添加这一领域，也千万别小看了产品经理这一职位，不然进去以后你也许会被暴打。

实际上，产品经理并不是只需懂技术性就到达了出道的规范，其职业发展目标是为商品的一整个生命期承担，从需求分析到设计产品到要求审查，再到项目风险管理、结果总结，这种阶段都必须产品经理去核心把控。除此之外，产品经理还需要按照设备的生命期，融洽产品研发、营销推广、经营等，明确和组织实施相对应的市场营销策略，及其其它一系列相应的产品经营主题活动。

不难看出，产品经理这一职位必须相应的职业素质，技术专业的知识与技能，不同寻常的岗位职责，且必须按照不一样工作中情景饰演者不一样的人物角色，可以称之为是综慧纳合性优秀人才，非通过多年学习培训实战演练不可以担任。

“产品经理新手入门很容易，可是要想搞好则是十分难。”先前大家荣幸邀约到贝壳找房产品总监刘炯来干了一场有关产品经理的直播分享，在共享最终他也针对从程序员转产品经理发布了一些见解。

“与别的岗位对比，从产品研发转商品的确有先天性优点，因为你了解这一需要的建立途径。但这一优势通常也成为了一个特别大的挑战，在你来想产品方案时，会特别关注这一要求怎样完成，这一侧重点方位就产生了误差。假如你准备从产品研发转商品，一定要将你的优点忘记，你需要潜心去想要做这件事情是不是有效，并非关心它是不是能完成换句话说它的完成逻辑是什么，你不能被‘实现的概率’拘束住‘对商业本质的探索’。”

那到底哪一类目的产品研发转产品经理会更易于获得成功呢？刘炯直播间中也得出了一个回应，“现在我关心到好的的产品研发转商品十分顺利的，大多数是中后台管理商品此碧态。由于这一商品方位对思维逻辑规定很高，或是要化解的问题大多数是相对性可预测性的问题，相对而言合适产品研发开展产品经理的改行。”

初中级产品经理的完整工作流程

一、用户调研

用户调研分为定性分析和定量分析。定性分析是指用户访谈，定量分析是指调查问卷。

用户访谈。当然访谈需要一定的技巧，更多的倾听为主，以了解用户的内心想法为主。访谈时对用户的初步回答反复追问“为什么”，引导用户从表面的行为开始思索，清理出行为背后的动机、需求乃至价值和文化观念。

调查问卷。问卷调查是一项有目的的研究实践活动，设计的问卷是为你的特定研究目的服务的，这是设计问卷之前必须植根于脑海中的一个观念。既然问卷调查是一项有目的的研究实践活动，那么从理论指导实践的角度出发，在设计问卷前必须要做好充足的理论准备，宏观层面上应做到以下两点：1.明确你们研究的主题是什么 2.明确你们想通过问卷调查获取的信息有那些。通过调研问卷你可以定量的验证你提出的需求。

二、需求的收集，建立自己的需求池

收集各个部门的需求，建立自己的需求池。并定期对需求池进行整理。你的需求池里面有不同人提出的需求。

定期对需求池做一定的梳理 。产品部门定期读需求池进行整理，那些需求是下一步要做的，那些需求是是可以暂缓的，那些需求是不做的，对需求池进行梳理和分类。

不同终端的需求裂明悔要分开 。分为APP、PC、微官网、前台、控台这些。

三、产品迭代前写一份立项报告

通过对需求池的整理以后，你决定要做那些不做那些。需要出一份立项报告和技术部门过一下，这样技术    可以安排开发周期。技术也可以从技术的角度给一些意见说那些可以做，那些可以暂时不做，这样技术在开发之前有一个心理预期，这样在你开原型评审会的时候阻力会小很多。这里教给大家一个小技巧：做立项报告的时候可以多写一些需求，这样多一些的需求可以给技术砍。

四、竞品分析

俗话说知己知彼，百战不殆。你做的东西别人也在做，买东西都还需要货比三家呢。做竞品分析有两个目的，第一、扬长避短。吸引别人做的长处，发现别人做的不足的地方。第二、验证与测试。别人上的这个功  能市场反馈怎么样，有没有遇到啥问题，通过竞品确定市场机会点。

竞品分析有一定的流程。可以从“战略层-范围层-结构层-框架层-表现层”这几个层面进行分析。

战略层： 确定竞品的商业模式、产品定位、市场状况、盈利情况等，目的是确定方向，了解市场。

范围层： 竞品的目标人群，满足了什么需求，用户的满意度如何，目的是参考竞品的目标人群以及需求的重要度。

结构层： 竞品的主要功能架构、特色功能、发展模槐指式，优缺点总结，目的是寻求差一点。

框架层： 竞品主要任务流程的顺畅，交互的细节，逻辑的准确，页面的框架，目的是优化流程，提高用户体验。

表现层： 竞品是视觉风格，颜色层级，文案的运用等，目的是维持用户对这类产品的传统认知的基础上打造产品独特性。

五、原型评审肆正和PRD文档制作

竞品分析做完以后，开始根据竞品分析的结果。开始自己的功能设计，流程的绘制，在原型上加一些功能的注释，这样在敏捷开发的时候可以节省PRD文档的制作，也可以在和技术开会的时候不会遗漏自己想讲的东西。

原型评审的时候技术人员的有效意见一定要虚心接受，不要觉得自己是产品就高高在上，涉及到原则问题坚持。别人提的有益意见也要虚心接受，只有这样你才能避免死逼，项目才能尽快落地。至于PRD文档的制作。有时间的话可以写word文档，没时间的话可以直接在原型中制作文档。但文档必须包含的部分有：

1、产品版本的迭代历史。 清晰的告诉项目成员每次改变都改了那些东西。

2、需求功能清单。 有需求功能清单 的时候技术人员在开发的时候才不会遗漏，测试工程师也会根据你的需求功能单来进行测试。

3、全局结构图和重要的功能流程图不能少。 产品全局结构图相当于房子的骨架，相当于文章的目录，别人看过你的全局结构图就知道你的产品大概分成那几个部分。其次，一些重要的功能流程图需要 写，这样有助于开发人员思路的建立。

4 、异常流程要考虑清楚 。 只有异常流程考虑清楚产品经理才不会挨批，技术开发起来才不会出现问题。

5、重要名词要定义。 对于首次出现的名词需要定义，这有这样别人在看到名字的时候才不会有疑问，再跑来找你问。

五、项目管理

项目进度表。 文档交给技术开发以后，就需要制定一个项目时间表，并向领导汇报。首先要全面地收集他们在听完需求文档评审后对于产品本身的意见与建议，然后逐项予以合理的解释，以保证程序员哥哥们打心底里认同这个产品，认同这个产品的每一个需求。另外作为一个PM，也应该要对基本的开发流程有所了解在制定每个需求的开发周期时提出正确的建议，保证最终的项目开发时间表既不会拖慢整个项目的进度，也没有超出程序员哥哥们每天正常的工作量，保证他们不会感到过大的开发压力。

进度跟踪。 对于项目进度要做到心中有数，每天更新项目进度表，并帮助技术解决他们在开发过程中遇到的问题，并将自己看到的潜在问题尽量扼杀在萌芽中。当然，跟进并不是天天问工程师进度，需要给他们鼓励打气，并描述产品的未来前景，让团队中的每一个人都感受到自己的重任并愿意承担。可能有些团队里面是CTO担任项目经理，这也无可厚非，毕竟在项目成员中程序员占了大半资源，当然产品经理要尽量参与这个过程当中。不能当局外人。

六、产品上线前协助测试

大公司有明确的职位分工：工程师、测试、设计、运营都由不同的人负责，测试自然是测试工程师的事，而 在中小型创业公司，人员匮乏，很多团队只有工程师和产品经理，工程师负责开发，开发以外的事情全都由产品经理承包，这 其中自然包括测试。但无论如何产品经理都要尽量参与测试工作，保证产品是按照你的预期做出来的。

1、首先与测试组沟通协作，确定产品测试排期。

2、跟进测试进度参与产品测试。

3、将测试出来的bug记录下来，并拍好优先级，反馈给技术来发人员

功能测试是合格产品经理的必备素质，产品经理要协助测试工程师完成测试报告并敦促工程师团队改进产品。

七、产品培训和推广

给业务方培训、推广产品。 客服可能需要给用户解答问题，所以每次迭代的内容都需要给客服培训，好让客服组织话术来应对客户随之而来的一些问题。同时也需要给市场、运营等部门培训，让他们知道产品到了那些阶段，有那些改变，一是让各个部门之间知道自己正在做的事情，二也好让营销市场部门做好宣传与推广。

收集产品使用反馈，为迭代做准备。 产品上线后设计的好不好，有哪些用户满意的，有那些用户不满意的。都会有用户进行反馈，收集并分析这些用户需求，并记录在你的需求池里面，为下一次迭代做准备。

八、数据分析

产品上线后产品设计的好坏很大程度上能从数据上体现出来。例如你设计个活动分享页面，用户可以通过好友分享的界面直接注册，那么你就要统计这个页面的点击量、PV/UV、页面访问市场、访问深度、用户的跳出率、用户的转化率等来评估你设计的好坏，以及活动的效果。再比如你产品进行改版，你需要评估改版的好坏。你就需要关注30日留存率提高了还是降低了，别关注7日留存率。因为你的产品刚更新你的粉丝用户可能会很活跃，导致7日留存率变高，这个时候你说你的改版比较成功可能没有说服力，也许30日以后你的用户活跃度变低了，30日留存率也变低了。

九、总结

这就是初级产品经理的日常工作流程，每个公司可能根据自己的不同情况有些流程会有增减，但基本上是这些。

最近几年要说哪个领域最火，无疑是互联网领域，而随着互联网的火热，伴随而来的也是相应的互联网职位的火热，比如炙手可热的程序员和产品经理（或者叫程序猿和产品汪）。我也是一个刚入行不到三年的菜鸟程序员一枚，大学学了四年计算机，毕业以后就一直在写程序。就像很多人说的那样，大部分时间似乎是在为了实现产品经理的需求而写程序，于是程序猿和产品汪之间那些相爱相杀的事情，我也基本都能体会一二。

如果按照主流的做法，作为程序猿王国里的一猿，我应该挥舞起长矛大刀对产品经理口诛笔伐一番，但是这里我却丝毫不想去为了黑而黑，而是一反常态，从自己的角度来谈谈，作为程序员，我们应该从产品经理那里学到些什么能力，而这些能力，程序员往往做得不够好甚至可能是欠缺的。

1、文案能力

对的，没错，就是文案能力。程序员最擅长的是写代码，用文字符号来清晰地表达程序的运行逻辑，简简单单的if...else、for就能表达很多枯州乱复杂的运行逻辑，时间久了，对于母语的表达能力渐渐下降，写个注释往往都能词不达意。更何况现在代码风格指南都在强调好的代码不需要注释，于是程序员越来越少写自然语言了。

2、沟通能力

据我的观察，画原型图只占据了产品经理工作时间很短的一部分，剩余的大部分时间是在和老板、开发、设计、测试沟通，推进产品的一次次迭代。所以，在一个程序员眼里，产品经理是要协调各方一起推进产品上线的角色，如果有人对需求产生了认知上的偏差，产品经理是要负很大一部分责任的，至少说明产品经理的沟通没做到位，而这样的产品经理大部分都被辞退了，因为出现沟通问题最严重的后果就是上线延期甚至产品失败，一个产品的失败是对产品经理最大的否定。

总之，产品经理绝不是埋头苦干的原型画家，要去关注外界、关注他人，平衡各方利益并且化解冲突。沟通，本质上也是权衡与妥协的艺术。我看到的和遇到的产品经理，沟通能力普遍都是很好的，至少大部分都不输于程序员。

3、整体思维

现在稍微有点规模的互联网公司都会把各个业务或者功能进行细分，很多程序员往往会专注于自己的业务和细分领域。精细化分工，是现代社会发展出来的一个高效率生产方式，对提高公司的竞争力是大有好处的。但是这有一个负面的影响是，很多程序员往往过于专注自己的一亩三分地，不太关心甚至忽略了整体的存在。

4、总结

一个迹滑好的产品经理其实绝不止这些能力，而文案、沟通、整体思维这些能力是我所观察到的作为产品经理最容易被放大和辨识到的能力，也是多数比较容易被程序员忽视的能力，程序员学习到产品经理身上这些最容易被没档观察到的特质，对程序员本身来说是一个非常好的进步的过程。所以，程序员，请多看看产品经理发给你的文案，是不是比你自己写的更友好，逼格更高？北大青鸟建议多观察产品经理是怎么说服大家接受需求变动的，如果换作是你，你能安抚大家的小情绪吗？多体会产品经理对产品设计和预期的宏观描述，再简单的功能也有它背后的逻辑和存在的意义。

---