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,如印象笔记、石墨文档、百度网盘。
不同点带来的问题:
导论 快速入门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。)
2.SaaS的过去和未来
- SaaS在美国的发展
传统软件巨头:Microsoft,SAP,IBM;
新兴公司:salesforce,workday,shopify;
shopify的发展(有赞的对标):软件工具-工具平台-生态系统
- 中美市场对比
中国SaaS市场的土壤环境
- 工商注册企业:8000万+
- 拥有完整财务信息化系统企业:200万+
- 信息化转型企业中选择“上云”占比:78.3%
- 企业平均账号单价:147.2$/终端账号*年
美国SaaS市场土壤
- 注册企业数量:2800万+
- 上云企业占比:80%
- 企业平均账号单价:255$/终端账号*年
- SaaS在中国未来趋势
宏观经济:消费互联网红利已尽,产业互联网崛起;
商业动态:传统软件厂商、互联网巨头入局;
用户群体:小B群体需求被挖掘;(夫妻店等)
技术升级:SaaS+PaaS成为趋势;
3.SaaS的细分结构和4个业务阶段
业务垂直型:面向特定业务;
行业垂直型:面向特定行业;
36氪和艾瑞的划分方法:
业务垂直型:ERP,CRM,OA,HRM,财税,客服呼叫等;
CRM:纷享销客,销售易,ec SCRM; HRM:北森,薪人薪事,MOKA;
行业垂直型:
零售电商,餐饮,医疗,教育,物流,金融;
零售、餐饮较分散,金融较聚集,比如北京金融街、上海陆家嘴;
零售电商:有赞,京东云,电商宝; 教育:校宝在线,云朵课堂,小鹅通;
企业经营活动划分
商业活动:纷享销客,有赞;
管理活动:teambition,薪人薪事;(管理人和事);
技术活动:GitHub,神策;
会计活动:金蝶,用友;
安全活动:云子可信;
财务融资活动:依赖创始人的人脉关系;
(思考:教育信息化场景,学校的活动怎么划分?)
不同阶段企业经营活动的侧重点
非成熟企业(商业模式未跑通) 早期需要资金,关注财务、融资活动; 早期需要打磨产品,关注技术活动; 成熟企业(商业模式跑通) 需要帮助企业创收,关注商业活动; 需要帮助企业提高管理效率,关注管理活动;
(PS:其实有些时候是需要同时做的)
SaaS业务的阶段特征
对应策略
基础产品完善期:做好产品和服务,关注续费和转介绍; 行业产品深入期:做好市场和销售,关注主动购买和毛利; 生态建设期:既定标准成势能,关注市场占有率;
产品经理不同阶段的工作重心
从0到1
- 找到标杆客户核心场景
- 定义最小场景闭环
- 优先满足核心场景功能模块
从1到N
- 厘清需求价值
- 寻找通用解决方案
- 运用可配置满足个性化需求
第一章 深刻理解SaaS业务
宏观:快速了解一个行业
微观:如何进行业务调研
行业模式:从宏观角度,我们需要了解在行业内的企业,相应的业务是怎么玩的,从而抽象出通用的玩法和规则。这样我们才可以了解企业的核心痛点,提供SaaS产品与服务也可以有的放矢。
运作流程:从微观角度,对于每个企业,我们也有必要了解企业内相应业务的不同员工是如何操作,最终实现公司业务的运转,了解这些内容,才可以使我们SaaS产品设计更加落地。
C端产品 | SaaS产品 | ||
---|---|---|---|
用户特征对比 | 用户分布 | 零散,呈点状 | 集中,呈环状 |
决策人群 | 一个人 | 一群人 | |
决策路径 | 短 | 长 | |
挖掘需求方式 | 产品经理一般都是用户; 通过共情来挖掘需求; |
产品经理通常不是用户; 通过理解业务来挖掘需求; |
PS:环是指业务闭环;C端的决策路径也会很长,比如买房买车;
业务到底是什么?
理解业务=懂行业模式+懂运作流程 行业模式(宏观):行业约定俗成的玩法和规则是什么? 运作流程(微观):行业中的某个企业的不同岗位、角色是如何各司其职的?
1.SaaS产品经理如何快速了解一个行业?
行业基础信息——这里不能只停留在大行业上,而是要聚焦于我们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要素描述产品场景
七要素
要素 | 要素 | 要素介绍 | 举例 |
---|---|---|---|
用户 | 某一个用户 | 一个人、一种类型的群体 | |
环境 | 在某一特定的环境下 | 空间、材料、设备等物理环境; 物质、工具、时间、金钱等约束条件 |
|
时机 | 出现某一个特定的时机 | 触发目标产生目标的事件;影响用户行为的环境变化; | |
目标 | 带着某一个目标 | 任务结束的停止条件 | |
动作 | 采取了一系列动作 | 简单、具体、最小化的任务 | |
介质 | 和某些介质交互 | 介质的背后,可以是另一个用户 | |
任务 | 完成一个特定的任务 | 通常是逐步进行的 |
七要素的关联
场景描述的方式本身不重要,对外沟通形成统一的认知,对内思考能够还原用户实际情况才是关键。
检验自己是否真正掌握场景定义七要素的标准是——你描述完场景,别人是否有清晰的画面感。
场景七要素是如何得到的?
通过观察与调研进行场景对比
- 观察:在没有这个功能的情况下
什么样的用户,在什么环境下,因为什么时机,产生了什么目标,并通过与哪些介质进行了什么动作,完成哪些系列的任务?
- 调研:如果有了这个功能
什么样的用户,在什么环境下,因为什么时机,产生了什么目标,并通过与哪些介质进行了什么动作,完成哪些系列的任务?
【任何一个要素发生变化,都会导致场景不一样,进而产生不一样的需求。】
2.如果通过场景需求清单梳理场景
步骤
梳理出清晰的业务流程;
将场景写出并归类到流程;
基于场景拆解用户需求;
样例:
有时候,为了验证,或受到成本约束,要梳理核心场景需求清单;
3.价值主张与需求对应的价值
价值主张:宏观层面,由总监提出,自己要理解;
需求对应的价值:微观层面,自己判断;
关系:价值主张为需求判断的价值提供方向和原则;不同需求价值的积累,进一步巩固价值主张;
为特定用户提供差异化的价值
价值主张是进行需求判断的第一原则:SaaS产品要尽可能的满足每个客户的个性化需求,但不应该包含与价值主张不一致的需求。
需求的两种价值
用户价值和商业价值
用户价值:与产品和服务相关的、与用户的人生价值、业务目标方向一致的;
商业价值:在经济意义上,用户愿意付出成本作为某个产品利益的回报;
- 用户价值的分类—对于用户
业务闭环类价值 效用类价值:便利性、安全性、耐用性、经济性… 体验类价值:权威、身份、社会关系、隐私、快乐、愉悦、好奇、回忆…
- 商业价值的分类—对于自身
收入:能不能促进客户签约,影不影响客户续约 数据:对自身是否能够采集到更多的业务数据
找出价值需要做三件事:
1.需求的用户价值是否与产品价值主张相契合? 2.需求的用户价值具体类型是什么?表现在哪里? 3.需求是否存在商业价值表现在哪里?
在有赞内部,用户价值和商业价值都是如何体现的。
1.有赞用户(商家)价值
用户增长类价值:比如客户运营、销售渠道、营销活动、数据报表等 经营管理效率价值:比如员工管理、连锁能力、商品管理、财务资产等 数智化价值:比如智能导购、智能营销等 安全稳定性价值:双机房、平台风控合规等 体验类价值:商家需求提报、客服咨询、认证流程等
2.有赞商业(企业)价值
商家增长:比如获客、活跃、留存等 商业化能力:搭建商业化体系&策略 降本提效:降低服务成本、销售成本、研发成本等 生态:通过第三方搭建生态 长期价值:战略合作、社会价值、品牌价值等
4.如何基于价值进行需求的判断
用户价值和商业价值四象限法(用户价值-纵轴和商业价值-横轴)
用户价值为负,无论商业价值多大,不能做。 商业价值为负,用户价值为正,需要谨慎考虑。
如何判断某个需求做不做?都为正也不一定能做,比如少显示营业额可减少租金,商家盈利,平台也能多得点。
不同角色的诉求冲突,如何权衡?使用者和决策者思路不一致,侧重决策者的诉求,调和使用者的体验。
如何判断多个需求的优先级?通过kano模型,优先级:P0必备型>P1期望型>P2惊艳型
(PS:怎么看怎么费解,建议去掉坐标轴,或者隐去负坐标轴,就会比较明白。)
必备型:
·一般是业务流程中必不可少,让业务可以闭环的基本需求 比如—商品管理中的添加商品,订单管理中的处理订单 期望型: ·一般是用户基本需求已经满足之上,更进一步提高用户的效率或帮助贡献收入 比如商品管理中的批量添加商品,店铺管理中的店铺模板 惊艳型: ·一般偏用户体验类型的需求 比如首次完成订单后给予夸奖的通知
先根据kano模型进行分类,再在不同层次内判断优先级。
必备型: ·必备型需求层次内不存在优先级 期望型: ·存在商业价值的需求优先 ·其余需求需评估对于效用价值的影响面 惊艳型: ·存在商业价值的需求优先 ·其余需求需评估对于用户体验价值的影响面
(PS:提到了效用价值和用户体验价值)
近似正确大于精准错误:没有一种方法可以将需求划分到足够小的优先级颗粒度,能够大体分类即可。
第三章 SaaS产品设计—构架与功能
如何梳理出符合业务的架构;
如何基于架构设计功能,满足个性化需求;
关于架构和功能
“后端标准化,前端个性化”
如果缺乏结构化思考(抽象),单点设计会让你筋疲力尽,导致功能不断堆砌,开发成本变高。对用户来说,信息也过于复杂,会降低使用效率。
eg:预约,要定金or不要定金,指定不指定技师,…
1.商业活动和管理活动通用的架构
这里把企业经营活动分为商业活动和管理活动。
商业活动:帮助企业把资源卖出去,或把资源买进来。 管理活动:帮助企业把人和事(项目)理清楚。
商业活动
商品管理:如何让商品有更好的卖相,如何高效的管理商品?
订单管理:了解商品的销售情况,最大化创收?
客户管理:了解购买者的情况。
业务 | 业务描述 | |
---|---|---|
商品管理 | 商品管理 | 进行商品的增删改查,上下架等操作 |
商品分类 | 商品在前后台的分类和标签,便于自身管理,同时让用户查看 | |
商品包装 | 进行商品介绍的包装和展现 | |
库存管理 | 进行商品库存和采购订单的管理 | |
商品信息 | 管理基础的不同品类的商品信息 | |
订单管理 | 订单详情 | 订单列表的查看,支付产生新订单 |
订单处理 | 正向交易有关业务:实物发货,到店核销,取消订单; | |
订单退款 | 负向交易有关业务:退款,退货; | |
管理评价 | 处理评价,维权 | |
客户管理 | 客户管理 | 客户的基本信息管理,增删改查 |
客户运营 | 查看客户的人群情况,进行场景化营销 | |
客户权益 | 厘定不同等级的客户所享受的权益,以及不同等级成长值的设置 | |
客户分析 | 分群与标签,便于push | |
客户积分 | 积分消费规则 |
其他模块都是基于这三个模块生长起来的。
管理活动
管人-HRM;管事(项目)-OA;管资源-ERP
管理对象不同,架构存在较大区别;
业务 | 业务描述 | |
---|---|---|
员工管理 | 招聘需求 | 发布招聘、筛选简历、面试反馈等招聘流程 |
岗位管理 | 各岗位设置和权限管理 | |
花名册 | 员工的基础信息 | |
考勤管理 | 创建考勤制度 | 时间、方式等规则,以及对员工的影响 |
打卡 | 集体考勤方式的执行与监控 | |
查看考勤记录 | 不同维度查看考勤数据,导出报表 | |
薪酬管理 | 创建薪酬方案 | 基于不同岗位级别和不同贡献度设置规则 |
计薪周期 | 计算工资生效时间 | |
工资管理 | 查看详情 | 查看不同员工的薪资发放情况 |
审核工资 | 审核工资是否存在问题 | |
发放工资 | 基于考勤制度,薪酬制度,结合员工数据进行工资自动化发放 |
员工管理模块通过考勤制度和薪酬制度产生活动数据,并最终通过工资管理反馈。
2.如何梳理复合业务的架构
架构是长出来的
梳理架构三个步骤
1.将场景需求清单拆解到功能; 2.将功能按不同维度进行分类聚合; 3.梳理模块之间的逻辑关系;
将场景需求清单拆解到功能示意
每一个功能都需要明确解决一个具体的业务问题;(比如“查看商品详情”是一个功能,“点击商品名称”不是)
将需求翻译成功能,十分考验对业务的理解;功能转化成原型,(视觉布局和操作流程)考验设计功底;
梳理模块之间的逻辑关系
先梳理静态模块(不产生数据流) 如:客户管理管理、员工管理模块、服务管理模块和资金管理模块 再梳理动态模块(产生数据流) 如:预约管理模块和订单管理模块
3.如果基于架构设计功能,满足个性化的需求
如何高效满足个性化需求是SaaS产品经理面临的最常见的问题
如何通过设计配置项解决个性化需求,最考验SaaS产品经理的功力
运用可配置高效满足个性化需求的两种情况?
业务流程与现有方案差别小——从功能层面进行配置
业务流程与现有方案差别大——从系统层面进行配置
高可配置的误区
1.高可配置往往会造成低易用性 配置项多会带来页面不简洁,流程不高效;用户要的不是配置项,是低成本实现目标的功能 2.高可配置会带来极高的开发成本 如果很多配置项没有被高效使用,无疑是开发资源的极大浪费
如何判断一个功能要不要做成配置项?
①可以做出配置项
②低成本,技术进行手动配置
③做出高级付费功能
④看商业价值是否需要定制