去年吴晓波在一次演讲中说：“我把2020年称为中国企业服务元年”。的确，由于疫情，企业协同服务在2020年进入公众视野，钉钉、飞书、企业微信等产品火爆，同时也推动了整个SaaS行业的快速发展，比如一些依托钉钉的SaaS公司，2020年营收增长了3倍以上。

中国的SaaS行业确实是近几年才开始快速发展，产业互联网概念的兴起功不可没。作为一名SaaS产品经理，我有幸见证了近几年这个行业的快速变化，也看到了一些想进入这个行业的同事的困惑——SaaS产品经理应该具备哪些能力？今天我想就这个问题谈谈我的看法。

不管是B端还是C端，产品经理都是承担着规划和管理产品、创造用户价值和商业价值责任的人。我认为一个优秀的产品经理，在宏观上要能够深耕行业、洞悉大势；在微观上要能够不骄不躁，写好每一个PRD，画好每一个原型。因此，我认为产品经理的能力模型可以抽象为“认知-判断-执行”。

其中，“认知能力”决定了产品经理能力的上限，“判断能力”代表了认知深度和专业度，“执行能力”则是产品经理的基本能力。

1. 认知 1. 认知 SaaS

SaaS是-as-a-的缩写，意为软件即服务，即通过互联网提供软件服务。目前SaaS产品主要分为行业SaaS、功能SaaS、通用SaaS三大类。

SaaS公司向客户提供产品服务的方式主要有三种：

由此我们可以看出SaaS的行业经验壁垒比较高，这对产品经理的要求非常高，具体来说，要求产品经理对整个行业有一定的了解，同时也要对自己产品的垂直领域有深入的了解。

1）SaaS的商业模式有哪些？

SaaS的商业模式是通过大规模服务客户来分摊公司的运营成本，从而产生收入。

其营收公式=（SaaS客户售价*客户数量）-公司运营成本。因为SaaS不是一次性付费，而是订阅续费的模式，如果想保证有持续的营收，核心指标就是租户的续费率。

目前我发现国内已经有一些公司基于SaaS模式开发出了一些新的商业模式，主要有两种：

2）为什么SaaS这几年这么火爆？

如果你熟悉国外互联网的话就会发现，国外领先的互联网公司大多都是to B，比如微软、IBM等；而国内的互联网巨头目前则主要都是to C。

随着移动互联网下半场接近尾声，C端已成红海，但国内产业互联网仍有巨大蓝海市场。加之去年疫情的加速、国家的倡导催化了大量to B企业，我们可以看到越来越多的to C企业在布局B端，比如BAT、今日头条等。

在IaaS、PaaS、SaaS三种业务侧服务模式中，SaaS是最贴近客户的模式。同时，SaaS模式本身具备两个天然优势：

SaaS公司在足够高的续费率基础上，拥有稳定的客户基础和稳定的现金流，随着SaaS产品的精细化，产品标准化能力越来越强，规模化能力越来越强的同时，产品接入的边际成本越来越低，公司的毛利率可以逐年提升。

SaaS商业模式不仅拥有稳定的客户基础，毛利率也逐年提升；同时与传统行业结合打造产业互联网也有巨大的想象空间，这也是SaaS近年来受到资本热捧的原因。

3）什么样的市场适合SaaS模式？

如果我们选择创业或者公司要转型做SaaS，不管外部的市场竞争如何，都要考虑自己想进入的赛道，它的市场规模能否覆盖公司的运营成本。市场规模=客户付费能力*客户付费意向*客户数量。

那么什么样的市场适合SaaS进入呢？

橄榄形市场：

橄榄形市场是SaaS模式最适合进入的市场，即顶级客户少且数量一般，中级客户多，长尾客户少。

国内领先企业普遍存在数据私有化、服务定制化的诉求，如果接入过多的SaaS公司，很容易陷入“项目制”的陷阱，走上与软件实施公司一样的“不归路”。

行业尾端客户处于“生死边缘”，生存时间短（中国企业平均生存时间为2.5年），支付意愿和能力差，死亡率极高。同时需要不断投入获客和营销成本来争取新的长尾客户，投入产出比低。因此，中端客户是SaaS最理想的客户群体。

这里需要特别注意的一点是，在当前国内激烈竞争的商业环境中，中小企业的付费意愿非常强烈，每一分钱都要花在刀刃上。因此，如果一款SaaS产品对于中小企业来说不是刚性需求（一般越接近花钱或者赚钱的生意，刚性需求程度就越高），那么市场规模会让SaaS公司很难盈利，这也是市场上很多SaaS公司“名不虚传”的根本原因。

平均订单价值较高的市场：

一些马太效应严重的行业，或者一些GMV过万亿的行业，也存在SaaS的机会。

我们回到这个公式：市场规模=客户付费能力*客户付费意愿*客户数量。如果客户数量一般，但是客户付费能力和付费意愿很高，那么盈利空间还是很大的。据我所知，市场上有几家类似的SaaS公司做得很好。

但我认为，对于这种市场，最好的交付方式并不是单纯的SaaS交付模式。因为在马太效应严重的行业（或者客户“钱多”的行业），大部分都是头部大公司。前面也提到，这样的公司或多或少都会有一些定制化的需求，这很容易让SaaS公司陷入“项目制”的陷阱。目前，国内针对这一市场的SaaS公司，主要以“项目制+SaaS”或者“aPaaS+SaaS”的形式交付解决方案（以后有机会再和大家聊SaaS公司要不要做aPaaS）。这其实很考验公司对头部市场需求的把握能力，以及战略决心，很容易“一不小心”就沦为软件实施公司。

2.认知 SaaS 产品

1）SaaS产品和普通to B产品有什么区别？

上文提到，SaaS商业模式的本质是通过服务海量客户来分摊公司运营成本，从而产生收益。对产品端的要求是能够满足大规模客户的需求，这是与普通B端产品最大的区别。

因此SaaS产品必须具备两个能力：

相应地，SaaS产品经理需要具备：

2）SaaS产品的生命周期是什么？

和其他产品一样，SaaS产品也有生命周期，吴昊的《SaaS创业路线图》会给出比较清晰的答案，推荐给大家，这里就不细说了，重点讲一下SaaS产品MVP阶段和C端产品的区别。

C端产品的MVP流程。如下图所示，

在产品规划设计上，C端产品需要持续为用户提供价值。用腾讯的话来说，“一切以用户价值为中心”。假设你的产品最终的价值是帮助用户更快到达某个地方，那么在设计MVP版本时，你需要做的就是交付一个可以让用户以更低的成本更快到达某个地方的工具。从产品功能层面，你需要保证交付产品每个版本的完整性和可用性。如上图所示，给一个滑板而不是轮子。

B端SaaS产品的MVP阶段如下图所示：（ps，请忽略我只画了4个版本的车。。）

在用户价值上它和C端是一致的，也需要帮助用户更快的到达某个地方。

但需要注意的是，在产品功能设计层面，如果产品的最终价值是帮助用户更快到达某个地方，而现阶段由于技术限制，最快的交通工具只能是汽车，那么就必须造汽车。而不是先送滑板，再送自行车。如果这样做，那么后续的每次版本迭代都将是一场“重建”的灾难。

2. 判决

判断其实是依赖于认知能力的，认知错了，判断就会错。在实际工作中，一个产品经理的判断体现在他对需求真实性、价值性、优先级的判断。

1. 确定需求

在SaaS公司的一般架构下，B端产品经理一般是离客户有些远的，通常夹杂着“客户成功”的角色。因此，目前B端产品的需求，大部分来自于客户成功同事传递过来的需求。在这个过程中，存在着大量的信息扭曲，所以SaaS产品经理经常要做一件事——判断这个“需求”是不是需求。

1) 您收到的是需求吗？

在现实世界中，人们对于解决方案的反应往往是潜意识的。比如朋友让你给我拿锤子和钉子，如果你不深挖电商项目经理岗位职责，把锤子和钉子解读成他的实际需求，你就无法发现他真正的动机是为了挂婚纱照，而也许我们可以提供比锤子和钉子更好的解决方案。所以产品经理在一些日常需求清单中，要注意区分哪些是客户真正的需求，哪些是客户自己提供的解决方案。

业界早就有规范需求的范式电商项目经理岗位职责，如果能养成这种思维习惯，就能轻松摆脱解决方案的束缚，范式如下：

作为【特定角色】，需要一种方法来【满足xxx需求】，然后【用户获得什么直接好处】

我们代入上面的例子。

作为一个已婚男人，他需要一种方式将他的结婚照挂在墙上，以提醒他婚姻的甜蜜。

再举一个例子：你的客户告诉你，他需要在系统后台首页上查看该店铺每日的交易数据。

按照这个范式。

这种范式最棒的地方在于它刻意把解决方案简化为方法，让你在拓宽思维的同时，聚焦需求。避免被框定在某个具体的解决方案里，从而了解客户的本质需求。

就拿上面的例子来说，如果你的思维方式是错误的，你思考的肯定是在后台首页要添加什么类型的数据，如何添加这些数据。如果你的思维方式是正确的，我想你一定会找到更好更优化的解决方案。

2）判断需求的合理性

在B端产品设计中，产品经理会遇到一些要求，这些要求对于某个角色来说是合理可行的，但是这个要求会给组织或者其他角色带来一定的利益，这时候产品经理就需要有很强的利益平衡能力。

在to B行业，有一个老华胜并不认可的产品“流派”：TO BOSS学派。他们认为在B端产品的设计上，必须优先考虑决策者的需求而不是用户，而BOSS就是典型的决策者。当然，我觉得TO BOSS大多数时候也没什么问题，毕竟订货、续约的决定权在BOSS手里，这无可厚非。但一切都需要批判性思维，需要辩证看待决策者的需求。

以下有两个示例：

第一是去年疫情期间，有营销SaaS公司为了满足BOSS的需求，推出了全员营销功能，帮助BOSS更好地监控员工带来的客户数量，甚至把这项功能作为亮点功能向市场推广。

我对此事的看法是，没有权利就没有义务，员工和公司应该是双赢的模式。如果只有单方面的员工义务，公司必然会在某些方面遭受隐形损失，这不是长远的解决办法。

第二个例子是我们在两年前的产品上遇到过类似的需求。当时为了更好地了解门店的客户画像，业务方要求销售员把来店的客户印象信息全部填写上去，完成率要求在 90% 以上。对于销售员来说，如果当天来店的客户很多，这基本上是一个不可能完成的任务，大量的印象信息对销售员来说并没有什么实质性的帮助。

当时我们也是按照BOSS优先的逻辑来设计产品的，产品跑了一段时间之后，发现了两个比较严重的问题：

从上面的例子我们可以看出，在B2B产品设计中，如果想让产品拥有长久的生命力，必须权衡整个生态系统中各个角色的利益，而不是简单地站在决策者的角度进行设计。

3）确定需求的优先级

需求优先级判定是产品经理的日常工作之一，如果排除一些特殊原因，比如老板指定，政策要求等，我一般会根据投入产出比来做判断。

ROI=需求价值/需求实现投资成本

需求价值=用户数*场景频次*场景重要度*用户效用

（用户数一般取决于该需求涉及的用户规模）

有同事曾跟我说过，他了解到在腾讯微信上，任何细小的改动都需要张小龙审核确认，往往方案很多，但批准的却很少；而我们公司，大量功能只需要在群内审核通过即可。我们为什么不像微信一样呢？

其实你仔细想一想就会明白，由于彼此的产品的用户量相差近几十倍，用户完全不在一个量级上，其诉求价值也不同。

不知大家有没有发现，有些优秀的产品对一些异常场景处理得并不好，只保留了一个人工干预的入口，其实原因是该场景出现的频率太低，需求值太低。

对于其他产品来说，哪怕某个场景发生的概率是万分之一，他们也需要介入才能满足需求。为什么会这样？主要原因是这个场景对用户来说极其重要。就像我现在处理的交易流程，任何细节上的异常流程，哪怕发生的概率极低，都需要介入才能解决。

在实现需求的成本上，这需要产品经理具备一定的技术理解深度，一般来说，具备一定技术理解，熟悉系统实现的人员，可以对人力投入、研发时间做出大致的判断。

2. 确定解决方案

当需求确定之后，对解决方案优劣的判断也极其重要。对于SaaS产品来说，产品标准化是最重要的能力之一。SaaS产品经理必须对解决方案心存敬畏。如果你以前设计过“有缺陷”的解决方案，那一定会在后续的产品迭代中给你带来诸多困难，甚至将公司拖入泥潭。

如何判断一个解决方案是否可行？可以从以下两点来判断。

1）解决方案是否能满足用户需求

判断一个解决方案是否能满足需求，可以把自己放在用户的角度去审视这个解决方案是否能满足需求，这个是任何一个对用户有深入了解的人基本都能判断出来的。

2）该解决方案是否可扩展且通用？

扩展性和通用性要求产品经理有很强的抽象能力，能够理解业务模块的边界和关系。B端产品经理经常接触的后台权限RBAC模型就是一个经典的产品抽象模型。下图是一个电商大促的产品模型。因为这部分太抽象了，以后有机会再跟大家讲讲怎么设计。

然而在评判解决方案的时候，产品经理不仅需要能够进行抽象建模，还需要掌握好抽象的粒度，避免过度设计。

过度设计，就是设计的系统复杂臃肿，封装过度，继承、接口、没用的方法很多，XML配置文件超级复杂。简单来说，客户需求是一把杀鸡的刀，你却设计了一把杀鸡的刀。杀鸡干嘛要用杀鸡的刀？

比如有些C端运营后端或者轻量级后端，权限设计非常简单，甚至没有做相应的权限控制。如果你在一家公司做产品经理，一定要把最复杂的RBAC（3）权限模型应用到你的后端，这显然是过度设计。

如何判断是否存在过度设计？只需以最常见的场景为例进行检查。如果配置或操作变得异常复杂，则可能存在过度设计。

3.执行

大家应该不难发现，现在市场由于对产品定位的理解不同，对产品的要求也有所不同，比如一些传统的软件实施公司一般只要求产品经理进行需求管理，而一些新兴的互联网公司一般会要求产品经理承担部分项目经理的职责。

产品经理的主要职责就是进行需求管理，今天我们主要讲一下这一部分。

以从挖掘需求到上线为例，一般常规的互联网软件协作流程如下图所示：

在以上这些流程中，产品方案设计是产品经理专业能力的具体体现，这里我就重点说一下产品经理在设计产品方案时，需要具备哪些技能。

我们主要根据用户体验的五大要素来设计相应的解决方案，很多同学可能对这个方法很熟悉，但是在实际工作中，能按照五大要素来分解、设计解决方案的产品经理真的很少，甚至一些“老手”都搞不清楚自己的PRD是如何和五大要素对应的。

用户体验的五个要素如下图所示：

1.战略层面

产品经理在设计战略层的时候，需要能够清晰的回答两个问题：一个是“用户能从产品中获得什么价值”，一个是“我们能从产品中获得什么”。用余俊先生的话来说，产品是用户与企业进行价值交换的载体。

战略层一般对应PRD中的背景描述。

以后台权限管理模块为例，策略层为：

很多时候，很多产品经理由于对战略层面的不清晰，导致整体产品设计偏离战略层面，从而产生“无效”的产品计划。

2. 范围层

范围层的定义是指产品的范围，包括产品边界、功能范围、用户需求范围等。范围层的设计对于产品经理来说极具挑战性，需要产品经理考虑什么范围才能够实现战略性的产品目标，并且对用户需求有很强的把握。

如果产品经理对范围层理解不够，很容易在产品设计时产生一些“大而全”的产品方案，这种方案在正确性和完备性上还行，但无法回答“为什么现在”的问题，会导致研发团队花费大量的时间去处理一些当下价值不大的功能，从而错失市场机会。

关于范围层的判断，我们以我从0到1设计的一个小产品模块《CC笔记》为例。

CC Note功能背景：

我们发现，即使一线业务人员拿到官方的产品介绍资料后，也会利用微信笔记（微信内置功能，类似有道云笔记，主要功能是可以自由编辑图片、文字、视频，插入地址）将产品介绍资料整理后，通过微信转发给目标客户。

经过进一步调研，我们发现业务人员觉得官方的介绍信息过于“官方”，不够站在用户的角度，目标客户在查看时需要进行两次转换。存在两个问题：

我们在设计的时候就考虑到，第一个版本要先替换CC Notes。战略层的定义：

当需求明确了，策略明确了，下一步就是定义产品范围。

CC笔记功能需要替代微信笔记，产品价值公式中，产品价值=（CC笔记功能价值-微信笔记价值）-替代成本>0

因为当时我们的产品载体是微信小程序，从操作体验来看，非原生的CC笔记功能是无法超越微信笔记的。这个公式里，CC笔记功能价值=自编能力+数据能力。其中CC笔记的自编能力是短板，所以策略是强化数据能力，降低CC笔记到微信笔记的替换成本，从而实现产品价值>0。

在数据能力的设计上，我们希望能够捕捉到顾客在浏览CC笔记时，在每个内容上所花的时间，从而更好地帮助业务人员了解每个顾客感兴趣的内容点。

当时我们的产品还没有这么强的数据采集能力，和研发同事评估后发现这个功能的开发周期比较长，所以在数据采集上做了妥协，功能范围只完成了单条笔记的阅读时长、打开次数、打开时间等大规模客户数据的采集。

在降低替换成本的设计上，考虑到大部分业务人员已经有编辑过微信笔记，我们主要考虑支持两种方式：一是将微信笔记转换成长图再上传到CC笔记；二是支持复制微信笔记内容，粘贴到CC笔记中。

最终我们框定的范围如下：

第一个版本主要完成CC注释的替换；第二个版本支持管理员审核，规避内容风险。后来我们进行了两个试点，运行两周后发现数据不如预期，只有少部分业务人员完成了注释创建。通过数据分析我们发现主要原因是替换成本太高，很多业务人员在粘贴、编辑过程中遇到了很多问题。

通过这个例子，大家应该能感受到功能范围的把握有多么困难。我自己对功能范围的总结就是一定要和战略层紧密结合，战略层之外的功能要坚决移除；范围内的功能要能满足用户的需求。

如果我要再次定义范围，我会将其修改为如下所示：

图中黑色部分是修改后的部分，我会去掉一些其他类型的分享，只保留核心的分享功能。至于更换成本，管理员会为销售人员预设模板，以降低微信笔记的更换成本。

后来我们通过对后台预设模板进行小小的功能改动，成功将CC Notes变成了销售人员最喜欢的功能之一。

3.结构层

对于非信息类产品，结构层主要关注交互设计。产品经理需要更多考虑什么样的交互才能让用户满意？市场上主流的用户操作习惯是什么？你的目标用户群体的主流交互流程是什么？交互设计能否降低用户对功能的认知，减少用户的误操作？

4.框架层

框架层的设计一般都是围绕某一功能页面进行，设计的时候需要对框架进行划分，帮助用户优先看到自己想要看到的内容。在目前的互联网功能划分下，UX/UI同事一般都会进行相应的设计，这里就不再赘述了。

5.表示层

当前的互联网产品设计中，主要注重的是视觉设计，一般的产品解决方案并不涉及这一层。

作者：劳华胜，5年SaaS产品经验。目前在房地产营销垂直行业，拥有微信生态营销和丰富的B端0-1产品经验。