SaaS产品经理概览
2023-05-18 20:57:29 1 举报AI智能生成
登录查看完整内容
SaaS产品经理概览
作者其他创作
大纲/内容
第一步：回归场景，梳理并描述业务场景
第二步：厘清价值，找出场景需求的价值所在
场景的定义与价值
对外沟通，外部部门或者人
对内思考，部门内部或自己
why
单个场景上，saas产品不能创造，只能还原场景
多个场景上，saas产品需要构建产品的闭环
what
将单个场景描述清楚
场景七要素
描述单个场景
梳理联调中的全场景
需要整理一个场景需求清单
描述全场景
how
回归场景
需求来源于场景，满足需求产生价值
场景是真实存在的，不存在伪需求
客户是要花钱买产品的
产品本身要实现商业价值
saas产品价值
在经济意义上，客户愿意付出成本去使用某个产品或者服务
商业价值
要与目标用户的，人生价值，业务目标相符合
用户价值
产品所谈的价值
明确产品的价值主张
找到需求对应的价值
找到价值
基于产品进行价值的判断
做价值判断
产品经理要干的就是
厘清价值
关于场景与价值
某一个用户
在某一特定的环境下
出现某一个特定的时机
带着某一个目标
采取了一系列行动
和某些介质交互
完成了某一特定的任务
场景的描述方式
场景7要素
一个人或者一个特定的群体
用户
空间、材料、设备等物理环境
物质、工具、时间、金钱等约束条件
环境
触发用户产生目标的事件
影响用户行为的环境变化
时机
任务结束的停止条件
目标
简单、具体、最小画的任务
行动
介质的背后，可能是另一个用户
介质
任务
对外沟通达成统一认识
对内思考能够复原场景
描述的关键
通过场景描述，能产生画面感
描述成功的标准
哪些相对更重要
观察：若没有这个功能
调研：若存在这个功能
如何获得
七要素之间的关联
场景需求清单是多个场景串联的结构化信息
它是一个业务链条下场景及场景拆分后的需求的合集
定义
梳理业务链条下场景之间的关系
避免遗漏影响业务闭环的场景
用途
梳理出清晰的业务流程
将场景写出并归类到流程
基于场景拆解用户需求
如何梳理场景需求清单
产品研发有先后顺序
ToB研发成本高
通过核心场景需求清单来迭代验证（MVP）
为什么需要得到核心场景需求清单
清单中的场景是否能让业务完成闭环
场景之间是否有明确的串联逻辑
清单是否已经是最简版本
核心场景自验清单
场景需求清单
产品对应的价值主张
由产品总监制定，产品经理进行理解
宏观层面：
需求对应的价值
更多的时候需要产品经理自行判断
微观层面
概述
为特定的用户群体，提供差异化的价值
这是进行需求判断的第一原则
价值主张
给产品的用户带来什么
效用类价值：便利性、经济性、安全性...
体验类价值：权威、身份、社会关系
saas产品中最常见的价值是效用类价值
给saas厂商带来什么
收入：签约、续约
数据：数据的采集
价值分类
需求的用户价值是否与价值主张相契合
需求的用户价值类型是什么，表现在哪里？
需求是否存在商业价值，表现在哪里？
如何找出价值
价值主张与需求对应的价值
判断是否符合价值主张
判断需求的用户价值和商业价值
如何判断一个需求要不要做
侧重决策者的诉求
调和使用者的体验
权衡的原则
业务链条不同角色的诉求冲突，改如何平衡
将需求按照KANO模型分类
在不同层次内判断优先级
如何判断多个需求的优先级
如果没有，用户就不满意
如果有，用户充其量刚刚满意
必备型
如果越多/越好，用户就越满意
如果越少/越差，用户就不满意
期望型
如果没有，用户无所谓
如果有，用户会非常满意
惊艳型
必备型》期望型》惊艳型
必备型需求层次内不存在优先级先后
期望型、惊艳型存在商业价值的优先
优先级
KANO模型
基于价值进行需求的判断
SaaS产品定义-场景与价值
最主要的能力，是提出一个有价值的解决方案
梳理业务流程图
梳理页面元素及交互
先梳理框架--理解业务模块的边界
再设计功能--解决用户的需求
面对多个类似需求
产品设计
SaaS产品有非常强的业务属性
内部：不断地堆砌功能，开发成本会越来越高
外部：用户所需信息繁杂，无法高效完成任务
如果缺乏框架思考，单点设计功能会让你精疲力竭
SaaS业务需求个性化的本质原因是场景不一样
设计功能前需要先厘清 【架构】
以一种抽象的架构视角来全局思考
如何解决
架构是一套将功能依据业务进行分类整合形成的抽象化的业务模型
架构可以帮助我们厘清每个业务模型/功能间的边界，以及它们之间的关系
理解业务是梳理功能架构的前提
什么是架构
标准化：梳理一套标准化业务模型，搭建框架
低成本：最终是为了高效满足用户的不同需求
后端标准化，前端个性化
架构的作用
关于架构与功能
商业活动的通用架构
管理活动的通用架构
通用架构
商品管理：让商品有更好的卖相，同时高效管理商品
订单管理：了解商品的销售情况，产生最大化创收
客户管理：让熟客产生复购和推荐，同时高效管理
业务目标
大部分模块都是基于这三个模块生产出来的
商品管理：上架商品的增删改查等基础操作
商品分类：商品的分类与标签，便于管理
商品包装：商品介绍的包装和展示
库存管理：商品库存、采购订单的管理
商品信息：管理最基础的不同类型的商品信息
商品管理模块
订单详情：订单列表的查看，支付产生新订单
订单处理：正向交易有关业务：实物发货、到店核销、取消订单
订单退款：逆向交易有关业务：交易后处理退款、退货等
评价管理：处理评价/维权等
订单管理模块
客户管理：客户信息的基本信息管理，包括增删改查
客户运营：查看客户人群情况，进行场景化营销
客户权益：厘清不同等级客户所享有的权益，以及不同等级成长值设置
客户分群：客户的分群与标签，便于push
客户积分：厘清客户的积分消费规则
客户管理模块
HRM
人是管理活动的基石
管人
OA
管事
ERP
管资源
管理活动
SaaS通用的架构
借助流程图梳理
第一步，将场景需求清单拆解到功能
找到符合通用模块的功能
归类整合，切忌重复制造轮子
非通用模块单独整合
第二步，将功能按不同维度进行分类整合
先梳理静态模块（不产生数据流）
再梳理动态模块（产生数据流）
第三步，树立模块之间的逻辑关系
梳理架构三步走
每一个功能需明确解决一个具体的业务问题
表面上是梳理架构图
背后都是对业务深刻的理解
注意点
如何梳理符合业务的架构
运用【可配置】：解决两种层面问题
其一前端，简洁高效，元素清晰，满足不同用户的业务需求
其二后端，配置项归类清晰
如何设计一个功能满足大多数的需求？
业务流程与现有方案差别小：从功能层面进行配置
业务流程与现有方案差别大：从系统层面进行配置
如何运用可配置高效满足个性化需求
配置项过多带来页面不简洁，流程不高效
用户要的不是配置项，而是低成本实现目标的功能
高可配置会造成低易用性
配置项没有被高效使用，是对开发资源的浪费
高可配置会带来极高的开发成本
高配置的误区
回归【场景】
基于核心场景下的需求提供默认配置项
如何设置默认配置项
回归场景是一切的基础
好的产品满足用户价值并带来商业价值
产品模式必须是持续正向增长的
产品定义
最小可用需要满足所有角色核心场景下的需求
每个客户都应该是独立的、个性化的
产品结构及呈现方式需要可延续、可扩展
系统稳定是前提
文案要说人话，拒绝设置专业门槛
永远保持一致的表达方式
产品研发
不轻易下线任何一个功能
先有，再高效，然后易用，最后好看
不骚扰客户
产品运营
SaaS产品设计的原则
基于架构设计功能，满足个性化需求
SaaS产品设计-架构与功能
SaaS产品的架构是长出来的
从发散到收敛的过程
产品定义：想清楚--场景与价值
产品设计：做出来--架构与功能
要关注产品设计，更要关注产品定义
SaaS产品工作的本质
SaaS产品存在很强的业务壁垒，隔行如隔山
存在业务壁垒
SaaS产品看似简单的功能也会设计多个角色，流程繁琐需要全盘考虑
业务流程复杂
SaaS产品需要满足不同客户的个性化需求，设计方案复杂
个性化需求多
不同点
理解业务难--搜集问题
需求梳理不清--分析问题
功能设计复杂--解决问题
所带来的问题
理解业务是需求梳理和功能设计的前提
SaaS的业务属性重
需要系统性从行业的角度来审视SaaS
从宏观角度看SaaS
SaaS产品和ToC产品
软件即服务
属于toB的范畴，但是不等于toB
SaaS（Software as a Service）
印象笔记
百度网盘
石墨文档等
常见面向用户的SaaS产品
提供需求说明
支付软件费用
提供硬件环境
上门安装调试
正式投入使用
流程
软件安装在用户指定的地方
用户拥有百分之百的控制权
数据私有
优点
需要持续投入人员和资源
维护成本高
缺点
传统软件的交付模式
SaaS是一种新的软件交付模式
SaaS公司提供服务器、数据库等硬件，无需本地部署
云端架构
无需客户承担基础设施成本、日常运维成本
成本下降
用户按月/年支付费用，而非一次性购买
付费灵活
后续的升级维护由SaaS公司负责，通过数据驱动迭代
体验提升
特点
SaaS模式就是软件公司事先把所有的软件相关工作都归类准备好，用户过来直接挑选自己需要的服务
SaaS交付模式
定义：什么是SaaS
SaaS：软件即服务
PaaS：平台即服务
IaaS：基础设施即服务
三种“aaS”
Microsoft
SAP
IBM
传统软件巨头
Salesforce
Workday
Shopify
新兴公司
SaaS模式在美国的发展
1999-2008
互联网刚刚普及
实验性的产品
代表产品：用友伟库
萌芽期
2008-2011
云计算概念进入中国
明确SaaS、PaaS和IaaS框架
代表产品：阿里云
进化期
2011-
人口红利带动互联网企业发展
资本市场开始关注SaaS市场
代表产品：有赞、纷享销客
成长期
SaaS模式在中国的发展
消费互联网红利已尽，产业互联网崛起
宏观经济
传统软件厂商和互联网巨头投入SaaS领域
商业动态
小B群体需求被挖掘
用户群体
SaaS+PaaS成为趋势
技术升级
SaaS在中国未来的趋势
趋势：SaaS的过去与未来
提供面向特定业务的SaaS解决方案
业务垂直型
提供面向特定行业的SaaS解决方案
行业垂直型
SaaS的细分结构
纷享销客、销售易
CRM
北森
客服呼叫
财税
有赞
零售电商
餐饮
医疗
教育
物流
金融
一个SaaS产品即会有特定的业务，又会有面向特定行业的特性
行业与业务之间有交叉
纷享销客、有赞
商业活动
github
技术活动
金蝶、用友
会计活动
安全活动
金融活动
财务活动
企业经营活动
商业模式未跑通
早期需要资金，关注财务活动
早期需要产品，关注技术活动
非成熟型企业
商业模式跑通
需要帮助企业面向市场创收，关注商业活动
需要帮助企业提高管理效率，关注管理活动
成熟型企业
不同阶段经营活动侧重点
分类：SaaS的细分结构
不断增加功能
不断稳定系统
不断完善服务
满足所有核心场景的需求
基础产品完善期
更深度的行业解决方案
更多的客户成功案例
更完善的客户服务体系
满足重点行业个性化需求
行业产品深入期
个性化定制
开放平台
开放服务生态
满足每个客户的个性化需求
生态建设期
SaaS业务的三个阶段
做好产品和服务
关注续费和转介绍
做好市场和销售
关注主动购买和毛利
制定标准
关注市场占有率
阶段策略
找到标杆客户的核心场景
定义最小场景闭环
优先满足核心功能场景
从0到1
理清需求价值
寻找通用解决方案
配置满足个性化的需求
从1到n
SaaS产品经理的工作重心
SaaS业务的阶段特征
SaaS模式概述
SaaS成为现在互联网企业切入B端市场的主流方式
用户分布：零散、呈点状
决策群体：1人
决策路径：短
C端产品
用户分布：集中、呈环形
决策群体：一群人
决策路径：长
SaaS产品
SaaS和c端产品用户特征的对比
C端产品经理一般是用户，可以通过共情来挖掘需求
SaaS产品经理通常不是用户，通过理解业务来挖掘需求
用户特征的差异，形成了业务壁垒
宏观层面
行业决定成俗的规则和玩法是什么
懂行业模式
微观
行业中某个企业的不同岗位角色是怎么各司其职的
懂业务流程
理解业务
运作流程是行业模式的直观体现
行业模式为理解运作流程提供指南
相辅相成
理解行业的现状，了解它的客观规律从而避免走弯路
理解行业中某个企业运作流程，还原场景并设计功能需求
理解业务的作用
宏观上：通过行业分析了解行业模式
微观上：通过业务调研了解某企业的运作流程
如何理解业务
关于理解业务
传统的行业：国民经济行业分类
新兴的行业：新零售、人工智能、区块链、VR/AR
行业类别
行业的定义
提供的产品与服务是什么
行业边界
市场规模/增速
行业的历史发展
行业演变
行业基础信息
政策趋势变化（P）
经济环境变化（E）
消费者习惯变化（S）
技术革新（T）
PEST分析模型
对政策有重依赖性的企业，一定要密切关注政策变化
外部经营环境
同一链条中企业的上下游关系，价值链传递环节
行业供应链
同一细分行业中市场竞争情况、资源集中度、进入门槛
就业竞争情况
内部市场环境
目标人群
提供的产品/服务
面向谁提供什么产品/服务
销售渠道
供应链
销售渠道和供应链
标杆企业分析
竞品的目标群体是哪些？
竞品主打的核心场景是什么？
SaaS竞品分析
了解行业的五个维度
如何快速了解一个行业
C端用户调研只需要关注单店用户
Saas业务调研需要全盘考虑整个业务运足流程
调研对象
C端用户调研需要以用户体验为中心
SaaS业务调研需要更关注需求解决了什么业务问题
调研目的
C端用户需求相对容易抽离出共性
SaaS天然存在大量个性化需求且极度分散
调研结果
C端用户调研 vs SaaS业务调研
业务调研的最终目的是为了理解业务的运作流程
该业务对应的客户画像是什么样的？
通过定义标杆企业描绘客户画像
企业
有哪些角色
对应的职业特点是什么？
通过查看组织架构和参考同类型企业来梳理角色特征
角色
核心业务的工作流程是什么样的？
观察与调研了解核心业务的工作流程
运作流程的主要元素
定义标杆企业的客户画像，以标杆企业的需求为核心
客户/企业的规模
从属细分类目
业务范围
客户画像
标杆企业业务具有代表性，核心业务容易抽离
标杆企业具有行业领导地位，容易带领其它企业的使用
why为什么选择标杆企业
第一步，定义并选择标杆企业
找到业务链条全部的角色，并定义角色特性
主要负责什么
业务目标/KPI是什么
...
角色特性
通过企业内部系统得到组织架构
参考同类型的企业
如何找到？
切勿遗漏角色
要保证业务闭环的完整性
第二步，梳理业务链条的角色
通过观察与调研理清角色的工作流
观察比直接开放式调研更有效
深入业务方工作场景
观察业务方工作方式
驻场
上手体验业务方的工作
轮岗
观察的方式
流程维度
场景维度
调研参考问题
调研补充细节
第三步，观察与调研并行
高效业务调研三部曲
头部：深度调研
普通：电话/问卷/反馈
不同层次的客户再调研方式上有侧重
前期和中期：深度调研
后期：电话/问卷/反馈
不同阶段在调研方式上有侧重
业务调研的关注点
如何进行业务调研
如何理解SaaS业务
每一个SaaS产品经理都应该是半个业务专家
SaaS产品经理概览
0 条评论
回复 删除
下一页
