需求分析是产品经理工作中的重要一部分，而对SaaS产品经理来说，因为业务的特殊性，所以需求分析更考验产品经理的基础能力比如还原场景中业务调研的能力、需求价值分析中对价值的界定等。

SaaS厂商的产品需求多数来自业务方真实场景，客户就是上帝不存在伪需求，产品经理多数抱怨自己只是需求的搬运工，处理需求比较被动，大多情况都是接收需求后为了赶项目进度直接动手做起来节奏看似时间紧凑，但事实往往事与愿违，一个功能反反复复不停不停打补丁，寻找源头常常是因为需求分析出现偏差，SaaS产品需求分析中存在一下问题：

1. 不会需求分析

Saas产品不能创造需求，需求大多来自客户实际工作中产生的业务际问题。产品经理缺乏了解相应的行业背景及业务链路的能力，接到需求后无从下手不知道该做什么，思维千头万绪不知道哪个方向开始思考；

2. 不分析全盘接收

产品经理很难设身处地的去体会用户的真实需求，无法判断需求是否符合真实业务场景，全盘接受领导安排的需求，直接照搬硬套竞品功能，功能上线不符合业务场景，功能上线使用感很鸡肋；

3. 不懂判断需求优先级

不同客户提出个性化需求太多，眉毛胡子一把抓需求来了就做，不知道怎么判断需求的优先级，开发计划天天延期；

SaaS产品业务链条长，缺少任何一个必备场景都无法完成闭环，产品经理如果没有对业务链条全面认知的能力，理解需求价值的能力，很难做到精准的需求分析。如果我们恰恰没有很深的业务背景以及闭环全链路思考的能力也不用着急，在工作中不管是新业务需求分析还是对细碎补丁的需求分析都可以从几个方面入手：

之一阶段：回归业务场景，梳理场景需求清单；

第二阶段：学会利用竞品，完善需求分析；

第三阶段：理清需求价值，判断需求的优先级；

01 回归业务场景，梳理场景需求清单 1. 回归业务场景

SaaS 产品面对企业级用户，某种程度上来说是解决他们工作的问题， SaaS 产品不能创造场景，只能还原场景，我们需要大量的调研、分析，找出对方业务场景中的真实问题。如果收集的信息不全，上线功能无法交付使用，都会重新返工，费时费力。

举例说明：需求-支付方式增加储值卡

客户调研需求：储值卡作为支付方式有什么特殊要求？业务方会说：我看xx都可以用储值卡支付支付你按那个一个做或者是储值卡里有钱用户支付方便，用户方便回购率就高了。

合情合理需求明确，产品经理经过这样的调研开始动手画原型，支付增加储值卡方式功能上线收到很多负面反馈，原来很多用户会购买多张打折储值卡，支付时不可使用多张只能选择单张使用，忽略了使用规则。

真实场景很多用户购买多张储值卡目的是支付时享受更多的优惠，而支付时一个订单下只能用一张储值卡，用户非常疑惑并且反感这样的做法，业务方收到很多客诉，业务方意识到问题要求多张卡支付功能必须加急上线，此时产品经理也很委屈明明是按需求来的怎么上线效果这么差呢。

为什么会出现这样的问题的呢？

产品经理在需求调研中脱离实际场景，在动手画原型、写文档之前没有回归场景、认真的观察、思考找出用户面临实际情况到底是什么样。在调研中应明确在业务场景中为哪些用户在什么环境中处于什么样的动机，做了哪些动作达成了什么目的，5要素还原场景。

如：小李（用户）店庆时购买的储值卡（环境），单张面值500元打折后只需400元，于是购买2张面值500元储值卡花费800元（时机），小李去门店购买商品总额1000元，正好自己有2张面值500的储值卡用于支付订单，实付800元购买了总1000元商品（使用动作），小李算了一下使用2张储值卡共优惠200元非常划算（目的）。

产品经理具备回归场景的能力还不够，SaaS产品的业务链条长，缺少任何一个必备场景都无法闭环，SaaS产品经理还要具备梳理链条中全场景的能力，如何梳理全场景呢？场景需求清单是业务链条下场景拆分后需求的合集，帮助我们打破业务的壁垒梳理全场景业务需求。

2. 梳理场景需求清单

基于对业务大量调研、分析、求证找到关联步骤/流程，根据流程还原每个流程下代表性场景，并拆解需求。梳理场景需求清单帮助我们梳理业务链条下全场景关系，避免遗漏影响业务闭环场景，简单来说可以分为一下3步实现：

梳理完整的业务流程

单个业务场景归类到流程

基于场景拆解需求

（1）梳理完整的业务流程