SaaS产品设计,从0到1案例实操
PMCAFF
共 8941字,需浏览 18分钟
·
2021-05-23 11:28
本文由作者 王戴明 发布于社区 对于大部分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能力就不是可选题,而是必选题。 但是,自研PaaS平台确实是一个费钱的工作,并不是所有SaaS创业公司,都能够轻易负担得起的。好消息是,中国SaaS正在进入平台时代,钉钉、企业微信逐步增强的低代码能力,有望帮助SaaS公司低成本的拥有“PaaS自由”。
04
标准化设计难点
和自研系统相比,SaaS产品的设计更依赖长远规划。这是SaaS设计的核心,也是SaaS设计的难点。重视长远规划,主要是由于两个原因: 1. 控制开发成本
由于标准化强调配置能力,因此同样一个功能,所需要的开发量可能是自研系统的数倍。一旦开发了拙劣的功能,就可能对开发资源造成惊人的浪费。 2. 便于持续迭代
更重要的是,作为“公用产品”,SaaS必须保持简洁性:如果系统充斥着一堆鸡肋的功能,且有少数企业坚持在使用,那么会对系统迭代造成阻碍。读者可以思考一下,当规划的新功能与这些鸡肋功能产生冲突,产品经理应该如何处理? 因此,好的SaaS设计就是尽量做“加法”,避免做“减法”和“改法”。 当然,标准化设计对产品经理本身也是有要求的。我常常比喻,所谓的标准化设计,就像在棋盘上放棋子:棋盘就是产品经理所拥有的架构能力,棋子就是具体的需求。没有棋盘,就不可能正确落子。
05
标准化设计步骤
从设计过程来说,标准化设计可以遵循以下四个步骤: 1. 策略层梳理
所谓策略层梳理,是站在相对宏观的层面梳理业务,具体又包括以下步骤: 1)明确业务范围 企业的业务可以分为前中后台业务,前台业务包括商城APP等,中台业务包括CRM、订单管理、物流管理等,后台业务则包括HR、财务等。 我们首先需要明确,第一版SaaS产品版本主要是满足哪一块业务需求。划定好了边界,才能匹配公司的战略和资源。 案例: 一家知名快消品厂家找到某SaaS公司(简称A公司),希望开发一款管理销售人员的移动APP。经过沟通,SaaS产品经理小李意识到,客户的需求实际上是分销管理,包括销售订单管理、销售人员管理和门店管理等。 虽然A公司有服务于快消品‘经销商’的分销管理系统,但是一直苦于无法切入利润更丰厚、收入更稳定的快消品‘品牌商’市场,这正是一个非常好的机会。 2)梳理经营策略所谓经营策略,其实就是企业的打法 比如:在线下分销业务中,用户企业是采用深度分销?还是兼有直销?搞清楚客户的经营策略,才能理清产品研发的思路。 此外,我们必须明白,SaaS是给一个行业的众多客户使用的。因此,我们还需要对企业所在行业的经营策略进行梳理。这样,一方面可以将客户的经营策略匹配到行业的经营策略,便于我们抓住本质,确保产品的通用性;另一方面,也可以通盘考虑未来的拓展方向,提前打好架构基础。 比如,快消品线下分销常见的策略包括大批发制、多级分销、深度分销、直销、车销等,而深度分销又分为厂家覆盖模式和经销商覆盖模式。作为产品经理,有必要全面梳理这些模式,才能在产品设计时胸有成竹。 案例: 小李和客户沟通后,发现该快消品厂家主要采用了大批发制、直销和深度分销三种经营策略,属于行业比较经典的打法,可以先开发这三种分销模式,同时兼顾到未来向多级分销和车销的拓展。
大批发制
直销制
深度分销
2. 业务层梳理
3. 多组织架构设计
4. 产品功能设计
功能升级需要大幅修改原有功能,开发抱怨; 功能升级改变原有体验,客户抱怨; 功能上线后,没有人使用,团队抱怨; 功能上线后,客户说需求变更了,各种人抱怨。
长远规划,谨慎设计
需要管理赠品发货; 买5增2,买5瓶大可乐送2种赠品; 需要和ERP系统集成等情况时,就会出现问题。
深度思考,究竟精神
便览竞品,死磕细节
总结
↘好文推荐: 俞军:产品经理必备的2个模型 用户细分指南:6种模型与5类维度 产品方案:我的PRD撰写规范 点个“在看”吧
评论