SaaS 产品的需求处理跟其他产品不同，本文作者基于 SaaS 产品的特点，分享了在SaaS 产品处理需求过程中的一些思考。
不知道作为 SaaS 产品经理的你，在日常工作中会不会经常碰到下面这些情况： - 销售：“我跟你讲，这个客户试用后提出了这么几个需求，你赶紧推进做了，我就能继续推进签单。”
- 运营：“你们能不能做个人员导入的功能啊？这样我们和客户新增人员的时候就不用一个一个添加了。”
- 老板：“当下这个需求很紧急，其他的先放放，优先做这个。”
一、明确产品和需求的价值
1. 知己，理解产品的价值主张
产品的战略主张是需求过滤筛选的第一步，而早在产品设计之前，战略主张就已经确定了。 简单说，可以将它理解为产品的战略层，通常是由老板和公司高层制定。 而处于执行层的我们大多数情况不会参与制定，只需要理解并在产品推进过程中贯彻这一理念。 比如某公司做的是餐饮行业做智能视频监控管理，这时有客户提出一个“需求”，希望希望能在管理后台，可对部分违规项进行隐藏处理。 同时对方承诺如果上了这个功能，在续约的同时还会帮你介绍新的客户。 说白了，这个功能背后存在很客观的商业价值。 这时你会不会动心呢？先别急，让我们来分析一下这个“需求”。 首先，将这个“需求”回归业务场景，思考并调研他们要解决的目标问题是什么。 在了解后发现，他们在做向上汇报时，隐藏某些巡检项可以减少相应的处罚。 而这就是他们间接向业务人员反映提出这个“需求”的动机。 要知道通常来说，业务人员的关注点补上问题背后的含义和动机，而是这个客户能否拿下。 因此也会很容易将他们的“需求”，直接传递给产品经理。 当然，这个例子说的比较直，在实际场景中其实复杂很多。 回归到公司产品的价值主张，是希望帮助商家杜绝后厨人员的违规，提高吃客的餐饮安全。 而隐瞒意味着会淡化监管，导致违规项无法整治，最终影响吃客的食品安全。 所以这个“需求”，显然是违背了产品的价值主张，即使这个“需求”存在巨大的商业价值，产品经理也绝对不能妥协去做。 换句话说，这也是作为一名产品经理的底线。 到这里你可以想想，你们公司产品的价值主张是什么？ 说实话，很多产品经理是不清楚的，甚至公司管理层都没想明白，这时候就需要我们自己思考并明确产品的价值主张了。 不仅是为产品负责，也是为自己负责。2. 知彼，判断需求的价值
这里结合 SaaS 产品，从客户价值和商业价值两个维度去分析。 （1）客户价值 SaaS 产品是对企业业务的一种解决方案，因此首先需要够保证业务的闭环，也就是满足「可用」。 先不说业务上的提效与降本，如果企业上下游的业务人员都用不起来，这款产品本身也就没有价值。 所以在处理 SaaS 产品的业务闭环上，首先需要将核心流程和分支流程都考虑在内，设计时要做到先增后减。 其次是需要达到「易用」，比如人员的批量导入，通讯录部分人可见，这类需求不会影响业务的整体闭环，但会让客户使用起来更方便。 最后就是「好用」，而这对于 SaaS 产品来说更偏向「个性化」，比如管理层的头衔，重要人员的标签区分。 目前我接触到「个性化」需求，更多的是数据看板的模型和导出 excel 表的样式，这些需求往往会伴随着更多的商业价值。 所以这里要记住一点，对方提出的任何需求都是围绕着企业业务展开的，产品经理需要时刻保持好奇心，挖掘背后的含义。 （2）商业价值 对于 SaaS 产品来说，让客户签单和续约是最常见的方式。 除此之外经常被忽略的一点，就是对业务数据的采集。 对于我们公司的视频监控智能算法来说，需要通过不断的采集、识别、矫正，反复训练来提高识算法的准确性。 因此会采取免费试用与接入对方摄像头的策略，推广让更多的商家去使用。 要知道如果是免费的产品，对方的心理预期不会很高，容忍性也比较强，同时也会提出很多的建议。 总结来说，产品的价值主张为需求价值的判断提供方向和原则，而需求价值反哺产品进一步巩固价值主张。二、价值是需求判断的风向标
根据上面的阐述，我们明确了「产品价值主张」和「需求价值」，接下来需要进行需求的实际判断。 这里列举以下几种常见的情况。1. 我们要做哪些需求
这里举一个我自己的反例： 产品是将实体门店巡检线上化，实现信息化管理。 我们系统早期没有权限管理模块，只有后台写好的一些权限，而且是用「职位」这个字段做过渡。 然后有客户提出了这么一个问题，目前他们会使用公司内部的人做门店的暗访巡检，也就是说这个人在公司本身可能是「财务人员」，但他这时需要「神秘顾客」的身份，那么在填写他职位的时候就无法完成。 当时我在接到这个需求时，没做深入的理解，就配合产品经理做了落地，最后用一个标签「神秘顾客」的方式“解决了这个问题”。 结果等了几周这个功能上线后，人家早就用职位填写神秘顾客这个方式解决了。 事后我去反思这件事，发现虽然业务场景不存在伪需求，但问题要不要解决，需要产品经理深思熟虑后做出判断。 实际上，如果我们的产品有财务模块，这个问题本质其实是权限分配的问题。 而这种情况，我们应该围绕着产品的已有功能，引导用户只填写「神秘顾客」行不行，如果不行还会存在什么问题，一步一步深挖场景和问题。 这才是解决问题的方式。 那么下次，如果对方提出了具体的问题，我会如何进行功能价值判断呢？ 这里用四象限来提供一个判断模型，这里需要注意的是第二象限与第四象限。
2. 权衡业务链间的不同角色
首先强调一点，SaaS 产品服务的是购买决策人。 因为很简单，他们才是购买 SaaS 产品客户，而那些一线的执行人员，并非决策人员，优先满足他们不会带来任何商业价值。 因此从客户企业和自身公司考虑，产品经理首先要判断决策人是谁，以他作为中心向四周发散来解决问题。 但要注意，这里并不是说忽略使用者的体验，而是要想办法做到平衡。 举个例子： 某企业区域负责人会要求督导巡检上报执行结果，可以理解为写日报的这种方式。 但实际上，有的督导一天会巡检多家门店，也就是他们会巡检完成一家门店，写报告然后提交，然后再巡检下一家门店。 那么对于这个问题，你会如何解决呢？ 最简单的方式就是做个写日报的功能，然后让督导每日完成即可。 实际上你可以想象，这个功能上线后一定会增加他们的工作量，导致巡检的降效，执行人员的抱怨。 而如果从业务场景和问题的角度去分析，我只要让上级负责人能够看到执行结果即可。 因此对于这个需求，最后的解决方案是在 PC 端选择任务抄送人，完成后抄送人会收到报告和数据统计的结果。 这样区域负责人不仅可以选择性的查看，同时督导也不需要每天写巡店报告。3. 评估需求的优先级
SaaS 产品需要按照业务流程排列需求优先级，在「02 知彼，判断需求的价值」中已经提到。 这里再借助 Kano 模型做详细说明。
（1）必备型需求 这类需求属于对方工作流中不可或缺的基础，对此重点不是要不要做，而是要怎么才能做好。 举个例子： 通常来说，企业管理的方式一般是自上而下，这也是产品目前的核心流程。 但由于这次疫情，会存在自下而上的汇报，也就是除管理者下派的任务，底层执行人员会根据店内情况做问题上报。 首先这个需求符合产品定义，其次结合业务场景，它的价值是能补充业务闭环。知道很多企业，会要求门店人员即时上报门店情况，并做到信息留档。 对此我们的处理方式，先基于疫情做了一个「疫情上报」，放在 App Banner 位，做初步功能验证和迭代调整，而后续可以作为新功能正式上线。 （2）期望型需求 + 兴奋型需求 通常会伴随着兴奋型需求一起提出，而我们要考虑这个需求能否解决对方关键的业务问题。 毕竟对于 SaaS 产品来说，收入的途径主要还是靠产品能否卖的出去。 而除此之外的需求，可以从影响面和 ROI 两个维度去进行排序。 常见的就是数据看板内容，以及数据导出的样式，而这里要注意一些用户价值高，但商业价值不明显的需求，比如人员导入。 事实上这类需求只能说让对方用起来更方便，但带来商业价值程度很低。 因此这类需求要结合对方的忍受程度，做谨慎考虑。 写在最后
以上就是关于 SaaS 产品设计中，如何理解产品与需求，到如何判断需求优先级的思考分析框架，也是我现在接到需求后，做出判断的回复对方的依据。 但说实话，想要完全掌握，实际上还是蛮困难的，我现在也只能称得上入门而已。当然这也是一个好的开始，慢慢地在实践中不断的反思与修正它，最后成为自己思考和分析的习惯。 实践的积累会让我们的决策质量越来越高，能够从容面对更多复杂的情况。 让我们一起加油，一起共勉。 作者：空，公众号：小木盒产品记 本文由 @空 原创发布，未经作者许可，禁止转载 题图来自Unsplash，基于CC0协议 数极客是新一代用户行为分析与数据智能平台，支持用户数据分析、运营数据分析、留存分析、路径分析、漏斗分析、用户画像、SEM数据分析等16种分析模型的数据分析产品，支持网站统计、网站分析、APP统计、APP分析等分析工具，以及会员营销系统和A/B测试工具等数据智能应用，支持SAAS和私有化部署,提升用户留存和转化率，实现数据驱动增长!
数极客是新一代用户行为分析与数据智能平台，支持用户数据分析、运营数据分析、留存分析、路径分析、漏斗分析、用户画像、SEM数据分析等16种分析模型的数据分析产品，支持网站统计、网站分析、APP统计、APP分析等分析工具，以及会员营销系统和A/B测试工具等数据智能应用，支持SAAS和私有化部署,提升用户留存和转化率，实现数据驱动增长!
【独家稿件及免责声明】本站原创文章如需转载请联系我们，未经书面许可禁止转载，本站转载文章著作权归原作者所有，如有侵权请联系:。
