B 端产品的需求来源通常有老板、管理层、市场、销售、法务、财务、一线业务、技术团队内部、用户反馈、市场调研等渠道。

据某上市企业产品总监反馈，当前中国的 SaaS 产品中能消耗掉来自各个渠道 30% 的需求就达到了优秀的水准。

本文将从需求优先级常用方法论、评估的目标以及拒绝需求的个人实战经验，做一些分享。

01 需求评估方法论的适用场景

总的来说，笔者的实践中比较有效的排序模型按场景分三种，在此抛砖引玉：

• 战略级需求规划：用户价值 = 新体验 – 旧体验 – 替换成本
• 日常需求排序：RICE 模型，触达、影响、信心、努力，可根据业务情况灵活调整
• 需求颗粒度选择：KANO 模型，充分考虑对用户的满足程度

△ 需求评估模型的适用场景

一、用户体验 = 新体验 – 旧体验 – 替换成本

用户价值 = 新体验 – 旧体验 – 替换成本，笔者认为在重大决策时可以作为产品第一参考原则。

例如在进入新型的市场或者新的方向时，限于企业的资源有限性，产品决策点在于“应该选择围绕成熟优势去拓展业务，还是应该选择新产品、新方向呢？”

按照这一理论的解释，如果潜在市场的需求量比较大并且有看到新的要素，导致未来的市场是成长型的市场，那么企业有没有优势都不重要，策略上应该着重提高市场渗透率，将先发优势变成企业最大的优势，占领“定义新体验”的卡点。

《创新者的窘境》一书也对此有所说明（点击可查看我的读书笔记），企业优先进入某一新兴市场的市场份额，可能是后进者的6倍。

如下图所示，确定业务方向后，在需求排期时也就有了更加清晰的理论基础：有助于提升新体验，提供了新的要素（新技术、新人群、新渠道、新方法、新工具），精确客群定位、降低用户流失率、降低替换成本的事项就是需求优先排序的“直通车”。

△ 信息源于《俞军产品方法论》，整理人：RaRa

以替换成本为例，某电商SaaS平台基本没有开放免费的商品搬家功能，而是将此服务开放给了第三方，例如蚂蚁搬家，或者收取定制服务费。

这可能是出于打造平台生态或者平衡商业价值的最终结果，但无形中抬高了替换成本。

笔者遇到过某甲方企业如果借助这类平台开发新的销售渠道，首要面对的就是海量商品迁移的问题，接下来就会绕进这些坑：

• 找第三方吧，指定了可搬家的综合电商平台，不接受内研系统搬家
• 找平台吧，收取万元级别的的定制服务费
• 有自研能力的企业，倒是可以选择api对接，接口收费价格倒是可以接受，但是不付费定制是没有任何服务的，api的通用性、文档逻辑、数据调取范围、对接模式，对双方都是一种挑战

用户能顺利从其他平台切换到新的平台，必定是新平台的用户价值 > 本平台体验 – 旧平台体验 – 替换成本，而商品迁移的体验做的不够好，迁移成本过高，用户会再三考量是否有必要继续。

如果你是负责跨系统数据同步的产品，就需要在商业价值与用户价值之间做权衡。这种情形下，要如何定义跨系统数据互通需求的优先级呢？大家可以在评论区聊一聊~

当然，需求的排序不是简单的加减法就可以完成的，这一理论只是主观价值判断的辅助工具，比如在政府政策的指导下、行业垄断下，这一规则就失去了适用性，需要灵活处理。

用户价值理论只是提供了决策的思路，提升个人预测的准确性和决策的质量。

俞军老师的用户价值理论很适用于 C 端产品，在 B 端的应用条件，笔者本人也还在不断的摸索中。在 B 端战略性需求的规划，大方向上还需要考虑：

• 是否符合产品长期规划
• 是否符合产品定位
• 是否能标准化

这三条可以作为 B 端产品设计的原则。

大多数产品不是死于需求做的太少，而是做的太多，超出了产品的边界越做越臃肿，迭代困难。

需求的规划需要从产品的定位着手，打造自己的核心卖点，服务于业务的北极星指标。也需要通过标准化设计摊平研发成本，低成本服务更多的用户。

下文一起来看一下作者作为 B 端产品最常用的需求优先级排序模型：RICE 模型。

二、RICE 模型

RICE 模型的出处难以求证，百度搜索关键词，大家可以看到长期排在榜首的就是知乎的一篇海外的译文。

笔者开始使用这一模型，也是受这篇文章启发，结合自己的项目情况做了一些调整。

R（Reach），触达：

笔者将触达分为了触达的用户数、频次，两者相乘得到触达的综合得分（具体参数和规则说明见截图）。

I（Influence），影响：

影响力分为技术、管理、商业方面的影响，好的需求能带来的影响是多方面的，所以权重可以叠加，也可以根据企业所处的阶段调整权重值。

例如在业务合规阶段的企业，风险控制因素大于其他一切因素，可赋予高权重值；例如信息系统优化阶段，产品力因素又要高于经济价值的追求等，需要在项目中灵活调整。

C（Confidence），信心：

“这个需求我说了算，怎么实现我不管，明天上线”，虽然是一句调侃的话，但是在鱼龙混杂的需求中，难免会存在创意性的想法需要验证后才有量化指标的状况产品。

笔者会对这类主观性的需求设置信心度指标，提醒自己多辩证思考，接纳批判性的声音，规避决策偏误。

而且后续会根据最终上线的结果，验证此类需求的提出人是否足够可靠（证伪），成为下次此人提出此类需求的参考指标。

看一个是否靠谱，要看他做成了什么事情，做成功的几率有多高。一个长期判断失误的人是不值得信任的。

E（Effort），努力：

努力按照预估的人工量化，是一项负面指标，因为我们总是希望用最少的时间做最有价值的事情，特别是需求还在价值分析阶段，并未得到真实验证的情况下，B端也讲求MVP，或者说最小场景闭环。

△笔者的常用需求排序模型

需求的最终目标都是响应企业战略规划获得商业利润，决策人因为其掌握的资源、视野不同，提出的需求分量也不同。

若量化这一指标，可以考虑设置决策人权重，排序按照老板 > 管理层 > 客户 > 一线业务设置，毕竟B端产品的推广运营有由上自下的特性，老板和管理层也很大程度上决定了产品的价值评估。

需求不闭环，是不少初阶产品容易忽略的事情。有了调研、评估、开发，但是缺少了上线结果的观察和复盘。笔者有习惯针对每个需求点分析上线结果，若二次迭代，本次的评估打分和最终结果就是下一次评估的参考。

△ 笔者的常用需求排序模型

关于这一套模型，笔者在团队内部做过培训分享，有小伙伴问，你真的会用这么复杂的模型来评估需求吗？国外的这些东西，套用到国内有些不适用性吧？业务他们认可这一套吗？

是否有必要，大家可以用需求分析过中的批判性思考、需求的有效性、最终产出价值来验证。不适用也很正常，没有一套准则能放之四海而皆准。

理论都是有使用限制条件和前置条件的影响，也有或多或少的干扰因素。它存在的价值在于提供了结构化的思考方式，帮助自己尽量规避主观决策的局限性和决策偏误。

三、KANO模型

网上有很多写 KANO 模型（基本型、期望型、兴奋型、无差异型、反向型）的文章，都分析的很好，但是对于B端产品而言，此模型的局限性也比较大，例如：

• 适用于测试用户对新功能的接受程度，在 C 端通过需要通过专业的调研工具打分评定
• 仅评估了用户价值，没有评估商业价值

俞军老师将产品效用对用户需求的满足程度划分为：底线需求（不能低于）、够用就好（不用高于）、越多越好（愿意多支付）、惊喜（超过惊喜或参照系），两者有相通之处。笔者在日常工作中，遇到功能的颗粒度问题需要决策时，会用到此模型。

例如在一次跨系统批量数据同步时，在同步数据的颗粒度和交互细节上，大家产生了不同的看法：批量同步数据，要通过队列传输成功就存储，还是等到批量任务执行完毕之后，通过校验再统一存储。

△ 跨系统批量数据同步的颗粒度问题

从商业价值上来说，这两者并不会产生什么差异，但是从用户价值来说，两个方案的体验感是不一样的。

单条存储适用于小批量数据同步，即同步成功一条存储一条，失败后继续执行下一条。这种同步方式对用户的及时反馈性高，也无需长时间等待。最终传输失败给出统一报错，便于用户排查，对接口响应的要求也不高。

批量存储适用于大批量数据同步，同步成功后统一存储。但是同步过程中一旦校验失败即停止任务，且信息不会存储下来，也难以精准报错，此方案在用户体验上的优劣势显而易见。

所以这个需求就可以从需要满足用户的程度去衡量。

在我司的业务中这是一个高频操作、多业务角色参与、小批量数据同步的场景，在资源支持到位的情况下，按照期望型需求（够用就好）的程度去满足，达到提升数据多系统同步的效率，高可用、易操作的效果即可。

最终我们采用了方案一，这项功能赢得了较好的业务口碑 。

四、四象限原则

四象限原则也是比较常用的排序方式，包含紧急且重要 > 重要不紧急 > 紧急不重要 > 不重要不紧急的规则，使用此原则需要有一套判断事情是否紧急、是否重要的标准。

笔者也会用四象限原则来规划日常的工作安排：

紧急且重要的事情需要立刻行动起来；

重要不紧急的事情，可以分解后制定计划，分步执行；

警惕需要长期做紧急需求的工作。在需求的优先级排序中较少用此抽象模型，本文就不展开啦。

△ 四象限原则

02 需求优先级评估的目标

一、保持个人决策的质量

产品经理是一个非标准化的岗位，特别是对于B端产品而言，很难衡量其价值所在。

而非标的原因在于产品经理的真正关键能力，不是能学习的知识（虽然产品经理也需要学习相关知识和技能），而是在实践中权衡取舍持续迭代以追求价值最大化。

需求优先级的评估建立在严谨的行业了解、深度调研、逻辑推理、用户洞察、数据分析之上，这些行为不代表成功的结果，毕竟产品的成功受大环境、团队、产品力多重影响，但是能确保产品个人决策的质量维持在比较高的水准。

二、平衡用户价值与商业价值，确保资源最优配置

很认同纯银的一个观点，需求池的排序，虽然一定程度上服务于老板的情绪价值，但是老板喜不喜欢你，还是在于产品是否能创造高价值。

好的需求是在用户价值于商业价值之间取得最优解，单单靠需求池的排序是难以做到的，但是有一套可行的需求评估方式，能树立产品团队在业务端的专业形象，有理有据争取资源支持，从而获取资源配置和产品团队决策的自主权，实现收益最大化。

三、管理用户预期

跨部门沟通是B端产品日常要处理的场景。笔者在需求调研过程中就遇到过各个部门负责人争论需求优先级的问题，因为各个部门负责人更多的是从自己的业务角度出发，追求局部效益的最大化。

比如一个系统间数据互导的功能，就能让供应链人员的工作时效从1小时降低到2分钟，如果争取下来优先开发，就会得到部门员工的感激，哪怕该功能并不会产生直接的经济收益。

所以遇到多需求渠道的情况下，有一套公开、透明、可靠的需求评估机制，能协调好各方对于需求优先级、上线时间的预期，避免对产品部门产生抱怨、不配合的情绪。当然，产品的满意度不是由此决定，篇幅原因，话题就不再做延伸。

03 怎么合理拒绝需求？

小白产品从入门的进阶的里程碑在于合理的拒绝需求开始，不懂得砍需求的产品经理不是好产品经理。只要符合以下几个规则，我们就要警惕并拒绝。

1、贯彻5why原则，业务背景不清晰的不做

产品经理要有究竟精神，只有刨根问底找到问题的根源才能定义合适的解决方案。如果业务的背景都不清晰，做出来的需求也是浮于表面，甚至容易弄巧成拙。

找到问题的本质，5why原则是简单又容易操作的方式，真正的挑战在于是否能提出合适的问题。

2、投产比得不到认可的需求不做

需求要获得商业价值或者用户价值，当价值的产出和实际要投入的成本（ROI）得不到管理层的认可时，就可以有理有据的拒绝掉，想办法低成本解决问题比埋头干活更重要。

3、不符合产品定位的需求不做

为核心用户解决核心问题，打造产品的护城河才是我们的追求，不符合产品定位的需求，一方面会分散研发资源，使团队偏离企业战略规划；另一方面还会让产品越来越臃肿，维护成本过高，最终落得推到重来的过程。

例如当前产品的定位是解决多渠道订单高效履约的痛点，SCRM相关的营销需求就不符合产品定位，需要谨慎决策系统的耦合程度。

4、违反法律的需求不做

这一点就不必多说了，好的产品必定是有效用（满足用户价值）、可持续（用户价值与商业价值统一）、有利润（企业可获利）的，缺一不可。