编辑导读：SaaS行业这几年在中国快速发展，吴晓波认为2020年是中国企业服务的元年。而作为一个SaaS产品经理，应该具备哪些能力呢？本文作者从自身工作经验出发，对此发表了自己的看法，与你分享。

去年吴晓波曾在一场演讲中说：“我会把2020年称为中国企业服务的元年。”的确，由于疫情的关系，2020年企业协同办服务浩浩荡荡进入公众视野，钉钉、飞书、企业微信等产品扶摇直上，与此同时，推进了整个SaaS行业的迅速发展。例如，一些依托于钉钉的SaaS公司2020年收入涨了3倍以上。

中国的SaaS行业，确实是近几年才开始快速发展起来，这中间还有产业互联网概念兴起的功劳。作为一个SaaS产品经理，很幸运我见证了这几年这个行业的日新月异，也看到了一些想进入这个行业的同行们的困惑——SaaS产品经理应该具备哪些能力？今天我想来谈谈对于这个问题的看法。

无论是B端还是C端，产品经理都是担起对产品进行规划和管理职责，创造用户价值和商业价值的那个人。我认为一个优秀的产品经理宏观上要能深钻行业，洞悉大势；微观上又能不骄不躁，写好每一个PRD，画好每一个原型。因而我认为产品经理的能力模型可以抽象为“认知—判断—执行”。

• 认知能力：指人脑加工、储存和提取信息的能力，即人们对事物的构成、性能与他物的关系、发展的动力、发展方向以及基本规律的把握能力。
• 判断能力：判断能力是人在思维的基础上对事物进行分析、辨别、断定的技能和本领。
• 执行能力：执行力就是一种把想法变成行动，把行动变成结果，从而保质保量完成任务的能力。

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

一、认知

1. 认知SaaS

SaaS是Software-as-a-Service的缩写，意思为软件即服务，即通过网络提供软件服务。目前SaaS产品主要分为三大类：行业 SaaS、职能 SaaS 和通用 SaaS。

• 行业 SaaS 是解决垂直行业的一揽子需求，如地产行业的明源云、餐饮行业客如云等。这种类型的产品，具备高度的行业属性。
• 职能 SaaS 是解决企业里模块化的需求，具备泛行业化、聚焦特定场景的特点，如EHR领域的北森、i人事；CRM领域的纷享销客、销售易等。
• 通用 SaaS 则不分行业和职能，如 tapd、钉钉（办公协同），企业微信、飞书等。

SaaS公司为客户提供产品服务的交付方式主要有以下三种：

• 项目交付：case by case，以项目实施方式进行交付，也就是传统的私有化部署的形式。
• 标准化产品解决方案交付：主要是以公有云的方式，为客户提供标准的整套系统解决方案。这也是SaaS公司最主要、最理想的交付方式。
• 以aPaaS技术能力进行交付：通过低代码、零代码的方式提供技术平台，借助可自由配置的字段能力、流程引擎能力，由甲方it人员或公司运营人员配置成系统解决方案。

从这里就能看出，SaaS的行业经验壁垒相对较高，对产品经理提出了非常高的要求。具体到工作中不仅需要产品经理对整个行业有一定认知，也需要对自己产品的垂直领域有深入的了解。

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

SaaS的商业模式是通过规模化服务客户来摊平自身公司的运营成本，从而获得营收。

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

目前，我发现国内有些公司已经有基于SaaS模式产生的一些新的商业模式。主要有两类：

• 平台衍生类服务：如易订货，产品是为中小商家提供采购管理的SaaS产品，这一产品连接供销两端（采购方和供货方），具有供应链平台型产品特质，因而在累积了大量用户后，形成了自己的平台生态，易订货在此基础上衍生了为中小商户提供的金融贷款服务。
• 产业服务改造类：如面向C端用户的APP小豆苗，产品核心是为C端用户提供预约接种服务。为了挖掘新的增长点，更好地服务用户，入局产业端衍生了为中小社区诊所提供的SaaS产品。

2）为什么这些年SaaS会备受追捧？

如果对国外互联网比较了解的同学不难发现，国外互联网头部公司大多都是to B，如微软、IBM等；而国内互联网巨头公司目前都还主要是to C。

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

在目前B端服务IaaS、PaaS、SaaS三种模式中，SaaS是距离客户最近的模式；同时SaaS模式本身天然具备两个优势：

1. SaaS公司在续费率足够高的基础下具备稳定的客户群体，稳定的现金流；
2. 随着SaaS产品的打磨，产品的标准化能力越来越来强，具备越来越强规模化能力的同时，产品接入的边际成本也越来越低。公司毛利率可以逐年递增。

SaaS这一商业模式不仅有稳定的客户群，还有逐年递增的毛利率；同时还存在和传统行业结合迸发出产业互联网的巨大想象空间，这就是为什么这几年SaaS被资本火热追捧的原因。

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

如果我们选择创业或公司要向SaaS转型，在抛开外部市场竞争的情况下，必须考虑要进入的赛道，其市场规模是否能够覆盖公司运营成本。其中市场规模=客户付费能力*客户付费意向*客户数量。

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

橄榄型市场：

最适合SaaS模式切入的是橄榄型市场，即头部客户少且数量规模一般，腰部客户众多，长尾客户少。

国内头部公司，普遍会有数据私有化、服务定制化的需求，SaaS公司接入过多很容易进入“项目制”的陷阱，走上和软件实施公司一样的“不归路”。

而行业内尾部客户因处在“生死边缘”，存活时间短（中国公司平均存活时间2年半），付费意愿和付费能力都较差，且具有非常高的死亡率，与此同时，还需要对新入行的长尾客户不断投入获客营销成本，投入产出低。所以腰部客户是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产品经理需要具备：

• 业务系统能力。因为SaaS一定会有很强的“业务”属性。如果你去EHR SaaS公司求职，公司一定会要求对EHR领域有一定的经验要求；如果你去求职垂直行业，比如房地产SaaS公司，一定会要求对房地产行业有较深的理解。因为只有对行业足够深入了解了，具备高屋建瓴的前瞻性，了解行业发展趋势和变化，才能打造出好的SaaS系统，为客户创造价值。
• 标准化能力。因为产品的本质是通过规模化来摊平成本，你在产品设计过程中制造的“重构”缺陷越少，你的团队研发成本越低，标准化的能力越高，越能降低公司成本。而这种能力需要具备极强的行业理解能力和抽象能力，后续我会在在“判断篇”进行说明。

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

和其他的产品一样，SaaS产品也有生命周期，吴昊老师的《SaaS创业路线图》会有更清晰的解答，推荐给大家阅读，老花生就不在此赘述了。我来重点和大家聊聊SaaS产品MVP阶段和C端产品的差异点。

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

在产品规划设计中，C端产品需要不断为用户提供价值，用腾讯的话来说，“一切以用户价值为归依”。假设你的产品终极价值是要帮助用户更快到达某地，那在MVP版本设计时，你需要做的就是交付更小成本、更快到达某地的工具。从产品功能层面来讲，你需要确保交付产品每个版本的完整性、可用性。就如上图所示，要给个滑板而不是车轱辘。

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

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

但需要注意的是，在产品功能设计层面，如果产品终极价值是要给帮助用户更快的到达某地，而现阶段受限于技术实现，最快的交通工具只能是汽车时，那你就必须造车。而不是一开始交付滑板，然后是自行车。如果你这么干了，那后续每次版本迭代都是一场“重构”灾难。

二、判断

判断力实际是依附于认知能力之下的，认知不对则判断有误。落地到实际工作层面，一个产品经理的判断力体现他对需求真伪、价值、优先级的判断。

1. 判断需求

在一般SaaS公司的架构下，B端产品经理普遍离客户有些距离，一般中间会夹杂着“客户成功”这一角色。因此目前B端产品大部分需求来源于客户成功同事转述过来的需求。在这个过程中，存在着大量信息失真的情况，因此saas产品经理经常要做一件事情——判断这个“需求”是不是一个需求中，存在着大量信息失真的情况，因此saas产品经理经常要做一件事情——判断这个“需求”是不是一个需求。

1）接收到的是不是一个需求？

人们在现实世界中，往往都是下意识反馈解决方案的。比如朋友跟你说，你拿下锤子和钉子给我，如果你不进行深入挖掘，把锤子和钉子理解为他的实际需求，是无法挖掘到他的真实动机其实是要挂结婚照，而也许我们可以提供比锤子和钉子更好的解决方案。所以产品经理在日常的一些需求list中，要注意去区分什么是客户的真实需求，什么是客户自己提供的解决方案。

行业内早有范式对需求进行了规范，如果你能形成这种思考习惯，就能很容易跳出解决方案桎梏。范式如下：

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

我们按照上文的例子代入。

作为已婚人士，他需要一种方法来  让他的结婚相框挂在墙上，然后  让他时刻想起婚姻的甜蜜。

我们再举个例子：你的客户跟你反馈，我需要在系统后台的首页上看到，今天店铺一天的汇总交易数据。

按照这个范式。

• 错误的方式：作为店铺老板，我需要一种方法  在后台首页看到最新数据，然后快速了解今日店铺经营情况。
•  正确方式：作为店铺老板，我需要一种方法  帮助我快速了解店铺经营情况，然后  我有更多的时间做其他更重要的事情。

这个范式最好的地方是，特意将解决方案缩略表述成一种方法，为的是让你聚焦在需求的同时，还能开阔你的思维。避免被框定在具体的解决方案中，进而可以了解到客户的本质需求。

就拿上面这个例子而言，如果你思考的是错误方式，你的思考范围一定是想着在后台首页增加什么类型的数据，怎么加入数据的问题。如果你思考是正确方式，我想你一定会挖掘出更好、更优的解决方案。

2）判断需求的合理性

在B端的产品设计中，产品经理会遇到一些需求对于某个角色而言，是合理且可行的。但是这个需求对于组织或者其他角色有一定的利益损害。这时，就需要产品经理有较强的利益权衡能力。

在to B行业内，有一个老花生不是太认可的产品“流派”：TO BOSS流派。他们认为，在B端产品设计中，一定要优先注决策者的需求而非使用者，BOSS就是典型的决策者。当然我觉得TO BOSS在大多时候都没有什么问题，毕竟成单和续费的决策都在BOSS上，这无可厚非。但凡事都需要有批判思维，需要辩证的去看待决策者的需求。

举两个例子：

第一个是去年疫情期间，有些营销SaaS公司，为了满足BOSS需求，推出了全员营销功能，帮助BOSS更好的去监控员工带来的客户量，甚至将该功能当成亮点功能推向市场。

我对于这个事情的看法就是，没有权利就没有义务，员工与公司应该是双赢的模式，如果只有单方面的员工义务，公司也必然会在某些方面有着看不见的损失，这并不是长久之计。

第二个例子是前年的时候，我们产品上遇到一个类似的需求，当时业务方为了更好地了解到店客户画像，要求业务员填写全部到店的客户印象资料，要求完成度达90%以上。对于业务员来说，如果当日到店客户较多，这基本是一个无法完成的事项，而且相当多的印象资料信息对于业务员而言，无任何实质性帮助。

当时我们也是基于BOSS优先的逻辑进行了产品设计。在产品运行了一段时间后，我们发现了2个严重问题：

• 第一是业务员出现了极大的不满的情绪，甚至开始抵制使用产品；
• 第二，因为印象填写本就主观，出现了大量业务员随意填写的数据，不仅背离了当初对到点客户进行画像分析的初衷，还产生了大量垃圾数据。

通过上述例子可以看到，to B的产品设计中，想要产品具备长久的生命力，必须要权衡整个生态环中各个角色的利益平衡，而不是一味从决策者的视角进行设计。

3）判断需求优先级

需求优先级判断是产品经理的日常工作之一。如果排除一些特殊原因，如boss指定、政策要求等外，我一般会遵循投入产生比来进行判断。

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

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

（其中用户数量一般是看这个需求涉及的用户规模）

曾经有一个同事告诉我，他了解到腾讯微信上，只要有任何一个小小的改动，都需要经过张小龙进行方案评审并确认，而且经常是做的方案多，通过的方案少；而在我们公司，有大量的功能只需要做到组内内审，即可通过。为什么我们不像微信一样做？

其实认真想想就能明白，因为彼此产品的用户量，差了近几十倍，用户完全不是一个量级，需求价值大小也不一样。

不知道大家有没有发现，有些优秀的产品在一些异常场景的处理上，处理的也不尽人意，只是预留了人工介入的入口。其实原因是场景发生的频次过低，需求价值太低。

而对另一些产品来说，即便场景发生的概率是万分之一，也是需要介入进去满足需求的，这又是为什么呢？究其原因，主要是这个场景对于用户来说，极其重要，就像我目前在处理的交易环节，任何细节上的异常流程，即便发生概率极低，都是需要去介入解决的。

在需求实现投入成本上，这个就需要产品经理具备一定的技术理解深度。一般来说，有一定技术理解和很了解系统实现的产品都能有一个大概投入人力、研发时长的判断。

2. 判断方案

需求确定的情况下，解决方案的优劣判断也极其重要。对于SaaS产品而言，产品标准化是极其重要的能力之一。SaaS产品经理一定要对解决方案心存敬畏，如果你在过往设计中，设计了“带病”的方案，那么一定会在后续的产品迭代中给你带来诸多困难，甚至把公司拖入泥潭。

那如何判断解决方案是否可行？可以从以下两点进行判断。

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

方案是否可以满足需求，可以代入用户视角，查看方案是否能满足需求，这基本对用户有较深的了解的都能进行判断。

2）解决方案是否具备可扩展性和普适性

可扩展性和普适性需要产品经理要具备极强的抽象能力，能理解业务模块的边界和关联关系，像B端产品经理经常接触的后台权限RBAC模型就是经典的产品抽象模型。下图是一个电商促销的产品模型，因为这块过于抽象，有机会再跟大家聊聊怎么设计。

但解决方案的判断上，不仅仅只要求产品经理会抽象建模就行了，还需要产品经理具备很好的抽象粒度的把握能力，避免出现过度设计。

过度设计（over-engineering）是指设计出来的系统复杂臃肿，过度封装、一堆继承、接口和无用的方法，超复杂的xml配置文件。简言之，客户需求是要一把杀鸡的刀，你给设计了一把牛刀，杀鸡焉用宰牛刀？

举个例子，有一些C端运营后台或者是轻量型的后台，其权限设计特别简单，甚至不进行对应权限的控制，如果你作为公司的产品经理，一定要将最复杂的RBAC（3）那套权限模型运用在你的后台，这就是明显的过度设计。

那如何判断是否存在过度设计？就是拿最常见的场景代入查看，如果配置或操作会变得异常复杂，那可能存在过度设计。

三、执行

大家应该不难发现，现在市场上因对产品岗位的理解不同，对产品的要求也不一致。像一些传统软件实施公司，对于产品经理的要求一般只需要进行需求管理，而在一些新兴互联网公司，普遍还会要求产品经理兼任一部分项目经理的职责。

产品经理的主要职责还是进行需求管理，今天我们主要聊聊这个部分。

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

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

我们主要是基于用户体验五要素的方法进行对应的方案设计。可能很多同学对这个方法很熟悉了，但实际工作中能按照五要素进行拆解和设计方案的产品经理真的为数不多，甚至有些“老手”都无法理清楚自己的PRD是如何对应五要素的。

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

1. 战略层

设计战略层的时候，需要产品经理能清晰地回答两个问题：一是“用户通过产品能获得什么价值”，二是“我们能从产品中获得什么”。用俞军老师的话总结来说，产品是用户和企业交换价值的载体。

而战略层一般对应PRD中的背景说明。

以后台权限管理模块的方案为例。战略层就是：

• 用户可通过权限管理模块，灵活地进行权限配置，以便保障业务信息安全和业务正常运转；
• 我们能从这个产品模块获得客户对系统功能的认可，提升客户满意度，从而提高产品在市场上的竞争力。

往往很多产品经理，因为对战略层的不清晰，导致整体的产品设计偏离战略层，致使一份“无效”产品方案的产生。

2. 范围层

范围层的定义是指产品涉及的范围，其中包含产品边界、功能的范围，用户需求的范围等。而范围层的设计极其考验产品经理的能力，既需要考虑怎么样的范围能完成战略层产品目标，又需要对用户的需求有着极强的把握。

如果产品经理对范围层没有很好的理解，在产品设计上就很容易产出一些“大而全”的产品解决方案，这种方案如果单从正确度和完整度层面讲，是没有什么问题的，但就是无法回答“why now”这一问题，会让研发团队耗费大量的时间在处理一些在当下价值低功能，从而白白错失市场机会。

关于范围层的判断，就拿我之前设计的一个从0-1的小产品模块——“CC笔记”为例吧。

CC笔记功能背景：

我们发现一线业务人员，在已经给到产品官方介绍资料的情况下，还会自己用微信笔记（微信自带功能，类似有道云笔记，主要功能是可以自由编辑图文、视频和插入地址）重新整理产品介绍资料，通过微信转发给到目标客户。

我们深入了解后，发现业务人员觉得是官方介绍信息过于“官方”，不够具备用户视角，目标客户查看时需要二次信息转换。其中存在两个问题：

• 第一，因为使用的是微信自带功能，转发给目标客户后，无法获知客户是否打开查看，也无法进行获客。
• 第二，业务员的管理者担心无任何约束的产品介绍，会存过度宣传的可能，有较高的内容风险。

那我们在设计的的时候，考虑到第一个版本，先要完成CC笔记的替换。对战略层的定义：

• 对用户而言“一线业务人员在CC笔记功能上能体验到和微信笔记一样的功能，并可以获得客户相关浏览数据，帮助业务人员了解目标客户关注点，促进成交”。
• 对于这一版本而言“我们通过最小mvp版本完成CC笔记对微信笔记功能的替代，提升我们产品的使用率”。

在需求明确，且战略层清晰的情况下，接下去就是如何框定产品范围。

CC笔记功能要完成微信笔记的替换，在产品价值公式上，需要产品价值=（CC笔记功能价值-微信笔记价值）-替换成本 >  0

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

在数据能力的设计上，我们希望能做到客户在浏览CC笔记内容时，抓取客户在每个内容上的停留时间，从而更好的帮助业务人员了解每个客户感兴趣的内容点。

当时我们产品并不具备这么强的数据采集能力，和研发同事一起评估确定这个功能研发周期相当长，于是在数据采集上做了妥协，功能范围只完成了客户大粒度数据的采集，如单篇笔记的阅读时间、打开次数、打开时间等等。

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

最后我们框定的范围情况如下：

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

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

如果重新来框定一次范围，我会修改成下图所示：

图中黑色部分为修改部分，我会将一些其他类型的分享，进行移除，只保留核心分享功能。对于替换成本，采用管理员给业务员预设模板来降低微信笔记的替换成本。

后来我们也通过后台预设模板这一小小的功能改动，成功将CC笔记变成了业务员最喜欢的功能之一。

3. 结构层

对于非信息型产品来讲，结构层主要交互设计。产品经理更多需要考虑怎样的交互可以使用户满意？市场上主流的用户操作习惯是怎么样的？你的目标用户群体主流的交互流程是怎么样的？能不能通过交互设计降低用户对功能的认知和减少用户的误操作等等。

4. 框架层

框架层的设计，一般已经聚焦在某个功能页面之上了。在设计时需要通过框架的划分，帮助用户优先看到他想看的内容。目前的互联网职能划分下，一般UX/UI同事会进行对应的设计，此处就不赘述。

5. 表现层

在目前的互联网产品设计，主要是视觉设计，一般产品方案不涉及到这一层。

作者：老花生，5年SaaS产品经验。现地产营销垂直行业，有微信生态营销和丰富的B端0-1产品经验。

本文由 @82年的老花生 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议