- 产品定义分为两步
1)回归场景
第一步:梳理并描述业务场景
2)厘清价值
第二步:判断场景中需求的价值
- 案例-如果没有回归场景
1)拼团案例
小明在一家电商公司做产品经理,有一天,老板给小明提了一个拼团的需求。小明没有仔细了解、厘清需求背后的场景,马上就答应了下来。
为了推进需求,小明先是费了很多口舌和运营、研发同学解释这个需求实现的必要性。然后,在围绕需求细节开始讨论时,团队成员争相用“我觉得”表达自己的观点,大家就拼团持续时间、成团人数、拼团流程等细节争得面红耳赤,无法达成统一意见。
为什么团队的沟通总是鸡同鸭讲,形不成统一的认知?
2)考勤案例
小红是一个协同OA工具的产品经理,在基础团队协作模块上,有越来越多的用户反馈想要考勤功能,小红没有多加思索,立刻着手画原型图,然后内部评审,接着推进开发。
功能上线后,却收到了大量的负面反馈,原来,小红设计考勤的打卡时间没有考虑具体场景,忽略了时间规则,很多用户在凌晨下班以后可以直接打上下一天的考勤,很多客户公司的考勤数据混乱。
为什么在功能上线时,总是不符合使用场景,还得推倒重来?
- 为什么要回归场景
对外沟通——部门外部/他人 |
产品经理想要完成一项任务,需要和多个部门、多个角色频繁地传递用户需求,因此使用一套易理解、贴近实际的沟通方式。
而场景就是通行于不同角色之间解决产品问题的语言。 |
对内思考——部门内部/自己 |
产品设计的过程是先发散后收敛,因此在动手画原型、写文档之前,我们需要做大量的思考、调研。
逻辑基点是用户面临的实际情况到底是怎样的,即回归场景。 |
单个场景上,SaaS产品不能创造,只能还原——
维度 |
C端的场景 |
SaaS的场景 |
单个场景上 |
C端子机就是用户,可以用发散的方式创造场景,从而引领用户需求。 | SaaS业务天然存在壁垒,无法发散获取,只能还原场景,且颗粒度更细 |
多个场景上,情况会如何?以下是某零售案例——
小亮是某提供线下门店零售解决方案的SaaS产品经理,在对某区域的便利店经营业务场景进行分析时,小亮把一些自认为比较重要的场景还原得特别透彻,但是却忽略了一些低频的场景,比如挂单这种分支场景就压根没考虑。
结果恰恰是因为这个场景没有考虑到,导致收到了很多客诉,甚至有些商家就干脆不用这个产品了。
梳理多个场景时,SaaS产品需要考虑业务的闭环——
维度 |
C端的场景 |
SaaS的场景 |
多个场景上 |
C端产品用户路径相对简单,重点在于单点突破核心场景。 | SaaS产品的业务链条场,缺少任何一个必备场景都可能无法闭环。 |
所以,SaaS产品经理先要将单个场景描述清晰,进而梳理链条中的全场景。
- 关于厘清价值
SaaS产品的需求来源于场景,产品经理通过满足客户需求从而产生价值。
因此,SaaS产品经理面对扑面而来的需求时,应当更清晰理解并评判需求的价值。
以下是SaaS产品价值判断三个最典型的问题——
1)如何判断某个需求要不要做?
2)业务链条不同角色诉求冲突,如何权衡?
3)如何判断多个需求的优先级?
为什么SaaS产品更需要理解需求,以下是C端和SaaS产品价值的对比——
C端的价值 |
SaaS的价值 |
C端产品可能存在很多伪需求,可以将其进行过滤,然后对其余需求进行价值判断。 | SaaS的场景都是真实存在的,客户就是上帝,不存在伪需求,所以需要对大量需求进行判断。 |
大部分C端产品只需要极致考虑用户价值,而忽略商业价值。 | SaaS客户是要花钱买产品的,所以产品经理更需要考虑需求对自身的商业价值。 |
产品所谈的价值有两类,一是用户价值:与产品和服务相关的、与用户的人生价值、业务目标方向一致的;二是商业价值:在经济意义上,用户愿意付出成本作为某个产品利益的回报。
用户价值和商业价值是有关系的,一个企业通过提供了一定的产品和服务,满足了用户的需求,从而带来的用户的价值,最终促成商业价值的产生。
所以,SaaS产品经理除了要关注用户价值,还要关注商业价值。
- 案例-电商拼团场景
1)场景是如何描述的1
嘤嘤平时很少做美容项目,周五回家的路上刷到了奈瑞儿的朋友圈广告,显示其正在搞拼团活动,看到原价20599元的热玛吉3人团只要1099元,她很想体验一下,于是点击广告卡片进入了页面了解一番,最后发起了一个拼团。
2)场景是如何描述的2
小王是某创业公司的产品经理,由于昨晚忘记了定闹钟导致起床晚了,平时走到公司楼下的时间绰绰有余,今天就只剩2分钟了,想到了公司规定迟到30分钟会罚款100元,于是他快速地掏出了手机打开钉钉,快速地完成了打卡。
- 场景的描述方式-场景描述的七要素
1)某一个用户……
一个人/一种类型的群体
- 穿格子衬衫的程序员
- 睡眼惺忪的产品经理
- 漂亮的前台
2)在某一个特定的环境下……
空间、材料、设备等物理环境/物质、工具、时间、金钱等约束条件
- 拥挤的10号线车厢里
- 在没有水源的沙漠
- 人口出生率连年下降
3)出现某一个特定的时机……
触发用户产生目标的事件/影响用户行为的环境变化
- 本来艳阳高照,突然倾盆大雨
- 马路对面红灯突然亮了
- 手机闹钟响了
4)带着某一个目标……
任务结束的停止条件
- 实现公司明年收入1000万
- 赶上最后一班地铁
- 两年内薪资翻倍
5)采取了一系列动作……
简单、具体、最小化的任务
- 单膝下跪,打开礼盒,拿出戒指
- 掏出手机,点亮屏幕,长按语音
- 选中一个图表,拖动到左下角,松手
6)和某些介质交互……
介质的背后,可以是另外一个用户
- 屏幕
- 电话
- 纸张
7)完成某一个特定的任务。
通常是逐步进行的
- 发送一条消息
- 添加一个联系人
- 挤进一辆公交车
8)案例-某公司年度产品发布会现场
- 用户:参会者
- 环境:拥挤闷热的酒店大堂
- 时机:到场时签到
- 目标:进入会场
- 动作:手机保存签到信息、到签到台展示给工作人员看
- 介质:现场面对面
- 任务:签到
那么,接待者的场景又是怎样的?
SaaS产品的场景是真实存在,不是凭空捏造的,需要在真实业务中得到验证。
- 案例-某美容业SaaS手机端开单场景
1)案例背景
你在一个为美容院提供SaaS解决方案的企业里做产品经理,最近收到一个商家的反馈——希望在手机端介绍美容项目并开单(原来是在pad上操作的),让用户扫码支付。
2)你可能会这么描述场景
小梅是一个美容院的工作人员,一天中午,在一位顾客进店后,小梅迎上去,拿出手机给顾客一个个介绍自家的美容项目,顾客对一个项目很满意,小梅选择项目开单,并让客户扫码支付。
3)实际开单场景
美容院的顾客大部分是高客单价的女性,一般进店之后,营销顾问把她引到沙发休息区,给一杯茶,拿着pad介绍项目。
- 顾客是不耐烦通过手机来看项目的——太low
- 工作人员通过手机开单的效率很低——很多人排队
所以,这个需求是YY的,切勿捏造场景。
4)如果把场景放在足疗店
小君是一个足疗店的工作人员,一天晚上,一位顾客进店后随便找了一个地儿休息,小君迎上去,拿出手机给顾客一个个介绍自家的足疗项目,顾客没有仔细看,直接说出了项目名字,小君选择项目开单,并让顾客扫码支付。
5)为什么足疗店的场景是ok的
- 足疗店男性顾客居多,对项目比较熟悉
- 足疗店较大,拿着pad到处介绍项目效率较低
- 小结
1)场景描述的方式本身不重要,在对外沟通形成统一的认知,对内思考能够还原用户实际情况才是关键。
2)检验自己是否真正掌握场景定义七要素的标准是——你描述完场景,别人是否有清晰的画面感。
要素 |
要素介绍 |
某一个用户 |
一个人/一种类型的群体 |
在某一个特定的环境下 |
空间、材料、设备等物理环境/物质、工具、时间、金钱等约束条件 |
出现某一个特定的时机 |
触发用户产生目标的事件/影响用户行为的环境变化 |
带着某一个目标 |
任务结束的停止条件 |
采取了一系列动作 |
简单、具体、最小化的任务 |
和某些介质交互 |
介质的背后,可以是另一个用户 |
完成了一个特定的任务 |
通常是逐步进行的 |
- 场景七要素之间的关联
1)第一步:产生前置条件
什么用户在什么环境下遇到了什么时机
2)第二步:产生目标
3)第三步:产生动作
与介质交互进行,具体动作完成一系列任务
4)哪些因素相对更重要
用户、环境、时机和目标相对更重要
- 场景七要素是如何得到的
※ 通过观察与调研进行场景对比
- 观察:在没有这个功能的情况下
什么样的用户,在什么环境下,因为什么时机,产生了什么目标,并通过与哪些介质进行了什么动作,完成了哪些系列的任务?
- 调研:如果有了这个功能
什么样的用户,在什么环境下,因为什么时机,产生了什么目标,并通过与哪些介质进行了什么动作,完成哪些系列的任务?
在《有效需求分析》(by徐锋)一书中,提到了一个回归场景的有趣案例,引用部分对书中案例进行了简化表达,一起来看看回归场景的奥义是如何体现的吧。
如果没有回归场景——
在一次酒店管理系统的建设项目中,酒店前台人员提出了一条需求:请在酒店入住页面增加一个酒店平面图,在图中实时展示出房型、状态和价格信息。
需求分析师小王没有多加思索,直接就针对此项需求与前台人员进行了深入探讨——“平面图是一层一张,还是把所有楼层都整合到一起?”“房态有几种,用文字还是用颜色展示?”小王迅速画好了原型图,初步获得了确认。
然而,到了实际开发的层面,由于开发成本远高于估计,最终实现的方案出现了较为严重的变形,远远达不到业务人员的预期,引起了业务人员的投诉,产生了很大的负面影响。
如果回归场景来看——
于是,我找到了最初提出这个需求的前台人员:“我这次来就是想了解您通过这个平面图解决什么问题,以便给您构思一个更加有效的解决方案。”
前台人员接过话题:“因为有时客人过来住,会需要两间甚至更多相邻的客房,而房间号相邻并不意味着房间相邻,我就会经常遇到困难。”我继续问道:“您是如何解决的呢?”
前台人员回答:“我首先会找哪些楼层有足够的客人需要的房间,然后再判断是不是挨着的,由于位置不好判断,所以才想有个平面图。”
所以问题并不在于一定要一个平面图,而是要找到相邻的空房间!
找到了问题之后,我认为应采用更简单的解决方案,于是我跟前台人员边画原型边解释道:“在原来的查询空闲房间的界面上,增加间数,是否挨着的选项,当你指定间数并要求挨着时,系统会查询出满足条件的房间。”前台人员听懂了我提出的解决方案后,爽快表示太好了。
只有回归场景,才能找到业务中真正的问题,从而给出更高效的解决方案。
- 关于场景需求清单
1)什么是场景需求清单
场景需求清单是多个场景串联形成结构化信息,它是一个业务链条下的场景及场景拆分后的需求的合集。
2)场景需求清单可以帮助你
梳理业务链条下场景的关系,避免遗漏影响业务闭环的场景。

- 如何梳理场景需求清单
- 基于之前的调研,找到关联步骤/流程,根据流程还原每个流程下的代表性场景,并拆解出需求
- 第一步:梳理出清晰的业务流程
- 第二步:将场景写出并回归到流程
- 第三步:基于场景拆解用户需求
- 案例-酒店业务对应的场景需求清单
1)案例背景
厂商A是给酒店提供全渠道订单管理的SaaS解决方案公司,作为产品经理的你,如何梳理某类面向亲子游的酒店业务对应的场景需求清单?
2)酒店业务早期的调研内容

3)第一步:梳理出清晰的业务流程
- 业务流程即为一种类别,可以梳理到场景清单中

4)第二步:将场景写出并归类到流程
- 每个流程下可以写多个有代表性的分支场景
- 如果有多个角色,也可以写出场景对应的角色
类别 |
场景 |
入住前-发布房型 |
发布房型:天域度假酒店马上就要到亲子游高峰了,经理张姐提前盘了盘房型的数量,哪些渠道该分配多少,然后点击发布房型。 |
入住前-订房/处理订单 |
订房:小路和老公计划端午节带上小孩去三亚玩,之前通过朋友圈看到朋友分享的李小璐和贾乃亮去过的三亚天域度假酒店不错,通过该酒店公众号查看具体位置和信息,提交订单后给商家留言加婴儿床,并用微信支付完成了预订。
处理订单(有房):张姐收到了有新的订房消息提醒,查看订单后截图个发送给PMS房间管理运营的同事,确认有房后,在订单处理里接单。 处理订单(无房):运营中心同事告知,房间已被携程渠道的用户订完,张姐收到通知后,对房间进行了关房操作,且在订单处理中取消接单。 |
入住前-确认信息 |
确认信息:小路收到微信推送的消息,订房订单已被商家接单,同时打电话给酒店客服,预约接机服务。 |
入住中-办理入住 |
办理入住:小路抵达酒店大堂后,凭身份证和手机号办理了入住,拿着门卡乘坐电梯抵达房间,前台阿玲按照小路的手机号在PMS办理了入住登记,并给小路发放了房间门卡和亲子活动表格。 |
入住中-亲子游活动 |
预约活动:休息片刻,小路在公众号上预订了晚上的亲子游晚宴,阿玲也收到了信息并把小路拉到了活动群里。 |
入住后-退房 |
退房:小路在三亚住了四天三晚后,跟前台预约送机服务,按送机时间抵达酒店门口,愉快回家。 |
入住后-分享 |
分享:回家路上,小路觉得亲子酒店的整体体验很不错,于是分享了酒店信息到朋友圈。 |
5)第三步:基于场景拆解用户需求

- 关于核心场景需求清单
抽离出最关键的类别/流程,以及其中不可或缺的场景,形成核心场景需求清单。如何抽离?必须要理解业务。
为什么需要得到核心场景需求清单?
① 产品研发有先后顺序
需要梳理出最不可或缺、能够完成业务闭环的场景。
② ToB研发成本高
如果后期发现功能存在问题,推倒重来的成本很大,因此需要试错。
所以,需要通过核心场景需求清单来迭代验证(MVP)。

- 核心场景需求清单的自检清单
- 通过自检清单,帮你检查核心场景需求清单
核心场景自检清单 |
|
清单中的场景是否能够让业务闭环? |
√ |
场景之间是否有有明晰的串联逻辑? |
√ |
清单是否已经是最简版本的?(即没有多余的、去掉也不影响闭环的场景) |
√ |
- 关于场景需求清单的一些Tips
1)业务中有不同的角色,是放到一个场景需求清单还是分开写?
根据需要,可以写到一个清单里,也可以基于不同角色分开写多个清单。
2)不同客户画像的具体场景不一样,如何表达?
单个场景需求清单里是基于某种特定客户画像的业务,不要混入。
3)分支场景都应该写进去么?
重点关注影响业务闭环的分支场景。
- 小结:关于场景需求清单
- SaaS产品经理通常不是产品的用户,没法依赖自己的经验。
- SaaS产品同时会有多个角色使用,并且相互影响和制约,需要一开始就梳理清楚场景需求清单。
- 如何判定核心场景是哪些
说到核心场景,就不得不提到业务闭环。什么是业务闭环?其定义为:为了完成业务目标下的最小步骤的集合。核心场景即是业务闭环下这些最小步骤的展开。
- 定义最小步骤依赖于对业务的理解:
需要站在业务人员的角度,来看哪些是必不可少的步骤。以商家编辑店铺详情页为例,预览功能就是符合业务闭环的最小步骤,因为业务方需要站在用户的角度来看店铺装修风格是否合适。
- 需要考虑到意外情况下的分支场景:
如果存在意外情况导致业务动作无法继续进行,业务无法闭环,也会导致用户放弃使用产品(见最开始零售案例没有考虑到挂单场景的案例)。
另外,场景需求清单不仅可以用于自身梳理与产品评审,还可以用来进行产品的宣贯。
- 关于价值主张与需求对应的价值
1)宏观层面:产品对应的价值主张
更多时候由产品总监制定,产品经理需要理解。
2)微观层面:需求对应的价值
更多时候需要由自己来判断。
- 两者之间的关系

- 关于价值主张
1)什么是价值主张
价值主张是为特定用户群体提供差异化价值。
2)案例-关于产品的价值主张

3)价值主张是进行需求判断的第一原则
SaaS产品应该尽可能满足每个客户的个性化需求,但不应该包含与价值主张完全不一致的需求。
- 案例-钉钉“Ding一下”是否符合价值主张
1)案例背景
钉钉产品“Ding一下”的功能曾经引起诸多争议,那么这个功能所对应的需求,是否符合产品的价值主张?
2)判断是否符合价值主张
钉钉的价值主张是什么?
- 目标用户:中小微企业管理者
- 价值:高效率与安全感
用户价值表现在哪里?
- 对于管理者确定性、安全感
所以,Ding一下功能与产品的价值主张极度符合。
- 关于价值主张的小结
- 产品的价值主张是需求价值判断的第一原则
- 产品的价值主张不一定由你定义,但你需要理解
- 如果需求判断经常找不到方向,也许应该开始思考产品的价值主张
- 需求的两种价值
1)用户价值
给产品的用户带来了什么
2)商业价值
给SaaS厂商带来了什么
- 价值的分类
1)用户价值的分类——对于用户
- 业务闭环类价值
- 效用类价值:便利性、安全性、耐用性、经济性…
- 体验类价值:权威、身份、社会关系、隐私、快乐、愉悦、好奇、回忆…
2)商业价值的分类——对于自身
- 收入:能不能促进客户签约,影不影响客户续约
- 数据:对自身是否能够采集到更多的业务数据
※ SaaS用户价值中最常见的是效用价值。
- 案例-某电商SaaS产品图片相关需求的价值
1)案例背景
厂商B面向线上店铺提供电商经营SaaS的解决方案,假设你已经还原了商家在店铺管理时与图片有关的种种场景与需求,你会如何分析这些需求对应的价值?
2)需求与价值的归类-用户价值的类型是什么(对于店主)
需求 |
价值 |
想要上传图片 |
业务闭环 |
想要取消上传 |
业务闭环 |
想要批量上传 |
便利性 |
想要新建分组 |
便利性 |
想给图片命名 |
便利性 |
想要预览大图 |
便利性 |
想要裁剪图片 |
美观性 |
想拥有个性化模板 |
个性化 |
3)存在商业价值-有收入
想拥有个性化模板 |
个性化 |
- 关于需求对应的价值的小结
- 找出价值需要做的三件事
1)需求的用户价值是否与产品价值主张相契合?
2)需求的用户价值具体类型是什么?表现在哪里?
3)需求是否存在商业价值,表现在哪里?
- 以有赞为例找到每个需求对应的用户价值和商业价值
1)有赞用户(商家)价值
- 用户增长类价值:
比如客户运营、销售渠道、营销活动、数据报表等。
- 经营管理效率价值:
比如员工管理、连锁能力、商品管理、财务资产等。
- 数智化价值:
比如智能导购、智能营销等。
- 安全稳定性价值:
双机房、平台风控合规等。
- 体验类价值:
商家需求提报、客服咨询、认证流程等。
2)有赞商业(企业)价值
- 商家增长:
比如获客、活跃、留存等。
- 商业化能力:
搭建商业化体系和策略。
- 降本提效:
降低服务成本、销售成本、研发成本等。
- 生态:
通过第三方搭建生态。
- 长期价值:
战略合作、社会价值、品牌价值等。
- 需求判断的3个常见问题
1)如何判断某个需求要不要做?
2)业务链条不同角色诉求冲突,如何权衡?
3)如何判断多个需求的优先级?
- 如何判断某个需求该不该做
1)判断是否符合价值主张
2)判断需求的用户价值与商业价值

- 案例-商家隐瞒营业额的需求价值
1)案例背景
有赞的有些商家的门店是开在商场里的,需要根据营业额按照固定比例给商场交租金。产品给商场的人开了一个权限可以看到后台的营业额。很多商家给有赞提需求,希望商场看到的营业额有一定比例的缩减,这样他们可以少交一点租金。
2)分析需求的用户价值与商业价值
从用户价值来看,此项需求对商家有用户价值,可以减免租金;从商业价值来看,此项需求商业价值极高,很多商家甚至愿意多花钱给有赞。
3)分析需求的用户价值是否对应价值主张
有赞的价值主张是——帮助每一位重视产品和服务的商家成功。
显然,提出此类需求的商家不符合价值主张中的目标用户。所以不做!
- 如何权衡业务中不同角色需求冲突
当决策者与使用者思路不一致,怎么破?
权衡的原则有两条——
- 侧重决策者的诉求
- 调和使用者的体验
- 案例-考勤管理SaaS多角色需求权衡
1)案例背景
你是一位考勤管理SaaS公司的产品经理,接到了一个客户需求:行政想要了解每个门店保洁的排班、打卡时间、重点区域的清洁程度这些维度的数据,但很多二三线城市的保洁阿姨连智能手机都不会用,按照行政的要求去设计的系统根本推不动。
已知产品的价值主张是用信息提高管理效率。
2)行政需求的价值梳理——全员打卡

3)如果遵从行政的需求
① 行政的需求:全体员工,包括保洁阿姨必须打卡考勤,才能体现出公司的有组织有纪律。
② 预期的效果:保洁阿姨离职,或者不懂得如何打卡而产生错误数据,无法实现行政诉求。
4)保洁需求的价值梳理——不想打卡

5)如果遵从保洁阿姨的要求
① 保洁的需求:不想打卡,因为不会用智能手机,不知道怎么打卡。
② 预期的效果:对于不让保洁阿姨打卡,对行政而言无法体现自身管理的高效,可能下一次不会续费。
6)经过权衡后的方案和效果
① 最终的方案:
遵从行政让全体员工打卡的需求(侧重决策者的诉求),加入硬件设备和项目经理干预结合(调和使用者的体验),打卡机记录保洁阿姨打卡情况,清洁部位由项目经理指导拍摄,同时加强保洁人员的培训。
② 最后的效果:
行政上总体比较满意,保洁阿姨并不抗拒用这种方式打卡,最终方案确保了用户价值,同时商业价值也得到了保障。
- 关于KANO模型

- SaaS产品三种需求类型的具体体现
1)必备型
一般是业务流程中必不可少,让业务可以闭环的基本需求。
比如,商品管理中的添加商品,订单管理中的处理订单。
2)期望型
一般是用户基本需求已经满足之上,更进一步提高用户的效率或者帮助贡献收入。
比如,商品管理中的批量添加商品,店铺管理中的店铺模板。
3)惊艳型
一般偏用户体验类型的需求。
首次完成订单后给予夸奖的通知。
- 如何判断多个需求的优先级
1)第一步:
将需求按照KANO模型进行分类
2)第二步:
不同层次内判断需求的优先级
- 案例-商品管理模块需求优先级排序
1)案例背景
厂商B是给生鲜店家提供店铺经营的SaaS解决方案公司,该店家在平台上只有线上一个卖货渠道。作为产品经理的你,该如何评判需求的优先级?
注:该场景仅针对店主这一角色。
2)对应商品管理模块的场景需求清单

3)KANO模型需求类别的优先级
必备型>期望型>惊艳型
4)将需求按照KANO模型进行分类
层次 |
需求 |
优先级 |
必备型 |
发布商品、编辑商品、查询商品、删除商品 |
P0 |
期望型 |
批量导出(有商业价值)、批量导入(有商业价值)、自定义报表、商品页模板、商品分组(有商业价值) |
P1 |
惊艳型 |
高级商品页模板(有商业价值)、配置详情页信息 |
P2 |
- 不同层次内需求优先级判断原则
1)必备型
必备型需求层次内不存在优先级。
2)期望型
存在商业价值的需求优先,其余需求需评估对于效用价值的影响面。
3)惊艳型
存在商业价值的需求优先,其余需求需评估对于用户体验价值的影响面。
- 案例-不同层次内判断需求的优先级
层次 |
需求 |
优先级 |
必备型 |
发布商品、编辑商品、查询商品、删除商品 |
P0 |
期望型 |
批量导出(有商业价值)、批量导入(有商业价值)、商品分组(有商业价值) |
P1.1 |
自定义报表、商品页模板 |
P1.2 |
|
惊艳型 |
高级商品页模板(有商业价值) |
P2.1 |
配置详情页信息 |
P2.2 |
- 需求价值判断的小结
近似正确大于精准错误,没有一种方法可以将需求划分到足够小的优先级颗粒度,能够大体分类即可。
- 问题背景
你上一次的分享体现出了对业务的深刻理解,团队小伙伴们受益良多,领导听了以后,也觉得公司的SaaS产品可以满足对应客户画像的需求,有必要迅速推进需求评审。所以接下来,你需要基于之前对业务的深入调研,就某一个客户画像梳理出场景需求清单,并向需求评审会上的大家说明。
- 作业要求
1)基于你选择的客户画像,请描述出全场景需求清单(至少包含10+场景);
2)在全场景需求清单上,标记出核心场景,并说明为什么这些场景是核心场景;
3)在全场景需求清单上,写出需求的价值,并对需求进行优先级排序。
- 补充说明
本题仍然是A线与B线二选一,建议选择的背景与上一题是连续的。
原创文章,作者:Saanet,如若转载,请注明出处:http://www.taosaas.cn/2020/04/15/saas%e4%ba%a7%e5%93%81%e5%ae%9a%e4%b9%89-%e5%9c%ba%e6%99%af%e4%b8%8e%e4%bb%b7%e5%80%bc/