如何从业务运维转岗至产品岗
作者分享了自己如何从业务运维转岗至产品岗，以及在此之后对工作的一些总结与思考，希望本文能够对新晋的PM带来帮助。
写这篇文章的初衷是想总结下自己从业务运维岗转到产品经理岗后，大半年来如何从“零”开始摸爬滚打过来的经历，同时作为一个新入行的产品同学对产品经理这个岗位与如何做2B产品的一些理解和思考！ 如果把这篇文章当做一个产品需求的话，那么这个需求中的角色与场景是什么呢？
对自己这个新产品同学大半年的一个梳理与总结
已有若干年工作经验积累想转产品岗的非产品岗同学（例如PM、开发、运维）。您可以从本文中获知产品经理是干什么的？需要那些能力？ 产品经理这个活要怎么干？
0-1岁的产品新同学，我们相互印证、借鉴、交流、提高。您可以从本文中获知一个新入行的产品经理在没人带的情况下这一路的成长路径与踩过的坑，说不定也可以帮您绕过这些坑！（建议阅读起点与在路上这两个章节）
有c端产品经理经验，刚进入2B端产品的同学。您可以从本文中获知同样一个作为新入行的2B产品经理，对2B产品的小理解，说不定这些小观点可以帮助到您！
起点
先做一个简单的自我介绍，加入腾讯后，一直是在手Q的业务运维岗位，负责手Q的产品运维，话说这个岗位和产品打交道最多的场景，那应该就是因为活动与产品功能导致的资源需求问题与产品经理PK了。
在转岗之前自己对产品经理这个岗位的理解其实也是很懵懂的，去年下半年中心试水成立做对外运维产品的团队，目标是让我们内部多年打磨的DevOps最佳实践平台织云走出去（团队的全体成员都是业务运维岗位出身），就摇身一变成了产品狗。 当时想着没吃过猪肉，还没有见过猪跑了，毕竟也带过内部运营系统的规划与熟悉运维所使用的运营系统，后面的经历充分验证了一句话无知者无畏！
-
这里先按序理清一些基本概念
产品是什么？
产品经理是个什么鬼？
2B产品经理的价值是什么？
产品经理的工作内容包括哪些？
产品经理需要那些能力？
产品团队有哪些角色构成？ -
产品是什么？
产品是指能够提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。
是不是觉的有点小抽象？这句话的关键词是 市场、使用、消费、需求。生活化来说每天在路边买的热干面是产品、腾大12楼的包子也是产品，它们同样都满足了我们要吃饱的需求。同样手机QQ与微信也是产品，满足我们沟通与连接的需求。
- 产品经理是个什么鬼？（Product Manager）
产品经理这个词其实是一个比较宽泛的且带有一定的行业属性的词汇，这里所描述的产品经理的定义是特指IT行业或者互联网行业中的一种职能，负责IT（互联网）产品的规划和设计，以及生命周期的管理。 这句话的关键词是 规划、设计与管理 。
在《启示录：打造用户喜爱的产品》这本书中是这样介绍的 产品经理的主要任务是探索产品的价值、可用性、可行性。以前看到这句话的时候是有些似懂非懂的，但是现在回头来看，是非常认同的。
这里多说两句，产品经理这个岗位是自带矛盾属性的，而且带上经理这两个字，感觉应该是有权利的，其实毛线权利都没有！
入行门槛低，相对于业务运维岗位来说，这个岗位并没有带很多硬性的技能指标，但是真正入门与做好感觉蛮难的，之前和同行交流新同学入行后基本会有三座大山，产品化思维、做产品的能力、行业产品的感觉，其中做产品的能力还相对是可量化的一些指标，而产品思维与感觉就有点不好量化了（每个人的解读可能都不同）
也有说每个产品经理都是一个潜在的CEO(乔帮主、pony、雷军等等行业大神)，但是同时也是一个全能的背锅侠，而且是360度无死角的背锅。
- 2B产品经理的价值是什么？
一般谈到价值就会有各种大词出现，这里不说大词，用一种接地气的方式描述。笔者认为产品经理的价值用一句话就能说的明白。
帮助自己所服务的团队(公司)，设计(演化)出能满足用户需求的正确的产品，并且能直接或者辅助的真金白银的把钱赚回来。
是不是觉的有些俗气？不过产品就是这样，一个设计且落地的产品如果不能直接或者间接辅助的把钱赚回来。那这个产品其实失败的，做好的包子卖不出去都是库存，那么这些包子也都没有创造应有的价值？ 这句话的关键词是 设计(演化)、 满足、需求、正确、赚钱。
- 产品经理的工作内容包括哪些？
基于我对产品经理岗位理解与这大半年的主要工作，我总结的产品经理具体工作内容如下，其实也就是一个产品落地的主要步骤（线性顺序）。
市场调研分析：主要是调研分析大的商业环境怎么样？蛋糕够不够大？这个额度的蛋糕能持续吃多久？蛋糕还能不能增大？行业内现有哪些重量级的玩家？有哪些成熟的商业化的竞品？我们的客户有哪些？这些客户拥有哪些共性、细分、潜在的需求等。 这部分其实对刚入行的产品经理来说是蛮难的部分，感觉就是无从下手，我印象我们那会也是套用兄弟部门成熟团队给老大们做的汇报PPT，然后照葫芦画瓢拆解着做。特别是大环境分析相关，如果没有BI团队的介入，基本搞不定，就算可以参照一些行业数据，也无法保证其有效性和准确性。
产品规划：规划产品的定位，确定用户群体分类(是谁用)？与怎么用？(场景)，在这部分一般都是输出产品功能地图(思维导图)，能说明白讲清楚就可以了。
产品设计：定义产品体验和价值、设计产品结构和功能。 在这部分就要输出整个产品(功能)的原型设计了，整体产品体验与功能点的框架在这里都通过原型展示。建议尽量输出带基本交互的产品高保真原型，这样一是内部评审时更加清晰，而且也可以减少后期后期与开发兄弟的沟通成本。
需求文档：配合原型一起讲述组成功能集的明细需求的文档(TAPD)可以让开发兄弟提供他们认为最便于他们理解的结构，产品经理填充内容即可。
需求实现：与开发同学一起紧密配合与沟通，共同完成需求的开发与上线。
产品验收：开发完成与自测后，产品经理来做主体功能的验收，这里主要是验收业务逻辑是否符合产品经理的设计。至于产品质量暂时不在这里考虑，那个层面主要是测试和开发一起来保证的。
用户手册与场景描述视频：用户的帮助说明文档。 用户文档这部分其实也可以分为产品手册与典型场景文档，典型场景文档是产品手册的一个子集。 不过通过后续的交付来看，用户基本都是不怎么看文档的，所以我们同时也录制了场景使用视频更方便用户使用。
迭代优化：收集分析用户的反馈，挖掘优化点与新需求。对产品进行迭代和优化升级。
- 产品经理需要那些能力？
基于上文的产品经理主要工作内容，我们就已经基本可以勾勒出一个产品经理需要那些能力，3+N能力模型 3个核心能力+N个基础能力。
会用工具
Axure RP（产品原型绘制）
Xmind(思维导图)
Visio(画业务逻辑流程图)
思维能力
抽象思维能力
结构思考能力(逻辑思维能力)
逻辑能自洽
能说会写
能和在产品整个设计与落地过程中和不同的人不同的角色把事聊明白聊透。
面对用户介绍的时候能讲用户故事并且能把用户故事讲圆。
能写出来你的团队成员和用户能看明白的文档。
懂点设计和交互
避免设计出反人类的交互流程
页面更好的布局
懂点技术
这里并不是说要很懂，毕竟不是具体的开发同学，而是说有一定的技术背景和开发能聊到一起。
行业业务能力
例如我是做业务运维出身的，那我就明白运维是做什么的？运维要怎么做？运维需要什么样的工具平台。
懂点数据分析
知道自己需要什么样的运营数据去作为后续迭代优化的基准。
懂点项目管理
思维能力、能说会写、行业业务能力 这三个是核心能力，其余是基础能力
7. 产品团队由那些角色构成？
一个完整的产品团队会有以下角色构成：
产品经理
设计(视觉与交互)
技术(前台、后台、测试、售前、售后)
运营
市场
商务
PM
我们这个团队在刚开始的时候，就只有我和另外一个同学两个产品经理，两个人共同负责织云自动化平台产品线的设计与落地，其余均是部门内的运营开发同学。那会开玩笑说，我们和创业公司的唯一的区别就是我们不会破产，不用担心发不出来工资，其余都是和初创公司都是一样一样的。不过这么一路走过来看，在初中期其实只要有三个角色（产品、开发、设计）就基本可以跑起来了，团队小了最大的好处是沟通成本极低，就这些枪没有什么问题不是站立在白板前讨论不清楚的，然后就直接do，遇到问题在讨论！
通过上文，想转岗的同学与产品新同学已经可以比较清晰的知道产品经理具体是干么的？与一个产品落地的主要步骤有哪些？
在路上
其实做产品与当产品经理和打游戏一样，一路也是升级打怪，层层升级的过程。下面讲讲我这大半年的收获与踩过的坑。一般来说成熟的团队会有导师带你走，但因为我们是初创团队,团队里面没有真正的产品经理，大家都是边做边学，所以更多的就是靠自己了悟了。可能我的经验更适合自己走的同学。
一、小学：找入门的路（画看读动拆跟）
该阶段是刚入行，对于整体商业化产品落地的流程不熟悉，基本是两眼一抹黑。在找寻入门的路时，我自己有哪些优势和劣势呢？
- 优势：
熟悉运维是怎么做的？知道运维的痛点（因为团队输出的是运维平台产品）
主导过运营系统建设，了解一些系统&功能落地的基本套路
自己看过与用过不少运营系统
和开发打了多年交道，知道如何与开发沟通
懂点项目管理
- 劣势
没有完整的经历过一个商业化产品从0到1的完整流程
不会画原形
不会写PRD
不会竞品分析
- 该阶段的重点
画：熟悉Axure RP，临摹别人的系统，对着画原型。那会有时间的时候，就会对着公司级平台系统画，这个收获不小。画是理清思路和熟悉基本页面交互的好方法。
看：多看些老外的产品，看看老外是怎么做的。有些看了当时的段位是理解不了的，不过没有关系，有印象就好，后面总会有机会在去印证的。
读：多看看书，看方法论的书＋具体指导的书
动：开始着手试着做竞品分析，哪怕分析的很稚嫩，多来几遍，自己就会渐渐的有感觉了。
拆：在当时手上已经有要完成的功能模块了，在具体开始前先对照内部的平台，去尝试的拆解业务逻辑，想想为什么要这样做？这样做覆盖了那些场景？不这样做会有什么样的影响？
跟：跟需求，保证需求如期并符合设计的落地。
- 当时踩过的坑
认为做内部运营系统就是做商业化产品的基础，其实差别很大
内部运营系统有人用，不代表是你做的好，而可能仅仅是你的目标用户没有的选择，只能用这个。
内部运营系统缺少版本化规划（产品路线图）、运营与硬性质量指标要求。
内部运营系统多数只是在做需求而不是在做产品，需求的加法在内部运营系统上体现比较深，而产品是要减法多过加法（聚焦、延伸、扩展、投入产出比等）
刚学着入门的时候，没有能力去分辨自己所了解的方法论与流程是否适用与自己工作的场景，给后面的路埋下雷。
二、中学：练手&熟悉（负责功能模块）
通过第一阶段的打基础，可以说已经基本了解了些做产品的基本套路，也摸过一些小需求了。可以开始逐步上手完整的功能模块规划与落地了。
- 该阶段的重点
了解与熟悉商业化产品从0到1的规划与落地流程
做好竞品分析，因为在第一阶段竞品分析都是比较浅的，这里我总结用剥洋葱法分析竞品功能，网上也有很多做竞品分析的方法论，大家也可以参照：
分析用户群体
分析用户场景
分析用户故事
分析用户功能点使用频率
分析现有功能覆盖面
分析所传达的理念
二八原则（20%的功能能满足用户80%的使用场景）
见用户、发现需求，并思考共性场景。
不能只能听用户的、甄别伪需求，思考用户真正的需求是什么？
确定产品功能做多少？功能优先级是什么？
做好业务逻辑构思与交互体验
- 当时踩过的坑
不擅长砍需求与合并需求，贪图大而全，技术人员思维，总想着做全面，不要遗漏场景
不善于定位需求的目标、目的与需求完成后的分析
过分注重产品交互体验
追求需求场景与表现形式的趋向完美
三、大学：全局视野与产品线规划（重点思考如何做减法，定义产品主线）
到这个阶段后，基本就可以尝试hold住整条产品线了，这个时候更多的是要想清楚如下的问题：
产品线大的目标与蓝图是什么？
大的用户故事是什么？
在这个阶段更多的思考不是简单的需求叠加了，而是要在产品路线图上清楚每个功能点的价值与意义了，需要把各个零散的点串起来。
想清楚在每个大的时间点(版本交付时间)要做什么？不要做什么？做了的价值在那里？不做会影响什么？
版本与版本之间的功能闭环如何做？如何保证全局逻辑自洽？
版本与版本间的递进如何勾勒？
- 该阶段的重点
掌握与应用MVP原则，MVP是《精益创业》里提出的概念，其实概念大家都好理解，但是落地的过程中就会有各种坑了。
要抓住核心流程，MVP是一个过程，且是一个持续的过程
MVP不是一个单一的产品形态
带着明确的目标去做MVP
尽量多用轮子(尽量尽可能的借用现在成熟的内部模块，跨团队与外部友商都OK)，对于我们一个非成熟的团队来说，尤为关键，不可能什么都是自己做，都自己做只能把自己累死。
做取舍与平衡，不该做的一定不要做，浪费人力。 对于初创团队，有时候就是和时间在赛跑。需求是做不完的，一定要想清楚在做。
版本的规划与迭代
用户故事的演化
产品(功能)的生命周期：
设计规划：产品的可用性
研发生产：产品的可行性。
销售：产品的价值。
运营
市场反馈
上面这三个阶段是我个人目前的升级之路，后面的路还很长，自己也在慢慢琢磨，等以后悟到了，并能应用到实践中，在和大家交流。
四、需求池管理
想了想还是单独把需求管理拎出来写，为什么？因为需求管理其实是在后面两个阶段会一直贯穿，而且也蛮重要的。
- 需求的来源分类
老板需求，相信每个产品同学都会遇到
客户反馈的需求，客户场景下的定义(撇开伪需求)
产品主线的需求，负责产品线的同学根据信息规划而来的，认为产品主线一定要做的功能点
签单需求，为了打单一定要做的需求
合作伙伴提的需求
这5类需求我都碰到过， 那么这5类需求有好与坏或者合理不合理之分吗？ 现阶段我感觉其实没有，每个需求都有自己特定的固化场景产生的背景和特定的目标。这几类需求肯定在时间或者功能上有冲突。而这个时候做什么不做什么就需要产品同学和团队一起讨论评估了,产品经理首先要想清楚。需求管理是一定要做的，要不产品经理就是救火队员(总是在做迫在眉睫的事情，会令人丧失目标的)，不但产品线混乱，最后整体出来的东西也是一个四不像，可能产品经理自己都晕了。
详细的需求管理方法论大家可以阅读《普拉姆原则》，这里提供一下我基于这个方法论和实践总结出来的一个需求分析模板。
需求提交公司优先级是说当你有多个客户的时候，对每个客户重要性的定义。
为什么要有客户公司内部职务呢？因为不同职务提的需求有时候会影响打单的，例如 客户CTO提的需求和一线员工提的需求就不能等同而看，这是现实！
还有一点因为不好客观度量，所以未在表格中呈现，那就是销售对客户的控制度，也就是在打单的时候销售有多少把握搞定。
5、产品经理的自我修炼
现阶段我感觉产品经理的修炼，用6个词就可以总结。
多看：多看行业，多看竞品
多听：多听第一手的客户声音，如果不能直接和客户交流，那么信息来源渠道也要是高保真的，不能有过多的失真度。
多想：多思考用户故事、产品价值、产品蓝图。 那些一定要做，那些一定不做，那些暂缓些做
多说： 多和同行们交流
多尝试：有度尝试，失败的成本是团队所能承受的，而不是把客户搞丢了
清零：避免思维定势
同样产品经理要避免的几个坑
自high： 自己觉的很OK，趋向完美，其实没人用。
想清楚在动手： 避免给产品埋下有明显的逻辑缺陷或者功能与功能之间不能逻辑自洽，宁肯有时候压节奏，也要想清楚。
过度坚持：除非你已经很牛了，大家公认的产品大牛，否则还是兼听则明的好。
功能大而全： 多多想想MVP原则吧
细节是魔鬼： 当负责产品线的时候，更多的应该考虑全局方向，而不是一个个小细节。不是说细节不重要，而是细节可以通过后续的迭代完善。
一起修炼2B吧
作为一个新入行的2B产品经理，我的工作也都是围绕着打造织云而展开的，织云是金融行业企业级的运维管理平台，是一款典型的TOB产品。
- 2B产品特征
解决一个个工作中的具体的问题，或者将现有流程系统化从而提高效率
用户具有一定的行业专业背景、并且在交付前会有对用户的专业培训
容错率很低，试错成本也高（2C端的小步快跑，快速迭代，几天或者一周一个小版本目前感觉不太适用）
对产品本身的质量要求很高，如果因为平台质量而导致客户业务失败或者现网故障，那是绝对大事件。
运维平台提供的功能要齐全，该有的功能一定要应有尽有，那怕刚开始每个功能的深度都不是很深。B端用户更看重一站式解决方案，而非多个平台混用，多平台企业整体IT成本和用户学习成本都高。
相对C端B端更轻体验与交互，刚开始挫一点丑一点问题都不大，只要交互流畅能顺利完成即可，B端用户在交互体验的容忍度是蛮高的，原因还是平台核心还是要完成一个个具体的工作任务。
之前听到一个销售说的一句话，一个好的2B产品就是能帮助所使用这个产品的用户打好他那份工，也就是说2B的产品要靠谱，非常认同这句话！
- 2B产品设计思路
设计产品的业务逻辑要求高，业务流程的上下文关联性强
业务规则复杂，场景更加细分
功能要先横向堆面，在纵向挖掘深度，该有的功能一定要有节奏的上，大功能方向上面要能闭环
在多数场景下，功能的完善与质量永远优先于交互体验(视觉)等，这里不是说体验不重要，而是说2B产品优先要帮用户把活干完。
设计时要多角色，例如一个大平台从组织架构这个维度上看，基本会有三个角色，一线干活的员工、中层管理、高层管理者，他们对于平台的视角不同，所期望的功能也不同。
权限要明细，不同的岗位在平台里面应该具备不同的权限。
管理用户预期的操作行为
简化用户的操作成本
- 踩过的坑
过分重视交互体验，耗费了不少时间与精力，我现在设计的一个基本原则是流畅的完成既定操作与操作流程设计的不是反人类即可，至于多点一下鼠标，少点一下鼠标与别的交互细节问题不大，而且交互本身也是要靠时间去打磨的。
业务逻辑不清晰，单纯的功能点逻辑不能闭环。
总结
产品经理的修炼之路很长，成长为一个优秀的产品经理也是蛮难的。想要做下去一定要保持对产品的热爱，好奇心，多琢磨不同的产品，多思考。产品经理是个蛮有意思的岗位，特别是当你看着一个产品从无到有，在逐步的被用户认可，这是一个很有成就感的事情。
书单
附上我阅读过的产品经理相关书籍，并给出一点点小的建议。话说现在市面上2C的产品书籍很多，而2B的就很少了。
《杰出产品经理》 有干活的指导意义，书中的一些方法论可以直接套用
《人人都是产品经理》现在应该是2.0了，有干活的指导意义，书中的一些方法论可以直接套用
《简约至上》 我买的时候，就已经印刷了25次了，可以让你知道与应用交互设计的基本原则与方法论
《启示录：打造用户喜爱的产品》 比较全面与有高度的方法论，同时也涉及到团队打造
扫一扫
219
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
