课程费用

5800.00 /人

课程时长

2

成为教练

课程简介

互联网进入到下半场,消费互联网萎缩,产业互联网兴起,企业服务话题逐渐变火,越来越多的在C端有过1-2年产品经验的产品经理想要入行或者正在真正开始从事SaaS产品的工作过程中。
但是,在思考自身SaaS产品如何满足一块新的业务时,往往会发现过程中与C端产品有所不同。
了解用户 VS 理解业务
单点突破 VS 权衡各方需求
一类需求 VS 个性化需求

目标收益

●解决”理解业务难”的问题
做SaaS产品,往往面临的是一个环状的业务需要理解,课程针对这个问题,专门从宏观与微观两个角度向产品经理教授如何理解业务。
●解决“需求不好梳理”的问题
做SaaS产品,往往面临的是整个业务链条需要权衡,课程从场景和价值两个角度,帮助产品经理更好梳理业务链条的业务场景与需求,并通过价值对需求进行评价。
●解决“功能设计复杂”的问题
做SaaS产品,往往会面临大量个性化需求,课程以“后端标准化,前端个性化”的角度出发,通过帮助产品经理理解架构,以及如何进行可配置来解决做SaaS产品的终极问题。

培训对象

课程大纲

模块一:SaaS模式概述 1、SaaS模式概述(该部分为总起)
为什么要从宏观角度看SaaS:因为SaaS存在业务属性
2、什么是SaaS:
- SaaS的定义与边界?
边界:SaaS模式有ToC和ToB,这里只讲ToB
- SaaS模式的特点?
特点:SaaS模式与传统软件交付模式的对比
3、SaaS的过去与未来:
- SaaS是怎么诞生的?
SaaS的过去:云计算时代SaaS、PaaS和IaaS
- SaaS以后还会火么?
SaaS中美对比:在美国/中国发展的历程和现状区别
SaaS中国未来的趋势:未来一片向好
4、分类细分:
- SaaS细分是什么样子的?
- 企业典型的经营活动类型
分类维度:
- SaaS业务垂直型细分及典型产品特点
- SaaS行业垂直型细分及典型产品特点
典型经营活动:
- 商业活动
- 管理活动
5、SaaS业务的几个阶段:从大体上明确学员本阶段和接下来的工作重心
SaaS业务的阶段特征和对应策略:
- 基础产品完善期
- 行业产品深入期
- 生态建设期
产品经理在不同阶段的关注重点:
- 从0到1:理解业务、找核心场景与核心场景的闭环
- 从1到N:厘清价值、梳理架构设计功能(可配置)满足个性化需求
模块二:如何理解业务 1、原来C端是单点了解用户,现在SaaS需要全盘理解业务
- 因为C端产品经理本身就是用户,理解用户成本很低;但隔行如隔山,SaaS产品经理本身不懂业务,理解业务真的很难。

理解不透彻,后面SaaS产品工作流——产品定义与产品设计——就会举步维艰。
- 通过了解行业分析的五个维度,了解如何快速针对自身SaaS产品面向的行业快速建立对于行业模式的认知,从宏观上了解业务,避免走弯路
- 通过SaaS业务调研的方法,学员可以从微观角度理解业务,深入了解单个企业的运作流程,包括客户画像、角色特征,以及角色工作流
2、章节导读:述本节要解决的问题,如何解决,以及小节的关系
为什么要理解业务:用户特征的差异形成了行业壁垒,隔行如隔山——不懂业务,就失去了真实的场景来源,后面工作没法展开

业务=行业模式+运作流程

理解业务有何用:行业模式可以帮助自己了解客观规律,少走弯路,了解运作流程就可以直接还原场景,设计功能满足需求(显然后者帮助更直接)

如何理解:通过行业分析了解行业模式,通过业务调研了解单个企业运作流程

行业模式(宏观)与运作流程(微观)的关系:相辅相成,前者是指南针,后者是具体表现,更重要是要落脚到微观,才能帮助到后面工作
3、如何理解业务:宏观:如何快速了解一个行业?
- 不了解行业,没办法从宏观上对行业约定俗成的规则和玩法有感觉,业务调研处处走坑,也没法跟同事和客户沟通,怎么办?
了解行业的五个维度:体-线-面-点
- 行业基础信息——定义、规模/增速
- 外部经营环境——趋势、风险
- 内部市场环境——产业链、竞争情况
- 标杆企业分析——产品/服务、销售/供应链
- SaaS竞品分析——竞品的面向对象,主打场景

交付物:对于学员SaaS服务的任何一个行业,都可以通过对五个维度的思考,回答完了能够清晰了解行业约定俗成的规则和玩法,从而进行业务调研时不走弯路
4、如何理解业务:微观:如何进行业务调研?
- 用C端的用户调研方法做SaaS业务调研总是踩坑,调研结果没法应用到下一步工作,怎么办?
SaaS业务调研遇到的问题(与C端不一样的地方):
- 调研对象上:需要关注整体业务,容易忽略角色
- 调研目的上:容易注重用户体验而忽略业务目标
- 调研结果上:个性化需求太多

运作流程三要素:客户画像、角色特征、工作流

SaaS业务调研方法:
- 选择并标杆企业——客户画像
- 梳理所有角色——角色特征
- 观察与调研并进——工作流
理解业务增强环:理解业务非一日之功

交付物:最终通过业务调研产出单个企业的运作流程,包括典型标杆企业客户画像,关键角色的职业特点和核心工作流
(其实工作流也包含了场景,场景怎么写?请看下一章)
模块三:场景与价值 1、产品定义上,原来场景是单点突破,现在需要考虑全场景闭环;原来是用户价值思考极致,现在需要思考商业价值。所以说业务流程复杂,需要全盘梳理

如果还是用之前方法去抓场景盘价值,场景描述不清晰,也容易遗漏,价值也会缺乏评判维度。如果这些没想清楚,做出来的功能就会没人用

- 通过学习场景七要素的描述方式与输出场景清单的方法论,基于一个特定的业务背景,学员可以输出一份完整的场景需求清单来高效梳理业务链条全场景。

- 通过学习SaaS产品的价值主张、对应的用户价值与商业价值,学员可以更清晰自身价值主张,写出场景需求清单中需求对应的价值;同时能够根据几种典型场景下的原则,判断需求该不该做,业务链条下的需求冲突该如何权衡,以及评判需求优先级

2、先回归场景,梳理清楚要做哪些事
场景的必要性:对内想清楚,对外共识

C端与SaaS的不同:
单个场景上,C端自己就是用户,可以发散场景;SaaS业务天然存在壁垒,只能还原场景,且颗粒度更细;
多个场景上,C端产品重点在于单点突破核心场景,SaaS产品的业务链条长,缺少任何一个必备场景都可能无法闭环
小节的关系:先描述出单个场景,再梳理全场景

3、再厘清价值,梳理清楚先做哪些事
为什么要厘清价值:判断需求到底做不做、权衡需求冲突,以及优先级评判都需要先理清价值

C端与SaaS的不同:
- SaaS几乎不存在伪需求,客户就是上帝
- SaaS产品别人一手交钱一手交货,更要考虑商业价值

用户价值与商业价值的定义与之间的关系

小节的逻辑:先明确价值主张+写出需求的价值,然后再来看如何应用价值——实战的三个典型问题

3.1 如何用场景七要素描绘场景
- 产品经理在描述SaaS复杂的业务场景时,经常没办法让大家有画面感从而形成共识,也不能让自己想清楚需求——所以需要用一种通用的表达方式,生动而详实地描述出单个业务场景

为什么需要描述好场景:有画面感,容易共识也容易想清楚(SaaS业务光凭畅想是想不出来的)

场景七要素:用户、环境、时机、目标、任务、介质、动作
场景七要素之间的关系
场景七要素哪些要素更重要:用户、环境、时机、目标
如何将一个场景以场景七要素的方式表达:通过观察与调研

场景七要素到底有啥用:通过案例说明写场景七要素不能靠YY,一定要回归到真实业务场景写出来

3.2 如何通过场景需求清单梳理场景?
- SaaS产品的业务场景之间相互关联,需要考虑业务链条的闭环,梳理起来相当复杂,不能像To C那样单点突破场景——所以需要串联起业务链条下相关联的场景

为什么需要场景清单:
- 确保业务链条全场景闭环
- 帮助梳理逻辑

交付物:
- 最终的场景清单(包含类别、场景、需求,可能包括角色)
- 如果是新业务需再抽离核心场景需求清单

如何梳理场景
- 先梳理流程,再写出场景(分解角色),最后拆解需求

核心场景清单的自检清单

4.1价值主张与需求对应的价值
- 宏观上,很多产品经理在进行价值判断时,缺乏一个大的价值标的或判断原则,即价值主张;微观上,产品经理也理不清每个需求背后的价值,从而判断上没有主见——所以,如何找到需求的价值?
价值主张与需求对应价值的关系:宏观与微观
- 前者提供指引,不一定由你定,但你需要理解
- 后者更落地,时时刻刻需要厘清需求的价值

价值主张的定义——目标用户与价值
价值主张是第一原则

产品用户价值与商业价值的具体表现

如何写出价值——找出价值需要做的三件事儿:
1. 需求的用户价值是否与产品价值主张相契合?
2. 需求的用户价值具体类型是什么?表现在哪里?
3. 需求是否存在商业价值,表现在哪里?

4.2如何基于价值进行需求的判断
- 单个需求判断:如何判断某个需求该不该做?
- 决策链:业务中不同角色诉求有冲突时,该如何权衡?
- 优先级:如何评判多个需求的优先级?

判断需求该不该做的原则:看价值主张,看用户价值和商业价值的正负

判断不同角色需求冲突的原则:侧重决策者的诉求,调和使用者的体验

判断需求优先级的原则:先根据KANO模型按层次把需求分类,然后层次类再排序
模块一:SaaS模式概述
1、SaaS模式概述(该部分为总起)
为什么要从宏观角度看SaaS:因为SaaS存在业务属性
2、什么是SaaS:
- SaaS的定义与边界?
边界:SaaS模式有ToC和ToB,这里只讲ToB
- SaaS模式的特点?
特点:SaaS模式与传统软件交付模式的对比
3、SaaS的过去与未来:
- SaaS是怎么诞生的?
SaaS的过去:云计算时代SaaS、PaaS和IaaS
- SaaS以后还会火么?
SaaS中美对比:在美国/中国发展的历程和现状区别
SaaS中国未来的趋势:未来一片向好
4、分类细分:
- SaaS细分是什么样子的?
- 企业典型的经营活动类型
分类维度:
- SaaS业务垂直型细分及典型产品特点
- SaaS行业垂直型细分及典型产品特点
典型经营活动:
- 商业活动
- 管理活动
5、SaaS业务的几个阶段:从大体上明确学员本阶段和接下来的工作重心
SaaS业务的阶段特征和对应策略:
- 基础产品完善期
- 行业产品深入期
- 生态建设期
产品经理在不同阶段的关注重点:
- 从0到1:理解业务、找核心场景与核心场景的闭环
- 从1到N:厘清价值、梳理架构设计功能(可配置)满足个性化需求
模块二:如何理解业务
1、原来C端是单点了解用户,现在SaaS需要全盘理解业务
- 因为C端产品经理本身就是用户,理解用户成本很低;但隔行如隔山,SaaS产品经理本身不懂业务,理解业务真的很难。

理解不透彻,后面SaaS产品工作流——产品定义与产品设计——就会举步维艰。
- 通过了解行业分析的五个维度,了解如何快速针对自身SaaS产品面向的行业快速建立对于行业模式的认知,从宏观上了解业务,避免走弯路
- 通过SaaS业务调研的方法,学员可以从微观角度理解业务,深入了解单个企业的运作流程,包括客户画像、角色特征,以及角色工作流
2、章节导读:述本节要解决的问题,如何解决,以及小节的关系
为什么要理解业务:用户特征的差异形成了行业壁垒,隔行如隔山——不懂业务,就失去了真实的场景来源,后面工作没法展开

业务=行业模式+运作流程

理解业务有何用:行业模式可以帮助自己了解客观规律,少走弯路,了解运作流程就可以直接还原场景,设计功能满足需求(显然后者帮助更直接)

如何理解:通过行业分析了解行业模式,通过业务调研了解单个企业运作流程

行业模式(宏观)与运作流程(微观)的关系:相辅相成,前者是指南针,后者是具体表现,更重要是要落脚到微观,才能帮助到后面工作
3、如何理解业务:宏观:如何快速了解一个行业?
- 不了解行业,没办法从宏观上对行业约定俗成的规则和玩法有感觉,业务调研处处走坑,也没法跟同事和客户沟通,怎么办?
了解行业的五个维度:体-线-面-点
- 行业基础信息——定义、规模/增速
- 外部经营环境——趋势、风险
- 内部市场环境——产业链、竞争情况
- 标杆企业分析——产品/服务、销售/供应链
- SaaS竞品分析——竞品的面向对象,主打场景

交付物:对于学员SaaS服务的任何一个行业,都可以通过对五个维度的思考,回答完了能够清晰了解行业约定俗成的规则和玩法,从而进行业务调研时不走弯路
4、如何理解业务:微观:如何进行业务调研?
- 用C端的用户调研方法做SaaS业务调研总是踩坑,调研结果没法应用到下一步工作,怎么办?
SaaS业务调研遇到的问题(与C端不一样的地方):
- 调研对象上:需要关注整体业务,容易忽略角色
- 调研目的上:容易注重用户体验而忽略业务目标
- 调研结果上:个性化需求太多

运作流程三要素:客户画像、角色特征、工作流

SaaS业务调研方法:
- 选择并标杆企业——客户画像
- 梳理所有角色——角色特征
- 观察与调研并进——工作流
理解业务增强环:理解业务非一日之功

交付物:最终通过业务调研产出单个企业的运作流程,包括典型标杆企业客户画像,关键角色的职业特点和核心工作流
(其实工作流也包含了场景,场景怎么写?请看下一章)
模块三:场景与价值
1、产品定义上,原来场景是单点突破,现在需要考虑全场景闭环;原来是用户价值思考极致,现在需要思考商业价值。所以说业务流程复杂,需要全盘梳理

如果还是用之前方法去抓场景盘价值,场景描述不清晰,也容易遗漏,价值也会缺乏评判维度。如果这些没想清楚,做出来的功能就会没人用

- 通过学习场景七要素的描述方式与输出场景清单的方法论,基于一个特定的业务背景,学员可以输出一份完整的场景需求清单来高效梳理业务链条全场景。

- 通过学习SaaS产品的价值主张、对应的用户价值与商业价值,学员可以更清晰自身价值主张,写出场景需求清单中需求对应的价值;同时能够根据几种典型场景下的原则,判断需求该不该做,业务链条下的需求冲突该如何权衡,以及评判需求优先级

2、先回归场景,梳理清楚要做哪些事
场景的必要性:对内想清楚,对外共识

C端与SaaS的不同:
单个场景上,C端自己就是用户,可以发散场景;SaaS业务天然存在壁垒,只能还原场景,且颗粒度更细;
多个场景上,C端产品重点在于单点突破核心场景,SaaS产品的业务链条长,缺少任何一个必备场景都可能无法闭环
小节的关系:先描述出单个场景,再梳理全场景

3、再厘清价值,梳理清楚先做哪些事
为什么要厘清价值:判断需求到底做不做、权衡需求冲突,以及优先级评判都需要先理清价值

C端与SaaS的不同:
- SaaS几乎不存在伪需求,客户就是上帝
- SaaS产品别人一手交钱一手交货,更要考虑商业价值

用户价值与商业价值的定义与之间的关系

小节的逻辑:先明确价值主张+写出需求的价值,然后再来看如何应用价值——实战的三个典型问题

3.1 如何用场景七要素描绘场景
- 产品经理在描述SaaS复杂的业务场景时,经常没办法让大家有画面感从而形成共识,也不能让自己想清楚需求——所以需要用一种通用的表达方式,生动而详实地描述出单个业务场景

为什么需要描述好场景:有画面感,容易共识也容易想清楚(SaaS业务光凭畅想是想不出来的)

场景七要素:用户、环境、时机、目标、任务、介质、动作
场景七要素之间的关系
场景七要素哪些要素更重要:用户、环境、时机、目标
如何将一个场景以场景七要素的方式表达:通过观察与调研

场景七要素到底有啥用:通过案例说明写场景七要素不能靠YY,一定要回归到真实业务场景写出来

3.2 如何通过场景需求清单梳理场景?
- SaaS产品的业务场景之间相互关联,需要考虑业务链条的闭环,梳理起来相当复杂,不能像To C那样单点突破场景——所以需要串联起业务链条下相关联的场景

为什么需要场景清单:
- 确保业务链条全场景闭环
- 帮助梳理逻辑

交付物:
- 最终的场景清单(包含类别、场景、需求,可能包括角色)
- 如果是新业务需再抽离核心场景需求清单

如何梳理场景
- 先梳理流程,再写出场景(分解角色),最后拆解需求

核心场景清单的自检清单

4.1价值主张与需求对应的价值
- 宏观上,很多产品经理在进行价值判断时,缺乏一个大的价值标的或判断原则,即价值主张;微观上,产品经理也理不清每个需求背后的价值,从而判断上没有主见——所以,如何找到需求的价值?
价值主张与需求对应价值的关系:宏观与微观
- 前者提供指引,不一定由你定,但你需要理解
- 后者更落地,时时刻刻需要厘清需求的价值

价值主张的定义——目标用户与价值
价值主张是第一原则

产品用户价值与商业价值的具体表现

如何写出价值——找出价值需要做的三件事儿:
1. 需求的用户价值是否与产品价值主张相契合?
2. 需求的用户价值具体类型是什么?表现在哪里?
3. 需求是否存在商业价值,表现在哪里?

4.2如何基于价值进行需求的判断
- 单个需求判断:如何判断某个需求该不该做?
- 决策链:业务中不同角色诉求有冲突时,该如何权衡?
- 优先级:如何评判多个需求的优先级?

判断需求该不该做的原则:看价值主张,看用户价值和商业价值的正负

判断不同角色需求冲突的原则:侧重决策者的诉求,调和使用者的体验

判断需求优先级的原则:先根据KANO模型按层次把需求分类,然后层次类再排序

活动详情

提交需求