编者按:本文来自微信公众号“ToB老人家”(ID:ToBlaorenjia),作者:王戴明,36氪经授权发布。 对于大部分SaaS公司来说,产品标准化程度决定了企业的生死。今天,我们就站在产品经理的角度,来看看SaaS从0到1的标准化设计应该怎么做。 限于篇幅,本文对如何画流程图、如何制作原型等基础技能就不再敷述,侧重阐述实现SaaS标准化设计的要点。 为便于大家理解,本文会以一个案例为线索,一步一步演示如何从0到1设计一款SaaS产品。 01 SaaS与自用系统的差异虽然同为B端产品,SaaS与自研系统的差异却非常明显。 从根本上来说,SaaS产品需要服务于众多企业:少则几十家,多则几万家。因此,对业务的包容性需要很强。代价则是产品迭代速度相对缓慢。 自研系统由于只服务于一家企业,强调的是贴身服务,因此对产品包容性要求较低,但是很强调迭代的速度。 虽然SaaS和自研产品的逻辑是类似的,但是对产品经理能力的要求却有一定差异。 具体可以参考下图: 内部B端产品经理更多是辅助角色。因此比较强调深入参与和支持业务,通过协调甚至推动业务部门,达成公司目标。 SaaS产品经理就不一样了。因为负责商业化产品,是公司实现营收和盈利的核心环节,所以比较强调产品本身的架构能力和设计能力。 我个人认为,衡量SaaS产品经理的优劣,其中一个重要的标准就是:当用户数不断增加,产品功能会不会被推翻或大幅修改,即能不能多做加法,少做减法和改法。 关于SaaS产品经理能力的更多观点,可以关注公众号:ToB老人家,阅读文章《我的实践:如何提升B端产品架构能力》。 02 标准化的意义产品标准化对SaaS公司至关重要。 曾经听某知名SaaS公司大区总监说,某个百万级项目谈得非常好,约定4个月交付上线。 结果到了第3个月,客户要求推倒重来,按客户实际业务重新开发。这位销售总监抱怨道:“前面谈得好好的,就用标准化产品。但到项目后期,客户却说产品满足不了业务需求。真是搞不懂。” 这就是典型的产品能力支撑不了销售能力。如果这样的项目很多,SaaS公司就很难盈利。 具体来说,SaaS标准化有以下三个重要意义: 1、降低边际成本SaaS公司最大的成本投入是研发成本, 如果每一个项目都是通过配置完成交付,这意味着随着用户数的增加,研发成本会被逐步摊薄,最终形成规模效应。因此标准化是SaaS公司盈利的关键之一。 2、沉淀最佳实践B端客户真正希望购买的是“行业最佳实践”。 即便SaaS公司具备丰富的行业经验,也了解行业标杆的业务策略和执行方案,如果SaaS产品不能体现和支撑这些“最佳实践”,那么推广和执行的成本都会很高。 所谓标准化,其实就是把领先企业的解决方案进行提炼,再固化到系统中。这些固化的解决方案,是SaaS系统的灵魂。 3、积累产品能力如果SaaS公司依赖运营而不是依赖产品来保障“客户成功”,那产品和产品经理的价值都会大打折扣。 标准化会不断增强产品的配置能力,使得产品越来越厚重,价值越来越高。也只有厚重的B端产品,才能磨炼和体现产品经理的产品能力。 03 标准化策略标准化策略是SaaS产品策略的重要组成部分。完整的SaaS产品策略这里不再敷述,感兴趣的读者可以关注公众号:ToB老人家,阅读文章《SaaS从0到1,产品策略决定成败》。 SaaS标准化策略可以分为三个部分,分别是: 1、产品版本标准化策略标准化最重要的策略,是确定“不满足哪些客户的需求”。 “一套产品吃遍天下”的传统软件时代,已经过去了。即便我们要占领多个细分市场,也要谨慎判断,是否通过“一个行业版本”满足全部客户的需求。 比如,在快消品行业,经销商和生产商的管理模式差异是比较大的。对于经销商来说,组织和权限的管理是相对简单的,也不涉及严格的外部账号管理;而品牌商则有复杂的多组织管理的需求,包括外部组织和账号的管理。 再比如,经销商的价格体系是相对简单的,不同等级的客户可能会有对应的价目表,部分客户会签订特定的价格协议;但是品牌商的价格体系则复杂很多,不同分公司、不同区域、不同商圈等级都会影响具体的价格。这是因为“价盘”是品牌商的生命线,所以精细的控制是有必要的。 快消品经销商和品牌商需求差异 当然,并不是说,我们一定不能在一个版本满足多个行业的需求。过去SAP、Oracle的成功已经证明这一点是可以实现的。 但是,SaaS引以为傲的正是足够“高可用”的系统。过于臃肿的产品,会大大增加客户的使用成本。 反过来说,“一个版本满足所有需求”当然是不正确的。但是如果盲目的横向扩充版本,也会给SaaS公司带来沉重的研发负担。 比如,当我们面对“非处方药”行业的客户,是否需要划分出一个版本呢?虽然并不是快消品行业,但是“非处方药”却在学习快消品行业的分销模式。在这种情况下,如果我们提供的是分销SaaS产品,就暂时没有必要单独为“非处方药”划分一个行业版本出来。 2、功能层标准化策略标准化第二重要的策略,是决定“哪些功能不标准化”。 对于大部分SaaS,90%以上的功能是能够在产品层面进行标准化的,但是可能有10%的功能是很难标准化的。分清楚哪些功能可以“在产品层面进行标准化”,也非常重要。 比如,中小企业对报表的需求相对简单,因此报表功能是相对容易标准化的;但是对于百亿级企业来说,报表是一个高度复杂且不能妥协的需求,因此对于还没有BI或者PaaS产品的SaaS企业来说,暂时进行定制也是一个可行的选择。 3、开发层标准化策略对于无法“在功能层进行标准化”的功能,我们要想办法在开发层进行标准化,即通常我们所说的PaaS,现在流行的叫法是“低代码”。 低代码是一个很“古老”的事物。我还在Oracle公司的时候,就很频繁的使用Oracle的低代码能力了——我们又叫personalization。通过它,我们可以改变字段的属性,也可以嵌入SQL甚至package。 也就是说,即便是能够灵活二次开发的传统软件,也非常依赖低代码。更不用说二次开发相对困难的SaaS公司了。 因此,如果一家SaaS决意要做大,PaaS能力就不是可选题,而是必选题。 但是,自研PaaS平台确实是一个费钱的工作,并不是所有SaaS创业公司,都能够轻易负担得起的。好消息是,中国SaaS正在进入平台时代,钉钉、企业微信逐步增强的低代码能力,有望帮助SaaS公司低成本的拥有“PaaS自由”。 04 标准化设计难点和自研系统相比,SaaS产品的设计更依赖长远规划。这是SaaS设计的核心,也是SaaS设计的难点。 重视长远规划,主要是由于两个原因。 1、控制开发成本由于标准化强调配置能力,因此同样一个功能,所需要的开发量可能是自研系统的数倍。一旦开发了拙劣的功能,就可能对开发资源造成惊人的浪费。 2、便于持续迭代更重要的是,作为“公用产品”,SaaS必须保持简洁性:如果系统充斥着一堆鸡肋的功能,且有少数企业坚持在使用,那么会对系统迭代造成阻碍。读者可以思考一下,当规划的新功能与这些鸡肋功能产生冲突,产品经理应该如何处理? 因此,好的SaaS设计就是尽量做“加法”,避免做“减法”和“改法”。 当然,标准化设计对产品经理本身也是有要求的。我常常比喻,所谓的标准化设计,就像在棋盘上放棋子:棋盘就是产品经理所拥有的架构能力,棋子就是具体的需求。没有棋盘,就不可能正确落子。 05 标准化设计步骤从设计过程来说,标准化设计可以遵循以下四个步骤: 1、策略层梳理所谓策略层梳理,是站在相对宏观的层面梳理业务。具体又包括以下步骤: 1.1、明确业务范围 企业的业务可以分为前中后台业务,前台业务包括商城APP等,中台业务包括CRM、订单管理、物流管理等,后台业务则包括HR、财务等。 我们首先需要明确,第一版SaaS产品版本主要是满足哪一块业务需求。划定好了边界,才能匹配公司的战略和资源。
1.2、梳理经营策略 所谓经营策略,其实就是企业的打法。比如,在线下分销业务中,用户企业是采用深度分销?还是兼有直销?搞清楚客户的经营策略,才能理清产品研发的思路。 此外,我们必须明白,SaaS是给一个行业的众多客户使用的。因此,我们还需要对企业所在行业的经营策略进行梳理。这样,一方面可以将客户的经营策略匹配到行业的经营策略,便于我们抓住本质,确保产品的通用性;另一方面,也可以通盘考虑未来的拓展方向,提前打好架构基础。 比如,快消品线下分销常见的策略包括大批发制、多级分销、深度分销、直销、车销等,而深度分销又分为厂家覆盖模式和经销商覆盖模式。作为产品经理,有必要全面梳理这些模式,才能在产品设计时胸有成竹。
1.3、梳理业务难点 相对于传统软件,SaaS是后来者。 根据产品替换公式:新产品价值>旧产品价值+替换成本,只有SaaS提供了更大的价值,客户才会考虑购买。退一步说,即便没有竞争的传统软件,SaaS也必须解决“以前无法解决的问题”,才能在激烈的竞争中站稳脚跟。 因此,梳理清楚业务难点,明白“客户为什么选择我们”,是非常重要的工作,可以让我们把资源集中在最关键的功能上。而不是分散资源,做那些客户虽然愿意使用,但是不构成“差异化竞争力”的功能。
2、业务层梳理业务层梳理,最有效的做法就是画业务流程图。 流程图的重点在于,产品经理要帮助客户梳理清楚业务和需求,避免错乱和遗漏。而做到这一点的关键,是产品经理要有一定的架构能力,即知道典范的流程应该如何流转。 如果是针对大客户的SaaS,那么建议到客户现场呆一段时间。大客户的要求比较细致,现场沟通可以提高沟通的效率。 如果是针对小客户的SaaS,那么建议你先找到几个种子用户,通过流程图,确保1.0版本是他们能够接受的MVP(最小可行产品)。 流程图绘制细节是基本功,这里就不再敷述。下面放一张我曾经绘制的流程图供大家参考。
3、 多组织架构设计企业业务的开展,是基于多个部门的相互协同和相互监督的。当用户在使用SaaS系统时,流程流转、数据安全性都必须符合企业协同与管控的要求。这就需要我们设计好组织、角色和权限功能。而这里面最有难度的,就是多组织架构设计。 比如,某饮料公司为扩大销售规模,分别在A市和B市建立了分公司,各负责一个大区的生产和销售。为便于管理和激励分公司团队,公司决定两个分公司独立核算利润,并根据实现的利润进行分红。 为支持两个分公司的独立核算,并防止数据泄露,该饮料公司IT团队决定分别给两个分公司建立一个“利润中心组织”。在“利润中心组织”下面建立了相应的“角色”,并分配了相应的“功能”比如销售订单、发货功能等等。最后,将相应的“角色”分别分配给了两个分公司的员工。 这样,A公司员工建立的销售订单,所产生的收入和利润数据,均会统计到A公司。且销售订单、收入和利润等数据,只能由A公司的员工查看。B公司亦如此。 多组织架构实际上体现了企业责权利的划分,决定了组织间协同与风险管控策略。由于企业越大,组织架构就越复杂,管控要求也越高。因此,越是针对大型企业的SaaS,越需要重视多组织架构的设计。 当然,如果是针对小企业的SaaS,多组织架构就相对简单了,大家把角色和权限管理设计好即可。 关于多组织架构设计的详细内容,我专门写了一篇文章,大家可以关注公众号:ToB老人家,阅读《B端大PM必备:多组织架构设计》。
4、 产品功能设计作为SaaS设计的主体,产品功能设计又可以分为应用架构设计和详细功能设计。 4.1、应用架构设计 所谓应用架构设计,即各系统应用的整体结构图。 相对于自研产品,SaaS的应用架构设计更为关键。合理的应用架构可以减少功能重复、避免数据混乱和降低系统拓展的难度。而一旦在不合理的应用架构上搭建起功能模块,并且拥有一定数量的企业客户后,修改的成本就非常高了。 相对来说,自研产品的纠错成本就低得多。毕竟只有一家企业在用,只要和业务部门协商好,推翻重建也不是不可以。 对于产品经理来说,应用架构设计的重点要做到低耦合、高复用。 所谓低耦合,是将功能按照业务相关性,分为多个系统应用。系统应用之间通过API进行交互。这样,单个应用的升级,对其他应用的影响就小很多,从而提高了系统的敏捷性。比如,销售订单管理、仓库管理和CRM就可以独立为多个应用,并且在必要的时候分配给不同的团队负责。 所谓高复用,即将各个模块所共用的功能抽离出来,单独形成一个系统应用。这样,一方面确保了信息来源的一致性,另一方面简化了系统,避免了重复开发。比如,客户信息在销售订单管理、CRM、TMS(运输管理)等系统应用中都会用到,是有必要独立成一个应用的。 应用架构设计虽然没有标准答案,但实际上不管是传统的Oracle ERP系统,还是新兴的各大电商、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同学充分沟通和探讨,更重要的是多研究和学习竞品。
06 总结SaaS产品的设计,很强调产品经理的架构能力。 关于架构能力怎么培养,大家可以关注公众号:ToB老人家,阅读文章《我的实践:如何提升B端产品架构能力》。 如果用一句话对本文做个总结,那就是: 画好棋盘,放好棋子。 祝大家,设计出一款改变世界的SaaS产品。 |
|