SaaS产品该如何设计和运营?
http://www.woshipm.com/topic/saas
SaaS产品经理的从业之道【三节课 课程导师-程功夫 有赞】
https://www.sanjieke.cn/course/detail/2/web/16794141?course_type=self_study


程功夫老师提到的文章:
2019年中国企业级SaaS行业研究报告
https://www.toutiao.com/a6698497036800492039/
了解SaaS产品经理的工作方法,看这一篇就够了
https://www.toutiao.com/a6663305773893812748/
潮起潮落,看SaaS如何理性突围?
https://www.toutiao.com/a6730790009265193485/
B端产品的配置应如何设计(李东林 公众号 SaaS产品说)
白鸦的那篇演讲


与C端的不同点

1.存在业务壁垒
·SaaS产品存在很强的业务壁垒,隔行如隔山。
2.业务流程复杂
·SaaS产品看似简单的功能也会涉及多个角色,流程繁杂需要全盘考虑。
3.个性化需求多
·SaaS产品需要满足不同客户的个性化需求,设计方案复杂。
SaaS不等于B端,也有面向C端的SaaS,如印象笔记、石墨文档、百度网盘。

不同点带来的问题:
image.png

导论 快速入门SaaS产品

宏观角度看SaaS

1.到底什么是SaaS

背景与趋势

需求端:随着市场的成熟,行业专业化分工水平不断提升。对于大多数公司,尤其是中小创业企业,购买SaaS类产品,通过企业服务类的互联网产品提升企业运营效率,降低运营成本成为一种共识。
供给端:云计算及其他基础设施的成熟,使得企业的去IOE化成为可能,尤其是SaaS基于订阅的销售模式,更进一步降低了to B产品的推广和使用成本,使得SaaS兴起成为可能。

去IOE化:阿里发起,IBM是服务器提供商,Oracle是数据库软件提供商,EMC则是存储设备提供商。

传统软件交付模式的优缺点
优点:数据私有(软件安装在用户指定的地方,拥有100%管控权)
缺点:维护成本高(需要持续投入人员和资源维护系统的正常运行)

一般流程:

提供需求说明。(提供不了,则找咨询公司IBM) 支付软件费用。 提供硬件环境。 上门安装调试。 正式投入使用,培训等。

SaaS模式的特点

SaaS是一种新的软件交付模式
(SaaS就是软件公司先把所有软件相关工作都归类准备好,用户过来直接挑选自己需要的服务)

云端架构:SaaS公司提供服务器、数据库等硬件,无需本地部署; 成本下降:无需客户承担基础设施成本、日常运维成本; 付费灵活:用户按月、年支付费用,而非一次性购买; 体验提升:升级维护有SaaS公司负责,通过数据迭代驱动;(PS:一次付费,终身升级?)

SaaS:微商城,teambition,有赞,MOKA;
非SaaS:钉钉,企业微信,东软,文思海辉;(PS:思考:为什么钉钉,企业微信不是SaaS;)

【类似自己打井和自来水。】

SaaS,PaaS,IaaS的区别

(阿里云、腾讯云属于IaaS。)
image.png

2.SaaS的过去和未来

  • SaaS在美国的发展

传统软件巨头:Microsoft,SAP,IBM;
新兴公司:salesforce,workday,shopify;
shopify的发展(有赞的对标):软件工具-工具平台-生态系统
image.png

  • 中美市场对比

    中国SaaS市场的土壤环境

    • 工商注册企业:8000万+
    • 拥有完整财务信息化系统企业:200万+
    • 信息化转型企业中选择“上云”占比:78.3%
    • 企业平均账号单价:147.2$/终端账号*年

    美国SaaS市场土壤

    • 注册企业数量:2800万+
    • 上云企业占比:80%
    • 企业平均账号单价:255$/终端账号*年
  • SaaS在中国未来趋势

宏观经济:消费互联网红利已尽,产业互联网崛起;
商业动态:传统软件厂商、互联网巨头入局;
用户群体:小B群体需求被挖掘;(夫妻店等)
技术升级:SaaS+PaaS成为趋势;

3.SaaS的细分结构和4个业务阶段

业务垂直型:面向特定业务;
行业垂直型:面向特定行业;
image.png
36氪和艾瑞的划分方法:
image.png

image.png

业务垂直型:ERP,CRM,OA,HRM,财税,客服呼叫等;

CRM:纷享销客,销售易,ec SCRM; HRM:北森,薪人薪事,MOKA;

行业垂直型:
零售电商,餐饮,医疗,教育,物流,金融;
零售、餐饮较分散,金融较聚集,比如北京金融街、上海陆家嘴;

零售电商:有赞,京东云,电商宝; 教育:校宝在线,云朵课堂,小鹅通;

企业经营活动划分

image.png

商业活动:纷享销客,有赞;
管理活动:teambition,薪人薪事;(管理人和事);
技术活动:GitHub,神策;
会计活动:金蝶,用友;
安全活动:云子可信;
财务融资活动:依赖创始人的人脉关系;
(思考:教育信息化场景,学校的活动怎么划分?)

不同阶段企业经营活动的侧重点

非成熟企业(商业模式未跑通) 早期需要资金,关注财务、融资活动; 早期需要打磨产品,关注技术活动; 成熟企业(商业模式跑通) 需要帮助企业创收,关注商业活动; 需要帮助企业提高管理效率,关注管理活动;

(PS:其实有些时候是需要同时做的)
SaaS业务的阶段特征
image.png
对应策略

基础产品完善期:做好产品和服务,关注续费和转介绍; 行业产品深入期:做好市场和销售,关注主动购买和毛利; 生态建设期:既定标准成势能,关注市场占有率;

产品经理不同阶段的工作重心

从0到1

  • 找到标杆客户核心场景
  • 定义最小场景闭环
  • 优先满足核心场景功能模块

从1到N

  • 厘清需求价值
  • 寻找通用解决方案
  • 运用可配置满足个性化需求

第一章 深刻理解SaaS业务

宏观:快速了解一个行业
微观:如何进行业务调研
image.png

行业模式:从宏观角度,我们需要了解在行业内的企业,相应的业务是怎么玩的,从而抽象出通用的玩法和规则。这样我们才可以了解企业的核心痛点,提供SaaS产品与服务也可以有的放矢。
运作流程:从微观角度,对于每个企业,我们也有必要了解企业内相应业务的不同员工是如何操作,最终实现公司业务的运转,了解这些内容,才可以使我们SaaS产品设计更加落地。

C端产品 SaaS产品
用户特征对比 用户分布 零散,呈点状 集中,呈环状
决策人群 一个人 一群人
决策路径
挖掘需求方式 产品经理一般都是用户;
通过共情来挖掘需求;
产品经理通常不是用户;
通过理解业务来挖掘需求;

PS:环是指业务闭环;C端的决策路径也会很长,比如买房买车;

业务到底是什么?

理解业务=懂行业模式+懂运作流程 行业模式(宏观):行业约定俗成的玩法和规则是什么? 运作流程(微观):行业中的某个企业的不同岗位、角色是如何各司其职的?

1.SaaS产品经理如何快速了解一个行业?

image.png
行业基础信息——这里不能只停留在大行业上,而是要聚焦于我们SaaS产品要满足的业务边界;
外部经营环境——这块市场未来趋势如何,我们SaaS产品切入有没有机会?如果已经切入,风险在哪里?(pest)
内部市场环境——表面上是分析产业链上下游和竞争,最终是为了找到业务通用的玩法和规则有哪些,即找到通用的业务模式种类;
标杆企业分析——其实就是上面业务模式种类的具体表达,类似于具体用户故事与用户群体的关系;
SaaS竞品分析——通过竞品分析,对比找到自家SaaS产品的差异和竞争点,回到自身产品的定位上。

传统行业和新兴行业

  • 国民经济行业分类:金融业,采矿业,IT业,建筑业,批发和零售业…;
  • 新兴行业:新零售,人工智能,区块链,VR/AR;

2.SaaS产品经理如何进行业务调研?

业务调研的最终目的是为了理解业务的运作流程;
运作流程的元素包括:企业,角色,流程;

企业:与行业分析中标杆企业不同的是,这里的客户画像需要有一个宏观的抽象,并非纯粹还原一个真实企业的信息;根据不同行业的不同,客户画像需要包含的维度也会存在区别,并不限于规模、从属类目、业务范围等等; 角色:除了弄清楚业务中每个角色的目标/KPI之外,还需要厘清角色之间的关联(绘制出角色关联的业务逻辑图是一个很好的主意) 流程:站在业务的视角,需要梳理全盘的业务流程,站在单个员工角色视角,也需要找到角色工作流。

企业:该业务对应的客户画像是什么样子的?
——通过定义标杆企业描绘客户画像;
角色:有哪些角色?对应的职业特点是什么?
——通过查看组织架构和参考同类型企业来梳理角色特征;
流程:核心业务的工作流是什么样的?
通过观察和调研了解核心业务的工作流;

用户调研的区别

维度 C端用户调研 SaaS业务调研
调研对象上 C端用户调研只需要关注单点用户 SaaS业务调研需要全盘考虑整个业务运作流程
调研目的上 C端用户调研需要以用户体验为中心 相对于体验,SaaS业务调研需更关注需求解决了什么业务问题
调研结果上 C端用户需求相对容易抽离出共性 由于业务千差万别,SaaS天然存在大量个性化需求且极度分散

步骤

交付物

客户画像 调研角色 角色特征 核心工作流
规模,从属细分类目,业务范围; 角色A 主要负责什么?
任务目标、KPI是什么?
其他职业特点?
任务A-B-C-D
B
C

1.定义并选择标杆企业
定义标杆企业的客户画像,以标杆企业的需求为核心;
为什么要选择标杆企业?

标杆企业需求有代表性,相对容易抽离; 标杆企业的声音有影响力,后期能够引领其他客户;

2.梳理业务链条的角色
找到业务链条的全部角色,定义角色特征;(即使不重要的角色也不能忽略,否则无法形成业务闭环)
如何找到这些角色?

通过企业内部系统获得组织架构; 参考同类别的企业;

3.观察与调研并行
通过观察和用户调研厘清角色的工作流;
观察比直接开放式调研更有效;
观察的两种方式?

驻场:深入业务需求方的工作场景,观察他们的工作方式; 角色的工作流如何?有没有SOP? 在什么情况下,执行了哪些任务,完成了什么业务目标? 轮岗:如果有机会,最好能够上手体验业务方的工作。

通过用户调研补充了解细节
调研参考问题

流程维度 ——最近一个月最花你精力的几件事情是什么?是怎么解决的? ——最近一个月和哪些人沟通会比较多?沟通目的是什么? 具体场景维度 十么情况下,遇到了什么问题,导致什么目标没有实现? ——如果有了这个功能,你准备如何去做?

第二章 定义SaaS产品的场景与价值

回归场景,梳理出场景清单;梳理并描述业务场景;
厘清价值,应用到需求分析;判断场景中需求的价值;

场景与价值

为什么要回归场景?

对外沟通—部门外部/他人 产品经理想要完成一项任务,需要和多个部门、多个角色频繁地传递用户需求,因此使用一套易理解、贴近实际的沟通方式。而场景就是通行于不同角色之间解决产品问题的语言。 对内思考—部门内部/自己 产品设计的过程是先发散后收敛,因此在动手画原型、写文档之前,我们需要做大量的思考、调研。逻辑基点是用户面临的实际情况到底是什么样的,即回归场景。

为什么SaaS更要回归场景?梳理多个场景需要考虑业务闭环。

维度 C端 SaaS
单个场景 自己就是用户,可以以发散的方式创造场景,从而引领用户的需求 存在业务壁垒,无法发散,只能还原场景,且颗粒度更细
多个场景 用户路径相对简单,重点在于单点突破核心场景 业务链条长,缺少任一环节都无法形成闭环

描述单个场景——场景七要素
梳理全场景——需求清单

需求来源于场景,满足需求产生价值
SaaS产品更需要理解价值?

C端的价值 SaaS的价值
可能存在很多伪需求,需要对其进行过滤,然后对剩余需求进行价值判断 场景基本都是真实存在的,客户就是上帝,基本不存在伪需求,所以需要对大量需求进行判断
大部分C端产品只极致考虑用户价值,而忽略商业价值 是客户花钱买的,需要考虑需求对自身的商业价值

价值判断的三个典型问题?

如何判断某个需求做不做? 不同角色的诉求冲突,如何权衡? 如何判断多个需求的优先级?

1.7要素描述产品场景

七要素

要素 要素 要素介绍 举例
用户 某一个用户 一个人、一种类型的群体
环境 在某一特定的环境下 空间、材料、设备等物理环境;
物质、工具、时间、金钱等约束条件
时机 出现某一个特定的时机 触发目标产生目标的事件;影响用户行为的环境变化;
目标 带着某一个目标 任务结束的停止条件
动作 采取了一系列动作 简单、具体、最小化的任务
介质 和某些介质交互 介质的背后,可以是另一个用户
任务 完成一个特定的任务 通常是逐步进行的

image.png
七要素的关联
image.png

场景描述的方式本身不重要,对外沟通形成统一的认知,对内思考能够还原用户实际情况才是关键。
检验自己是否真正掌握场景定义七要素的标准是——你描述完场景,别人是否有清晰的画面感。

场景七要素是如何得到的?

通过观察与调研进行场景对比

  • 观察:在没有这个功能的情况下

什么样的用户,在什么环境下,因为什么时机,产生了什么目标,并通过与哪些介质进行了什么动作,完成哪些系列的任务?

  • 调研:如果有了这个功能

什么样的用户,在什么环境下,因为什么时机,产生了什么目标,并通过与哪些介质进行了什么动作,完成哪些系列的任务?
【任何一个要素发生变化,都会导致场景不一样,进而产生不一样的需求。】

2.如果通过场景需求清单梳理场景

步骤
梳理出清晰的业务流程;
将场景写出并归类到流程;
基于场景拆解用户需求;
样例:
image.png
有时候,为了验证,或受到成本约束,要梳理核心场景需求清单;

3.价值主张与需求对应的价值

价值主张:宏观层面,由总监提出,自己要理解;
需求对应的价值:微观层面,自己判断;
关系:价值主张为需求判断的价值提供方向和原则;不同需求价值的积累,进一步巩固价值主张;
为特定用户提供差异化的价值
价值主张是进行需求判断的第一原则:SaaS产品要尽可能的满足每个客户的个性化需求,但不应该包含与价值主张不一致的需求。

需求的两种价值

用户价值和商业价值
用户价值:与产品和服务相关的、与用户的人生价值、业务目标方向一致的;
商业价值:在经济意义上,用户愿意付出成本作为某个产品利益的回报;
image.png

  • 用户价值的分类—对于用户

业务闭环类价值 效用类价值:便利性、安全性、耐用性、经济性… 体验类价值:权威、身份、社会关系、隐私、快乐、愉悦、好奇、回忆…

  • 商业价值的分类—对于自身

收入:能不能促进客户签约,影不影响客户续约 数据:对自身是否能够采集到更多的业务数据


找出价值需要做三件事:

1.需求的用户价值是否与产品价值主张相契合? 2.需求的用户价值具体类型是什么?表现在哪里? 3.需求是否存在商业价值表现在哪里?

在有赞内部,用户价值和商业价值都是如何体现的。
1.有赞用户(商家)价值

用户增长类价值:比如客户运营、销售渠道、营销活动、数据报表等 经营管理效率价值:比如员工管理、连锁能力、商品管理、财务资产等 数智化价值:比如智能导购、智能营销等 安全稳定性价值:双机房、平台风控合规等 体验类价值:商家需求提报、客服咨询、认证流程等

2.有赞商业(企业)价值

商家增长:比如获客、活跃、留存等 商业化能力:搭建商业化体系&策略 降本提效:降低服务成本、销售成本、研发成本等 生态:通过第三方搭建生态 长期价值:战略合作、社会价值、品牌价值等

4.如何基于价值进行需求的判断

用户价值和商业价值四象限法(用户价值-纵轴和商业价值-横轴)

用户价值为负,无论商业价值多大,不能做。 商业价值为负,用户价值为正,需要谨慎考虑。

如何判断某个需求做不做?都为正也不一定能做,比如少显示营业额可减少租金,商家盈利,平台也能多得点。
不同角色的诉求冲突,如何权衡?使用者和决策者思路不一致,侧重决策者的诉求,调和使用者的体验。
如何判断多个需求的优先级?通过kano模型,优先级:P0必备型>P1期望型>P2惊艳型
image.png
(PS:怎么看怎么费解,建议去掉坐标轴,或者隐去负坐标轴,就会比较明白。)

必备型:
·一般是业务流程中必不可少,让业务可以闭环的基本需求 比如—商品管理中的添加商品,订单管理中的处理订单 期望型: ·一般是用户基本需求已经满足之上,更进一步提高用户的效率或帮助贡献收入 比如商品管理中的批量添加商品,店铺管理中的店铺模板 惊艳型: ·一般偏用户体验类型的需求 比如首次完成订单后给予夸奖的通知

先根据kano模型进行分类,再在不同层次内判断优先级。

必备型: ·必备型需求层次内不存在优先级 期望型: ·存在商业价值的需求优先 ·其余需求需评估对于效用价值的影响面 惊艳型: ·存在商业价值的需求优先 ·其余需求需评估对于用户体验价值的影响面

(PS:提到了效用价值和用户体验价值)
近似正确大于精准错误:没有一种方法可以将需求划分到足够小的优先级颗粒度,能够大体分类即可。

第三章 SaaS产品设计—构架与功能

如何梳理出符合业务的架构;
如何基于架构设计功能,满足个性化需求;

关于架构和功能

“后端标准化,前端个性化”
如果缺乏结构化思考(抽象),单点设计会让你筋疲力尽,导致功能不断堆砌,开发成本变高。对用户来说,信息也过于复杂,会降低使用效率。
eg:预约,要定金or不要定金,指定不指定技师,…

1.商业活动和管理活动通用的架构

这里把企业经营活动分为商业活动和管理活动。

商业活动:帮助企业把资源卖出去,或把资源买进来。 管理活动:帮助企业把人和事(项目)理清楚。

商业活动

商品管理:如何让商品有更好的卖相,如何高效的管理商品?
订单管理:了解商品的销售情况,最大化创收?
客户管理:了解购买者的情况。

业务 业务描述
商品管理 商品管理 进行商品的增删改查,上下架等操作
商品分类 商品在前后台的分类和标签,便于自身管理,同时让用户查看
商品包装 进行商品介绍的包装和展现
库存管理 进行商品库存和采购订单的管理
商品信息 管理基础的不同品类的商品信息
订单管理 订单详情 订单列表的查看,支付产生新订单
订单处理 正向交易有关业务:实物发货,到店核销,取消订单;
订单退款 负向交易有关业务:退款,退货;
管理评价 处理评价,维权
客户管理 客户管理 客户的基本信息管理,增删改查
客户运营 查看客户的人群情况,进行场景化营销
客户权益 厘定不同等级的客户所享受的权益,以及不同等级成长值的设置
客户分析 分群与标签,便于push
客户积分 积分消费规则

其他模块都是基于这三个模块生长起来的。
image.png

管理活动

管人-HRM;管事(项目)-OA;管资源-ERP
管理对象不同,架构存在较大区别;

业务 业务描述
员工管理 招聘需求 发布招聘、筛选简历、面试反馈等招聘流程
岗位管理 各岗位设置和权限管理
花名册 员工的基础信息
考勤管理 创建考勤制度 时间、方式等规则,以及对员工的影响
打卡 集体考勤方式的执行与监控
查看考勤记录 不同维度查看考勤数据,导出报表
薪酬管理 创建薪酬方案 基于不同岗位级别和不同贡献度设置规则
计薪周期 计算工资生效时间
工资管理 查看详情 查看不同员工的薪资发放情况
审核工资 审核工资是否存在问题
发放工资 基于考勤制度,薪酬制度,结合员工数据进行工资自动化发放

员工管理模块通过考勤制度和薪酬制度产生活动数据,并最终通过工资管理反馈。
image.png

2.如何梳理复合业务的架构

架构是长出来的
梳理架构三个步骤

1.将场景需求清单拆解到功能; 2.将功能按不同维度进行分类聚合; 3.梳理模块之间的逻辑关系;

将场景需求清单拆解到功能示意
image.png
每一个功能都需要明确解决一个具体的业务问题;(比如“查看商品详情”是一个功能,“点击商品名称”不是)
将需求翻译成功能,十分考验对业务的理解;功能转化成原型,(视觉布局和操作流程)考验设计功底;
梳理模块之间的逻辑关系

先梳理静态模块(不产生数据流) 如:客户管理管理、员工管理模块、服务管理模块和资金管理模块 再梳理动态模块(产生数据流) 如:预约管理模块和订单管理模块

3.如果基于架构设计功能,满足个性化的需求

如何高效满足个性化需求是SaaS产品经理面临的最常见的问题
如何通过设计配置项解决个性化需求,最考验SaaS产品经理的功力
运用可配置高效满足个性化需求的两种情况?

业务流程与现有方案差别小——从功能层面进行配置

业务流程与现有方案差别大——从系统层面进行配置

高可配置的误区

1.高可配置往往会造成低易用性 配置项多会带来页面不简洁,流程不高效;用户要的不是配置项,是低成本实现目标的功能 2.高可配置会带来极高的开发成本 如果很多配置项没有被高效使用,无疑是开发资源的极大浪费

如何判断一个功能要不要做成配置项?
image.png
①可以做出配置项
②低成本,技术进行手动配置
③做出高级付费功能
④看商业价值是否需要定制