从产品助理晋级到产品专家，需要哪些必备条件？

萧羽 2023-07-24 17:23:55

笔者之前一直秉持的是写一些与数据相关的文章，但是在这个过程中（尤其是昨天深圳召开的产品经理大会上听到的）对自己进行了反思，自己对自己定位太狭隘了。正如大会上所说“在工作中你是产品经理，但是在生活中你是丈夫是父亲，我们只是在工作上的角色是产品经理而已”，所以我们不能对自己定义太狭隘，否则就会对自己束缚过大。

所以，结合着在大会上学到的内容以及自己的实践，想和大家分享下，产品经理晋级的必备条件。

一、概述

产品经理的价值是什么？引用俞军的《产品方法论》里面的话就是“产品经理是为企业创造可以与用户进行价值交换的服务”。

所以，产品经理的核心就是需要创造有价值的服务。

在这里，我们需要引申一下，产品经理我们是一个独立的“CEO”，外界所有的人，都是我们的“用户”。因此，我们不仅仅是为了“企业”的用户创造价值服务，也需要为我们产品经理服务的上下游创造价值服务。这里的上下游，笔者不再赘述，各位读者可以根据产品经理的日常工作流程自行梳理。

笔者梳理下针对各个不同的职级，产品经理需要输出的价值内容是什么？

众所周知，产品经理的路线一般是“产品助理->产品经理->中级产品经理->高级产品经理->产品专家”，而走管理路线的话一般是“产品经理->主管/经理->产品总监->VP”，由于笔者暂时没有走到“产品总监”的位置，所以笔者这次主要介绍的路线是第一条“产品助理——>产品专家”。

产品助理，一般只需要做好产品经理交代的任务，画画圆形、写写需求文档即可。
产品经理，需要的是做好产品本身的管理。
中级产品经理，需要学会向上级汇报，向领导汇报。
高级产品经理，需要学会做产品规划。
产品专家，需要深入行业，做产品战略、行业洞察、商业生态等内容。

当前的产品能力理论体系都比较成熟了，接下来将详细讲解，如下图所示的内容。

产品经理，产品经理网站

二、管理——产品经理

所论及的管理是产品经理要对当前的产品及产品团队进行统一的管理。管理分为3个方面：

1. 需求的管理

需求的管理分为两部分，一部分是需求池的管理，另一部分是需求迭代的管理。

a）需求池的管理可以根据情况，分为外部需求池和内部需求池。

外部需求池是指针对自己服务的业务人员、业务线、或者业务产品经理在使用过程中提出来的。一般他们会根据业务形态的演变、产品使用的体验度、使用问题，针对性的提出对产品的改进建议，从而形成了外部的需求池，但外部的需求池需要做的事情很多，需要对需求进行鉴别是否为客观真实存在的需求；

其次是需要根据产品的定义是否属于产品边界范围内的需求，然后是根据重要等级对业务需求进行提炼为产品需求，最后再根据产品需求进行优先级的等级排序，纳入到内部需求池。

内部需求池一般来源于两部分，一部分是外部需求池的需求清洗，另外一部分是自己的运营过程发现或者是部门的战略规划的需求。也就是说，所有团队的需求来源都是来自于内部需求池。内部需求池需要秉持的原则就是，战略布局，创造最大的价值体验进行优先排列。（ps：需求池的管理都有规范的模版，可以在底部扫描二维码私信获取）

b）需求迭代的管理则主要是对需求进行产品化和迭代跟进。

产品化的过程就是需要有一套规范的流程，包括调研（市场调研、用户调研、竞品调研）->业务逻辑需求设计->原型设计->prd文档输出->需求评审->需求计划会（对需求进行任务拆分并进行工期评估和迭代排期）->开发（有进度管理和风险管理）->上线->运营->内部需求池，从而形成一个完整的产品工作闭环流程。

这里特别说明一点，在当前的时代，产品上线并不等于结束，而仅仅只是开始。运营需要制定详细的指标跟踪和指标目标，所以在需求设计的阶段就需要定义好运营目标，如此才能方便在产品迭代过程中进行针对性的事件埋点，从而有效的了解产品的运营情况。

2. 产品质量的管理

产品质量的管理主要从两方面来理解，一方面是产品的满足场景需求的质量，另外一部分是产品本身运行状况的质量。

a）产品满足需求场景的质量，就是要确保开发完全理解业务场景。

产品经理的主要手段就是原型+prd。一般而言，需求评审和平时的沟通效果都远远小于原型+prd文档的。由于人的异质性，人与人之间的沟通存在信息的消耗，并不能准确传达出自己的思想或者无法有效get到对方的意思。因此原型+prd是最有效的样例说明。原型和prd的规范，业内也有统一的定义，这里笔者不再赘述。

b）产品本身运行状况的质量，就是产品在验收过程中，要考虑到产品在不同场景下的使用是否充分考虑了异常场景的兼容处理。

产品的容错处理搞，产品的体验度才会很好。比如让你做一个智能评测你的风险，填写了半天系统告知你无法计算你的风险，是不是有一种砸手机的冲动。

3. 团队的管理

团队的管理其实主要是对团队氛围的管理和调和，笔者有亲身感受。笔者所带的一只团队，团队氛围特别好，好到的程度是，团队内的各个成员之间都是相互帮助，对共同负责的产品都非常有主人翁的意识。

这里举一个非常能说明的例子，笔者带的团队，在6月份的重要季度迭代的时候，受到公司战略调整的影响，整个资源都彻底倾向于另外一个项目。笔者团队所有的测试资源都被抽离，另一个前端的工作量非常大，有可能无法按期提测。

在这个期间，其实笔者没有开过一次风险会议，也没有开过什么早会、晚会，笔者的团队都自发的肩负起哪里缺失补哪里。

后端开发帮助前端部署nignx服务环境，解决微信公众号授权等问题，同时后端也积极帮助产品和项目管理部沟通测试资源，产品（也就是笔者这边）在疯狂的进行测试。在最后提测阶段，所有的人员都进入了测试阶段，同时也协调了一个测试2天时间来保证基本测试质量，有问题都是产品、开发一起共同探讨技术解决方案，产品也积极和业务沟通相应的解决方案。最后的效果是整个迭代按质按时上线，且无任何问题，非常稳定。

笔者对团队氛围的管理主要有两方面，一个是在平时的工作过程中，和开发站在一起，从他们的角度去考虑问题以及方案，尽量不要让开发去承担业务问题。另外一个方面，就是业务对我们负责的产品的赞赏，笔者也积极在团队内部分享，让他们都充分感受到自己工作的价值体现。

三、汇报——中级产品经理

汇报主要分为两方面，一方面是工作过程汇报，另一方面是结果汇报。良好的汇报习惯和行为，可以有效进行向上管理，获取自己所需的资源，也能在领导面前留下深刻的印象。

1. 工作过程的汇报

宏观来说就是需求节奏和项目节奏的进度汇报（ps：也是有规范的模版以及成熟的方法论）。需求节奏就是产品经理自己对自己的工作的安排的时间计划，让领导一目了然的知道整个项目未来的路是在一步一步在铺垫的。

而项目节奏的进度也就是燃尽图，或者时间计划的工作进度，让领导一目了然知道整个项目当前的进度情况，风险情况。汇报的方式可以有2种，一种是发邮件（日报、周报的形式），另外一种是在线文档的更新维护。其实两种方式的汇报内容都是一样的。

2. 结果汇报

产品经理需要对整个产品的结果和价值输出负责，因此定期（如月度、季度）撰写ppt，总结和回顾当前产品新特性的运营情况，对各个指标的提升情况，以及业务使用的反馈情况这几个方面的内容，然后再根据运营情况，展望下个阶段的项目规划。

四、规划——高级产品经理

这个阶段，产品经理就需要对产品的未来走向有一个目标性的规划，这个规划可以是未来一年、未来三年等的，但一定会有一个产品的可预见未来的规划的目标。

这个时候做产品，不再是拘泥于一个“点”、一条“线”的产品思考，而是要结合一个“面”，甚至是一个“体”来思考。比如笔者所在的公司是一个大金融行业的公司，而同时笔者所负责的产品，又是一条业务线的产品（公司内部有好几条业务线，不同业务线的业绩提层不同，而且数据隔离），领导要求笔者将这条业务线的产品打造成公司平台级的产品。

打造成平台级的产品不难，难的是对业务的“钱”的划分，非常难以拿捏。所以这个时候就需要从整个公司的成面上来考虑从一条业务线的产品演化为一个公司平台级的产品的变化。

对于所做的产品的需求，也需要考虑到公司的战略的发展，来进行产品设计。比如，笔者的领导要求笔者的产品需要支持另外一条业务线的产品服务支撑。这个时候，笔者考虑的不是仅仅去支撑这条业务线，而是可能未来其他很多业务线都有可能会来使用笔者的产品服务。

因此，笔者在设计之初，从业务架构上就考虑的是所有业务线接入使用笔者产品服务的形态来进行统一的设计。最终的效果就是，笔者的产品很快又迅速被其他业务线接入使用，而且还不用过多占用笔者的开发资源，同时又能快速满足公司的业务发展需要。