产品经理晋级产品专家必跨的14道台阶

张杨 2023-07-21 01:42:17

2020，做产品经理也有五个年头了，踩坑、爬坑一路走来，收获颇多。

幸运的是，最近2年可以有机会在公司内部创业做一项从0到1的事业，并且随着业务从1到10的发展，自己也有了不错的进阶机会，能够独当一面地负责近50人的团队。在这里将自己关于产品之路进阶的思考和经验总结为14条，个人认为是产品经理想要进阶产品专家必须要跨越的14级台阶，希望对读者您有助益。

一、环顾脚下的“土壤”

南橘北枳，农业种植需要谨慎考虑种植物跟土壤之间的关系。

在企业内部创新或者孵化新业务时，不能盲目，不可以草率开始。作为主导业务方向的产品经理，尤其需要思考清楚，新业务跟公司现有业务、团队资源、行业属性、组织机制以及业务积淀有何种匹配度，这些是不是可以在新业务发展过程中起到助力，团队是否具备开启新业务的行业知识储备。如果结果乐观，那么业务发展阻力就会相对少一些；如果都不具备甚至抵触，那么面对先天劣势的状况，产品经理就需要有更多的耐心和信心，逐渐去创造出这些优势资源为己用。

比如，我们团队在初始阶段分析，我们要开启的新业务是跟公司现有业务有较多的交叉性，团队资源有一定的复用性。但是，我们也分析发现，新业务客户群体是之前没有正式碰触过的，并且团队行业知识储备、业务所需的组织机制都是没有的，这都需要重新建立，这就意味着土壤贫瘠，需要自己辛苦增肥了。

二、判断时机不当，可能会颗粒无收

春种-秋收。乱了时令，农作物可能会颗粒无收。

按节气播种是千年来的农业智慧，也是农业朴素的成功法则。

创新业务虽然要在一开始尽可能规划完整的业务图景和商业模式，但是更要基于当下所能掌握的团队、资源、市场状况来决定在什么时机应该做什么产品决策。产品经理不要上来就闷着头做完美方案、做大中台、做一切皆可组件化配置… … 这样反而可能会对业务有伤害。

在我们业务发展初期，我并没有着急去构建大而全的产品架构，跟行业top竞对PK功能丰富度，而是仔细分析了手头可动用的有限资源、看看脚下贫瘠的“土壤”，然后围绕着现有成熟可用旧产品模块去打造单点场景下的爆点。

在做好1-2个产品突破点构成差异优势之后，我拿到更多资源；然后构建产品主干，再捕获更多资源；然后逐渐丰满肌肉和脏腑，获得更多客户和市场认可，然后补充皮肤和毛发，每一个阶段都需要卡在点上，否则业务就可能松到拖死或者紧到崩断。

三、跳出产品思维，融入商业思维

产品经理工作的终极目标是什么？商业化盈利。

其实，产品经理就是互联网公司一个岗位而已，公司的创建从经济学意义上就是为了实现商业盈利。而产品经理作为业务火车头，必须要了解公司的商业模式，以帮公司达成盈利为最终工作目标，毕竟没有公司是以做慈善为经营目的的。其他价值，包括用户价值，皆为附属。

另一方面，如果产品经理眼中只有产品功能、交互、UI、PRD文档，看不到产品可以为公司带来的商业价值和盈利点，那么他大概率不是一个杰出的产品经理。

所以产品经理要先思考几个问题问自己：你是否清晰的了解公司的战略和商业化目标？你所负责的产品是否迎合公司的商业化战略方向并最终可以推动商业化目标的实现？

产品的商业化思维并不意味着产品经理就一定只做跟商业变现直接相关的产品，而是说，你在做产品的时候，无论直接还是间接，一定要清晰最终目标是为了公司实现商业化价值。

比如，对于支付宝而言，有更多的日活才能带来更多的商业变现，才可能会有更多的理财、保险销售额，那么，蚂蚁森林虽然不直接产生商业收益，但是蚂蚁森林为支付宝贡献了非常大的日活用户、粘性和停留时长，这个也是间接实现商业价值的体现。

四、产品经理要融入到行业里

产品经理要以做学术的心态做行业调研和学习。

尤其是创新业务，产品经理在初始阶段务必要系统化、深度的调研行业的发展历史、趋势、特征、发展症结等信息。

包括但不限于当前业务所处行业在国内发展状况如何？国外公司市场境况是否有差异，差异是什么，什么原因？发展这类业务的公司是否融资便利？如果不顺利，是行业大环境如此还是公司产品目前还缺乏产品优势和差异化的竞争力？整个行业还有哪些未被满足或者满足较差的领域，你的产品在这里表现是否够亮眼？

比如我们在做业务创新孵化时，会翻查多篇行业论文、易观智库/艾瑞网上的行业专题/趋势报告、各种相关专业平台新闻报道、标杆top客户的官网官媒资料，并且跟商务全国范围内出差拜访客户，当面调研交流，探知行业第一线客户真实遇到的情况，从而不仅仅是了解行业，更能了解客户，基于此，才衍生出产品创新的着力点。尤其是to B的业务，产品经理自己坐在工位上研究交互、研究用户行为数据、漏斗是起不到什么太大作用的。

此外，其他有几个问题可以供大家思考，可以试试你对行业的了解可以有多深?

你觉得共享经济是什么？你见过的共享经济有哪几种场景类型？

比如小电和滴滴，他们的共享经济模式有什么异同？
不同的共享经济业务之间，他们的资产运作方式有何不同，哪一类是偏轻资产的，哪一类是重资产的？
不同共享经济业务公司的运营策略有何差异？这些策略跟他的共享角色之间是何种影响？
不同的共享经济业务在衍生出的社会效益和政策风险上有何区别，他们分别是怎么样的应对策略？

五、产品经理要做射出去的箭头，扎到客户群里

产品经理要做客户肚子里的蛔虫。

C端客户往往是独立的用户个体，但B端客户一般都是由多人协作、组织复杂严密、流程化有机运转的“机器”，所以B端产品不像C端产品那样可以很容易实现共情，去把自己还原成小白用户从而揣摩用户心理。

B端产品经理往往难以置身事外去做产品设计，因此务必深入了解客户是怎么做生意的，他们是怎么赚钱的，他们组织内部是怎样的工作流程，了解他们的员工为什么加班，为什么吐槽，为什么被老板骂……只有这样才能做好产品，做的产品才能被客户用得起来。

我们团队在业务产品孵化的过程中就是这样，要求产品经理和运营同学定期或者不定期一定要去客户现场驻场办公，跟客户定期面对面的交流产品使用体验。

在全国范围内频繁的调研客户，跟客户交流学习，了解行业特征，了解这类客户的公司运营机制，对比不同客户公司的组织架构差异，了解客户公司的核心干系人角色，了解客户使用竞品时未被满足的痛点。基于此，我们团队逐渐完善面向用户角色的产品策略，并且最终形成具有差异化优势的产品解决方案。

六、产品经理要培养全局观，融入业务，to be业务经理

公司整体产品方案就像一个社区。产品经理不要只关注院子里，要出门看看过道是不是干净。

从产品维度来看。产品经理往往负责公司的一个产品模块或者一条产品线，但是公司整体产品解决方案可能包含了很多产品线和产品功能，如果产品经理只着眼于自己范围边界内的产品，没有去全面了解公司整体产品架构、各产品线之间的协作机制和依赖关系以及资源冲突等问题。

那么，这个产品经理一定无法很好的具备产品全局观，更不用谈业务全局观了，那么怎么能指望他很好的推动公司的业务发展前进呢？这种水平，距离产品专家的能力要求也相去甚远。

从业务维度来看，产品经理也不可能为了做产品而做产品，每一个产品经理都是为了业务最终落地变现服务的，每一个产品经理更是一个业务经理。因此，产品经理除了要了解公司产品全局，同样重要的是要了解业务的上下游，以及上游的上游，还有下游的下游。

比如to B的产品经理，需要了解的就包括从BD商务->售前->产品->研发->测试->项目交付->运营和长生命周期客服的业务全流程。如果是想晋级产品专家的伙伴，是必须要做到全流程了解。

在此过程中，产品经理需要向前向后走几步，思考自己可以从他们身上获得什么，自己可以为他们提供什么样的协助和内容，以此推动整体业务向前发展，为业务落地变现和商业结果负责。这也是一般公司对产品专家的要求。

我们团队是面向购物中心等商业综合体开发智慧商圈解决方案的，这种综合型场景天然就要求我们的产品经理将全公司的产品线融会贯通、重新整合，甚至打包其他公司的产品模块到我们的产品解决方案里来，在这个过程中我们感受到掌握产品全局观对于业务发展的助益以及对于团队内产品经理视野和思维高度的拓展。

此外，我们团队要求产品经理务必都对从BD商务开始到售后客服的全业务流程的掌握。

PD要努力向上推动BD的商务策略和商务报价体系的完善；协助售前团队搭建标准化高效率的解决方案；推动项目实施交付流程形成标准化SOP；联合售后客服团队搭建适合商场类客户新业务的大客户服务机制。最终实现业务增长和客户落地。

七、99%=1% ，产品和业务闭环的完整价值

“行百里者半九十。”

B端产品非常重要的一点就是要求有闭环思维，不只是产品方案上的闭环，更重要的是业务流程上的闭环思维。

产品上最小流程闭环如果未完成，哪怕前面90%的产品流程都很完整，体验都很好，可是其中一步漏掉了或者收尾产品功能缺失，都会导致客户体验=1%的烂尾。

在业务流程层面，如果对客户销售-交付-服务全流程存在环节体验极差或者缺失，对外会造成客户信任感下降，停止续约，业务结果就有损失；对于团队内部而言，团队成员工作没有节奏感，整天忙于救火，大家工作成就感很难提高，产品在大团队内的威信也会下降。对内对外都是一种伤害~

所以，产品经理不仅需要考虑产品方案的流程闭环完整，更需要站在业务全流程的视角观察，努力推动完善各业务环节的缺失或者错漏。

八、优化产品和业务的容错性

无法避免404的发生时，我们可以做什么？

对错漏，容错性的价值体现在3个层面：

产品的容错性：设计产品时要充分考虑产品的容错能力，针对异常场景和错误发生场景的容错设计至关重要，不要把灾难和绝望留给客户；
产品经理的容错性：产品经理也需要打造自身的容错设计，面对错漏、变更、异常情况快速反应，保持韧性，推动项目向前拿结果；
业务团队的容错性：对于无论是否由产品功能本身引起的问题，只要是你的产品相关业务在交付和服务客户的过程中发生了问题，产品经理也需要推动业务团队制定灵活有效的应对机制，提升业务团队的容错能力。

我们的产品解决方案在客户落地过程中，曾经也出现过系统网络抖动或者客户人为配置失误导致的优惠券自动赠送逻辑异常。

这种情况下，系统降级方案支持客服手动赠券；在产品早期资源紧张情况下，无法及时将业务报表配合功能同时上线时，安排数据分析师手动定期给KA客户拉取报表邮件同步给客户；在系统遇到无法及时修复的问题时，立刻派运营到客户现场驻场，跟客户一起面对问题，舒缓客户情绪甚至请客户公司负责该模块的同事吃饭、喝奶茶等。最终目的是让客户对产品保持信心和继续使用，这就是我们为业务团队容错性做的设计。

九、聚焦！要事第一！

如果你今天只能做一件事。

产品工作的复杂性导致我们每天要开重要的会、做重要的产品设计、调研重要客户、写重要PRD文档……可是，绝大部分的”重要”可能只是感觉上重要。我们就是这样被很多感觉重要的事情侵蚀了全部的时间和精力，到了要交付结果的时候，可能会感到懊悔和无力，感叹自己本可以做好XXXX事情却没有提前聚焦完成。

因此，产品经理必须要将真正的“要事”跟无足轻重的“小事”区分开来，优先聚焦处理最重要的事情，每天早上都要想一下当天如果只能做一件事情，你会做什么？本周如果你只能做好三件事情，你会选择做什么？

我自己之前也是对于事务和项目的管理很散漫，不够聚焦，后来也尝试用过事件管理工具（在此推荐2个好用的工具：【things】【滴答清单】），可是周一设定好10个待办事项，到了周末，列表里居然还剩下30个待办，其中最难做的几个事件赫然在目。

其实每个人天生都有一定的畏难情绪，当你的待办事项有几个难搞的“要事”时，可能你会优先做好容易搞定的事，这样就容易失去焦点，浪费掉我们最宝贵的时间和精力。后来我开始给自己，给团队每周定期制定“要事”聚焦表，要求自己和团队每周集中精力优先搞定重要的事情，兼顾其他事件，使得个人和团队工作效率有了相应的提升，拿结果的能力强于以往。

十、项目管理能力是燃油宝

产品经理必须成为项目管理师。

项目管理是产品经理核心能力模型的重要组成部分，每一个产品经理都要求具备良好的项目管理能力。项目管理五大过程组：【启动】、【规划】、【执行】、【监控】、【收尾】也是产品经理一个需求项目必须经历的全生命周期，尤其是在没有PMO的公司里做产品，当你面对多需求项目并行的情况下，没有良好的项目管理能力，在执行过程中就很容易造成项目延误、资源冲突、里程碑节点混乱且时间无法保证等问题，最终容易导致项目延期和交付失败。

而良好的项目管理能力可以帮助我们有效的管控项目的过程，可以很大程度上提升团队工作效率和质量，就像油箱里的燃油宝。

为了系统的掌握一定的项目管理能力，我在3年前考取了美国项目管理协会认证的PMP（项目管理师），这给我的产品管理工作带来很大的助益。这里不是说一定建议大家都去考取这个证书，而是希望每一个产品经理都需要系统的去学习项目管理的知识和技能，因为这个是产品专家进阶的必备核心技能之一。

十一、NO DATA , NO BB … …

数据是照妖镜，也是宝莲灯。它让我们的工作成果量化，为我们提供指引。

产品经理和其他业务团队成员都应该定期关注业务数据和产品数据情况，利用良好的数据分析工具和数据报表，定期分析输出数据周报、数据月报、数据季度报。在有条件的情况下，最好可以给你的标杆KKA客户定期输出一份针对于他们项目的数据分析报告，从业务数据分析角度帮助客户找到业务改善或者增长点。

产品经理首先需要关注自己的产品数据，以便产品内部追踪产品迭代效果、发掘数据异常变化趋势并分析背后原因为下次迭代作为参考依据。产品经理同时也应该了解自己产品数据之外的业务大盘数据状况，从业务数据层面补充自己的全局观。

在我们业务孵化发展的早期，为了完善产品功能而一路狂奔，却忽视了最重要的产品和业务数据监控。突然有一天我发现，当我的领导问我一些实时的核心业务数据时，我居然无法回答他。

于是我们搭建起来我们的业务数据监控中心，并不断完善，最终形成良好且有节奏的数据分析汇报机制，每周/每月/每季度都定期输出业务数据报告同步给团队全员，核心业务数据随时可查，各产品经理的产品数据每周会自己分析汇报，在团队内部形成了一切数据说话的习惯，并且也多次利用数据分析结果反向的推动了业务改进和产品优化及创新。

十二、有价值的差异化就是竞争力

成熟市场的后来者，必须依赖差异化优势竞争。“与其更多，不如不同。”

作为市场上的后来者，尤其是进入一个相对成熟的市场领域时，一定要基于深度的行业和市场调研，要发掘客户还未被竞品很好满足或者服务缺位的模块，并据此结合自己的产品基础打造差异化的竞争优势，并且确信该模块是有足够的价值的，这样新产品才能最大几率的站稳第一步脚跟。

因为现今市场上，几乎不太可能存在只有你想到，别人都想不到的创意和办法了，如果作为后来者，亦步亦趋的学习/复制成熟竞品的功能，这样跟屁虫一样的成长策略大概率会死得很惨。

梁宁在产品三十讲里提到过一个亚朵酒店的案例，也分析过类似的场景：“与其更好/多，不如不同。”

我们团队在孵化这个业务初始时，面对诸多存在了一二十年的竞品，没有直接铺开了去做功能硬刚，而是仔细分析客户是否还有未被很好满足的地方，后来我们发现综合体里面，智慧零售解决方案已经完善，但是竞品对购物中心越来越渴望的智慧餐饮解决方案几乎满足的很差。

而这恰好也是我们公司核心主业务，于是我们没有急于跟进竞品做功能，而是围绕智慧餐饮场景切入做了智慧商圈/综合体解决方案，以补位者的姿态进入综合体市场，基于综合体内餐饮业态数字化和餐饮服务在线化连接为差异，填补市场缺口。

接着，逐步完善/打造SAAS化连接全业态收银终端、商管租约/物管ERP、线上线下结合的全渠道营销CRM系统和C端服务平台的一体化解决方案，并在随后的一年时间实现业务从1到10的突破，收获一大波top商业地产品牌作为KA标杆客户。

十三、坚持产品化大前提

如果有一天你的大客户都丢了，你的产品是否还具备快速捕获新客户的能力。

尤其是ToB的项目制重实施交付SAAS产品，经常会陷入大客户的定制化需求陷阱，不做的话，怕客户走掉；做的话，很难持续做好通用的SAAS产品，违背了产品经理的初心。

尤其是创业早期的产品，往往很容易妥协去做大客户的定制化诉求。但是，建议正确的选择是尽可能坚持产品化的大前提去做需求，即便一定会妥协，也要把定制化需求方案做成具备一定程度上可通用/可复制的产品化方案，至少保证一点：即便有一天你的KA大客户全丢了，你的产品也要具备快速拓展新客户的能力。

这里有一个行业案例可供参考。8年前，在智慧商圈CRM系统服务商里，有一家初创小公司，面对着复杂的市场和客户环境，缺少强大的资源和财力，这时他们做了一个选择：深度绑定一家全国top5级别的KA购物中心客户合作，因为业务发展早期标杆客户对于行业的认知和对行业发展困境的了解远高于创业公司。

这种情况下产品团队倾听、满足该大KA客户的各种需求，转化成产品方案，逐渐成长。当创业公司的产品能够满足好该KA购物中心客户时，标杆效应使他们很容易就能收获很多其他新客户，有了更多的客户，这个创业公司的产品就越来越行业化、标准化，最终达到了全国智慧商圈CRM系统服务商top3的地位。这家KA购物中心客户是大悦城，这家创业公司，大家感兴趣可以自己去探究一下。