对于大部分SaaS公司来说，产品标准化程度决定了企业的生死。今天，我们就站在产品经理的角度，来看看SaaS从0到1的标准化设计应该怎么做。
限于篇幅，本文对如何画流程图、如何制作原型等基础技能就不再敷述，侧重阐述实现SaaS标准化设计的要点。
为便于大家理解，本文会以一个案例为线索，一步一步演示如何从0到1设计一款SaaS产品。
01 SaaS与自用系统的差异
虽然同为B端产品，SaaS与自研系统的差异却非常明显。
从根本上来说，SaaS产品需要服务于众多企业：少则几十家，多则几万家。因此，对业务的包容性需要很强。代价则是产品迭代速度相对缓慢。
自研系统由于只服务于一家企业，强调的是贴身服务，因此对产品包容性要求较低，但是很强调迭代的速度。
虽然SaaS和自研产品的逻辑是类似的，但是对产品经理能力的要求却有一定差异。
具体可以参考下图：
内部B端产品经理更多是辅助角色。因此比较强调深入参与和支持业务，通过协调甚至推动业务部门，达成公司目标。
SaaS产品经理就不一样了。因为负责商业化产品，是公司实现营收和盈利的核心环节，所以比较强调产品本身的架构能力和设计能力。
我个人认为，衡量SaaS产品经理的优劣，其中一个重要的标准就是：当用户数不断增加，产品功能会不会被推翻或大幅修改，即能不能多做加法，少做减法和改法。
02 标准化的意义
产品标准化对SaaS公司至关重要。
曾经听某知名SaaS公司大区总监说，某个百万级项目谈得非常好，约定4个月交付上线。
结果到了第3个月，客户要求推倒重来，按客户实际业务重新开发。这位销售总监抱怨道：“前面谈得好好的，就用标准化产品。但到项目后期，客户却说产品满足不了业务需求。真是搞不懂。”
这就是典型的产品能力支撑不了销售能力。如果这样的项目很多，SaaS公司就很难盈利。
具体来说，SaaS标准化有以下三个重要意义：
1、降低边际成本
SaaS公司最大的成本投入是研发成本， 如果每一个项目都是通过配置完成交付，这意味着随着用户数的增加，研发成本会被逐步摊薄，最终形成规模效应。因此标准化是SaaS公司盈利的关键之一。
2、沉淀最佳实践
B端客户真正希望购买的是“行业最佳实践”。
即便SaaS公司具备丰富的行业经验，也了解行业标杆的业务策略和执行方案，如果SaaS产品不能体现和支撑这些“最佳实践”，那么推广和执行的成本都会很高。
所谓标准化，其实就是把领先企业的解决方案进行提炼，再固化到系统中。这些固化的解决方案，是SaaS系统的灵魂。
3、积累产品能力
如果SaaS公司依赖运营而不是依赖产品来保障“客户成功”，那产品和产品经理的价值都会大打折扣。
标准化会不断增强产品的配置能力，使得产品越来越厚重，价值越来越高。也只有厚重的B端产品，才能磨炼和体现产品经理的产品能力。
03 标准化策略
SaaS标准化策略可以分为三个部分，分别是：
1、产品版本标准化策略
标准化最重要的策略，是确定“不满足哪些客户的需求”。
“一套产品吃遍天下”的传统软件时代，已经过去了。即便我们要占领多个细分市场，也要谨慎判断，是否通过“一个行业版本”满足全部客户的需求。
比如，在快消品行业，经销商和生产商的管理模式差异是比较大的。对于经销商来说，组织和权限的管理是相对简单的，也不涉及严格的外部账号管理；而品牌商则有复杂的多组织管理的需求，包括外部组织和账号的管理。
再比如，经销商的价格体系是相对简单的，不同等级的客户可能会有对应的价目表，部分客户会签订特定的价格协议；但是品牌商的价格体系则复杂很多，不同分公司、不同区域、不同商圈等级都会影响具体的价格。这是因为“价盘”是品牌商的生命线，所以精细的控制是有必要的。
快消品经销商和品牌商需求差异
当然，并不是说，我们一定不能在一个版本满足多个行业的需求。过去SAP、Oracle的成功已经证明这一点是可以实现的。
但是，SaaS引以为傲的正是足够“高可用”的系统。过于臃肿的产品，会大大增加客户的使用成本。
反过来说，“一个版本满足所有需求”当然是不正确的。但是如果盲目的横向扩充版本，也会给SaaS公司带来沉重的研发负担。
比如，当我们面对“非处方药”行业的客户，是否需要划分出一个版本呢？虽然并不是快消品行业，但是“非处方药”却在学习快消品行业的分销模式。在这种情况下，如果我们提供的是分销SaaS产品，就暂时没有必要单独为“非处方药”划分一个行业版本出来。
2、功能层标准化策略
标准化第二重要的策略，是决定“哪些功能不标准化”。
对于大部分SaaS，90%以上的功能是能够在产品层面进行标准化的，但是可能有10%的功能是很难标准化的。分清楚哪些功能可以“在产品层面进行标准化”，也非常重要。
比如，中小企业对报表的需求相对简单，因此报表功能是相对容易标准化的；但是对于百亿级企业来说，报表是一个高度复杂且不能妥协的需求，因此对于还没有BI或者PaaS产品的SaaS企业来说，暂时进行定制也是一个可行的选择。
3、开发层标准化策略
对于无法“在功能层进行标准化”的功能，我们要想办法在开发层进行标准化，即通常我们所说的PaaS，现在流行的叫法是“低代码”。
低代码是一个很“古老”的事物。我还在Oracle公司的时候，就很频繁的使用Oracle的低代码能力了——我们又叫personalization。通过它，我们可以改变字段的属性，也可以嵌入SQL甚至package。
也就是说，即便是能够灵活二次开发的传统软件，也非常依赖低代码。更不用说二次开发相对困难的SaaS公司了。
因此，如果一家SaaS决意要做大，PaaS能力就不是可选题，而是必选题。
04 标准化设计难点
和自研系统相比，SaaS产品的设计更依赖长远规划。这是SaaS设计的核心，也是SaaS设计的难点。
重视长远规划，主要是由于两个原因。
1、控制开发成本
由于标准化强调配置能力，因此同样一个功能，所需要的开发量可能是自研系统的数倍。一旦开发了拙劣的功能，就可能对开发资源造成惊人的浪费。
2、便于持续迭代
更重要的是，作为“公用产品”，SaaS必须保持简洁性：如果系统充斥着一堆鸡肋的功能，且有少数企业坚持在使用，那么会对系统迭代造成阻碍。读者可以思考一下，当规划的新功能与这些鸡肋功能产生冲突，产品经理应该如何处理？
因此，好的SaaS设计就是尽量做“加法”，避免做“减法”和“改法”。
当然，标准化设计对产品经理本身也是有要求的。我常常比喻，所谓的标准化设计，就像在棋盘上放棋子：棋盘就是产品经理所拥有的架构能力，棋子就是具体的需求。没有棋盘，就不可能正确落子。
05 标准化设计步骤
从设计过程来说，标准化设计可以遵循以下四个步骤：
1、策略层梳理
所谓策略层梳理，是站在相对宏观的层面梳理业务。具体又包括以下步骤：
1.1、明确业务范围
企业的业务可以分为前中后台业务，前台业务包括商城APP等，中台业务包括CRM、订单管理、物流管理等，后台业务则包括HR、财务等。
我们首先需要明确，第一版SaaS产品版本主要是满足哪一块业务需求。划定好了边界，才能匹配公司的战略和资源。
案例：
一家知名快消品厂家找到某SaaS公司（简称A公司），希望开发一款管理销售人员的移动APP。经过沟通，SaaS产品经理小李意识到，客户的需求实际上是分销管理，包括销售订单管理、销售人员管理和门店管理等。
虽然A公司有服务于快消品‘经销商’的分销管理系统，但是一直苦于无法切入利润更丰厚、收入更稳定的快消品‘品牌商’市场，这正是一个非常好的机会。
1.2、梳理经营策略
所谓经营策略，其实就是企业的打法。比如，在线下分销业务中，用户企业是采用深度分销？还是兼有直销？搞清楚客户的经营策略，才能理清产品研发的思路。
此外，我们必须明白，SaaS是给一个行业的众多客户使用的。因此，我们还需要对企业所在行业的经营策略进行梳理。这样，一方面可以将客户的经营策略匹配到行业的经营策略，便于我们抓住本质，确保产品的通用性；另一方面，也可以通盘考虑未来的拓展方向，提前打好架构基础。
比如，快消品线下分销常见的策略包括大批发制、多级分销、深度分销、直销、车销等，而深度分销又分为厂家覆盖模式和经销商覆盖模式。作为产品经理，有必要全面梳理这些模式，才能在产品设计时胸有成竹。
案例：
小李和客户沟通后，发现该快消品厂家主要采用了大批发制、直销和深度分销三种经营策略，属于行业比较经典的打法，可以先开发这三种分销模式，同时兼顾到未来向多级分销和车销的拓展。
1）大批发制
大批发是厂家把货卖给批发商，由批发商再进行二次分销。大批发模式虽然是比较粗放的分销方式，但是当厂家管理能力不足时，采用大批发模式可以实现快速铺货，因此仍然是常见的一种分销模式。
2）直销制
快消品行业有40%左右的销量，都是通过以大超市为代表的现代通路完成的。这些大超市往往是区域连锁甚至全国连锁，可以树立品牌形象，但是进入门槛高、谈判过程复杂，因此，往往是由快消品厂家直接进行合作。
3）深度分销
深度分销是快消品分销的重要方向。实行深度分销的企业，往往已经具备一定的规模和管理能力。他们将区域进行划分，指定经销商专营，强调终端门店的铺货率、陈列、新品普及率等。
对于企业来说，深度分销可以最大化挖掘终端门店的潜力，提高新品和高毛利商品的销售量，并有效的阻击竞争对手。因此，这种模式一直是伊利、康师傅、可口可乐等大型快消品企业的重点分销模式。
1.3、梳理业务难点
相对于传统软件，SaaS是后来者。
根据产品替换公式：新产品价值>旧产品价值 替换成本，只有SaaS提供了更大的价值，客户才会考虑购买。退一步说，即便没有竞争的传统软件，SaaS也必须解决“以前无法解决的问题”，才能在激烈的竞争中站稳脚跟。
因此，梳理清楚业务难点，明白“客户为什么选择我们”，是非常重要的工作，可以让我们把资源集中在最关键的功能上。而不是分散资源，做那些客户虽然愿意使用，但是不构成“差异化竞争力”的功能。
案例：
经过和客户沟通，小李了解到，其实客户之前已经耗费上百万实施了某国际知名品牌的CRM系统，但是移动端的用户体验非常糟糕。除了使用上不够高可用，需要反复培训才能上手；低下的操作效率和缓慢的响应速度，更是使得系统的推广困难重重。
客户为什么选择由A公司来开发分销系统，就是在体验了A公司的移动端产品后，认为产品的用户体验非常优秀，可以解决当前系统推广的最大难题。
了解到客户的诉求后，小李意识到：这个针对快消品厂家的SaaS系统，设计的重心要放在移动端。
快消品行业普遍存在销售人员学历低、管理难的问题，如果通过移动端大大提高员工效率、降低员工使用难度，那么该SaaS产品将对快消品品牌商产生巨大吸引力。
2、业务层梳理
业务层梳理，最有效的做法就是画业务流程图。
流程图的重点在于，产品经理要帮助客户梳理清楚业务和需求，避免错乱和遗漏。而做到这一点的关键，是产品经理要有一定的架构能力，即知道典范的流程应该如何流转。
如果是针对大客户的SaaS，那么建议到客户现场呆一段时间。大客户的要求比较细致，现场沟通可以提高沟通的效率。
如果是针对小客户的SaaS，那么建议你先找到几个种子用户，通过流程图，确保1.0版本是他们能够接受的MVP（最小可行产品）。
流程图绘制细节是基本功，这里就不再敷述。下面放一张我曾经绘制的流程图供大家参考。
案例：
一开始，该快消品企业认为自己的需求很简单，主要是业务人员在手机端录入销售订单，再通过接口实时传送到已有的ERP系统即可，如下图：
小李并没有急于下结论，而是在黑板上画出了典范的分销管理流程，然后按照流程环节逐个进行梳理，如下图：
经过梳理，小李很快发现，该厂家对于区域连锁卖场等大客户，采取的是厂家业务员拜访、工厂直接发货的直营销售策略；对于非连锁便利店等小客户，采取的是厂家业务员拜访、经销商发货的深度分销策略。因此，客户实际上有两种不同的销售管理流程，如下图：
流程梳理清楚，设计思路也就清晰了。同时，小李专业的需求梳理方法也得到了客户认可，客户领导当场表达了合作的意向。
3、多组织架构设计
企业业务的开展，是基于多个部门的相互协同和相互监督的。当用户在使用SaaS系统时，流程流转、数据安全性都必须符合企业协同与管控的要求。这就需要我们设计好组织、角色和权限功能。而这里面最有难度的，就是多组织架构设计。
比如，某饮料公司为扩大销售规模，分别在A市和B市建立了分公司，各负责一个大区的生产和销售。为便于管理和激励分公司团队，公司决定两个分公司独立核算利润，并根据实现的利润进行分红。
为支持两个分公司的独立核算，并防止数据泄露，该饮料公司IT团队决定分别给两个分公司建立一个“利润中心组织”。在“利润中心组织”下面建立了相应的“角色”，并分配了相应的“功能”比如销售订单、发货功能等等。最后，将相应的“角色”分别分配给了两个分公司的员工。
这样，A公司员工建立的销售订单，所产生的收入和利润数据，均会统计到A公司。且销售订单、收入和利润等数据，只能由A公司的员工查看。B公司亦如此。
多组织架构实际上体现了企业责权利的划分，决定了组织间协同与风险管控策略。由于企业越大，组织架构就越复杂，管控要求也越高。因此，越是针对大型企业的SaaS，越需要重视多组织架构的设计。
当然，如果是针对小企业的SaaS，多组织架构就相对简单了，大家把角色和权限管理设计好即可。
案例：
小李梳理发现，客户下设2个独立核算的营业部，每个营业部下面都有若干经销商。对于直营的KA门店，只能由对应营业部管理数据和处理业务；对于经销商管理的便利店，只能由对应经销商管理数据和处理业务。同时，经销商所属的营业部，也具有这些便利店相关数据的管理权。
小李设计了“利润中心”组织类型，并创建了两个利润中心组织：江东营业部和江南营业部。经销商A、经销商B、KA门店C都属于客户（具有不同的客户类型），在客户信息上加上“所属组织”字段，通过该字段，将这3个“客户资料”都分配江东营业部。这样，就只有江东营业部的人员可以看到他们的资料以及业务数据。
对于便利店a、b、c、d，则通过类似的方式，关联到对应的经销商，确保经销商之间业务信息的隔离。
4、产品功能设计
作为SaaS设计的主体，产品功能设计又可以分为应用架构设计和详细功能设计。
4.1、应用架构设计
所谓应用架构设计，即各系统应用的整体结构图。
相对于自研产品，SaaS的应用架构设计更为关键。合理的应用架构可以减少功能重复、避免数据混乱和降低系统拓展的难度。而一旦在不合理的应用架构上搭建起功能模块，并且拥有一定数量的企业客户后，修改的成本就非常高了。
相对来说，自研产品的纠错成本就低得多。毕竟只有一家企业在用，只要和业务部门协商好，推翻重建也不是不可以。
对于产品经理来说，应用架构设计的重点要做到低耦合、高复用。
所谓低耦合，是将功能按照业务相关性，分为多个系统应用。系统应用之间通过API进行交互。这样，单个应用的升级，对其他应用的影响就小很多，从而提高了系统的敏捷性。比如，销售订单管理、仓库管理和CRM就可以独立为多个应用，并且在必要的时候分配给不同的团队负责。
应用架构设计虽然没有标准答案，但实际上不管是传统的Oracle ERP系统，还是新兴的各大电商、SaaS系统，都有非常成熟的应用架构设计。多研究竞品，再结合实际情况进行适当的调整是应用架构设计的好方法。
案例：
考虑到A公司已经有独立的客户信息系统，也有成熟的商品管理系统，小李决定直接复用这些系统。为了满足品牌商的需求，小李增加了一些新的功能，比如商圈管理、价格策略管理等。
其实，复用客户信息管理和商品管理模块，小李还有长期的考虑，即未来品牌商版本和经销商版本可能会打通，形成交易型的SaaS产品。如果两个版本共用一套基础数据功能，会有利于将来的数据集成和流程整合。
4.2、详细设计
SaaS详细功能设计很考验产品经理的系统经验。
从设计流程上来说，SaaS功能设计也遵循通用B端产品设计流程，如下图：
但是，SaaS系统面对的是多个企业的具体需求，而这些具体需求看起来总是千差万别的；更困难的在于，产品经理并不能确定未来会面对什么样的企业，也就无法预知所有的需求。
在这种情况下，产品经理可能就会面临各种尴尬局面，比如：
功能升级需要大幅修改原有功能，开发抱怨
功能升级改变原有体验，客户抱怨
功能上线后，没有人使用，团队抱怨
功能上线后，客户说需求变更了，各种人抱怨
所以SaaS详细功能设计很考验产品经理的规划和深度思考能力。
具体来说，SaaS产品经理需要做好以下几点：
1）长远规划，谨慎设计
从0到1的SaaS，往往是从一小群客户的需求起步。
当客户数量较少，功能也不多的时候，产品的设计缺乏约束，很容易野蛮的生长。
比如，买赠是消费品行业常用的促销手段。在某些情况下，赠品需要关联到主品，比如买5瓶大可乐送1瓶小可乐。产品经理为了设计和操作方便，可能选择直接在订单行上新增字段，体现赠品名称和数量。
这样的设计在面对简单需求的时候，可能不会出现问题。但是一旦遇到比较复杂的情况，比如1）需要管理赠品发货；2）买5增2，买5瓶大可乐送2种赠品；3）需要和ERP系统集成等情况时，就会出现问题。
正确的做法是，主品和赠品都放在独立的订单行，拥有相同的字段，并且通过“赠品”字段来标识该订单行是否赠品（打勾即为赠品）。
因此，作为SaaS产品经理，不能够只盯着眼前的需求，而应该放眼长远，尽可能考虑全面。
另外，SaaS产品经理必须承认：即便通晓所有需求，我们仍无法确定全部需求的优先级。
因此，一般情况下，产品经理只能挑选那些最有价值的需求优先进行满足。而且，每一次的设计都应该是MVP，从而避免暂时不需要的功能被提前开发。
这就是SaaS谨慎设计的原则。
2）深度思考，究竟精神
SaaS设计的纠错成本，远高于自研产品。
但是，SaaS产品经理离客户往往比较远，不容易深入参与客户的日常经营。
相对而言，传统软件时代的项目制，需求设计师可以在一个客户现场驻点数月进行需求调研和系统开发；而自研产品的产品经理，则几乎天天和业务方在一起沟通。
SaaS公司的研发团队庞大，不可能都派驻到客户现场，因此产品经理往往需要两头兼顾，既要把客户的需求搞透彻，也要做好设计，让研发能够顺利工作。
在这种情况下，SaaS产品经理就必须具备“究竟精神”：对客户的每一个需求刨根问底，究其本质。
我一直坚守一个原则：永远相信客户有一个痛点，但是永远不要相信客户有一个正确答案。也把这个原则送给大家。
3）便览竞品，死磕细节
SaaS为什么能够抢占传统软件的市场？最重要的原因并不是SaaS更便宜，而是SaaS的出生就带有移动化、社交化的属性。
但是，移动端设计的难度是PC端设计的好几倍。原因除了手机屏幕更小，同时也是因为移动端操作是在户外，场景更复杂，对体验和效率的要求也更高。
比如，快消品车销业务员为了完成一天的拜访任务，拜访一个客户的时间平均不能超过5分钟。为了节约时间，业务员需要一边卸货一边拿着手机下订单。因此，“录入销售订单”这个页面必须足够简单和高效。
比如，在输入商品数量时，就可以直接录入多单位数量（不需要选择单位），如“1箱/3瓶”。并且允许通过加减号来增减数量。
这样，当业务员搬下车1箱3瓶酸奶（假设1箱酸奶有9瓶），他就不需要再计算出“1箱3瓶等于12瓶”才能录入系统。这就可以大大提高业务员的操作效率。
要做好SaaS交互设计，除了和UE同学充分沟通和探讨，更重要的是多研究和学习竞品。
所谓三人行必有我师焉，何况我们是从0到1的设计SaaS呢？
案例：
在进行报表设计时，客户有几张已经使用了5年的核心统计报表，客户领导希望新的报表仍然沿用以前的统计逻辑。
但是，小李仔细分析后，发现以前的逻辑并不是最优的。
因为客户的部门和人员每年都会调整，而原报表是根据“订单-人员-部门”的对应关系，来计算销售业绩。这就导致进行同期对比时，历史年份和最新年份的业绩基础并不公平。
比如，去年的A部门，有10个人员，管辖a片区；今年的A部门，有20个人员，管辖b片区。如果简单的把去年A部门业绩和今年A部门业绩做对比，实际上是有失公允的。
小李和客户的项目负责人进行了沟通。由于这个客户是快消品行业最顶尖的企业之一，项目负责人也属于比较自信的领导，因此一开始小李的建议并没有得到重视。
但是小李坚持与客户进行沟通，指出“在分销模式下，只有便利店和对应的区域是相对稳定的。因此应该用A部门所负责c区域的今年业绩，和c区域去年业绩做对比，这样才是真正公平的”。
最终，客户领导被小李说服了，他当着众人的面夸奖了小李。而有了客户领导的配合，项目的推进也非常顺利，最终成功上线。小李也借助这个项目完成了SaaS的从0到1。不久，他又将这个SaaS产品销售给了其他的大客户，帮助公司成功完成在大客户市场的突破。
06 总结
SaaS产品的设计，很强调产品经理的架构能力。
如果用一句话对本文做个总结，那就是：
画好棋盘，放好棋子。
祝大家，设计出一款改变世界的SaaS产品。
————/END/————
近期活动
我的新一轮的决胜B端线下特训营正在招生中，这次带给大家的是最新研发的需求分析精品课，已经在微盟、华润集团等多家企业交付过，评价很好。
需求分析是所有产品经理的基本功，课程融合了传统需求分析工程以及现代软件基于场景的体验化设计思想，通过两天线下实战课，交给你一套开箱即用的成熟实用方法论！
【决胜B端线下特训营】11、12月北上深开启招生
