SaaS产品设计方法论

有这样一个场景：

老板/用户：我有⼀个特别棒的想法，优先级很高，你赶紧把方案产做出来。

产品经理：保证效率！我马上就开始画原型，然后内部评审，接着推进开发。

这时候部分产品经理急于表现，需要将需求快速落地，第⼀反应就是开始执行，所以经常会发生⼀种情况，产品经理很努力的去做，把需求或想法百分百的去还原，但结果老板或用户体验完之后发现，这并不是我想要的功能。

出现这种情况的原因是产品经理没有了解到这个需求背后的动机和目的，这是很多小伙伴容易出现的问题。而SaaS产品设计，不仅仅只关注设计，在此之前我们更要关注产品的定义。需要我们想清楚这个需求对应的场景是什么，场景中的需求价值是什么。之后才是结构化的框架把功能设计出来。

文章整体分为以下几个部分：

以下，咱们一起进入正文~

一、SaaS产品设计痛点场景拆分

1. SaaS产品经理的工作方式

SaaS产品经理⼯作本质是从发散到收敛的⼀个过程。发散是指产品的定义，收敛是指产品的设计。但往往很多产品经理⼀上来就开始收敛了，开始画原型，好⼀点的产品经理可能先去思考这个功能影响的范围，影响的面。最后梳理出⼀个脑图，用这个脑图去跟开发去碰，但是⼀个优秀的产品经理除了⼀上来就收敛之外，其次需要我们思维先发散，最终产品定义这个场景对应的价值是什么。

2. SaaS产品理解业务是进⾏需求梳理与功能设计的前提

在这里在跟大家分享三个场景：

场景一：很多同学都是半路转行过来做SaaS产品经理，往往会遇到不知道如何去跟进行业的趋势，同时也不知道如何去做业务调研。而对于业务理解的欠缺也直接影响到对应的产出，这时候根据对业务理解而设计的产品方案也会被吐槽，不懂业务。这种场景我相信很多SaaS产品经理都会有许多感触。【理解业务难】

场景二：很多产品经理由于之前经验习惯，专注思考单个场景下的用户价值，在这时候会导致在思考业务场景时经常出现遗漏，从而导致业务无法闭环，终端用户对产品感到满意，却没有直接转换成付费。【需求梳理不清晰】

场景三：产品经理进行了全盘梳理，理清价值之后，全身心投入产品设计中去，然而业务出现了⼀堆个性化需求，产品经理硬着头皮单点设计，最后演变成定制化设计，导致产品逻辑异常复杂，研发成本也不断升高，终端用户在前端界面也会吐槽越来越复杂，不知道怎么入手了。【功能设计复杂】

出现上面三种场景情况的原因是SaaS产品有非常强的业务壁垒，所以不同行业产品经理会出现隔行如隔山的情况，产品设计不清楚具体场景的痛点和难点。其次是SaaS产品业务流程是比较复杂的，看似简单的功能也会涉及多个角色，所以需要通盘考虑。最后SaaS产品个性化需求非常多，需要满足不同个性化需求，所以导致设计方案复杂。

所以接下来的文章也会围绕这三个场景去跟大家分享对应的产品方法论。

二、SaaS产品不同维度的认知

1. SaaS产品认知的歧义

很多人认为SaaS产品是toB产品，但从本身定义软件即服务来看，即没有说是toB也没有说是toC。而广义的SaaS定义是既有toB也有toC（比如印象笔记/石墨⽂档）。从软件交付方式来讲，SaaS本身作为一种交付模式，本身不存在toB或toC之分。从商业模式来讲，如果我们把toB产品定义为基于互联网提供服务，⽤以提升企业效率，增加企业收⼊的产品，那么SaaS产品可以算是B端产品的⼀个分支。

2. SaaS产品不同维度的认知

SaaS模式的出现很大程度上是顺应用户对数据安全和低维护成本的需求而衍生的。

SaaS产品划分：业务垂直型（提供面向特定业务的SaaS解决方案比如：crm erp等）、行业垂直型（提供面向特定行业的SaaS解决方案比如零售电商、餐饮、医疗、制造业）行业和业务之间肯定有交叉的，⼀个SaaS产品既会有特定的业务，也会面向特定的行业。

SaaS产品特点：

• 云端架构：SaaS公司提供服务器、数据库等硬件，无需本地部署；
• 成本下降：无需客户承担基础设施成本、日常运维成本，付费灵活；
• 用户按月/年支付费用，而非⼀次性购买，体验提升；
• 后续升级维护由SaaS公司负责，通过数据驱动迭代。

SaaS产品业务阶段：整体划分为四个阶段，基础产品完善期、行业产品深入期、生态建设期、再创新。

三、我们通过什么方式去理解业务

1. 业务理解=行业模式（宏观）+企业运作流程（微观）

对业务的理解我们可以由抽象化转换为具象化，本质需要从行业模式和运作流程去了解。懂行业模式是要能够理解约定俗成的玩法和规则是什么。懂运作流程是行业中某个企业不同岗位/角色如何各司其职的。运作流程是行业模式的直观体现，行业模式⼜为理解运作流程提供指南针。

理解行业的限制，了解他的客观规律从而避免走弯路，理解运作流程从而能够还原场景，并设计功能满足需求。所以我们需要通过行业分析了解行业模式，通过业务调研了解某个企业的运作流程。

⾏业模式：从宏观角度，我们了解行业内企业相应业务的玩法，从而抽象出通用的玩法和规则，这样我们才可以了解企业的核心痛点，其次也为SaaS产品及服务提供方向指南。

运作流程：从微观角度，对于每个企业我们需要了解企业内部不同员工是如何操作的，最终实现公司业务运转，了解这些才能使我们产品设计更加落地。

2. 行业模式（宏观）：如何快速了解一个行业

SaaS产品经理算半个行业专家。

网上做行业分析的方法有很多，重要的是需要找对维度，不能只停留在大范围层面，而是需要聚焦于我们自身业务的边界。关于维度层面这边跟大家分享五个分析行业的维度，分别是：行业基础信息、外部经营环境、内部市场环境、标杆企业分析、SaaS竞品分析；

通过上诉几个维度我们可以快速了解⼀个行业，但是往往实际工作场景是我们做出了⼀份分析报告，但不知道真正作用在哪⾥。这种情况下需要回归到本质，我们是为了了解行业通用规则和玩法，最终服务于自身SaaS业务。

3. 企业运作流程（微观）：如何进行业务调研

先跟大家讲讲C端产品的用户调研与SaaS产品业务调研的区别，C端用户调研只需要关注单点用户，SaaS业务调研需要全盘考虑整个业务流程，这也是很多转行做SaaS产品经理会按照以前的调研方式，去做业务调研，容易导致产品流程上没有闭环。其次C端⽤户调研需要以用户体验为中心，相对于来说SaaS产品更关注需求，解决了什么业务问题。最后C端产品用户需求层面相对于容易抽离共性，SaaS天然存在大量个性化需求且极度分散。而且C端产品⼀般都是用户可以通过共情来挖掘潜在需求，SaaS产品经理通常不是用户，需要通过理解业务来挖掘需求。

4. 运作流程要素与调研步骤

业务调研最终是为了理解业务的运作流程，运作流程包括的元素有什么：企业（通过定义标杆企业描绘客户画像）、角色（通过查看组织架构和参考同类型企业来梳理角色特征）、流程（通过观察与调研了解核心业务的工作流）。

业务调研整体分三步：

第⼀：定义并选择标杆企业。在这里需要定义标杆企业的客户画像，以标杆企业的需求为核心。客户画像包含（客户/企业规模、从属细分类目、业务范围），在这里面为什么我们需要选择标杆企业的原因是在于标杆企业需求具有代表性，相对容易抽离。其次也是因为标杆企业的声音有影响力，后期能够引领其他客户。

第⼆：梳理业务链条的⻆⾊。在这⼀步梳理好业务流程中的关键角色之后，我们需要定义角色的特征（主要负责什么、业务目标标/KPI是什么、职业特点是什么），怎么找到这些业务流程中的关键角色，第⼀可以从企业的组织架构中寻找，这是最便捷也是最直接快速的方法。在得不到组织架构的情况下，可以参考同类型企业的流程及角色（当然这里的企业也是属于标杆企业），在做整体角色梳理的时候我们必须要注意业务的闭环，如果忽略了业务链条不重要的角色，可能会导致业务无法闭环。

第三：观察与调研并行。在梳理完业务流程之后我们需要通过观察与调研，理清角色的工作流（核心流程）。对于SaaS产品来说，观察比直接开放式调研更有效，这么说的原因是在于产品很难从根上去撼动绝大部分公司的业务模式，所以我们侧重在还原业务，而非创造业务，还有⼀个原因是调研过程中多少都会有主观成分在，所以需要通过观察还原业务。

观察的方式我们可以通过驻场，深⼊业务需求方的工作场景，观察他们平时的工作方式。在观察的同时我们也需要得到这个角色的工作流是什么样子的？有没有标准化流程？在什么情况下，执行了那系列任务，完成了什么业务上的目标？还有⼀种方式轮岗机制，有机会的话能够直接上手体验业务方的工作是最好的。用户调研主要从流程维度和具体场景维度去设计调研问题。

在理解业务这个层面上我们需要循序渐进的，理解业务没有太多的技巧，通过观察和调研交叉，了解用户/用户需求，并通过产品设计满足需求，了解反馈，进而根据反馈持续满足需求—-通过不断地这样循环深耕业务，才能不断深化对业务的理解。

四、SaaS产品如何梳理业务判断需求价值

很多产品经理在做了⼀波业务调研之后，也对业务有了⼀定程度的理解，认为接下来就该到需求分析了。其实不是这样，除了对业务要有⼀个深度了解之外，还需要还原业务中遇到的场景是什么，用户需求价值是什么。如何去判断需求的价值，其实本质是我们需要在产品定义这个环节去梳理清晰。

产品定义分两个部分：第⼀回归场景（梳理并描述业务场景），第⼆理清价值（判断场景中需求的价值）。

1. 为什么要回归场景？

在这个跟⼤家描述两个我们常见的工作场景，很多时候产品经理在提出产品方案时，大家围绕实现细节开始讨论的时候容易出现，‘我觉得’的⽅式来表达自己的观点，每个人都有自己的想法，无法达成统⼀的意见。还有⼀种情况是在没有理解场景的情况下直接开始画原型，这时候会出现我们产品上线之后总是不符合实际线下流程，还得推倒从来。

现在我们回想上⾯两个场景中为什么出现这种情况，本质是因为产品经理对外（项目组其他人），完成⼀项任务肯定是需要多个部门多个角色频繁的传递用户需求，因此使用一套易理解，贴近实际的沟通的⽅式就很重要，而场景就是通行于不同角色之间解决产品问题的语言。

对内（自身思考）产品设计我们需要先发散后收敛，因此动⼿画原型，写文档之前我们需要做⼤量的思考，调研。逻辑基点是用户⾯临的实际情况到底是什么样的，即回归场景。

2. 单个场景与多个场景

在单个场景上，SaaS产品不能创造，只能还原。这也是和C端的区别点，C端因为自己就是用户，可以以发散的⽅式创造场景，从而引领用户需求。SaaS业务天然存在壁垒，无法发散获取，只能还原场景，且颗粒度需要更细。在多个场景上，SaaS产品需要考虑业务的闭环。同样以C端举例，c端产品相对简单，重点在于单点突破核心场景。SaaS产品业务链长，缺少任何⼀个必备场景都可能⽆法闭环。所以回归场景我们需要先将单个场景描述清晰，进而梳理链条中的全场景。

3. 场景我们该如何去描述

回归场景我们需要通过⼀种通⽤的场景描述方式，对内形成自己的思考基点，对外让大家形成共识。在这里跟大家分享⼀种场景描述方法，场景描述的7要素（用户、环境、时机、目标、动作、截止、任务）SaaS产品的场景是真实存在的，不是凭空捏造的。需要在真实业务中得到验证。场景描述方式本身不重要。重要的是对外能够形成统⼀的认知，对内思考能够还原用户实际情况才是关键。

针对单⼀的场景我们可以通过单⼀场景描述方式去还原，针对多个场景时我们可以借助场景需求清单，场景需求清单是多个场景串联形成的结构化信息，他是⼀个业务链条下的场景拆分后的需求集合，场景需求清单可以帮助我们梳理业务链条下的场景关系，避免遗漏影响业务闭环的场景。基于之前的调研，找到关联步骤/流程，根据流程还原每个流程下的代表性场景，并拆解出需求。核⼼步骤提炼成三步：第⼀梳理出清晰地业务流程、第⼆将场景归类到流程中、第三基于场景拆分用户需求；需要注意的是每个流程下可以写多个具有代表性的分⽀场景，同时我们也可以把⻆⾊标注出来。

示例：场景需求清单

当场景清单足够庞大时，我们需要对原有的场景需求清单进行抽离，抽离出最关键的类别/流程，以及其中不可或缺的场景形成场景需求清单，这⼀步的核心在于如何抽离（需求理解业务），说到核心场景我们需要前面提到的业务闭环，业务闭环我们可以定义他为为了完成目标下的最小步骤的集合，核心场景即最小步骤的展开，对于最小步骤依赖于对业务的理解，需要站在业务员的角度，来看哪些是不可或缺的，同时我们需要考虑到意外情况下的分支场景，如果出现意外情况而导致业务无法进行，业务无法闭环，那么也会导致用户放弃使用产品。讲到这里我们发现核心场景也是MVP版本。

4. 宏观与微观的价值理清（理清价值）

价值主张与需求对应的价值，两者之间产品的价值主张为判断需求的价值提供方向和原则，而不同需求价值的积累进⼀步巩固价值主张。

价值主张（宏观）：为特定用户群体提供差异化价值，价值主张是进行需求判断的第⼀原则，SaaS产品应该尽可能满足每个客户的个性化需求，但不该包含与价值主张完全不⼀致的需求。如果在实际工作中遇到需求判断经常找不到方向，也许应该开始思考产品的价值主张。

需求价值（微观）：需求的两种价值⼀是⽤户价值（给产品⽤户带来什么），另外⼀种是商业价值（给SaaS⼚商带来什么），针对用户（我们提供业务闭环类价值、效用类价值、体验类价值）、对于SaaS厂商（收入价值、对自身是否能够采集到更多的业务数据价值）。在SaaS产品中用户价值中最常见的是效用价值。

5. 如何找出场景中的需求价值

找出价值我们需要做的三件事：第⼀需求的用户价值是否与产品价值主张相契合？第二用户的需求价值具体类型是什么，表现在哪里？第三需求是否存在商业价值，表现在哪里？

6. 如何判断场景中的需求价值

需求来源于场景，满足需求则产生价值，⾯对扑面而来的需求SaaS产品经理更需要清晰理解并判断需求的价值。SaaS产品为什么更需要理解价值，原因在于SaaS场景都是真实存在的，客户就是上帝，不存在伪需求，所以需要对⼤量需求进⾏判断。在需求判断中常规会出现三种场景分别是：

示例：场景需求价值清单

五、我们如何设计业务架构与功能

1. 什么是业务架构

对于SaaS产品首先我们理解场景七要素中的任何⼀个要素发生变化，都会导致场景不⼀样，从而产生不⼀样的需求。SaaS产品有非常强的业务属性，如果缺乏框架性思考，单点设计功能将会让你精疲力尽，对内部来说不断堆砌功能，开发成本会越来越⾼，对外部来说用户看到的信息繁杂，无法高效的完成任务，所以我们设计功能前需要理清架构，以⼀种全局的框架视⻆来思考。

业务架构是⼀套功能依据业务进⾏分类整合，形成抽象化的业务模型，架构可以帮我们理清每个业务模块/功能间的边界，以及他们之间的关系，在我们⾯对多个类似的需求时先梳理架构就可以基于场景迅速定位到对应的模块，在设计功能时我们需要重点考虑以⼀个功能满足多个类似的需求。

业务架构：架构的作用在于建立⼀套标准化的业务模型，搭建框架，最终是为了高效满足用户的不同需求。所以也就是我们常听说的后端标准化，前端个性化。理解业务是梳理功能架构的前提。

示例：微信业务架构

2. 基于目前的场景和需求我们如何梳理架构

梳理架构分成三步⾛：第⼀将场景需求清单拆解到功能、第⼆将功能按不同维度整合、第三梳理模块之间的逻辑关系；在第⼆步将功能按不同模块分类整合时我们先拿出符合通⽤模块的功能，进行归类整合，切记重复造轮⼦。不符合通用模块的功能，根据业务重要程度和复杂性单独整合。如果有必要根据业务重要程度和复杂性，继续梳理⼦模块。在梳理模块之间的逻辑关系时我们先梳理静态模块（不产生数据流），在梳理动态模块（产生数据流）。整体表面上是梳理架构图，背后是对业务的深刻理解。

架构本质是后端业务逻辑的标准化；在完成后端标准化之后，随着产品的不断发展，我们需要通过可配置的方式在前端满足⼤量个性化需求，即前端个性化。因为SaaS产品本身特质，我们需要考虑到大量个性化需求。那么我们需要考虑如何设计⼀个功能满足绝大多数需求，核心我们需要运用可配置去解决前端个性化需求和后端业务归类。

3. 如何设计一个功能满足不同场景需求

通过可配置化满足客户的个性化需求。⼀般会存在两种情况，第⼀是业务流程与现有方案差别较小，那我们可以从功能层面进行配置，第⼆是业务流程与现有方案差别大，那我们从系统层面进行配置。

在可配置层面⼀般来说包含界面布局，字段名、验证逻辑、计算规则、审批流配置，角色配置，角色功能权限配置，用户配置，用户数据权限配置等。在产品设计时需要规划好什么样的配置功能开放给客户，什么给到自己。原则上为了避免客户的复杂度，尽量开放小范围的配置功能给到客户自己使用。高配置往往会造成低易用性，配置项过多会带来页面不简洁，流程不高效；本质上来说用户要的不是配置项，是低成本实现目标的功能。

在判断功能要不要做成配置时我们可以通过两个维度来做判断，⼀个是模式切换频率，还有⼀个则是需求的长尾程度（用户需求差异化程度），针对⼀些默认配置项判断标准我们需要回归到场景，在大量同⼀种类型的个性化场景中，找到最核心的场景，并根据场景下的功能设计设置为默认配置项。

六、SaaS产品生命周期中的设计原则

通过前面的文章，我们知道了SaaS产品的方法论之后，我们也应该了解底层的设计原则，了解原则的好处有两点，通俗的来说一方面是可以驱动产品优化和产品经理本身的自我成长，另一外面则是可以消除外部给你带来的一些负面影响。

给作者点赞，鼓励TA抓紧创作！

来源：http://www.woshipm.com/pd/5398732.html
本站部分图文来源于网络，如有侵权请联系删除。