编辑导读：升职加薪，是职场不变的话题。它与个人能力成长速度有关，也与环境、时机、运气有关。从产品助理到产品专家，要跨越产品经理、中级产品经理和高级产品经理这三个阶段。那么，每个阶段的工作重点是什么？需要具备什么技能？本文作者对此展开了梳理分析，与大家分享。

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

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

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

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

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

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

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

　　产品助理，一般只需要做好产品经理交代的任务，画画圆形、写写需求文档即可。产品经理，需要的是做好产品本身的管理。中级产品经理，需要学会向上级汇报，向领导汇报。高级产品经理，需要学会做产品规划。产品专家，需要深入行业，做产品战略、行业洞察、商业生态等内容。当前的产品能力理论体系都比较成熟了，接下来将详细讲解，如下图所示的内容。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　自此，产品经理从初级到高级就暂时这里，欢迎大家留言探讨。

　　总之，笔者想说的是，我们在阅读很多产品著作的时候，似懂非懂，但不要气馁，等到你自己碰到的时候，就会突然恍然大悟，原来之前自己就学过类似的产品方法论。而且，很多能力，虽然这些著作没有说清楚是哪个层次的产品人所具备的，但是的确这些能力，在不同的产品经理的阶段会有不同的侧重点。

　　逐步点亮技能树，逐步走向更高级的产品人！

　　作者：萧羽；公众号：数据产品之道

　　本文由 @萧羽 原创发布于人人都是产品经理。未经许可，禁止转载

　　题图来自Unsplash，基于CC0协议

　　2017年进入职场，到现在9个月的时间。从校园到职场，从懵懂到了解，我想和你分享一下我在产品助理这个职位的成长。

　　2016年6月，我开始做情感类自媒体，自诩斜杠青年，从内容创作到UI到推广，也朋友圈也小有名声。那时候陆陆续续看了一些杂七杂八的书，偶尔看到了“对这个世界颇多质疑”的职业产品经理，拍案而起，太COOL了，这TM说的不就是我嘛。

　　2017年7月，带着对“产品”以及“经理”这个职业无限的憧憬和期待，我从校园真正踏入到了职场。还没从毕业季中缓过来到拿到工牌的那一刻起，我看着身边忙忙碌碌的人群，其实并没有很多经验的我像一只刚刚从笼子里飞到森林的鸟，紧张、惶恐、陌生、迷茫、向往，各种情绪杂糅在一起。

　　幸运的是，入行的第一个产品就是一个DAU在一千万的APP。无疑这是一个充满挑战的机会，也是一个可以充分锻炼自己的平台。

　　毕业后的大半年，在一个领域摸爬滚打，也稍微有了一些能力上和心理上的变化。我想也是时候总结一波，以便更稳步得向前。

　　画好产品文档是一个产品经理的必修课。去年7月底，我就开始尝试负责一个即将上线的小需求的PRD撰写。好在导师带的好，现在回看起来，PRD也没有画的很丑（虽然没有高保真，也算得上中保真），我心甚慰。我尝试把所有的逻辑都写清楚，把PRD写得像一篇论文一样，充分表达了自己的想法。可惜正在沾沾自喜之际，开发哥哥看完跑来问我说：“你这个需求到底要是修改哪里啊？”，把我也问懵逼了。

　　产品需求文档是产品经理和开发、测试沟通的最明确的书面材料，在版本高速迭代的过程中需求文档的沟通效率显得极为重要。比起又臭又长得描述产品内已经有的很多逻辑，如何摘出重点，如何从“表达自己”到“表达这个需求本身”体现了一个产品经理对这个APP的熟悉程度以及对这个需求目的的把控。这是我在写产品文档中学到的最重要的一个知识点。

　　从需求本身产生的原因（O，objective），到需求策略的重点摘要（S，strategy），再到做这个需求我所期待的数据变化（M, measurement），是必然写在产品文档的头部的，这样能让整个需求的传达更为精准有效。而且，当产品经理把需求表达清楚了，在开发和测试遇到一些极端的逻辑时，他们就可以自己判断应当如何处理才符合这个需求的初衷，省去了很多不必要的沟通成本。

　　最开始参加需求评审会的时候，整个项目组的80多号人集结在一个会议室里，对着需求文档，一边产品讲解需求，一边项目组内任何一个角色都可以对这个需求进行提问。

　　在这样的情况下，产品经理就像是一个需要接受全项目组审阅的角色，着实鸭梨山大。第一次尝试讲解一个需求的时候，就有同学直接提出来“这里为什么要这样处理呢？对用户来说并没有任何好处”，当时傻眼，于是出动上级帮忙救场。

　　对于用一个需求，从不同思维和角度出发，处理模式是不一样的，因此需求确定前的多角度“需求讨论”是非常必要的。如果把“需求讨论”的环节放在需求评审会上，那就太迟了，可能会严重影响整个项目组的进度。

　　“需求讨论”需要在“需求评审”之前执行，通过一个最小的讨论组（其中包含各个角度的人群，例如开发、测试、UI、运营、渠道）来反复确定需求的方向和细节。

　　这样的工作模式也让人收益颇多：

　　沟通效果变好。需求的产生本身就集合了项目组内各种角色的智慧，在需求评审时，这种精神是可以通过角色内的相互联动去传达的。拓宽自己需求思考的角度。在经常与项目组内其他角色反复碰撞后，即使颇多分歧和争吵，事后思考一下不同的角度都有可取之处。执行过程变得简单。当项目组内每个人都对这个需求有认同感，认可需求能给用户带来价值，那么执行过程中就可以发挥团队最大的积极性。

　　我一直坚信数据是会说话的，如果你看不出来，那就是你还没有找到和它沟通的正确语言。我开始尝试看数据时，是从DAU、MAU、留存开始的，大致知道一个数据范围以及近期波动的情况。我注意到，安卓平台的留存从一月份之后一直跌了十个百分点，而iOS平台却并没有。数据本身告诉我的只有这些，那背后反应的问题到底是什么呢？

　　首先，iOS用户和安卓用户的区别可能在于收入程度不同、审美倾向不同、机型性能差异、地理位置差异等等。

　　再去看APP从一月份开始的需求变化，最明显的一个变化就是包体积越来越大、启动速度越来越慢。

　　而iOS用户对性能的接受度比安卓用户高，因此我们猜想，可能是性能的降低使得安卓用户流失。

　　因此后期我们着重减少安卓平台的包体积，优化安卓平台的性能，安卓的留存慢慢被提升了。

　　这个分析和验证的过程，就是从“数据本身”到“数据背后的问题”的能力提升。

　　类似的，数据能帮助我们解决很多问题，总结下数据方面的成长：

　　善用工具。如果不是数据出身的产品经理，也许再做一些数据分析的时候，是极其耗费时间和精力的。Growing IO数据平台的出现在很大程度上解决了这个问题，通过很简单的事件分析以及漏斗分析，可以看出用户的精准行为数据以及流失过程。这样更能够有的放矢，重点优化薄弱环节。学会使用AB Test。当市场难以判断时，AB test是基于用户行为数据让用户“说话”的很有效的一个途径。产品经理在AB test的过程中所扮演的最重要的角色是如何设计实验组和对照组以达到需求验证的目的。要注意“控制变量”和“最大程度上保证用户体验”的思维方式。不要被你的用户带着走。我始终记得记得张小龙说过的一句话“产品经理的决策不是follow数据的，而是应该follow你的心”。数据本身给产品带来的是辅助性的判断，真正决策的时候，也万万不可紧跟着数据。否则就可能会导致相应速度满、永远走在市场之后的危机。

　　入职后的整整7天我都在做自家APP的分析报告，对比竞品以及逻辑思考，我列出了一堆的优化项。我认为，首页的类似功能的入口应该合并，应该引导更多用户注册以增加用户粘性等等。现在看来，有大胆的可取之处，又缺少了一些对用户本身的关注，如空中楼阁，经不起推敲。

　　每天，我会看最少50条用户反馈，回复10条，每周找1-2个用户聊聊天，即使有的时候很忙，也要抽空做这件事情。

　　在和用户聊天的时候，我可以定性的知道美国的一个男收银员很喜欢使用我们的某一个功能，并且会把它推荐给朋友；

　　泰国的漂亮空姐会在APP内录视频唱歌，30s根本不够用啊；日本的漂亮“援交”MM在外面喝酒的时候常打开我们的APP与姐们们拍照；荷兰的一个妈妈，经常用很萌的贴纸和她的3岁的儿子拍照逗趣。在非常自豪的同时，需求的梳理与发掘都从用户本身的生活场景出发，做更多角度的思考。

　　在这里也记录一个非常温暖的事情，和产品无关但却让我难以忘怀。一个女孩在意见反馈里发了一张图片，希望我们能逆出她和他男朋友的原图。照片是用我们的APP处理过的图片，一对情侣笑得特别开心，脸上加了很多可爱的贴纸。她很喜欢这张图，但是她希望能找回原图以便看清楚她男朋友更多的五官，而他的男朋友就在前两天过世了。我帮她问了很久，找了很多开发的哥哥，但我们目前还是没有这个技术。

　　我为我没有帮助到她而感到遗憾，但也为一个APP能给人带来的回忆和价值而感动。我们在做一件非常简单但却又可以非常伟大的事情：用图片帮人们记录和表达生活。

　　一开始涉足相机类APP的领域时，我仅仅因为一个臭美的女孩还蛮爱自拍。身边的人有的在用这款相机，有的在用那块相机，我会时常分析这些竞品有哪些不同。当对这个行业不够了解时，分析往往浮于表面，常常专注在APP内的功能性体验。这样的眼界对一个产品助理来说，或许已经足够，但是要想从产品经理助理向产品经理进阶，需要开始逐渐培养在互联网相关领域内的锐度。

　　阿里的一个大牛来公司做分享时说过这样一句话：“商业锐度决定产品未来”。当上一波互联网红利已经结束，APP的增长趋于平稳甚至衰落。下一波红利在哪里？如何演延长APP生命周期？竞品近期在战略上有什么动态？这是产品助理最薄弱的地方，也是我们在熟悉业务之后最需要提升的地方。

　　每天阅读互联网的最新动态，每天刷刷知乎、 36kr、虎嗅自然不必说。可以推荐给大家的还有，每天早上我一边化妆的时候，都会一边去听“得到”APP每日推荐的文章，时间得到有效利用。在相关社交媒体上去发现年轻人最新的潮流是什么？用户表达的场景有什么样的变化趋势？抓住年轻人，抓住潮流，甚至开创新的使用场景。方向性的东西往往需要跳出框架去思考，可以用MVP去验证你的想法。运营是最小的MVP，其次是最简单的开发。

　　刚进入公司的时候，我觉得每个人都很厉害，都是前辈。敬佩之余，更多的是惶恐，觉得需要学习和提高的东西太多太多了，根本无从下手。因为没有任何产品的相关经验，零实习零实践，我就是一张白纸。那时候也跟Leader表达了我的惶恐，Leader很温暖的鼓励我说，“永远不要害怕自己是一张白纸，勇敢得去做，也许白纸就是你的优势！”

　　于是我也大胆得去尝试，听不懂的会议也要去参加，哪里不懂就积极得问同事，认识了更多的人，了解了更多的事情，什么都努力的、盲目的去学。九个月过去了，在渐渐熟悉业务之后，我知道产品经理的角色需要背负什么，更加知道自己最应该提升的是哪一个方面的能力。如果说前段时间都在做横向的业务了解，那么接下来，我会更加着重在培养自己纵向的产品能力。

　　今年的规划：

　　看十本互联网领域的书籍，记录读后感，结合实践构建自己的产品经理理论。每天练习英文口语。提升英语能力，因为是海外的业务，所以常常要跟外国人接触，定期总结和分享，与业界同事多沟通。就像今天这篇文章一样，希望引起同道中人的共鸣和交流。从身边的同事身上学习更多思考的方式。产品经理的逻辑思维和思考方式是需要反复训练的。今天，也是我原来的Leader离开公司去的日子，万般情绪涌入心头。我曾经因为曾经因为和同事的分歧而委屈，也曾经因为制度和流程的不公平而抱怨，甚至因为压力太大和节奏太快想要在互联网行业退缩。

　　但不可否认的是：我深深的爱着这种“年轻”、“创造”、“扁平化”的互联网氛围，爱着那个永远充满激情、努力向上的自己。

　　感恩Leader带给我的成长，我会带着你的期待，继续前行。

　　本文由 @MissFive 原创发布于人人都是产品经理。未经许可，禁止转载

　　题图来自 Unsplash ，基于 CC0 协议