我以前经常把产品经理的PM拆分为,Pilot&Merchant,简单理解是把控产品的航线,制造产品卖点。
在传统的互联网领域,产品经理最常见的活儿是,产品功能定位与设计,产品经理常规性的思考出发点,是用户路径。
也就是说,在互联网尤其是移动互联网出现以后,绝大多数的产品本身以功能(稍微正经的说是以用户需求)来赢得用户,从而进一步赢得市场与商业成功。
就像产品经理界的上古之神俞军老师说的,需求三要素:用户价值,愿付价格,企业成本,其中用户价值=(新体验-旧体验)-替换成本。
在这种方法论指导下,我们非常关注产品的表现层,用户看到的界面,数据,交互都是PM极为关注的方面,这些表现层代表了用户的感受或者情绪变化。
好的产品都是解决用户的情绪问题,高级的产品是在引导用户情绪变化,顶级的产品是在试图帮助建立用户的情感。所以在原先很多PM的讨论里,我们常常会说归属感/参与感等等,无非就是希望能控制用户路径下的情感建立。
逐步的,当互联网发展到一定阶段,互联网变成了一种工具属性(尤其是移动化),于是和传统行业更多紧密的结合,并大幅改造传统行业,因此产品也开始拆分成了To G/B/C等不同领域,而PM处理的事儿也变得复杂起来。
视角变化带来的是对PM的分层,更多PM进入行业后,做起了工程任务,比如脑图/原型/逻辑图等等。
我常常在面试的时候,听到两种截然不同的跳槽诉求,To B的PM会说,我想做更多和用户相关的事儿,直接把握C端用户需求;To C的PM说,我想和业务结合的更紧密一点。
本质上,因为分工的细化,各层PM并未跳出自己的思考惯性,大家仍然沉浸于顶层设计路径的Pilot&Merchant的幻觉里,那种角色确实太爽了。
可随着行业的快速转变,那种爽感只能被CEO或者业务负责人感受了,PM越来越难以进入到那个领域里了,因为互联网改造的行业和业务越来越多,好改造的都改造完了。
如今已经进入了教育/医疗这种离互联网语境光年距离的传统行业(注意是语境,不是环境),作为PM会发现,咦,这事儿我完全不懂啊。
当然作为工程角色没有任何问题,但那意味着随时可被替代,不管是被全栈时代的他人替代还是被AI时代的机器替代,那PM该怎么继续做好?
先Hold一下,PM可以自问一下,如果现在要被调去开始负责HR的事情了,在不掌握怎么做工资,员工培训,和员工访谈这些技能前提下,我们的PM技能该怎么发挥?
其实让我们先回到HR的本质上去,让合适的人去干合适的事儿,持续增加员工对公司的归属感。
咦,好像又回到我们的老本行了,处理情绪,建立情感,是吧?
接下来我们就可以从员工体验设计,管理系统,制度化等事情,按照公司发展阶段下的优先级干起来了。
当然我是在刻意把复杂的事物简单化。
只是想说解析事物本质是PM的一个本事,无论我们处理什么业务,我们都需要先回归事物本质,因为归根结底,产品本质是解决人类欲望问题。
宗教在解决人类负罪感问题,应用下载解决人类猎奇心问题,用户举报解决了人类发泄欲的问题,只有把需求下沉理解到这个层面,才能整体把握产品设计和每一个触动用户情感的机关,同时也能很好的放弃掉一些边角的需求困扰。
当然,一个业务持续的发展或者一个复杂业务本身会触发多种人类欲望,比如陌陌从开始的生理欲望衍生到了参与感,存在感(被需要感),荣耀感等多方面的情感体验。
可惜,在下半场的产业互联网中,有了这些仅仅是我们做好了最最最基础的PM角色,那回到那个问题,下半场了,PM该怎么继续做好。
让我们回到现实世界里,在所谓产业互联网内,我们经常碰到这样的问题。
业务方找过来说,现在在某地这个策略需要调整,因为相关部门给我们提要求了,再不改就下线。或者是我们有非常重要的合作用户,他提出来你们如果这么做个功能他们就先用咱们的不用某某产品了。
这个时候,PM很矛盾,因为原先的训练模式叫洞察用户需求,屁股得坐到大量用户那边去,做普适需求,小众需求优先级都调低。
现在搞成了一个人/一批人要这么做,还就得做,否则产品连MVP都跑不起来,纠结啊。
坑的还在后面,PM要是干劲儿十足,可系统性思维训练不够,那可能就会是做了100个业务方提过来的需求,使用了100种解决方案,相当于刨了100个坑儿,后续接手的人到处踩坑,造成更大规模的效率折损,于是动不动的就得技术重构。
这就是现实世界的骨感。
究其原因,上面也提到过,原先互联网PM与产业的业务距离太过遥远了,而且学习业务所需的时间是非常漫长的,甚至是不可能的,为什么说甚至不可能?
作为PM这个角色来说,它具备通用性和适用性的职业特点,换句话说,就是靠方法论吃遍天下的,再加上PM本身是一波学习能力强的同学,这就很难要求这么一波人永久服务一个产业业务。
即便存在熟悉业务语境的PM,从全行业趋势来说,一定会是越来越多原先互联网的PM将进入到产业互联网中,因此我们得找到PM在新的行业中的定位和解决问题思路。
简单说,进入下半场,PM一定要有的意识是,从原先顶层设计用户路径转变成为顶层设计能力系统,这是根本性上PM的定位转变。
从做驱动轮的角色或部门转变为了变速器角色或部门,目的是让所有落地产品形态(公司内外部)去匹配产业中业务的快速变化和创新。
那到底我们搭建的能力系统到底是什么东西?可以分成两层来看,一类是业务产品的能力,一类是业务产品的工具。
**什么是业务产品的能力?**是指我们通过技术手段和产品手段把原先已有的产品功能拆解成单元,并把单元隔离和逻辑抽象,形成了组装件,组装件一般由各类组件组成,组件的颗粒度可以按照业务各自形态进行定义,举个例子,比如在英语培训里,课程管理,老师管理,师生关系都是不同的组装件,课程管理的组装件里,包含了课程上传,课程标签,课程编辑等不同组件,当业务要开小班课,开大课,开1对1,或是面向少儿/大学生/商务人士不同人群提供服务的时候,都可以集成组装件或者是某个组件去快速完成业务搭建,从而在底层形成了一套独立的业务能力系统。
**什么是业务产品的工具?**一般是给业务运营来使用的一类完整的产品形态,再举个例子,在英语培训里,我们做了一套拼购满减的产品形态,线上的月度会员付费业务部门可以直接使用这套工具来进行自己的业务目标安排,同样的公司内做线下课程的业务部门也能基于自己的收入目标来直接使用,就像使用工具一样,只是业务面向的用户不同,或者业务的合作方不同罢了。
以上两种类型的差异是,使用能力组装件的仍需要业务方进行集成开发,使用工具的直接就能配置使用,但本质上都是为了满足业务方完成目标和创新。
PM在这样的新环境里,通常也会分成两种类型。
一种PM是业务内的PM,主要做的还是目前互联网PM最擅长做的事情,专注在业务内的用户路径,毕竟业务还要有落地的产品形态,他们需要掌握一定的业务语境。
另一种PM就是来搞业务产品的能力和业务产品的工具,实际上产品部在这个意义上更像一种职能支撑部门,PM们的思考出发点是如何更好的为业务部门的人员提供系统性服务,所以实际用户是业务部门的PM,业务部门的技术,业务部门的运营,业务部门的销售等等,而作为使用者对服务体验的满意度是对第二种PM的考核,当然PM所抽象出来的能力和工具满足的业务数量越多,这种PM的能力越强,绩效越好。
拆分了两种PM以后,那么除了考核以外,一个事儿该归到业务PM还是归到能力系统PM,似乎成了一个挺大的问题。按我的理解,可以制定一些类似的原则来对事情做判断:
与页面/用户路径相关的,理论上归属于业务PM;
与数据/逻辑相关的,理论上归属于能力系统PM;
与技术相关的,比如OCR/NLP/安全,理论上归属于能力系统PM;
与大平台相关的,比如帐号/审核等,理论上归属于能力系统PM;
互联网进入下半场以后,适者生存的理念越来越突出,上半场的红利造就了产品经理这个职业,下半场是真正考验PM们进化的时候了。
毕竟,我也只是这进化中的一员。