编辑导语：传统ToB产品经理的价值衡量，就是把产品做出来，并且销售能卖出去就算过关了。对于SaaS产品经理来说，价值衡量标准是产品容易卖出去，而且用户会持续用下去。本文作者围绕SaaS产品经理责任边界和价值最大问题分析，希望对你有帮助。
去年项目开始前，我们计划招聘几名产品经理。但是谈了快三十位候选人，最后我们决定还是放弃外招。
过程和原因大致是这样的：
除了常规产品技能，我主要问了两个问题：
每个人除了讲了一套产品设计的理念、原则和方法以外，所有答案都归结为两个：
如果真是这样的话，那我们为什么要招聘你，这活我们自己就能干啊。
其实，我是想在两个问题上与候选人达成共识：
这两件事是决定招聘的充分必要条件，其它的都在其次。
现在市面上把ToB产品经理和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产品经理的习惯和绩效也变了，比如：
最后，为什么招聘SaaS产品经理，去麦当劳找要比去Google挖更合适？
Google产品经理面对的问题是：如何做出一款好产品；而麦当劳“产品经理”要解决的问题是：如何保证几款标准的汉堡，能在全世界长盛不衰。
你觉得谁更适合SaaS的服务订阅模式？
作者：戴珂；公众号：ToBeSaaS
本文由@ToBeSaaS 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。