课程简介
互联网进入到下半场，消费互联网萎缩，产业互联网兴起，企业服务话题逐渐变火，越来越多的在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模型按层次把需求分类，然后层次类再排序 |
近期公开课推荐
