**
写在前面
有这样一个场景
⽼板/⽤户：我有⼀个特别棒的想法，优先级很⾼，你赶紧把⽅案产做出来。
产品经理：保证效率！我⻢上就开始画原型，然后内部评审，接着推进开发。
这时候部分产品经理急于表现，需要将需求快速落地，第⼀反应就是开始执⾏，所以经常会发⽣⼀种情况，产品经理很努⼒的去做，把需求或想法百分百的去还原，但结果⽼板或⽤户体验完之后发现，这并不是我想要的功能。出现这种情况的原因是产品经理没有****了解到这个需求背后的动机和⽬的，这是很多⼩伙伴容易出现的问题。而SaaS产品设计，不仅仅只关注设计，在此之前我们更要关注产品的定义。需要我们想清楚这个需求对应的场景是什么，场景中的需求价值是什么。之后才是结构化的框架把功能设计出来。
文章整体分为以下几个部分
1.SaaS产品设计痛点场景拆分
2.SaaS产品不同维度的认知
3.我们通过什么方式去理解业务
4.我们如何梳理业务判断需求价值
5.我们如何设计产品架构与功能
6.SaaS产品生命周期中的设计原则
以下，咱们一起进入正文~
1.SaaS产品设计痛点场景拆分
1.1.SaaS产品经理的工作方式
SaaS产品经理⼯作本质是从发散到收敛的⼀个过程。发散是指产品的定义，收敛是指产品的设计。但往往很多产品经理⼀上来就开始收敛了，开始画原型，好⼀点的产品经理可能先去思考这个功能影响的范围，影响的⾯。最后梳理出⼀个脑图，⽤这个脑图去跟开发去碰，**但是⼀个优秀的产品经理除了⼀上来就收敛之外，****其次需要我们思维先发散，**最终产品定义这个场景对应的价值是什么。
1.2.SaaS产品理解业务是进⾏需求梳理与功能设计的前提
在这⾥在跟⼤家分享三个场景：
**场景一：**很多同学都是半路转⾏过来做SaaS产品经理，往往会遇到不知道如何去跟进⾏业的趋势，同时也不知道如何去做业务调研。⽽对于业务理解的⽋缺也直接影响到对应的产出，这时候根据对业务理解而设计的产品⽅案也会被吐槽，不懂业务。这种场景我相信很多SaaS产品经理都会有许多感触。【理解业务难】
**场景二：**很多产品经理由于之前经验习惯，专注思考单个场景下的⽤户价值，在这时候会导致在思考业务场景时经常出现遗漏，从而导致业务⽆法闭环，终端⽤户对产品感到满意，却没有直接转换成付费。【需求梳理不清晰】
**场景三：**产品经理进⾏了全盘梳理，理清价值之后，全身⼼投⼊产品设计中去，然⽽业务出现了⼀堆个性化需求，产品经理硬着头⽪单点设计，最后演变成定制化设计，导致产品逻辑异常复杂，研发成本也不断升⾼，终端⽤户在前端界⾯也会吐槽越来越复杂，不知道怎么⼊⼿了。 【功能设计复杂】
出现上面三种场景情况的原因是SaaS产品有⾮常强的业务壁垒，所以不同⾏业产品经理会出现隔⾏如隔⼭的情况，产品设计不清楚具体场景的痛点和难点。其次是SaaS****产品业务流程是⽐较复杂的，看似简单的功能也会涉及多个⻆⾊，所以需要通盘考虑。最后SaaS产品个性化需求⾮常多，需要满⾜不同个性化需求，所以导致设计⽅案复杂。
所以接下来的文章也会围绕这三个场景去跟大家分享对应的产品方法论。
**2.**SaaS产品不同维度的认知
2.1.SaaS产品认知的歧义
很多⼈认为SaaS产品是toB产品，但从本身定义软件即服务来看，即没有说是toB也没有说是toC。而⼴义的SaaS定义是既有toB也有toC（比如印象笔记/⽯墨⽂档）。从软件交付⽅式来讲，SaaS本身作为一种交付模式，本身不存在toB或toC之分。从商业模式来讲，如果我们把toB产品定义为基于互联⽹提供服务，⽤以提升企业效率，增加企业收⼊的产品，那么SaaS产品可以算是B端产品的⼀个分⽀。
2.2.SaaS****产品不同维度的认知
SaaS模式的出现很⼤程度上是顺应⽤户对数据安全和低维护成本的需求⽽衍⽣的。
**SaaS****产品划分：**业务垂直型（提供⾯向特定业务的SaaS解决⽅案 ⽐如：crm erp等）、⾏业垂直型（提供⾯向特定⾏业的SaaS解决⽅案⽐如零售电商、餐饮、医疗、制造业）⾏业和业务之间肯定有交叉的，⼀个SaaS产品既会有特定的业务，也会⾯向特定的⾏业。
SaaS产品特点：
云端架构：SaaS公司提供服务器、数据库等硬件，⽆需本地部署；
成本下降：⽆需客户承担基础设施成本、⽇常运维成本，付费灵活；
⽤户按⽉/年⽀付费⽤，⽽⾮⼀次性购买，体验提升；
后续升级维护由SaaS公司负责，通过数据驱动迭代。
**SaaS****产品业务阶段：**整体划分为四个阶段，基础产品完善期、⾏业产品深⼊期、⽣态建设期、再创新。
3.我们通过什么方式去理解业务
3.1.业务理解**=行业模式（宏观）+**企业运作流程（微观）
对业务的理解我们可以由抽象化转换为具象化，本质需要从⾏业模式和运作流程去了解。懂⾏业模式是要能够理解约定俗成的玩法和规则是什么。懂运作流程是⾏业中某个企业不同岗位/⻆⾊如何各司其职的。运作流程是⾏业模式的直观体现，⾏业模式⼜为理解运作流程提供指南针。理解⾏业的限制，了解他的客观规律从⽽避免⾛弯路，理解运作流程从⽽能够还原场景，并设计功能满⾜需求。所以我们需要通过⾏业分析了解⾏业模式，通过业务调研了解某个企业的运作流程。
**⾏业模式：**从宏观⻆度，我们了解⾏业内企业相应业务的玩法，从⽽抽象出通⽤的玩法和规则，这样我们才可以了解企业的核⼼痛点，其次也为SaaS产品及服务提供⽅向指南。
**运作流程：**从微观⻆度，对于每个企业我们需要了解企业内部不同员⼯是如何操作的，最终实现公司业务运转，了解这些才能使我们产品设计更加落地。
3.2.行业模式（宏观）****：如何快速了解一个行业
SaaS产品经理算半个⾏业专家。
⽹上做⾏业分析的⽅法有很多，重要的是需要找对维度，不能只停留在⼤范围层⾯，⽽是需要聚焦于我们⾃身业务的边界。关于维度层⾯这边跟⼤家分享五个分析行业的维度，分别是：⾏业基础信息、外部经营环境、内部市场环境、标杆企业分析、SaaS竞品分析；
通过上诉⼏个维度我们可以快速了解⼀个⾏业，但是往往实际工作场景是我们做出了⼀份分析报告，但不知道真正作⽤在哪⾥。这种情况下需要回归到本质，我们是为了了解⾏业通⽤规则和玩法，最终服务于⾃身SaaS业务。
3.3.企业运作流程（微观）****：如何进⾏业务调研
先跟⼤家讲讲C端产品的⽤户调研与SaaS产品业务调研的区别，C端⽤户调研只需要关注单点⽤户，SaaS业务调研需要全盘考虑整个业务流程，这也是很多转⾏做SaaS产品经理会按照以前的调研⽅式，去做业务调研，容易导致产品流程上没有闭环。其次C端⽤户调研需要以⽤户体验为中⼼，相对于来说SaaS产品更关注需求，解决了什么业务问题。最后C端产品⽤户需求层⾯相对于容易抽离共性，SaaS天然存在⼤量个性化需求且极度分散。而且C端产品⼀般都是⽤户可以通过共情来挖掘潜在需求，SaaS产品经理通常不是⽤户，需要通过理解业务来挖掘需求。
3.4.运作流程要素与调研步骤
业务调研最终是为了理解业务的运作流程，运作流程包括的元素有什么：企业（通过定义标杆企业描绘客户画像）、⻆⾊（通过查看组织架构和参考同类型企业来梳理⻆⾊特征）、流程（通过观察与调研了解核⼼业务的⼯作流）。
业务调研整体分三步：
第⼀：定义并选择标杆企业。在这⾥需要定义标杆企业的客户画像，以标杆企业的需求为核⼼。客户画像包含（客户/企业规模、从属细分类⽬、业务范围），在这⾥为什么我们需要选择标杆企业的原因是在于标杆企业需求具有代表性，相对容易抽离。其次也是因为标杆企业的声⾳有影响⼒，后期能够引领其他客户。
第⼆：梳理业务链条的⻆⾊。在这⼀步梳理好业务流程中的关键⻆⾊之后，我们需要定义⻆⾊的特征（主要负责什么、业务⽬标/KPI是什么、职业特点是什么），怎么找到这些业务流程中的关键⻆⾊，第⼀可以从企业的组织架构中寻找，这是最便捷也是最直接快速的⽅法。在得不到组织架构的情况下，可以参考同类型企业的流程及⻆⾊（当然这⾥的企业也是属于标杆企业），在做整体⻆⾊梳理的时候我们必须要注意业务的闭环，如果忽略了业务链条不重要的⻆⾊，可能会导致业务⽆法闭环。
第三：观察与调研并⾏。在梳理完业务流程之后我们需要通过观察与调研，理清⻆⾊的⼯作流（核⼼流程）。对于SaaS产品来说，观察⽐直接开放式调研更有效，这么说的原因是在于产品很难从根上去撼动绝⼤部分公司的业务模式，所以我们侧重在还原业务，⽽⾮创造业务，还有⼀个原因是调研过程中多少都会有主观成分在，所以需要通过观察还原业务。观察的⽅式我们可以通过驻场，深⼊业务需求⽅的⼯作场景，观察他们平时的⼯作⽅式。在观察的同时我们也需要得到这个⻆⾊的⼯作流是什么样⼦的？有没有标准化流程？在什么情况下，执⾏了那系列任务，完成了什么业务上的⽬标？还有⼀种⽅式轮岗机制，有机会的话能够直接上⼿体验业务⽅的⼯作是最好的。⽤户调研主要从流程维度和具体场景维度去设计调研问题。
在理解业务这个层⾯上我们需要循序渐进的，理解业务没有太多的技巧，通过观察和调研交叉，了解⽤户**/⽤户需求，并通过产品设计满⾜需求，了解反馈，进⽽根据反馈持续满⾜需求----通过不断地这样循环深耕业务，才能不断深化对业务的理解。**
4.SaaS产品如何梳理业务判断需求价值
很多产品经理在做了⼀波业务调研之后，也对业务有了⼀定程度的理解，认为接下来就该到需求分析了。其实不是这样，除了对业务要有⼀个深度了解之外，还需要还原业务中遇到的场景是什么，用户需求价值是什么。如何去判断需求的价值，其实本质是我们需要在产品定义这个环节去梳理清晰。
产品定义分两个部分：第⼀回归场景（梳理并描述业务场景），第⼆理清价值（判断场景中需求的价值）。
4.1.为什么要回归场景？
在这个跟⼤家描述两个我们常⻅的⼯作场景，很多时候产品经理在提出产品⽅案时，⼤家围绕实现细节开始讨论的时候容易出现，‘我觉得’的⽅式来表达⾃⼰的观点，每个⼈都有⾃⼰的想法，⽆法达成统⼀的意⻅。还有⼀种情况是在没有理解场景的情况下直接开始画原型，这时候会出现我们产品上线之后总是不符合实际线下流程，还得推倒从来。
现在我们回想上⾯两个场景中为什么出现这种情况，本质是因为产品经理对外（项⽬组其他⼈），完成⼀项任务肯定是需要多个部⻔多个⻆⾊频繁的传递⽤户需求，因此使⽤⼀套易理解，贴近实际的沟通的⽅式就很重要，⽽场景就是通⾏于不同⻆⾊之间解决产品问题的语⾔。
对内 （⾃身思考）产品设计我们需要先发散后收敛，因此动⼿画原型，写⽂档之前我们需要做⼤量的思考，调研。逻辑基点是⽤户⾯临的实际情况到底是什么样的，即回归场景。
4.2.单个场景与多个场景
在单个场景上，SaaS产品不能创造，只能还原。这也是和C端的区别点，C端因为⾃⼰就是⽤户，可以以发散的⽅式创造场景，从⽽引领⽤户需求。SaaS业务天然存在壁垒，⽆法发散获取，只能还原场景，且颗粒度需要更细。在多个场景上，SaaS产品需要考虑业务的闭环。同样以C端举例，c端产品相对简单，重点在于单点突破核⼼场景。SaaS产品业务链⻓，缺少任何⼀个必备场景都可能⽆法闭环。所以回归场景我们需要先将单个场景描述清晰，进⽽梳理链条中的全场景。
4.3.场景我们该如何去描述
回归场景我们需要通过⼀种通⽤的场景描述⽅式，对内形成自己的思考基点，对外让⼤家形成共识。在这里跟⼤家分享⼀种场景描述⽅法，场景描述的7要素（⽤户、环境、时机、⽬标、动作、截⽌、任务）SaaS产品的场景是真实存在的，不是凭空捏造的。需要在真实业务中得到验证。场景描述⽅式本身不重要。重要的是对外能够形成统⼀的认知，对内思考能够还原⽤户实际情况才是关键。
针对单⼀的场景我们可以通过单⼀场景描述⽅式去还原，针对多个场景时我们可以借助场景需求清单，场景需求清单是多个场景串联形成的结构化信息，他是⼀个业务链条下的场景拆分后的需求集合，场景需求清单可以帮助我们梳理业务链条下的场景关系，避免遗漏影响业务闭环的场景。基于之前的调研，找到关联步骤/流程，根据流程还原每个流程下的代表性场景，并拆解出需求。核⼼步骤提炼成三步：第⼀梳理出清晰地业务流程、第⼆将场景归类到流程中、第三基于场景拆分⽤户需求；需要注意的是每个流程下可以写多个具有代表性的分⽀场景，同时我们也可以把⻆⾊标注出来。
示例：场景需求清单
当场景清单⾜够庞⼤时，我们需要对原有的场景需求清单进⾏抽离，抽离出最关键的类别/流程，以及其中不可或缺的场景形成场景需求清单，这⼀步的核⼼在于如何抽离（需求理解业务），说到核⼼场景我们需要前⾯提到的业务闭环，业务闭环我们可以定义他为为了完成⽬标下的最⼩步骤的集合，核⼼场景即最⼩步骤的展开，对于最⼩步骤依赖于对业务的理解，需要站在业务员的角度，来看哪些是不可或缺的，同时我们需要考虑到意外情况下的分⽀场景，如果出现意外情况⽽导致业务⽆法进⾏，业务⽆法闭环，那么也会导致⽤户放弃使⽤产品。讲到这⾥我们发现核⼼场景也是MVP版本。
4.4.宏观与微观的价值理清（理清价值）
价值主张与需求对应的价值，两者之间产品的价值主张为判断需求的价值提供⽅向和原则，⽽不同需求价值的积累进⼀步巩固价值主张。
**价值主张（宏观）：**为特定⽤户群体提供差异化价值，价值主张是进⾏需求判断的第⼀原则，SaaS产品应该尽可能满⾜每个客户的个性化需求，但不该包含与价值主张完全不⼀致的需求。如果在实际⼯作中遇到需求判断经常找不到⽅向，也许应该开始思考产品的价值主张。
**需求价值（微观）：**需求的两种价值⼀是⽤户价值（给产品⽤户带来什么），另外⼀种是商业价值（给SaaS⼚商带来什么），针对⽤户（我们提供业务闭环类价值、效⽤类价值、体验类价值）、对于SaaS⼚商（收⼊价值、对⾃身是否能够采集到更多的业务数据价值）。在SaaS产品中⽤户价值中最常⻅的是效⽤价值。
4.5.如何找出场景中的需求价值
找出价值我们需要做的三件事：第⼀需求的⽤户价值是否与产品价值主张相契合？第⼆⽤户的需求价值具体类型是什么，表现在哪⾥？第三需求是否存在商业价值，表现在哪⾥？
4.5.如何判断场景中的需求价值
需求来源于场景，满⾜需求则产⽣价值，⾯对扑⾯⽽来的需求SaaS产品经理更需要清晰理解并判断需求的价值。SaaS产品为什么更需要理解价值，原因在于SaaS场景都是真实存在的，客户就是上帝，不存在伪需求，所以需要对⼤量需求进⾏判断。在需求判断中常规会出现三种场景分别是：
示例：场景需求价值清单
**5.我们如何设计业务架构与功能
**
5.1.什么是业务架构
对于SaaS产品首先我们理解场景七要素中的任何⼀个要素发⽣变化，都会导致场景不⼀样，从⽽产⽣不⼀样的需求。SaaS产品有⾮常强的业务属性，如果缺乏框架性思考，单点设计功能将会让你精疲⼒尽，对内部来说不断堆砌功能，开发成本会越来越⾼，对外部来说⽤户看到的信息繁杂，⽆法⾼效的完成任务，所以我们设计功能前需要理清架构，以⼀种全局的框架视⻆来思考。业务****架构是⼀套功能依据业务进⾏分类整合，形成抽象化的业务模型，架构可以帮我们理清每个业务模块/功能间的边界，以及他们之间的关系，在我们⾯对多个类似的需求时先梳理架构就可以基于场景迅速定位到对应的模块，在设计功能时我们需要重点考虑以⼀个功能满⾜多个类似的需求。
业务架构：架构的作⽤在于建⽴⼀套标准化的业务模型，搭建框架，最终是为了⾼效满⾜⽤户的不同需求。所以也就是我们常听说的后端标准化，前端个性化。理解业务是梳理功能架构的前提。
示例：微信业务架构
5.2.基于目前的场景和需求我们如何梳理架构
梳理架构分成三步⾛：第⼀将场景需求清单拆解到功能、第⼆将功能按不同维度整合、第三梳理模块之间的逻辑关系；在第⼆步将功能按不同模块分类整合时我们先拿出符合通⽤模块的功能，进⾏归类整合，切记重复造轮⼦。不符合通⽤模块的功能，根据业务重要程度和复杂性单独整合。如果有必要根据业务重要程度和复杂性，继续梳理⼦模块。在梳理模块之间的逻辑关系时我们先梳理静态模块（不产⽣数据流），在梳理动态模块（产⽣数据流）。整体表⾯上是梳理架构图，背后是对业务的深刻理解。
架构本质是后端业务逻辑的标准化；在完成后端标准化之后，随着产品的不断发展，我们需要通过可配置的⽅式在前端满⾜⼤量个性化需求，即前端个性化。因为SaaS产品本身特质，我们需要考虑到⼤量个性化需求。那么我们需要考虑如何设计⼀个功能满⾜绝⼤多数需求，核⼼我们需要运⽤可配置去解决前端个性化需求和后端业务归类。
5.3.如何设计一个功能满足不同场景需求
通过可配置化满⾜客户的个性化需求。⼀般会存在两种情况，第⼀是业务流程与现有⽅案差别较⼩，那我们可以从功能层⾯进⾏配置，第⼆是业务流程与现有⽅案差别⼤，那我们从系统层⾯进⾏配置。
在可配置层⾯⼀般来说包含界⾯布局，字段名、验证逻辑、计算规则、审批流配置，⻆⾊配置，⻆⾊功能权限配置，⽤户配置，⽤户数据权限配置等。在产品设计时需要规划好什么样的配置功能开放给客户，什么给到⾃⼰。原则上为了避免客户的复杂度，尽量开放⼩范围的配置功能给到客户⾃⼰使⽤。⾼配置往往会造成低易⽤性，配置项过多会带来⻚⾯不简洁，流程不⾼效；本质上来说⽤户要的不是配置项，是低成本实现⽬标的功能。
在判断功能要不要做成配置时我们可以通过两个维度来做判断，⼀个是模式切换频率，还****有⼀个则是需求的⻓尾程度（⽤户需求差异化程度），针对⼀些默认配置项判断标准我们需要回归到场景，在⼤量同⼀种类型的个性化场景中，找到最核⼼的场景，并根据场景下的功能设计设置为默认配置项。
6.SaaS产品生命周期中的设计原则
通过前面的文章，我们知道了SaaS产品的方法论之后，我们也应该了解底层的设计原则，了解原则的好处有两点，通俗的来说一方面是可以驱动产品优化和产品经理本身的自我成长，另一外面则是可以消除外部给你带来的一些负面影响。
1.原则是自我改善的有利工具，可以在日常工作中验证我们自己的方法论，帮助自己成长；
2.有了原则，就能超脱情绪和环境的影响，自主判断选择最佳方案。
