SaaS产品开发运营培训课程
2022-10-19 09:33:56 0 举报AI智能生成
SaaS产品开发运营培训课程
作者其他创作
大纲/内容
课程导论
背景
随着产业互联网的发展，国内企业进行互联网转型的需求与日俱增
传统IT企业与互联网巨头纷纷入场
企业服务公司兴起
SaaS产品逐渐兴起
需求端：随着市场的成熟，行业专业化分工水平不断提升，中小企业购买SaaS类产品，通过企业服务类的互联网产品提升企业运营效率，降低运营成本成为一种共识
供给端：云计算及基础设施的完善，使得企业去IOE化成为可能，尤其是SaaS基于订阅的销售模式，更进一步降低了许多ToB产品的推广与使用成本，也使得SaaS兴起成为可能
延伸阅读
了解SaaS产品经理的工作方法，看这一篇就够了！
课程导读
SaaS课程面向谁？
有2C产品经验，具备一定产品设计方法，想要转型到SaaS产品的同学
正在从事SaaS的产品经理，但缺少体系化的方法论
SaaS要解决什么问题？
问题将着眼于ToC产品工作与SaaS产品工作的不同点
SaaS产品不仅关注产品设计，更专注产品的定义
产品定义
产品设计
SaaS产品工作的本质是
从lt;font color=quot;#f15a23quot;gt;发散lt;/fontgt;到lt;font color=quot;#c41230quot;gt;收敛lt;/fontgt;的过程
与C端产品的不同点
1、存在业务壁垒
2、业务流程复杂，涉及角色多
3、个性化需求多，设计方案复杂
SaaS课程框架
导论：SaaS模式概述
从宏观的角度来看SaaS
第一章：如何理解业务？
宏观：如何快速了解一个行业？
微观：如何进行业务调研？
第二章：SaaS产品定义--场景与价值
如何回归场景，并梳理出场景清单？
如何厘清价值，并应有到需求分析中？
第二章：SaaS产品设计--架构与功能
如何梳理出符合业务的架构？
如何基于架构设计功能，满足个性化需求？
SaaS模式概述
什么是SaaS？
Soft As A Service
面向用户toC
印象笔记，石墨文档，百度网盘
面向企业toB
SaaS本身是一种软件交付模式
本身不存在ToB或ToC之分
传统模式
1、提供需求说明
2、支付软件费用
3、提供硬件环境
4、上门安装调试
5、正式投入使用
优点：数据私有
缺点：维护成本高
SaaS特点
1、云端架构
/2、成本下降
/3、付费灵活
/4、体验提升
SaaS是一种商业模式
ToB产品定义为所有基于互联网提供服务，用以提升企业效率，增加企业收入的产品
商业产品，中后台产品与SaaS产品
SaaS的过去与未来
SaaS的细分结构
业务垂直型
CRM
ERP
OA
HRM
客服呼叫
财税
行业垂直型
零售电商
子主题
餐饮
医疗
教育
物流
金融
企业经营活动
商业活动
有赞，纷享销客
管理活动
teambition,薪人薪事
技术活动
会计活动
扩展阅读
艾瑞网2019中国企业SaaS行业研究报告
潮起潮落，看SaaS如何理性突围？
SaaS业务的几个阶段
1、基础产品完善期
2、行业产品深入期
3、生态建设期
4、再创新
产品经理工作重点
从0到1阶段
找到标杆客户核心场景，定义最小场景闭环，优先满足核心场景功能模块
从1到N阶段
厘清需求价值，寻找通用解决方案，运用可配置满足个性化需求
第一章：如何理解业务？
导读
如何理解业务？
宏观：如何快速了解一个行业？
微观：如何进行业务调研？
学习目标
通过行业分析的五个维度，快速建立对于行业模式的认知
通过SaaS业务调研的方法，深入了解单个企业的运作流程，包括客户画像，角色特征以及角色工作流
关于理解业务
为什么SaaS有明显的业务属性？
SaaS与C端用户特点对比
C端用户
用户分布：零散，呈点状
决策群体：一个人
决策路径:短
SaaS用户
用户分布：集中，呈环状
决策群体：一群人
决策路径：长
产品需求的挖掘方式对比
C端用户
产品经理一般都是用户，通过【共情】来挖掘需求
SaaS用户
产品经理通常不是用户，通过【理解业务】来挖掘需求
用户特征的差异形成了业务壁垒
一个典型的餐饮供应链业务的用户特征
集团总部--区域配送中心--中央厨房--门店
当我们在聊业务的时候，我们在聊什么？
行业的玩法与规则
行业内企业员工的工作流程，KPI或OKR是什么
业务到底是什么
懂行业模式
行业约定俗成的玩法与规则是什么？
懂运作流程
行业中某个企业的不同岗位/角色是如何各司其职的？
理解业务=懂行业模式+懂运作流程
宏观：行业模式
在行业内的企业，相应的业务是怎么玩的，从而抽象出通用的玩法与规则
微观：运作流程
企业内相应业务的不同员工是如何操作，最终实现公司业务的运转
行业模式与运作流程是相辅相成的
运作流程是行业模式的直观体现
行业模式为理解运作流程提供指南针
理解业务有何用？
理解行业现状，了解它的客观规律避免走弯路
通过了解行业内某个企业的运作流程，从而还原场景，并设计功能满足需求
如何理解业务？
1、通过行业分析了解行业模式
2、通过业务调研了解某个企业的运作流程
宏观：如何快速了解一个行业？
行业类别
传统行业
新兴行业
了解行业的五个维度
行业基础信息
外部经营环境
内部市场环境
标杆企业分析
SaaS竞品分析
案例：某厂商主要面向以蛋糕店为主的线下门店提供零售SaaS解决方案
行业基础信息
所属行业
大行业
蛋糕店属于零售行业
小行业
蛋糕店属于烘焙行业
烘焙行业的产品与服务
面向消费者提供面包，蛋糕，糕点及其他混合甜点等烘焙食品
烘焙行业的市场规模
2017年销售规模达2000亿元，2013-2017年复合增长率为13%，行业品牌集中度10%左右
外部经营环境
烘焙行业的PEST分析
烘焙行业所面临的趋势
经济环境上
用户习惯上
早餐场景拓宽
低糖饮食习惯养成
更关注经济政策动向
内部市场环境
烘焙上下游
原材料--加工环节--流通环境--销售环节---消费者
中央厨房-门店
前店后厂一体化
烘焙行业的经典玩家
企业类型，典型企业，特点
外资品牌，内资全国连锁，地方品牌，无名小店
标杆企业分析
以【好利来】为例
目标用户
核心聚集在一二线城市，更注重品牌的消费者
产品服务
蛋糕与甜点，主打精品蛋糕
销售渠道
连锁门店，第三方超市与烘焙电商
供应链
前店后厂一体化：加工和门店一体化，后厂制作后再销售
SaaS竞品分析
面向烘焙行业的SaaS竞品分析
竞品，目标群体，特点（核心业务）
麦田守望，有数新零售，千米-连锁O2O，科脉-天天饮食
微观：如何进行业务调研？
SaaS业务调研与C端业务调研的区别
调研对象上
SaaS
全盘考虑整个业务运作流程
C端
关注单点用户
调研目的上
SaaS
更关注需求解决了什么业务问题
C端
以用户体验为中心
调研结果上
SaaS
由于业务千差万别，天然存在大量个性化需求且极度分散
C端
用户需求相对容易抽离出共性需求
业务调研最终目标
为了理解业务的运作流程
运作流程包括的元素
企业
该业务对应的客户画像是什么？
角色
有哪些角色？对应的职业特点是什么？
流程
核心业务的工作流是什么样的？
案例：某公司招聘业务流程细节
业务调研三步走
1、定义并选择标杆企业
定义标杆企业的客户画像，以标杆企业的需求为核心
2、梳理业务链条的角色
找到业务链条上的全部角色，定义角色特征
主要负责什么
业务目标/KPI是什么
其他职业特点
如何找到这些角色？
通过企业内部系统得到组织架构
参考同类型标杆的企业
切勿遗漏角色，保证业务闭环
3、观察与调研流程并行
通过观察与用户调研厘清角色的工作流
观察的方式
驻场
深入业务方的工作场景，观察他们平时的工作方式
轮岗
上手体验业务方的工作
用户调研补充了解细节
流程维度
最近一个月最花费经历的几件事是什么？怎么解决的
最近一个月跟哪些人沟通最多？沟通的目的是什么？
具体场景维度
什么情况下出现了什么问题导致什么目标没有实现？
如何有了这个功能，你准备如何去做？
业务调研的tips
不同层次的客户在调研方式上有不同的侧重
不同的阶段在调研方式有不同侧重
案例：面向亲子游的酒店旅社业务调研
1、定义并选择标杆企业
亲子酒店定义
主要面向有3-12岁孩子的宝爸宝妈们提供一个轻松，舒适的度假环境，同时能满足小孩的游玩及与小孩参与亲子活动
某客户画像
基本介绍
某五星级度假酒店，2017年飞猪单体酒店GVM排名第一，目前1000个房间
面向客群
主攻亲自酒店，旅客多为3-12岁小孩的宝爸宝妈
所属类目
酒店旅游
2、梳理业务链条上的角色
酒店经理
30-40岁，女性为主
主要负责酒店房间发布安排管理与接单
关注酒店收入，酒店入住率，
游客
宝爸宝妈
宝爸宝妈
带3-12岁孩子，想要安静，轻松，舒适的环境
前台
18-30岁，女性为主
主要负责前台接待，开房与退房处理，协调亲子活动
耐心，具备良好的服务意识，最怕客户投诉
观察与调研流程并行
一对一用户访谈
观察+轮岗
核心工作流
酒店经理
发布房型-管理房型；处理订单
游客
订房--入住--退房--分享
前台
办理入住--退房
第二章：SaaS产品定义--场景与价值
产品定义
通俗来讲就是“想清楚”
进行用户使用场景的梳理，以及判断对应的需求该不该做
回归业务需求的场景
厘清业务需求的价值
产品设计
通俗来说就是“做出来”
梳理出产品的大致功能框架，并通过原型绘制出来
课程学习目标
通过学习场景七要素的描述方式与输出场景清单的方法论
通过学习SaaS产品的价值主张，对应的用户价值与商业价值，写出场景需求清单中需求对应的价值
能够根据几种典型场景下的原则，判断需求该不该做,业务链条下的需求该如何权衡，以及评判需求优先级
产品定义分2步，第一步：回归场景
梳理并描述业务场景
为什么要回归场景？
对外沟通
产品经理需要一套易理解，贴近实际的沟通方式
场景就是通行于不同角色之间解决产品问题的工具
对内沟通
产品设计过程要先发散后收敛，在写文档前需要做大量的思考，调研
ToC产品与SaaS产品在场景部分的区别
单个场景上
C端产品自己就是客户，可以以发散的方式创造场景，从而引领用户需求
SaaS业务天然存在壁垒，无法发散获取，只能还原场景，且颗粒度更细
多个场景上
C端产品用户路径相对简单，重点在于单点突破核心场景
SaaS产品业务链条长，缺少任一个必备场景都可能无法闭环
回归场景这部分的内容
1、描述单个场景
如何通过场景7要素描述场景？
2、描述多场景
如何通过场景需求清单描述全场景?
产品定义分2步
第二步：厘清价值
关于厘清价值
需求来源于场景，需求产生价值
SaaS产品价值判断的三个最典型的问题
1、如何判断某个需求要不要做？
2、业务链条不同角色诉求冲突，如何权衡？
3、如何判断多个需求的优先级？
为什么SaaS产品更需要理解价值？
需求场景上
C端产品可能存在很多伪需求，可以将其进行过滤，然后对其余需求进行价值判断
SaaS产品的场景都是真实存在，客户就是上帝，不存在伪需求，所以需要对大量需求进行判断
价值考虑上
大部分C端产品只需要极致考虑用户价值，而忽略商业价值
SaaS客户是要花钱买产品的，所以产品经理更需要考虑需求对自身的商业价值
产品价值
用户价值
与产品和服务相关的，与用户的人生价值，业务目标方向一致的
商业价值
在经济意义上，用户愿意付出成本作为某个产品利益的回报
关系
企业提供产品/服务满足用户需求，带来用户价值
用户价值的促进达成，给企业带来商业价值
厘清价值这部分的内容
1、找到价值
明确产品的价值主张，找到需求对应的价值
;2、价值判断断
如何基于价值进行需求的判断？
如何用场景7要素描述场景？
场景七要素描述方式
1、某一个客户……
2、在某一个特定的环境下……
3、出现某一个特定的时机……
4、带着某一个目标……
5、采取了一系列动作
6、和某些介质交互……
7、完成了一个特定的任务。
举例：嘤嘤平时很少做美容项目，周五回家的路上刷到奈瑞儿的朋友圈广告，显示他们正在搞拼团活动，看到原来20599元的热玛吉3人团仅需要1000元，她很想体验一下，于是点击广告卡片进入活动页面了解了一番，最后发起了拼团
SaaS产品的场景是真实存在的，不是凭空捏造的，需要在真实的业务中得到验证
检验自己是否真正掌握场景定义七要素的标准是
你描述完场景，别人是否有清晰的画面感
场景七要素的关联
什么用户在什么环境下遇到了什么时机
用户，环境，时机
产生目标
目标
与介质交互进行具体动作完成一系列任务
介质，动作，任务
拓展
回归场景的奥义
如何用场景需求清单来梳理需求？
什么是场景需求清单？
场景需求清单是多个场景串联形成的结构化信息，它是业务链条下的场景及场景拆分后的需求的集客
场景需求清单的作用
梳理业务链条下场景的关系
避免遗漏影响业务闭环的场景
如何做？
第一步：梳理出清晰的业务流程
基于前期调研内容，尽可能梳理业务流程
单独的分支流程可以加上
第二步：将场景写出并归类到流程
每个流程下可以写多个有代表性的分支场景
第三步：基于场景拆解用户需求
案例：酒店业务对应的场景需求清单
酒店业务早期的调研内容
--客户画像
基本信息，客户群体，所属类目
--调研角色
酒店经理，前台，游客
--角色特征
年龄性别，主要负责内容，关注KPI或指标
核心工作流
酒店经理
发布房型-管理房型；处理订单
游客
订房--入住--退房--分享
前台
办理入住--退房
第一步：梳理出清晰的业务流程
核心流程
入住前
-入住中
-入住后
角色
酒店经理，前台，游客
第二步：将场景写出并归类到流程
类别
场景
角色
入住前--发布房型
发布房型：天城度假酒店马上要到亲子游高峰期了，酒店经理张姐提前盘了盘酒店房型，哪个渠道该分配多少，然后点击发布房型
入住前--订房
订房：
处理订单（有房）：
处理订单（无房）：
入住前--确认信息
入驻中--办理入住
入驻中--亲子活动
入住后--退房
入住后--分享
第三步：基于场景拆解用户需求
类型-场景-发布房型：天城度假酒店马上要到亲子游高峰期了，酒店经理张姐提前盘了盘酒店房型，哪个渠道该分配多少，然后点击发布房型
需求：可以发布房型，可以管理房型
核心场景需求清单
抽离出最核心的类别/流程，以及其中不可或缺的场景
为什么需要？
产品研发有先后顺序
ToB研发成本高
核心场景自检清单checkList
1、清单中的场景是否能够让业务闭环？
2、场景之间是否有清晰的串联逻辑？
2、清单是否已经是最简单的版本？（即没有多余的，去掉也不影响闭环的场景）
价值主张与需求对应的价值
什么是产品的价值主张？
为特定用户群体提供差异化价值
案例
有赞
帮助每一个重视产品和服务的商家成功
重视产品和服务的商家
商家成功
效益与效率
钉钉
为中小微企业管理者提供全方位的数字管理服务
中小微企业管理者
基于数字管理服务的高效率与安全感
价值主张是进行需求判断的第一原则
尽可能满足每个客户的个性化需求，但不应该包含与价值主张完全不一致的需求
产品价值主张不一定由你定义，但要理解
需求判断找不到方向时，需要思考产品价值主张
需求的价值
价值的分类
用户价值
对于用户
商业价值
对于自身
案例:某电商SaaS产品图片相关需求的价值
想要上传图片
价值：业务闭环
想要取消上传
价值：业务闭环
想要批量上传
价值：便利性
想要新建分组
价值：便利性
想给图片命名
价值：便利性
想要预览图片
价值：便利性
想要裁剪图片
价值：美观性
想拥有个性化模板
个性化（商业价值：收入）
找出价值要做的三件事儿
需求的用户价值与产品价值主张是否相契合？
需求的用户价值具体类型是什么？表现是哪里？
需求是否存在商业价值？表现在哪里？
如何基于价值进行需求的判断？
如何判断某个需求是不是要做？
判断是否符合价值主张？
判断需求的用户价值与商业价值
若用户价值为负，无论商业价值多大不能做
商业价值为负，用户价值为正，则谨慎考虑
业务链条不同角色诉求冲突，如何权衡？
侧重决策者的诉求
调和使用者的体验
如何判断多个需求的优先级？
KANO模型
必备型需求
一般是业务流程中必不可少，让业务可以闭环的基本需求
期望型需求
lt;span style=quot;font-size: inherit;quot;gt;一般是用户基本需求已经满足之上，更进一步提高用户的效率或帮助贡献收入lt;/spangt;
兴奋型需求
一般偏用户体验类型的需求
KANO模型需求优先级
必备型gt;期望型gt;兴奋型
Step1：将需求按KANO模型进行分类
Step2：不同层次内判断需求的优先级
必备型需求不存在优先级
期望型需求
存在商业价值的需求优先
其余需求需评估对效用价值的影响
兴奋型需求
存在商业价值的需求优先
其余需求需评估对用户体验价值的影响
案例：
商家隐瞒营业额的需求价值
不做
考勤管理SaaS多角色的需求平衡
公司行政要求全员打卡
二三线城市的保洁阿姨不会使用智能手机
商品管理模块需求优先级排序
发布商品
编辑商品
查询商品
删除商品
商品分组
批量导入/导出
自定义报表
商品页模板
高级商品页模板
配置详情页信息
第三章：SaaS产品设计--架构与功能
课程学习目标
通过学习商业活动和管理活动架构建立初步认知，并能应用到梳理框架中
根据课程中的方法梳理出符合当前业务的架构，并基于架构给出各种配置的方法，满足个性化需求
关于架构和功能
SaaS产品已度过了基础完善期
建立标准化业务模型，更高效的满足个性化需求
后端标准化，前端个性化
分支主题
产品设计
1、梳理业务流程
2、梳理页面元素与交互
SaaS业务个性化需求不一样的本质是场景不一样
场景七要素中任一要素发生变化，都要导致场景不一样，从而产生不同的需求
缺乏框架性思考会造成的后果
内部
不断的堆砌功能，开发成本会越来越高
外部
用户看到的信息繁杂，无法高效完成任务
什么是架构？
架构是一套将功能依据业务进行分类整合形成的lt;font color=quot;#c41230quot;gt;抽象化的业务模型lt;/fontgt;
可以帮你厘清每个业务模块/功能的边界，以及他们之间的关系
好处
梳理一套标准化模型，搭建框架
最终是为了高效满足用户的不同需求
当我们面对多个类似的需求时
先梳理架构
理解业务模块的边界
基于场景迅速定位对应的模块
再设计功能
解决用户需求
用一个功能解决类似的场景
理解业务是梳理功能架构的前提
SaaS通用架构
企业经营活动
商业活动
帮助企业把资源卖出去，或者买进来
管理活动
帮助企业把人或事（项目）理清楚
商业活动有哪些通用架构?
管理活动有哪些通用架构？
本章内容
SaaS通用的架构介绍
商业活动有哪些通用架构?
管理活动有哪些通用架构？
通过梳理架构，更高效满足需求
如何梳理出符合业务的架构？
如何基于架构设计功能，满足个性化需求？
商业活动通用的架构
商业活动模块的目标
商品管理
如何让商品有更好的卖相，同时高效管理商品？
订单管理
了解商品的销售情况，让自己最大化创收？
客户管理
如何更好让熟客产生更高的复购与推荐，同时高效管理他们？
商品管理模块的主要业务
商品管理
可以进行上架商品的增删改查，上架等基础操作
商品分类
商品在前台后台的分类或打标签，便于自身管理，或者让用户查看
商品包装
可以进行商品介绍的包装和展现
库存管理
可以进行商品库存，采购订单的管理
商品信息
管理最基础的不同类型的商品信息
订单管理模块的主要业务
订单详情
订单列表的查看，支付产生新的订单
订单处理
正向交易有关的业务：实物发货/到店核销，取消订单
订单退款/售后
逆向交易有关业务：交易后处理退款/退货等
评价管理
处理评价/维权等等
客户管理模块的主要业务
客户管理
客户信息的基本信息管理，包括增删改查
客户运营
查看客户人群情况，进行场景化营销
客户权益
厘清不同等级客户所享受的权益，以及不同等级成长值设定
客户分群
客户的分群和标签，便于push
客户积分
厘定客户的积分消费规则
商品和用户提供订单进行关联，串联起了整个交易链路
大部分模块基于此模块生长出来
如采购管理，库存管理，店铺管理，营销管理，资金管理等
管理活动通用的架构
关于管理活动的模块
管人
HRM
管事（项目）
OA
管资源
ERP
人是管理活动的基石，所以管理活动主要讲述人的管理（HRM）
员工管理模块的主要业务
招聘需求
发布招聘，筛选简历，面试反馈等员工招聘有关流程
岗位管理
公司各个岗位的设置与权限管理
花名册（通讯录）
员工最基础的信息管理
考勤管理模块的主要业务
创建考勤制度
包括具体时间，考勤方式等规则设置，以及对员工的影响
打卡
具体考勤方式的执行与监控
查看考勤记录
不同维度查看考勤的数据，数据导出，报表生成
薪酬管理模块的主要业务
创建薪酬方案
基于不同岗位级别，不同贡献度的薪酬规则设置
计薪周期
计算工资生效的时间
工资管理模块的主要业务
查看工资
查看不同员工的具体发放工资情况
审核工资
审核工资是否存在问题
发放工资
基于考勤制度，薪酬制度结合员工数据进行工资的自动化发放
员工管理模块基于考勤制度和薪酬制度产生活动数据，并最终通过工资管理反馈
如何梳理符合业务的架构？
第一步：将场景需求清单拆解到功能
每一个功能需明确解决一个具体业务问题
如何将业务需求翻译成功能，极其考验对业务的理解
第二步：将功能按不同维度进行分类整合
先拿出符合通用模块的功能，进行归类整合，lt;font color=quot;#c41230quot;gt;切勿重复造轮子lt;/fontgt;
不符合通用模块的功能，根据业务重要程度和复杂性单独整合
如有必要，根据业务重要程度和复杂性继续梳理子模块
第三步：梳理模块之间的逻辑关系
先梳理静态模块（不产生数据流）
客户管理，员工管理，服务管理和资金管理等模块
再梳理动态模块（产生数据流）
比如预约管理，订单管理
tips：
每一个功能需明确解决一个具体业务问题
案例：
商业活动案例
管理活动案例
如何基于架构设计功能，满足个性化需求？
SaaS业务的几个阶段
维度
横轴：时间
纵轴：规模
1、基础产品完善期
满足所有核心场景的需求
不断增加功能
不断稳定系统
不断完善服务
2、行业产品深入期
满足重点行业个性化需求
更深度的行业解决方案
更多的客户成功案例
更完善的客户服务体系
3、生态建设期
满足每个客户的个性化需求
个性化定制
开放平台
开放服务生态
4、再创新
有了架构
在前端
展现出清晰简洁的信息架构
在后端
把配置项按模块划分
运用【可配置】，解决两个层面的问题
前端：简单高效，元素清晰，满足不同用户的业务需求
后端：配置项归类清晰
可配置的两种情况
如果业务流程和现有方案差别小，从功能层面进行配置
如果业务流程和现有方案差别大，从系统层面配置
高可配置项的误区
1、高可配置往往会造成低易用性
配置项越多，页面不简洁，流程不高效
2、高可配置往往会带来高开发成本
很多配置项没有被高效利用，造成开发成本浪费
判断功能要不要做成配置项的四象限思考
纵轴：模式切换频率
模式切换频率如何？
横轴：需求长尾程度
用户需求是否一样？
多数用户都不一样，模式之间切换频率高
少数用户不一样，模式之间切换频率高
少数用户不一样，模式之间切换频率低
多数用户都不一样，模式之间切换频率高
案例：以预约为模块的配置为例
case1：通用预约需求，几乎大部分商家都有一些通用的预约配置需求，比如预约的时间范围
可以做成配置项
case2：预约与支付的先后顺序，有的是先预约，到店消费后支付，有的是预约时付款然后到店消费
低成本，技术手动切换
case3：按准确排版时间预约，大多数商家是周一到周日的工作时间，少数商家要求某些服务的客户按精准排班时间预约
做成高级付费功能
case4：完全特殊的个性化需求
看商业价值是否需要定制
如何设置默认配置项？
回归【场景】
在大量同一种类型的个性化场景中，找到最核心的场景，并依据该场景下的功能设计设置为默认配置项
案例：
经营状态有关
经营状态：【默认营业】，休息
营业时间有关
经营时间：【默认全天】，自定义
购买门槛有关
购物门槛：【默认粉丝/非粉丝均可购买】，仅粉丝可以购买
延伸阅读
B端产品的配置应如何设计
扩展--SaaS产品设计的原则
SaaS产品设计的原则
产品定义
回归场景是一切的基础
吾日三省吾身：场景呢，用户呢,需求呢？
好的产品满足用户价值并带来商业价值
产品模式必须是持续正向增长的
产品设计
最小可用需要满足所有角色核心场景下的需求
每个客户都应该是独立的，个性化的
产品结构及呈现方式需要可延续，可扩展
产品研发
系统稳定是前提
文案要说人话，拒绝设置专业门槛
永远保持一致的表达方式
产品运营
不轻易下线任何一个功能
先有，再高效，然后易用，最后好看
不骚扰客户
白鸦内部培训：企业服务类产品的底层逻辑，和“有赞产品设计原则”
0 条评论
下一页
