SaaS产品从0到1案例实操

SaaS产品从0到1案例实操

01标准化的意义

产品标准化对SaaS公司至关重要。

曾经听某知名SaaS公司大区总监说，某个百万级项目谈得非常好，

约定4个月交付上线。

结果到了第3个月，客户要求推倒重来，按实际业务重新开发。

这位销售总监抱怨道：”前面谈得好好的，就用标准化产品。但到项

目后期，客户却说产品满足不了业务需求。真是搞不懂。〃

看来他不懂SaaS产品，因为这就是典型的产品能力支撑不了销售能

力。

如果这样的项目很多，SaaS公司就很难盈利。

具体来说，SaaS标准化有以下三个重要意义：

1、降低边际成本

SaaS公司最大的成本投入是研发成本，如果每一个项目都是通过配

置完成交付，这意味着随着用户数的增加，研发成本会被逐步摊薄，

最终形成规模效应。

因此，标准化是SaaS公司能否盈利的关键。

2、沉淀最佳实践

B端客户真正希望购买的是“行业最佳实践”。

即便SaaS公司具备丰富的行业经验，也了解行业标杆的业务策略加

执行方案，如果SaaS产品不能体现和支撑这些〃最佳实践〃，那么推广

和执行的成本都会夕艮高。

所谓标准化，其实就是把领先企业的解决方案进行提炼，再固化到系

统中。这些固化的解决方案，是SaaS系统的灵魂。

3、积累产品能力

如果SaaS公司依赖运营而不是依赖产品来保障〃客户成功〃，那产品和

产品经理的价值都会大打折扣。

标准化会不断增强产品的配置能力，使得产品越来越厚重，价值越来

越高。

也只有厚重的B端产品，才能磨炼和体现产品经理的产品能力。

02标准化策略

标准化策略是SaaS产品策略的重要组成部分。可以分为三个部分，

分别是：

1、产品版本标准化策略

标准化最重要的策略，是确定"不满足哪些客户的需求〃。

〃一套产品吃遍天下〃的传统软件时代，己经过去了。

即便我们要占领多个细分市场，也要谨慎判断，是否通过〃一个行业

版本〃满足全部客户的需求。

比如，在快消品行业，经销商和生产商的管理模式差异是比较大的。

对于经销商来说，组织和权限的管理是相对简单的，也不涉及严格的

外部账号管理。

而品牌商则有复杂的多组织管理的需求，包括外部组织和账号的管

理。

再比如，经销商的价格体系是相对简单的，不同等级的客户可能会有

对应的价目表，部分客户会签订特定的价格协议。

但是品牌商的价格体系则复杂很多，不同分公司、不同区域、不同商

圈等级都会影响具体的价格。

这是因为〃价盘〃是品牌商的生命线，所以希细的控制是有必要的。

组织与权限管理

单组织/内部账号

品牌商多组织/内外部账号

快消品经销商和品牌商需求差异

当然，并不是说，我们一定不能在一个版本满足多个行业的需求。过

去SAP、Oracle的成功已经证明这一点是可以实现的。

但是，SaaS引以为傲的正是足够“高可用〃的系统。过于臃肿的产品，

会大大增加客户的使用成本。

反过来说，〃一个版本满足所有需求〃当然是不正确的。

但是如果盲目的横向扩充版本，也会给SaaS公司带来沉重的研发负

担。

比如，当我们面对"非处方药〃行业的客户，是否需要划分出一个版本

呢？

虽然并不是快消品行业，但是〃非处方药〃却在学习快消品行业的分销

模式。

在这种情况下，如果我们提供的是分销SaaS产品，就暂时没有必要

单独为〃非处方药〃划分一个行业版本出来。

2、功能层标准化策略

标准化第二重要的策略，是决定“哪些功能不标准化〃。

对于大部分SaaS,90%以上的功能是能够在产品层面进行标准化的，

但是可能有10%的功能是很难标准化的。

分清楚哪些功能可以〃在产品层面进行标准化〃，也非常重要。

比如，中小企业对报表的需求相对简单，因此报表功能是相对容易标

准化的。

但是对于百亿级企业来说，报表是一个高度复杂且不能妥协的需求。

因此对于还没有BI或者PaaS产品的SaaS企业来说，暂时进行定制也

是一个可以接受的选择。

3、开发层标准化策略

对于无法〃在功能层进行标准化〃的功能，我们要想办法在开发层进行

标准化。

即通常我们所说的PaaS,现在流行的叫法是〃低代码〃。

低代码是一个很〃古老〃的事物。

我还在Oracle公司的时候，就很频繁的使用Oracle的低代码能力了

---我们又叫

personalization0

通过它，我们可以改变字段的属性，也可以嵌入SQL甚至package。

也就是说，即便是能够灵活二次开发的传统软件，也非常依赖低代码。

更不用说一次开发相对困难的SaaS公司了。

因此，如果一家SaaS公司决意要做大（主要是管理型SaaS产品），

PaaS能力就不是可选题，而是必选题。

但是，自研PaaS平台确实是一个费钱的工作，并不是所有SaaS创业

公司，都能够轻易负担得起的。

好消息是，钉钉等平台正在逐步增强低代码能力，有望帮助很多小型

SaaS公司低成本拥有"PaaS自由〃。

03标准化设计难点

和自研系统相比，SaaS产品的设计更依赖长远规划。

这是SaaS设计的核心，也是SaaS设计的难点。

重视长远规划，主要是由于两个原因。

1、控制开发成本

由于标准化强调配置能力，因此同样一个功能，所需要的开发量可能

是自研系统的数倍。

一旦开发了拙劣的功能，就可能对开发资源造成惊人的浪费。

2、便于持续迭代

更重要的是，作为"公用产品〃，SaaS必须保持简洁性。

如果系统充斥着一堆鸡肋的功能，且有少数企业坚持在使用，那么会

对系统迭代造成阻碍。

读者可以思考一下，当规划的新功能与这些鸡肋功能产生冲突，产品

经理应该如何处理？

因此，好的SaaS设计就是尽量做〃加法〃，避免做“减法〃和"改法〃。

当然，标准化设计对产品经理本身也是有要求的。

我常常比喻，所谓的标准化设计，就像在棋盘上放棋子。

棋盘就是产品经理所拥有的架构能力，棋子就是具体的需求。

没有棋盘，就不可能正确落子。

04标准化设计步骤

从设计过程来说，标准化设计可以遵循以下四个步骤：

1、策略层梳理

所谓策略层梳理，是站在相对宏观的层面梳理业务。

具体又包括以下步骤：

1.1、明确业务范围

企业的业务可以分为前中后台业务。

前台业务包括商城APP等，中台业务包括CRM、订单管理、物流管理

等，后台业务则包括HR、财务等。

我们首先需要明确，第一版SaaS产品版本主要是满足哪一块业务需

求。

划定好了边界，才能匹配公司的战略和资源。

案例：

一家知名快消品厂家找到某SaaS公司（简称A公司），希望开发一

款管理销售人员的移动APPo

经过沟通，SaaS产品经理小李意识到，客户的需求实际上是分销管理,

包括销售订单管理、销售人员管理和门店管理等。

虽然A公司有服务于快消品，经销商，的分销管理系统，但是一直苦于

无法切入利润更丰厚、收入更稳定的快消品'品牌商'市场，这正是一

个非常好的机会。

1.2、梳理经营策略

所谓经营策略，其实就是企业的打法。

比如，在线下分销业务中，用户企业是采用深度分销？还是兼有直

销？

搞清楚客户的经营策略，才能理清产品研发的思路。

此外，我们必须明白，SaaS是给一个行业的众多客户使用的。

因此，我们还需要对企业所在行业的经营簧略进行梳理…

这样，一方面可以将客户的经营策略匹配到行业的经营策略，便于我

们抓住本质，确保产品的通用性；

另一方面，也可以通盘考虑未来的拓展方向，提前打好架构基础。

比如，快消品线下分销常见的策略包括大批发制、多级分销、深度分

销、直销、车销等。

而深度分销又分为厂家覆盖模式和经销商覆盖模式。

作为产品经理，有必要全面梳理这些模式，才能在产品设计时胸有成

竹。

案例：

小李和客户沟通后，发现该快消品厂家主要采用了大批发制、直销和

深度分销三种经营策略，属于行业比较经典的打法。

因此可以先开发这三种分销模式，同时兼顾到未来向多级分销和车销

的拓展。

1）大批发制

(1)大批发

大批发是厂家把货卖给批发商，由批发商再进行二次分销。

大批发模式虽然是比较粗放的分销方式，但是当厂家管理能力不足

时，采用大批发模式可以实现快速铺货，因此仍然是常见的一种分销

模式。

2)直销制

厂家

（2）直销

快消品行业有40%左右的销量，都是通过以大超市为代表的现代通路

完成的。

这些大超市往往是区域连锁甚至全国连锁，可以树立品牌形象，但是

进入门槛高、谈判过程复杂，因此，往往是由快消品厂家直接进行合

作。

3）深度分销

厂家经销商

（3）深度分车

深度分销是快消品分销的重要方向。实行深度分销的企业，往往已经

具备一定的规模和管理能力。

他们将区域进行划分，指定经销商专营，强调终端门店的铺货率、陈

列、新品普及率等。

对于企业来说，深度分销可以最大化挖掘终端门店的潜力，提高新品

和高毛利商品的销售量，并有效的阻击竞争对手。

因此，这种模式一直是伊利、康师傅、可口可乐等大型快消品企业的

重点分销模式。

1.3、梳理业务难点

相对于传统软件，SaaS是后来者。

根据产品替换公式：新产品价值〉旧产品价值+替换成本，只有SaaS

提供了更大的价值，客户才会考虑购买。

退一步说，即便没有竞争的传统软件，SaaS也必须解决“以前无法解

决的问题“，才能在激烈的竞争中站稳脚跟。

因此，梳理清楚业务难点，明白“客户为什么选择我们〃，是非常重要

的工作，可以让我们把资源集中在最关键的功能上。

而不是分散资源，做那些客户虽然愿意使月，但是不构成〃差异化竞

争力〃的功能。

案例：

经过和客户沟通，小李了解到，其实客户之前已经耗费上百万实施了

某国际知名品牌的CRM系统，但是移动端的用户体验非常糟糕。

除了使用上不够高可用，需要反复培训才能上手；低下的操作效率和

缓慢的响应速度，更是使得系统的推广困难重重。

客户为什么选择由A公司来开发分销系统，就是在体验了A公司的移

动端产品后，认为产品的用户体验非常优秀，可以解决当前系统推广

的最大难题。

了解到客户的诉求后，小李意识到：这个针对快消品厂家的SaaS系

统，设计的重心要放在移动端。

快消品行'也普遍存在销售人员学历低、管理难的问题，如果通过移动

端大大提高员工效率、降低员工使用难度，那么该SaaS产品将对快

消品品牌商产生巨大吸引力。

2、业务层梳理

业务层梳理，最有效的做法就是画业务流程图。

流程图的重点在于，产品经理要帮助客户梳理清楚业务和需求，避免

错乱和遗漏。

而做到这一点的关键，是产品经理要有一定的架构能力，即知道典范

的流程应该如何流转。

如果是针对大客户的SaaS,那么建议到客户现场呆一段时间。大客户

的要求比较细致，现场沟通可以提高沟通的效率。

如果是针对小客户的SaaS,那么建议你先找到几个种子用户，通过流

程图，确保1.0版本是他们能够接受的MVP（最小可行产品）。

流程图绘制细节是基本功，这里就不再敷述。下面放一张我曾经绘制

的流程图供大家参考。

产品定价流程（根据内部结算价，制定对外售价）

1制定结算

屣v\/---价

昭

Y

定对

确

峨确定利润

价

售

加成

=1

案例:

一开始，该快消品企业认为自己的需求很简单，主要是业务人员在手

机端录入销售订单，再通过接口实时传送到已有的ERP系统即可，如

下图：

小李并没有急于下结论，而是在黑板上画H了典范的分销管理流程,

然后按照流程环节逐个进行梳理，如下图：

经过梳理，小李很快发现，该厂家对于区域连锁卖场等大客户，采取

的是厂家业务员拜访、工厂直接发货的直营销售策略；

对于非连锁便利店等小客户，采取的是厂家业务员拜访、经销商发货

的深度分销策略。

因此，客户实际上有两种不同的销售管理流程，如下图:

流程梳理清楚，设计思路也就清晰了。

同时，小李专业的需求梳理方法也得到了客户认可，客户领导当场表

达了合作的意向。

3、多组织架构设计

企业业务的开展，是基于多个部门的相互协同和相互监督的。

当用户在使用SaaS系统时，流程流转、数据安全性都必须符合企业

协同与管控的要求。

这就需要我们设计好组织、角色和权限功能。而这里面最有难度的，

就是多组织架构设计。

比如，某饮料公司为扩大销售规模，分别在A市和B市建立了分公司，

各负责一个大区的生产和销售。

为便于管理和激励分公司团队，公司决定两个分公司独立核算利润，

并根据实现的利润进行分红。

为支持两个分公司的独立核算，并防止数据泄露，该饮料公司IT团队

决定分别给两个分公司建立一个〃利润中心组织〃。

在〃利润中心组织〃下面建立了相应的〃角色〃，并分配了相应的〃功能〃

比如销售订单、发货功能等等。

最后，将相应的“角色〃分别分配给了两个分公司的员工。

销售管理角色

r

销售订单客户信息库存查

这样，A公司员工建立的销售订单，所产生的收入和利润数据，均会

统计到A公司。

且销售订单、收入和利润等数据，只能由A公司的员工查看。B公司

亦如此。

多组织架构实际上沐现了企业责权利的划分，决定了组织间协同与风

险管控策略。

由于企业越大，组织架构就越复杂，管控要求也越高。因此，越是针

对大型企业的SaaS,越需要重视多组织架构的设计。

当然，如果是针对小企业的SaaS,多组织架构就相对简单了，大家把

角色和权限管理设计好即可。

案例：

小李梳理发现，客户下设2个独立核算的营业部，每个营业部下面都

有若干经销商。

对于直营的KA门店，只能由对应营业部管理数据和处理业务；对于

经销商管理的便利店，只能由对应经销商管理数据和处理业务。

同时，经销商所属的营业部，也具有这些便利店相关数据的管理权。

小李设计了“利润中心〃组织类型，并创建了两个利润中心组织：江东

营业部和江南营业部。

经销商A、经销商B、KA门店C都属于客户（具有不同的客户类型），

在客户信息上加上"所属组织〃字段，通过该字段，将这3个〃客户资料〃

都分配江东营业部。

这样，就只有江东营业部的人员可以看到他们的资料以及业务数据。

对于便利店a、b、c、d,则通过类似的方式，关联到对应的经销商，

确保经销商之间业务信息的隔离。

某快消品公司

（便利店a）（便利店,（便利店c）（便利店d）

4、产品功能设计

作为SaaS设计的主体，产品功能设计又可以分为应用架构设计和详

细功能设计。

4.1、应用架构设计

所谓应用架构设计，即各系统应用的整体结构图。

相对于自研产品，SaaS的应用架构设计更为关键。

合理的应用架构可以减少功能重复、避免数据混乱和降低系统拓展的

难度。

而一旦在不合理的应用架构上搭建起功能模块，并且拥有一定数量的

企业客户后，修改的成本就非常高了。

相对来说，自研产品的纠错成本就低得多。毕竟只有一家企业在用，

只要和业务部门协商好，推翻重建也不是无可以。

对于产品经理来说，应用架构设计的重点要做到低耦合、高复用。

所谓低耦合，是将功能按照业务相关性，分为多个系统应用。系统应

用之间通过API进行交互。

这样，单个应用的升级，对其他应用的影响就小很多，从而提高了系

统的敏捷性。

比如I,销售订单管理、仓库管理和CRM就可以独立为多个应用，并

且在必要的时候分配给不同的团队负责。

所谓高复用，即将各个模块所共用的功能抽离出来，单独形成一个系

统应用。

这样，一方面确保了信息来源的一致性，另一方面简化了系统，避免

了重复开发。

比如，客户信息在销售订单管理、CRM、TMS（运输管理）等系统应

用中都会用到，是有必要独立成一个应用的。

应用架构设计虽然没有标准答案，但实际上不管是传统的OracleERP

系统，还是新兴的各大电商、SaaS系统，都有非常成熟的应用架构设

计。

多研究竟品，再结合实际情况进行适当的调整是应用架构设计的好方

法。

案例：

考虑到A公司已经有独立的客户信息系统，也有成熟的商品管理系统，

小李决定直接复用这些系统。

为了满足品牌商的需求，小李增加了一些新的功能，比如商圈管理、

价格策略管理等。

其实，复用客户信息管理和商品管理模块，小李还有长期的考虑，即

未来品牌商版本和经销商版本可能会打通，形成交易型的SaaS产品。

如果两个版本共用一套基础数据功能，会有利于将来的数据集成和流

程整合。

4.2、详细设计

SaaS详细功能设计很考验产品经理的系统经验。

从设计流程上来说，SaaS功能设计也遵循通用B端产品设计流程，如

下图：

但是，SaaS系统面对的是多个企业的具体需求，而这些具体需求看起

来总是千差万别的；

更困难的在于，产品经理并不能确定未来会面对什么样的企业，也就

无法预知所有的需求。

在这种情况下，产品经理可能就会面临各朴尴尬局面，比如：

功能升级需要大幅修改原有功能，开发抱怨

功能升级改变原有体验，客户抱怨

功能上线后，没有人使用，团队抱怨

功能上线后，客户说需求变更了，各种人抱怨

所以SaaS详细功能设计很产品经理的规划和深度思考能力。

具体来说，SaaS产品经理需要做好以下几点：

1）长远规划，谨慎设计

从。到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分钟。为了节约时间，业务员需要一边卸货一边

拿着手机下订单。

因此，"录