你要去Google找SaaS产品经理?我建议你还是到麦当劳去挖

戴珂
+ 关注
2022-05-13 14:01
734次阅读
去年项目开始前,我们计划招聘几名产品经理。但是谈了快三十位候选人,最后我们决定还是放弃外招。
过程和原因大致是这样的:
除了常规产品技能,我主要问了两个问题:
1. 如果产品不好卖,可能是什么原因?
2. 如果用户不能持续用下去,又可能是什么原因?
每个人除了讲了一套产品设计的理念、原则和方法以外,所有答案都归结为两个:
1. 产品不好卖,那肯定是销售的问题
2. 用户不能持续使用,那一定是CS的问题。
如果真是这样的话,那我们为什么要招聘你,这活我们自己就能干啊。
其实,我是想在两个问题上与候选人达成共识:
1. SaaS产品经理的责任边界问题
2. SaaS产品经理的价值最大问题
这两件事是决定招聘的充分必要条件,其它的都在其次。
现在市面上把ToB产品经理和SaaS产品经理混为一谈,这不科学。虽然它们看起来很像,但因为不同的商业模式,决定了两种产品经理,根本就是两类人
这样分类并不关乎对错,而只是关于责任边界,从而影响产出价值的不同。看下图:

你要去Google找SaaS产品经理?我建议你还是到麦当劳去挖

一般产品经理所讲的理论和方法,主要适合ToB产品的交易型模式;而不一定适合服务的订阅模式。
二者对应不同的交付界面:功能界面和业务成果界面(价值界面)。前者不用解释,我们主要说什么是业务成果。
产品经理也经常讲价值,但是这些价值主要是想象出来的,或者说不好量化,客户没感觉到。所以我们用基于价值的业务成果VBO(Value-Based Outcomes)来定义SaaS的价值界面。
因为它们是可量化的、用户视角的,所以落地的摩擦比较小,能更容易地被卖出,客户也能更持续地使用。
原来,外界有个不太靠谱的产品价值标准,说SaaS产品要么就帮客户赚钱,要么就帮客户省钱,否则就没意义。对此,大部分产品经理都无言以对。
其实,产品是否挣钱或省钱,那只是财务部门关注的问题;而业务使用者根本不关心这些,他们只关心能否解决业务绩效的问题
不信你看,SaaS的采购决策顺序,首先是业务,然后是IT,然后是财务,然后是采购。所以上面这个产品价值,多数情况下是个伪问题。
这就是为什么以VBO为交付界面,因为它们是直接面向终端用户的业务绩效问题。以终为始,VBO才是SaaS产品的原点。
但一般产品经理很少到达这个层面,大部分到达功能界面就算完成了。因此产品经理的价值到此也就结束了。
传统ToB产品经理的价值衡量,就是把产品做出来,并且能卖出去(这其实取决于销售),就算过关了。
对于SaaS产品经理来说,价值衡量标准是产品容易卖出去,而且用户会持续用下去。
这个效果不是靠销售和CS做出来的,而是产品团队工作的另一个重要部分。除了做出产品外,从“落地”到“续约”,是一个服务的设计过程,这两部分构成SaaS产品的完整过程,也就是责任边界。
至于销售和CS,它们仍然是重要的和不可或缺的,但它们是根据这个设计的执行。
更重要的是,产品经理的价值,是可以货币化的,比如驱动ARR的增长、利润的增长、CAC的降低。
以往谈到PLG,都认为它代表的是无销售就能增长。其实PLG的正确理解,是多级增长驱动中,以产品为驱动力的一级。即从产品驱动,到销售驱动,再到服务驱动。
回到最初招聘的问题,公司为什么要招聘SaaS产品经理?
答案是为了提升ARR。
从这个角度看,可能并不存在SaaS产品经理这么个角色,而是一个SaaS产品复合团队。因为除了做出产品,还有定价策略、利润计算、控制CAC,以及运营策略等一堆事。
所以SaaS产品经理的训练,本质上是一个基于量化价值的数学问题;而重点不是如何创新、用什么样的概念
总之,只要与ARR和增长无关,都不是SaaS产品经理必修的内容。
有些习惯不改变,可能就做不好SaaS产品经理。
因为基于服务订阅的产品世界变了,ToB产品经理的习惯和绩效也变了,比如:
  • 成功标准

传统ToB产品经理,是交易的完成;SaaS产品经理,ARR增长才算成功。
  • 产品设计

传统ToB产品经理的设计目标是面向IT;SaaS产品经理则面向业务终端用户。
  • 购买者

原来是IT和采购部门;现在是业务买家和终端用户。
  • 落地推广

原来是自编、自导、诱导;现在是客户价值体验的结果。
最后,为什么招聘SaaS产品经理,去麦当劳找要比去Google挖更合适?
Google产品经理面对的问题是:如何做出一款好产品;而麦当劳“产品经理”要解决的问题是:如何保证几款标准的汉堡,能在全世界长盛不衰。
本文经授权转载自 微信公号:ToBeSaaS
续费,决定中国SaaS的未来 | 专家视角
资深作者戴珂
0
消息通知
咨询入驻
商务合作