鹅厂运维汪转产品狗的幸（kan）福（ke）之路

1）入行门槛低

相对于业务运维岗位来说，这个岗位并没有带很多硬性的技能指标，但是真正做好却是非常的难。

之前和同行交流新同学入行后基本会有三座大山：产品化思维、做产品的能力、行业产品的感觉。

其中做产品的能力还相对是可量化的 一 些指标，但产品思维与感觉根本无法量化。

2）背锅之王

大家都说每个产品经理都是 一 个潜在的CEO(乔帮主、龙哥、雷军、红衣教主等行业大神)，但是PM同时也是 一 个全能的背锅侠，而且是360度无死角的背锅。

1)市场调研分析

主要是调研分析大的商业环境怎么样？蛋糕够不够大？这个额度的蛋糕能持续吃多久？蛋糕还能不能增大？行业内现有哪些重量级的玩家？有哪些成熟的商业化的竞品？我们的客户有哪些？这些客户拥有哪些共性、细分、潜在的需求？

这部分对刚入行的产品经理来说是蛮难的部分，感觉无从下 手 。我那时也是套 用 兄弟部门成熟团队给老大们做的汇报PPT，照葫芦画瓢拆解着做。特别是大环境分析相关，如果没有BI （商业智能） 团队的介入，基本搞不定。就算可以参照 一 些行业数据，也无法保证其有效性和准确性。

2）产品规划

规划产品的定位，确定 用 户群体分类(是谁 用 )与场景( 怎么 用 )，在这部分 一 般都是输出产品功能地图(思维导图)，能说明白讲清楚就可以了。

3）产品设计

定义产品体验和价值、设计产品结构和功能。 在这部分就要输出整个产品(功能)的原型设计了，整体产品体验与功能点的框架在这里都通过原型展示。

建议尽量输出带基本交互的产品高保真原型，这样 一 是内部评审时更加清晰，而且也可以减少后期与开发兄弟的沟通成本。

4）需求文档

配合原型 一 起讲述组成功能集的明细需求的文档(TAPD)，可以让开发兄弟提供他们认为最便于他们理解的结构，产品经理填充内容即可。

5）需求实现

与开发同学 一 起紧密配合与沟通，共同完成需求的开发与上线。

6）产品验收

开发完成与自测后，产品经理来做主体功能的验收，这里主要是验收业务逻辑是否符合产品经理的设计。至于产品质量暂时不在这里考虑，那个层面主要是测试和开发 一 起来保证的。

7） 用 户 手 册与场景描述视频

用 户的帮助说明 文 档。 用 户 文 档这部分其实也可以分为产品 手 册与典型场景 文 档，典型场景 文 档是产品 手 册的 一 个子集。不过通过后续的交付来看， 用 户基本都是不怎么看 文 档的，所以我们同时也录制了场景使 用 视频更方便 用 户使 用 。

8）迭代优化

收集分析 用 户的反馈，挖掘优化点与新需求。对产品进行迭代和优化升级。

1）会 用 工具

a.Axure RP（产品原型绘制）

b.Xmind(思维导图)

c.Visio(画业务逻辑流程图)

2）思维能力

a.抽象思维能力

b.结构思考能力(逻辑思维能力)

c.逻辑能自洽

3）能说会写

a.能在产品整个设计与落地过程中和不同的人不同的角色把事聊明白聊透。

b.面对 用 户介绍的时候能讲 用 户故事并且能把 用 户故事讲圆。

c.写出你的团队成员和 用 户能看明白的 文 档。

4）懂点设计和交互

a.避免设计出反人类的交互流程

b.页面更好的布局

5）懂点技术

a.这里并不是说要很懂，毕竟不是开发同学，而是说有 一 定的技术背景和开发能聊到 一 起。

b.避免 自己 被开发同学打入狼坑。

6）行业业务能力

例如我是做业务运维出身的，那我就明白运维是做什么的？运维要怎么做？运维需要什么样的工具平台。

7）懂点数据分析

知道 自己 需要什么样的运营数据去作为后续迭代优化的基准。

8）懂点项目管理

思维能力、能说会写、行业业务 是核心能力，其余是基础能力。

1）优势

• 熟悉运维流程，知道运维产品的痛点需求（潜在需求挖掘）。

• 主导过运营系统建设，了解 一 些系统和功能落地的基本方法（潜在功能理解）。

• 自己 看过与 用 过不少运营系统（潜在竞品分析）。

• 和开发打了多年交道，知道如何与开发沟通（潜在协作沟通）。

• 懂点项目管理（直接项目管理能力）。

2）劣势

• 没有完整的经历过 一 个商业化产品从0到1的完整流程。

• 不熟悉调研。

• 不熟悉拆 用 户。

• 不熟悉原形。

• 不熟悉PRD。

• 不熟悉竞品分析。

3）阶段重点

基于 自己 的劣势，我将该阶段内的重心放在了全面提升产品能力之上。 主要涉及的领域就是：画、看、读、动、拆、跟六大步 。

• 画：熟悉Axure RP，临摹别人的系统，对着画原型。有时间就会对着公司级平台系统画，这个收获不 小 。画是理清思路和熟悉基本页面交互的好方法。

• 看：多看些外国人的产品，看看外国人是怎么做的。有些看了是理解不了的，不过没有关系，有印象就好，后面总会有机会再去印证的。

• 读：多看看书，看方法论的书＋具体指导的书。

• 动：开始着 手 试着做竞品分析，哪怕分析的很稚嫩，多来几遍， 自己 就会渐渐的有感觉了。

• 拆：当时 手 上已经有要完成的功能模块了，在具体开始前先对照内部的平台，去尝试拆解业务逻辑。

• 跟：跟需求，保证需求如期并符合设计地落地。

（4）踩过的坑

认为做后台管理运营系统的经验就是做商业化产品的基础，其实这两者的差别很大。 内部运营系统有人 用 ，不代表是你做得好，而可能仅仅是你的目标 用 户没有别的选择； 内部运营系统多数只是在做需求而不是在做产品，需求的加法在内部运营系统上体现 比 较深，而产品是要减法多过加法（聚焦、延伸、扩展、投入产出 比 等）。

刚学着入门的时候，没有能力去分辨 自己 所了解的方法论与流程是否适 用 于 自己 工作的场景，容易给后面的路埋下雷。

1）该阶段的重点

• 了解与熟悉商业化产品从0到1的规划与落地流程

• 做好竞品分析，在第 一 阶段竞品分析都是 比 较浅的，这里我用剥洋葱法分析竞品功能，网上也有很多做竞品分析的方法，大家也可以参照：

  分析用户群体

  分析用户场景

  分析用户故事

  分析用户功能点、使用频率

  分析现有功能覆盖面

  分析所传达的理念

• 二八原则（20%的功能能满足用户80%的使用场景）

• 接近用户、发现需求，并思考共性场景。

• 不能只能听用户的，甄别伪需求，思考用户真正的需求是什么？

• 确定产品功能做多少？功能优先级是什么？

• 做好业务逻辑构思与交互体验

2）当时踩过的坑

• 不擅长砍需求与合并需求，贪图大而全，技术人员思维，总想着做全面，不要遗漏场景

• 不善于定位需求的目标、目的与需求完成后的分析

• 过分注重产品交互体验

• 追求需求场景与表现形式的趋于完美

该阶段的重点

要抓住核心流程，掌握与应 用 MVP原则。MVP是 一 个过程，且是 一 个持续的过程。做好取舍与平衡，不该做的 一 定不要做，浪费人力。对于初创团队，我们 一 直在做的就是和时间赛跑。需求是做不完的， 一 定要想清楚再做。

• 设计规划：产品的可 用 性。

• 研发生产：产品的可行性。

• 销售：产品的价值。

  
  

上面这三个阶段是我个人目前的升级之路，后面的路还很长， 自己 也在慢慢琢磨，等以后悟到了，并能应 用 到实践中，再和大家交流。

1）老板需求，相信每个产品同学都会遇到；

2）客户反馈的需求，客户场景下的定义(撇开伪需求)；

3）产品主线的需求，负责产品线的同学根据信息规划而来的，认为产品主线 一 定要做的功能点；

4）签单需求，为了打单 一 定要做的需求；

5）合作伙伴的需求；

1)多看： 多看行业，多看竞品。

2)多听： 多听第 一 手 的客户声音，如果不能直接和客户交流，那么信息来源渠道也要是高保真的，不能有过多的失真度。

3)多想： 多思考 用 户故事、产品价值、产品蓝图。哪些 一 定要做，哪些 一 定不做，那些暂缓些做。

4)多说： 多和同行们交流。

5)多试： 有度尝试，失败的成本是团队所能承受的，而不是把客户搞丢了。

6)清零： 避免思维定势。

1)自high： 自己 觉的很OK，趋向完美，其实没人 用 。

2)没想清楚就动 手 ： 这种没想清楚的行为 一 定会为之后的事情埋下非常大的坑。

3)过度坚持： 除非你已经很牛了，大家公认的产品大牛，否则还是兼听则明的好。

4)功能大而全： 多多想想MVP原则吧。

5)细节是魔鬼： 当负责产品线的时候，更多的应该考虑全局方向，而不是 一 个个 小 细节。 不是说细节不重要，而是细节可以通过后续的迭代完善。