产品经理常用需求优先级评估模型

Posted 2023-03-31 郭子安不爱学编程

阐述了其在事件中认为比较有效的3种排序模型，以及适用的场景。另外也对需求评估的目标以及拒绝需求的个人实战经验，做了一些分享。相信对各位B端新人能够带来帮助，欢迎阅读。

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

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

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

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

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

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

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

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

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

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

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

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

以替换成本为例，某电商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、违反法律的需求不做

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

产品经理分析模型大全

SWOT

SWOT 模型是一种常用的战略规划分析方法，代表分析企业的优势（strengths）、劣势（weakness）、机会（opportunity）和威胁（threats）。

适用场景：竞品分析，评估产品机会

PESTEL

PESTEL 模型是用来分析宏观环境的有效工具，包括 6 大因素：政治、经济、社会、技术、环境和法律。

适用场景：竞品分析，评估产品机会，战略分析

用户体验要素

出自《用户体验要素：以用户为中心的产品设计》，虽然原书介绍的是网站设计，但同样适用于移动产品。用户体验要素模型可以帮助我们梳理产品从 0 到 1 的 5 个阶段工作，也可以利用这 5 个方面对竞品进行分析。

适用场景：竞品分析，产品设计

马斯洛需求层次理论

马斯洛需求层次理论是行为科学的理论之一，由心理学家亚伯拉罕·马斯洛在《人类激励理论》论文中提出。该理论将人类需求从低到高按层次分为：生理需求、安全需求、社交需求、尊重需求和自我实现需求。

通俗理解：假如一个人同时缺乏食物、安全、爱和尊重，通常对食物的需求量是最强烈的，其它需要则显得不那么重要。只有当人从生理需要的控制下解放出来时，才可能出现更高级的、社会化程度更高的需要如安全的需要。

适用场景：需求挖掘

七宗罪

天主教教义中的七种罪过，揭示了人类原始的本能欲望，分别是傲慢、妒忌、暴怒、懒惰、贪婪、淫欲和贪食。

适用场景：需求挖掘

KANO 模型

日本教授狩野纪昭 (Noriaki Kano) 构建出的 kano 模型。将影响用户满意度的因素划分为五个类型，包括：

• 魅力因素：用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升；
• 期望因素（一维因素）：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低；
• 必备因素：当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度会大幅降低；
• 无差异因素：无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意；
• 反向因素：用户根本都没有此需求，提供后用户满意度反而会下降；

KANO 模型

四象限法进行 KANO 分析

适用场景：需求评估

Fogg 行为模型

为了让用户的某个行为发生，产品需要具备三个特性：行为动机、执行能力和触发机制。

为了让一个行为发生，用户首先需要足够的动机和激励，然后得有执行动作的能力。用户具有充分的动机和足够的能力来执行的话，当触发机制出现的时候，操作就会自然而然地出现。这个简单的模型被成为 Fogg 行为模型。

适用场景：产品设计，交互设计，用户体验设计

尼尔森十大可用性原则

十大可用性原则由人机交互学博士尼尔森针对 web 设计提出，对 APP 设计亦有重要参考价值 。

状态可见性原则（Visibility of system status ）：系统应该让用户知道发生了什么，在适当的时间内做出适当的反馈

环境贴切原则（Match between system and the real world ）：系统应该用用户的语言，用词，短语和用户熟悉的概念，而不是系统术语。遵循现实世界的惯例，让信息符合自然思考逻辑。

撤销重作原则（User control and freedom）：用户经常错误地选择系统功能而且需要明确标识离开这个的 “出口”，而不需要通过一个扩展的对话框。要支持撤销和重做的功能

一致性原则（Consistency and standards）：遵循平台的惯例。同一用语、功能、操作保持一致。

防错原则（Error prevention）：比出现错误信息提示更好的是更用心的设计防止这类问题发生。

易取原则（Recognition rather than recall）：尽量减少用户对操作目标的记忆负荷，动作和选项都应该是可见的。用户不必记住一个页面到另一个页面的信息。

灵活高效原则（Flexibility and efficiency of use）：中级用户的数量远高于初级和高级用户数。为大多数用户设计，不要低估，也不可轻视，保持灵活高效。

易扫原则（Aesthetic and minimalist design）：互联网用户浏览界面的动作不是读，不是看，而是扫。易扫，意味着突出重点，弱化和剔除无关信息。

容错原则（Help users recognize, diagnose, and recover from errors）：帮助用户从错误中恢复，将损失降到最低。如果无法自动挽回，则提供详尽的说明文字和指导方向，而非代码，比如 404。适用场景：产品设计

人性化帮助原则（Help and documentation）：如果系统不使用文档是最好的，但是有必要提供帮助和文档。任何信息应容易去搜索，专注于用户的任务，列出具体的步骤来进行。帮助性提示最好的方式是：

1. 无需提示；
2. 一次性提示；
3. 常驻提示；
4. 帮助文档。

适用场景：产品设计，交互设计，用户体验设计

漏斗模型

简单来说，漏斗模型就是通过产品每一个设计步骤的数据反馈得出产品的运行情况，然后通过各阶段的具体分析改善产品的设计，提升产品的用户体验。

漏斗模型分析示例

适用场景：运营分析，用户体验优化

SMART

Smart 原则最早是由管理学大师 Peter Drucker 提出，这个方法不但有利于员工更加明确高效地工作，而且可以让上级更好的去考核手下的员工，这个原则大部分也适用于对自己目标的要求。

• 目标必须是具体明确的（Specific）：所谓具体明确就是要用具体的语言清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可，或没有将目标有效的传达给相关成员。
• 目标必须是可以衡量的 (Measureable)：目标是明确的，应该有一组明确的数据，作为衡量是否达成目标的依据。
• 目标必须是可以达到的 (Attainable)：目标是要能够被执行人所接受的，如果上司利用一些行政手段，利用权利性的影响力一厢情愿地把自己所制定的目标强压给下属，下属典型的反映是一种心理和行为上的抗拒。
• 目标必须和其它目标有相关性（Relevement）：目标的相关性是指实现此目标与其他目标的关联情况。如果实现了这个目标，但对其他的目标完全不相关，或者相关度很低，那这个目标即使被达到了，意义也不是很大。
• 目标必须具有明确的截止期限（Time-based）：目标特性的时限性就是指目标是有时间限制的。没有时间限制的目标没有办法考核，或带来考核的不公。适用场景：项目管理，目标管理

总结

一方面我们要学会利用前辈总结的这些经验，有针对的，快速有效的解决问题，但另一方面，也要以发展的眼观看待这些既有方法，在实践中不断对已有的知识进行梳理、整合和扩充，从而总结产生出新的更适应时代变化的宝贵经验。