以京东钱包为例,产品经理如何给需求分优先级

2-1. 用各种方法确认相对成本（如Team Estimation Game、Planning Poker，可展开），注意，这里是要各个功能的成本比例和排序，并不用评估到具体的“人天”
3. 确认性价比 = 价值/成本，得到初步排序
4. 识别功能类别，个人比较习惯用KANO模型（可展开）
4-1. 分类-基础、期望、亮点、无差别、反向
4-2. 分别对待：基本功能必做、实现个别低成本的亮点（大公司做法不同，可展开）、期望功能按性价比排序、无差别功能别做（无差别功能的低成本判断方法，可展开）、反向功能权衡利弊（往往是多目标的冲突处理，可展开）
4-3. 得到优化过的排序
5. 其他实际情况的考虑
5-1. 内外部依赖关系：合作部门？公司？某功能必须要谁做？……
5-2. 功能组合的完整性，模块依赖什么的
5-3. 其他朋友说到的老板需求什么的
6. 如太极，把招式忘掉，追求“如何拿到结果”
由团队共同决定@JoAnna
1. 团队的KPI
2. 产品的已有定位
3. 大盘和竞品分析
4. 用户集中的反馈
根据产品数据分析确定排序@粥小夏
根据产品的核心功能和产品的数据分析报告来确定最终的需求优先级排序
用户的需求只是产品迭代的部分依据，并不是产品的最终走向
总结
产品经理要通过分析用户需求来决定产品迭代，但无论如何所做的一切迭代都不能脱离产品最核心。

高级产品经理管理需求采优先排序的原则需求管理是产品经理的基本技能。

尽管产品经理从职业生涯开始就接触到需求，但大多数人都可以通过经历需求过程来快速理解过程。

但基本技能也是测试技能深度的关键。

原本希望用一篇文章来说明如何做好需求管理，但是发现这会导致文章太长不易阅读，简单用一系列的话来说，到底需求是什么，如何做好需求管理。

这一期主要讲两个方面基本解决问题：什么是需求总体思路下的优先权确定原则以下，Enjoy。

需求是装配线上的零件吗？回想刚入行时，我对需求的理解就好像是从流水线上传过来的一个零件，这个需求是上游给的，这个需求是业务给的。

即使是mentor说，或者你意识到要评估衡量管理需求，对于一个新手来说，事实上总是缺少对需求的管理的。

当然，这是每个产品经理成长必须经过的一个阶段，我以及周围很多同行的经验告诉我，这个阶段是无法jump过去的，在这个阶段中的PM们也不要心急，没有什么秘诀或者捷径可以让你获得老司机的功力，必须有这样的思想准备。

和所有学生迷茫焦躁的新手PM们一样，我也是可以跟着老师一遍一遍走需求的完整工作流程。

最开始在需求的管理和把控上都很被动，因为在业务创新驱动的公司，业务相关部门之间具有中国天然的话语分析优势，你会感受到分分钟被GMV碾压——“这个社会功能发展非常十分重要！这一期必须上！”“为什么？”“不上我们会损失XXGMV，会严重问题影响企业用户使用体验”……类似的对话相信我国很多技术产品设计都很熟悉了。

我当时的感受是，每个月总有效率那么通过几天是在和业务主要围绕着成吨的需求信息进行一些低效率地撕逼，撕完之后需要再去反省，就会一直觉得他们自己好弱鸡，“如果不能换成这样的思路，这样的说服教育方式，效果研究应该会好一点。

”经历多次撕逼——反省——撕逼的非良性生态循环后，正好是另一个新的大版本的开始，我下定决心要整体复盘寻找解决这种经济循环的七寸。

经过任何一个传统春节假期对所有旧版本需求的梳理知识以及分版本的复盘之后，突然出现感觉打通了经脉，有一种“呵，原来生活需求要这样财务管理”的感悟能力以及“我原来到底是怎么做需求的？！”的诧异。

产品经理如何制定项目优先级在当今竞争激烈的市场环境中，产品经理面临着众多的项目和任务，如何合理地制定项目优先级成为了他们工作中的关键挑战。

有效的项目优先级制定不仅能够确保资源的合理分配，提高团队的工作效率，还能够更好地满足市场需求和实现企业的战略目标。

首先，产品经理需要明确企业的战略目标。

这是制定项目优先级的基础和出发点。

企业的战略目标可能包括市场份额的扩大、盈利能力的提升、品牌形象的塑造等。

产品经理要深入理解这些目标，并将其转化为具体的产品目标。

例如，如果企业的战略目标是在短期内迅速提高市场份额，那么与之相关的产品功能改进或新产品开发项目就应该具有较高的优先级。

其次，对市场需求进行深入的调研和分析。

了解用户的痛点、需求和期望，以及市场的趋势和竞争态势。

通过用户反馈、市场调研数据、竞争对手分析等手段，获取全面的市场信息。

如果发现某个市场需求非常紧迫且未被满足，那么针对该需求的项目就应该被优先考虑。

比如，在智能手机市场，如果用户对电池续航能力的抱怨强烈，而竞争对手尚未在这方面取得显著突破，那么开发一款具有超长续航能力的手机项目就可能具有较高的优先级。

再者，评估项目的潜在价值和风险也是至关重要的。

潜在价值包括直接的经济效益，如销售额的增长、成本的降低，也包括间接的价值，如用户满意度的提升、品牌忠诚度的增强等。

同时，要充分考虑项目可能面临的风险，如技术难题、市场变化、法律法规限制等。

对于价值高且风险低的项目，应给予较高的优先级；而对于价值不明确或风险过高的项目，则需要谨慎对待。

资源的可用性也是影响项目优先级的重要因素。

产品经理需要清楚了解团队的人力、技术、时间等资源状况。

如果某个项目需要大量的资源投入，而当前资源紧张，那么可能需要调整其优先级或者寻找更高效的资源利用方式。

比如，一个需要跨部门协作且多个关键人员已经在其他重要项目中忙碌的项目，可能就需要暂时降低其优先级。

项目的紧急程度也是不能忽视的。

有些项目可能由于外部因素，如竞争对手的行动、法规的即将生效等，具有很强的时间紧迫性。

需求优先级的确定及划分方法
在进行项目开发过程中，需求的优先级是十分重要的，它决定了项目开发的先后顺序和时间周期。

本文将介绍需求优先级的确定及划分方法。

确定需求优先级的方法
1. 利益相关者投票法
利益相关者包括项目经理、开发人员和用户等，他们可以利用投票的方式来确定需求的优先级。

具体方法可以选择各个利益相关者独立投票，或者在协商过程中形成一致意见后再进行投票。

2. 价值评估法
通过对需求的价值进行评估，以此来确定需求的优先级。

对于公司或用户或项目经理等不同的利益相关者来说，对需求价值的评估标准也将不同，可以选择合适的评估方法，在评估结果中确定需求优先级。

划分需求优先级的方法
1. 高中低优先级法
将所有需求按照其优先级分为高、中、低三个等级，在开发的
过程中，按照其等级优先进行开发。

当高优先级开发完成后，再进
行中等优先级的需求开发，以此类推。

具体实现可以通过建立需求
清单和任务清单来进行划分。

2. 时间迫切法
将所有需求按照其完成时间的紧迫程度来进行划分，需要最快
完成的需求视为高优先级，需要较长时间才能完成的需求视为低优
先级。

综上所述，确定和划分需求的优先级是一个精细、复杂的过程，需要进行有效规划和合理分配。

在确定需求优先级的过程中，可以
通过利益相关者投票法和价值评估法来进行；在划分需求优先级的
过程中，可以采用高中低优先级法和时间迫切法等方法。

产品经理如何做好版本管理与需求优先级产品经理在版本管理和需求优先级的管理上要做好以下几方面的工作：1.收集和整理需求：产品经理应该全面地了解用户需求和市场需求，并将其收集起来进行整理和分类。

一方面可以通过与用户和销售团队的沟通来收集需求，另一方面可以通过市场调研和竞品分析来了解用户的需求和行业趋势。

2.设定优先级：对于不同的需求，产品经理需要根据公司策略、业务目标和市场需求来设定优先级。

通常可以根据以下几个方面来进行评估：用户价值，技术可行性，市场竞争力和紧迫程度等。

可以使用一些常见的方法如KANO模型、九宫格优先级矩阵等来帮助确定需求的优先级。

3.制定产品路线图：产品经理需要将所有的需求整合到产品路线图中。

产品路线图是指产品的发展规划，可以从短期和长期两个维度来制定。

短期的产品路线图可以根据当下的优先级需求来安排，而长期的产品路线图则是为了实现公司的长远目标而制定的。

5.优化需求实施：产品经理需要与开发、设计和测试团队密切合作，确保需求的实施质量和进度。

在需求实施过程中，应该及时跟踪进度，解决问题，及时调整优先级，确保产品按时发布。

6.监控和反馈：产品经理需要对发布的产品进行监控和反馈。

可以通过用户反馈、数据分析和市场调研等方式来了解产品的使用情况和市场反馈。

根据这些反馈，可以对产品进行优化和调整，并根据市场需求重新制定优先级和版本计划。

7.持续优化：版本管理和需求优先级是一个不断优化的过程。

随着产品的不断发展和市场需求的变化，产品经理需要不断地对版本管理和需求优先级进行调整和优化，以保持产品的竞争力和满足用户需求。

总结起来，产品经理想要做好版本管理和需求优先级的管理，需要全面了解和整合用户需求和市场需求，设定合理的优先级，制定清晰的产品路线图和版本计划，与开发团队紧密合作，及时调整优先级和解决问题，并持续监控和优化产品。

这样才能确保产品按时、高质量地发布，并不断满足用户需求。

需求的优先级排序所谓“熊掌与鱼，不可兼得”，我们的时间、精力或者其它资源都是稀缺的。

当我们做出决定的时候，我们就该为这些事情指定优先级，一件一件的完成。

需求优先级排序无论是在刚入职还是到产品总监一直到老板，一直存在的问题就是需求优先级的问题。

所以在这一点上，不仅仅在产品的工作中，其实日常的工作和生活中这个方法也是管用的。

对于产品也一样，我们搞出来很多需求，感觉都想做，无处着手~接下来，我们一起来学习一下如何通过几个简单的维度给需求进行优先级排序。

我建议优先级排序依据四种：频率、开发难度和效果、产品价值、对用户的熟悉程度。

老板：最近上门服务特别火，我们转型吧，要不我们也做一个每天送花上门的APP吧，我老婆就特别喜欢有人给他送花，一定有市场。

PM：中国人没有每天送花的习惯，而且花太贵了，这个项目不靠谱。

老板：怎么可能，中国有好多土豪呢，还有很多包二奶的，都有钱啊。

PM：……反正不靠谱。

所以，基本这类PM老板很难受，肯定是第一波被开掉的人。

因为永远是在否定，而不是在网下在延伸。

在这个情况下，产品经理应该怎么合理说服老板呢？1、优先解决大用户量的高频问题，基础体验。

2、最后解决少量以用户的低频问题，超好体验。

我们在日常工作中经常会发生一个问题，我们老是去解决一些少量用户的低频问题。

这样的话，少量用户的口碑当然好，体验也还可以，但是你的基础体验出问题了。

应该大量用户做的事情并没有做好，但是你做了一些特别小众的用户，它并不能给你带来大量的价值。

所以在这个角度来说，是有问题的。

所以，这个四象限大概是这样的。

首先是发生频率从低到高，用户量从少到多。

这个时候，首先要做的是频率非常高，用户非常大的，这是第一个；第二个是做用户非常大，但频率相对比较低的，这个能带来更好的体验。

第一个是基础体验，说明这个产品能通了，基本的路径能用，而且是在一个六七十分的水平，然后对大量用户来说，还有一些频率不高但是体验还可以的，这就是我们提供一个相对良好的体验。

前几天在社群里有人问怎么排需求优先级，今天来简单聊聊这个问题。

其实需求优先级有很多成熟的方法论，常用的有4个：我平时用的，是矩阵分析法，的变种。

先来一下矩阵分析法，它是根据需求的重要性和紧急性两个属性来确定优先级。

其实我一直不是很理解，重要性和紧急性分得开吗？一个很紧急的需求，难道不是很重要吗？比如之前的淘宝弹窗事件，ios版本突然出现一个bug，启动应用时会有个弹窗：常规来说，这种bug的修复肯定是紧急性max，难道不也是重要性max 吗？所以为了更清晰的表述一个需求的优先级，我对矩阵分析法做了调整：同样是一个矩阵，纵轴代表需求之于产品的价值，越往上，价值越高，横轴是需求的开发成本，越往右边开发成本越高。

总共分为4个区域，序号代表优先级。

这样排优先级的好处是，非常方便的确定下一次迭代做哪些需求：P1需求+部分P2需求。

现在互联网产品崇尚快速迭代，一般每次迭代的开发上线周期不超过2周，所以每次要做的需求也是比较有限的，按照我们这个需求优先级，P1需求是每次必做的，然后根据工作量，加入部分P2需求，确保开发同学在本次迭代周期内工作量是饱和的。

具体分析一下矩阵的两个维度：产品价值和开发成本。

怎么确定一个需求的产品价值高还是低呢？主要看这么几个方面：一个需求影响的用户量越大、用户使用的频次越高、用户需要的迫切程度越大，就说明这个需求的价值越高。

另外，如果一个需求能明显的提高用户的付费意愿，那么这个需求的产品价值也是很高。

特别是B端saas产品，如果一个大客户明确表示：你做了a需求，我就签单！决定一个几十甚至几百万的大合同，你说a需求的价值高吗？所谓的产品价值，说白了，就是做了这个需求，我们的产品能得到什么？产品需要的东西，就两类：要么是用户增长，要么是营收。

这两类就是产品价值的本质。

开发成本就比较好理解了，主要就是开发同学的工作量。

具体到需求的工作量，最好找开发同学一起评估。

众所周知，程序猿的工资很高，既然付出了固定的成本，就要让他们做价值高的事情。

需求优先级管理流程说明本文档旨在说明需求优先级管理的流程，以确保需求的合理排序和高效实施。

通过正确管理需求优先级，可以最大程度地满足用户需求并提升项目的成功率。

流程概述需求优先级管理流程分为以下几个步骤：1. 需求收集：团队收集并记录所有相关需求。

2. 需求评估：团队对每个需求进行评估，包括需求的重要性、紧急性和影响程度等。

3. 优先级制定：根据评估结果，制定每个需求的优先级。

4. 优先级确认：团队与相关利益相关者确认需求的优先级，并确保达成一致。

5. 优先级调整：根据项目实际情况和利益相关者的变化意见，调整需求的优先级。

6. 实施计划制定：根据需求的优先级，制定实施计划，确保高优先级需求能够及时得到满足。

7. 需求跟踪：在项目执行过程中，跟踪需求的实施情况，并及时更新需求优先级。

流程细节1. 需求收集需求收集是需求优先级管理的第一步，团队成员通过与利益相关者沟通，收集并记录所有相关需求。

2. 需求评估在需求评估阶段，团队对每个需求进行评估。

评估的内容包括需求的重要性、紧急性和影响程度等。

评估结果将为后续的优先级制定提供依据。

3. 优先级制定基于需求评估的结果，团队制定每个需求的优先级。

常用的优先级分为高、中、低三个级别，也可以根据实际情况进行细分。

4. 优先级确认团队与相关利益相关者进行沟通和确认，确保对需求优先级达成一致。

利益相关者的意见和反馈将被纳入考虑，以确保优先级的准确性和公正性。

5. 优先级调整在项目执行过程中，需求的优先级可能会发生变化。

团队应密切关注项目进展和利益相关者的需求变化，并及时调整需求的优先级。

6. 实施计划制定根据需求的优先级，制定实施计划，确保高优先级需求能够及时得到满足。

实施计划需要考虑团队资源和项目时间的可行性，并与相关人员进行沟通和确认。

7. 需求跟踪在项目执行过程中，需要跟踪需求的实施情况，并及时更新需求优先级。

通过需求跟踪，可以及时发现问题和调整优先级，以保证项目的顺利进行。

如何判断需求的优先级1. 如何判断需求的优先级基本的原则是通过两个维度来判断：重要程度和紧急程度。

优先级的排序是：重要紧急 > 重要不紧急 > 紧急不重要 > 不紧急不重要那么如何判断需求的重要和紧急程度？⽅法1：根据产品发展阶段判断，产品阶段划分为起步阶段，发展阶段和迭代阶段。

起步阶段注重核⼼功能的实现，需要快速推出市场验证产品的可⾏性；发展阶段会进⾏功能扩展和完善，这个阶段会进⾏⼩范围的试错试验；到了迭代阶段，产品已经成熟稳定，需求会更加注重⽤户体验⽅⾯。

起步阶段做基本型功能，发展阶段做期望型功能，迭代阶段做兴奋性功能，重要程度是基本型功能>期望型功能>兴奋型功能。

⽅法2：需求价值判断法：也就是性价⽐判断，考虑需求实现需要的开发资源和运营资源，考虑需求的受众⾯，⽤户的使⽤频次，是否为刚需（对⽤户的必要程度）。

2. 如何做版本规划- 明确每个版本迭代的⽬标，这样团队在设计、开发产品的时候有⽅向感，另外后期时间紧张的话，⽐较容易砍掉⼀些⽆关的需求。

- 根据产品发展阶段指定版本⽬标启动期：启动期主要验证产品的功能是否符合市场需求，这才是1，否则市场根本没这个需求，或者有这个需求，但你的产品满⾜不了，后期拉新多少，死多少。

所以这个时候，迭代要快，只做产品主要功能。

成长期：在市场需求验证成⽴之后，这个时候产品的主要⽬标就是拉新，尽可能多的拉新⽬标⽤户，所以这个时候产品经理的迭代⽬标就以拉新为主。

顺带要优化⽤户体验，这样你才能形成⼝碑传播，让更多的⽤户来⽤。

所谓的⽤户体验，就是你要超出⽤户预期，让⽤户觉得好⽤，成熟期：成熟期的产品已经进⼊稳定阶段，这个时候的产品很难再突破性的增长，这个时候我们的主要⽬标是活跃和营收，毕竟不赚钱只烧钱的产品谁也撑不住。

这个时候的迭代可以以稳为主，就像公司发展到⼀定阶段，求稳，⽽不求快⼀样。

产品的优先级应该怎么定产品经理通过各种渠道接到产品需求后，第一步要做的就是对需求进行和处理，对需求的优先级采取评估。

具体怎么做？可能需要遵循哪些标准？本版我从自身工作实践出发，对此积极展开了分析讨论，一起来看看~先说下要产品经理的职责是什么？我理解产品经理分管要为以下几点负责：这4点，我认为排列优先级是最玄学的。

一千个人排列优先级，就有一千种排列方式。

那为什么是玄学呢？或者说为什么每个人都有不同的优先级排列方式，因为这是一个某种程度判断，且影响因素太多，例如项目阶段、实现成本、提出人、收益情况、紧急情况、重要与否，每个人对于这些线性的感受程度是所有不一样的。

拿我之前做的一款内容产品来讲，当时我负责一块研究性模块内容，当时我判断继续的优先级是持续产出优质的内容，所以会把焦点放在秩序持续放在输出的内容品质，与输出内容的人身上。

虽然项目刚开始启动的时候，这么做没有问题，但是当我们有了这部分内容的累积，重要是扩大影响力，通过相同类型的内容客户端，投放我们的内容，曝光在更多的用户面前，赢取更多的影响力，从而以获取更多的资源，帮助优质内容的输出，形成良性循环。

因为错误的判断，错过时间窗口，产品影响力没有做恨不得。

所以为什么要有优先级？优先级其实是聚焦目标，有好好了目标再以去拆解实现方法，没有目标，就不知道终点是哪里，不具体也不可表征。

排优先级，我们在排什么？我在此之后产品的理解是产品需求的优先级，例如我现在手上三个有几个需求，根据今天的业务诉求，阶段目标，来排下序。

最近通过实际做业务和一些大佬的文章，有了一些新的认知。

我现在在做TOB产品，所以简要以TOB产品的工作方式，进行举例。

需求的主要来源方为六个渠道渠道，业务方提出的需求，产品自己提出的需求，来自老板提出的需求。

需求叠加在一起，我们怎么样应该优先实现哪个？为自己的业务发展目标、产品首要目标建立一个清单，例如：线索量、交易转化率、完成最小交易双方闭环、解决打印能力，根据业务目标倒推我要实现的产品需求。

如何给需求分优先级？在收集需求阶段，从各个渠道收集⽽来的需求，应该如何梳理？哪些做、哪些不做，哪些先做、哪些后做？产品都是解决某类⽤户在特定场景下的问题的，想满⾜所有⼈需求的产品⼀定不是好产品。

⽤户穿⿊⽪鞋就会买⿊⾊的鞋油，不会去买棕⾊的鞋油，除⾮没办法。

众⼝难调，不要做万⾦油的产品，要细分⽬标市场，锁定⽬标⽤户群。

1．商业优势 + ⽤户偏好哪些做，哪些不做，这是由产品定位、企业战略、商业优势决定的。

哪些先做，哪些后做，这是由⽤户偏好决定的，要将⽤户偏好分级，优先级⾼的先做，优先级低的后做。

优先级如何划分？可以从商业优势和⽤户偏好两个⽅⾯考虑，先画好横坐标——⽤户偏好；再画好纵坐标——商业优势（见下图）。

先把所有的需求列出来，再针对⽬标⼈群，把需求按横坐标和纵坐标的要求划分到不同象限中。

偏好⾼的靠后、偏好低的靠左。

再把需求按商业优势划分到坐标中，优势⼤的靠上、优势⼩的靠下。

把所有需求和优势都放到上图所⽰的坐标中，对不同象限的情况分别进⾏分析，就形成了产品的优先级。

2．逐⼀分析第⼀象限：⽤户偏好强、商业优势强，此象限应该为优先开发的需求。

第⼆象限：⽤户偏好弱、商业优势强，此象限应该选择性开发，如果⽤户不太反感，则可以开发。

第三象限：⽤户偏好弱、商业优势弱，此象限不建议开发。

第四象限：⽤户偏好强、商业优势弱，此象限应该选择性开发，如果⽤户偏好性很⼤，则需要开发，否则选择性开发。

实例——以“京东钱包”为例，谈谈如何划分⽤户的需要的优先级1．产品分析京东钱包（见下图）这款产品的核⼼应该是理财。

从京东钱包APP可以看出，其中的第⼀个频道“今天”将京东钱包⾥的所有功能都罗列开，其功能还是很丰富的，两屏能显⽰完全部内容，如果⽤户想要理财或是购物可以到⼆级栏⽬中找。

京东钱包APP这款APP的设计思路实际是⽹站的设计思路，“今天”相当于⽹站⾸页，“理财”是其核⼼内容；“⽣活”是其附属功能；“我的”是⽤户⾃⼰的资⾦管理。

需求，是我们在产品工作中接触最多的词语。

不管是来自用户、业务还是老板，产品经理总会收到各种各样的需求。

需求，不是一个单纯的名词。

在需求被提出时，对于提出方是结束，但对于产品经理是工作的开始，需要打出一套组合拳来承接。

产品经理需要在接到需求时辨别真伪、在迭代时排好优先级、在开发时做好需求变更、在上线后分析数据给出反馈。

在这一系列过程中，都需要产品经理做好需求管理工作。

在管理需求时，产品经理首先要对不同的渠道进行管理。

因为需求来源不同，后续的做法完全不同。

需求的渠道大致可以分为五方：用户、老板、业务、客户、自身。

那么，这几方的需求产品经理应当如何妥善处理呢？01用户的需求看问题产品是给用户使用的。

那么产品是否符合用户预期、使用过程是否顺畅、是否帮助用户解决了问题或达到了目的，就需要产品经理时刻保持关注。

长链接是保持关注用户需求的常用方式。

建立长链接需要找到快速触达用户的方式，可以是收集用户反馈、做用户调研访谈、客服跟进或直接混迹在用户群体中。

但具体链接形式不太重要，核心在于能够听到用户的真实表达。

比如在访谈时，不要预设有引导性的问题。

用户一般不会主动提出需求或者表达想要什么功能，尤其是产品流程相对完善后，用户基本就不会提出建议了，更多是发牢骚和吐槽。

在产品发展的前期要产品经理要找到和关注KOL，在需求上听从他们的建议，根据他们的反馈做产品流程优化，使得产品快速从0到1。

有区别的是，在产品发展的上升期和稳定期，要谨慎对待KOL的需求，他们毕竟只代表小部分用户，大部分用户都是小白，可能用不到KOL的专业诉求。

那这时候用户的需求体现在什么地方呢？更多的体现在观察用户的使用感受上，从他们的牢骚和吐槽中定位到背后的真实问题，根据他们的实际反馈来不断的调整力度，完善产品。

02老板的需求看目的老板，是需求的另一来源。

大部分情况是，老板提了一个需求，让产品经理去执行。

这个时候就要采用对用户完全不同的做法了。

我们可以用两个明确来完成老板的需求。

需求价值与优先级我们会接到不同来源的各有不同需求，有的源于业务部门、领导要求，有的来源于用户反馈、线上问题，有的是市场反馈建议，或者竞品已提供支持等等。

收到原始需求之后，我们怎么想到哪些需求要做？哪些需求要优先做，哪些可以往后排？或者在需要澄清需求价值时，我们要回答哪些问题后，才算讲清楚了需求收藏价值，又如何做需求的优先级做依序。

首先，我们要对原始需求进行分析，明确该需求具体解决了谁的什么问题。

即目标用户是谁，提出融资需求的动机是什么，该需求能解决目标用户的什么既定目标问题。

当我知道了需求的用户和问题之后，问自己几个问题：这个问题实际上是去思考新融资需求是否与产品定位匹配，我们回溯产品定位，将需求与产品产品定位做个适配，如果和我的产品不相关也不是产品将要演进的方向，就不做这个需求。

可以思考是否与组织有否内部其他产品设计匹配，并记录下来。

要识别核心用户，先做用户细分，再聚焦核心用户，就是明确消费者的优先级。

B端产品的用户与C山皮产品用户不太相同，下图是两类用户细分的参考纬度。

C后端用户细分参考纬度B端用户细分参考纬度举个例子，例如宜家APP做用户细分时考虑从用户基本属性开始，以用户收入、职业、家庭出发去考虑。

而对于KEEP来说以消费需求来做用户细分，想要尝试的健身小白，需要健康适时及定期执行锻炼的这类喜爱健身的职场人士，热爱健身、分享的健身大牛……对于车企供货管理系统，以不同的用户管理职责为纬度，例如销售顾问、试驾体验专家、销售经理、区域经理等等。

用户细分用户具体方法这里不曾给出，数据资料这里只是一个用户细分纬度参考资料，用户识别实际上需要谈论更大的篇幅讨论，B端、C端用户辨别各有明定适用的方法。

做好用户细分后，然后可以进行核心用户作出识别，这里推荐非常积极使用价值表格能很好量化用户权重，方便我们后续量化需求价值，以评估优先级。

一般来说评估用户内在价值的纬度，有用户的影响力、花费的⾦钱、使用频率、权利、用户规模等。

作为PM，如何快速确定产品需求列表的优先级身为产品经理，你是否也曾为用户故事的积压的问题苦恼过？本文我介绍了一整套体系方法，通过决定用户故事的优先级来解决这个。

上个迭代还有好几个用户没有完成！燃尽绘没有燃尽是因为出现了Bug……上述的吐槽听起来有没有很进去熟悉？我身边的产品经理基本上都经历过这样的事情。

可以说，用户故事的积压和产品的缺陷对于是经理们来说应该产品家常便饭了。

深究其原因，我认为是大家缺乏一套体系方法来决定用户故事的优先级。

所以在这里，我想以自己的创业团队为例，给大家介绍我们正在使用的排用户故事和Bug修复优先级的工具框架。

我的项目组采用了一套「故事排名系统」。

这套系统是这样的：我们把紧急度和商业价值这几个两个维度在1–5的范围内施于一个值，然后把纯量这两个数相乘以确定一个用户童话故事的最终权重。

我们把权重标在权重一个向量上，用这种方法对产品路线图中的用户故事进行可视化和排列优先级。

在实际工作中，我会为和卡每个用户故事制作一张分值卡，上面有两个打分三项：紧急度和商业价值。

紧急度的取值与三个利空因素有关：交付时限、任务依赖和直接后果。

举个栗子：一个紧急度为1微秒的用户故事可能没法时间限制、影响很小，而一个紧急度为5的用户受制于故事可能时间紧迫并依赖很多其他用户故事，如果不先把它完成就不能推进其他的故事。

商业价值的取值也与三个韦尔泰宗各种因素有关：客户影响、品牌或声誉影响和竞争市场优势。

再举个栗子：一个商业价值为1的用户故事可能只对很少的桥段客户／用户有影响，而一个商业价值为5的用户故事则对每个客户都很重要——也对联营公司生存很重要。

怎样确定每个用户故事的客户分值呢？可以使用紧急度排序表来确定。

说了这么多，我们给每个用户故事分配了紧急度和商业价值这两项的数值此后，怎么决定用户故事的轻重缓急呢？你要做的，就是把同一个用户故事使用者放入这个矩阵。

在实际使用中，我发现老板和公司更喜欢晚一点再对付取值6、8、9的用户故事，所以我根据实际情况「修订」了一下矩阵。

编辑导语：对于高级产品经理来说，在面对需求很多的情况下，应该如何去安排优先级呢？本文作者分析了常用的KANO模型和四象限法的缺点，推荐了WSJF模型，并且详细地介绍了其使用方法，希望能够带给各位产品经理们一点启发。

先抛3个问题，如果你在评估需求价值、排优先级的过程中也有类似的困惑，继续阅读也许能找到答案：经过我调研，这3个问题，在B端产研团队、科技转型企业、业务主导条线中经常发生。

如果不能善加解决，你的产品就会做得很臃肿、琐碎，体验也会很差，如下图：这种就是我说的臃肿型APP：因为业务的权重，会新增堆叠很多功能模块，同时因为权重相同无法排出先后，就只能抽屉式平级罗列。

这样就导致整个页面很臃肿，每个功能的使用率都不高，产品的ROI很差。

并非是产品经理不知道这个问题，只是在企业的战略要求下，业务需求权重就是更高的，难以抽出人力和精力去做功能的整合、体验的提升。

但难，并不是没有办法。

长此以往恶性循环，总有一天产品体验会跌到谷底，影响正常业务发展，这是一个可以预见的后果。

我们假设用户满意度（受用户体验影响）是一个观测指标，即只要在60分以上，用户就能忍、不会流失。

那么如果你的产品当前满意度在60附近，你可以认真考虑一下重新梳理优先级、提升用户体验的问题了。

如何能够满足业务需求的情况下，又能让用户体验不受损伤，或长期持续让用户满意，是每个产品经理必须承担的责任。

而用户体验问题，在产品经理能力都不差的今天，往往就是因需求优先级评估不当而导致的资源排布问题。

说到需求优先级，很多人会说KANO模型和四象限法，很遗憾这两个方法在实战中很难奏效。

先看看KANO模型的背景和先验条件（不提先验条件直接摆方法论的都是耍流氓）：KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

如上所述，kano模型只展示了用户价值，但用户需求是无限大的，所以不能用户要什么就做什么。

2类常用方法，解决需求优先级决策在产品初期，产品经理们会面临这样一个苦恼：这个需求很关键、那个需求很重要。

想实现的消费需求很多，但奈何资源是非常有限的。

这个时候，决定需求的优先级演变成了一种难题。

交易成本任何一个需求实现都需要消耗资源成本，如何让这些成本获得最大化收益，考验着产品负责人的决策能力。

一个惯常的思路是——我们投入经费了资源成本，对应地会地能带来超额收益或效率提升。

只要关注投产比这个主要指标，自然能很轻松做出正确决策。

理论与实践的已经开始差距正在于此。

绝大多数时候，投入经费投入和劳动生产率都是很难量化的东西。

就算真正去量化，涉及很多拆解出来十项的细分项，也靠着拍脑袋估算；少量的指标估算对结果少部分的影响可控，一旦绝大多数评价指标都需要通过估算来完成，结果只不过就不可靠了。

所以，进行需求优先级决策时则，定性的分析尤为重要。

站在公司或项目的角度，上一层级四级的目标实现通过下面层级来拿结果，至上而下的目标拆解和执行，至下而上的过程管理和关键步骤结果反馈，共同推动公司目前整体目标的实现。

用人话来说，就是心往一处想，劲儿往一处使，聚焦出成果。

说起理论框架，大家都不爱听，那么如何对业务目标进行拆解？在数据分析领域，有一个很重要的工具——MECE拆解原则。

我也曾在一篇文章中详细介绍过这个原则。

英文发音为：me-see，中文意思是：相互独立，完全穷尽。

即是明确业务目标后才，找准一个切入点，从这个维度将目标进行细分，要求细分结果不重不漏。

细分结果可以理解为要达成整体目标所必须具备的部分。

再说通俗点，就是你自己找一个你认为合理的角度，然后从这个侧面出发，不断需要进行分类拆分，但至不能再分为止。

举个例子：公司领导要求五月份内新增20个城市业务，要实现这个目标，子系统所有相关业务模块都需要拆解出自己的KPI，而要实现这些KPI很多需要产品的提供支持。

首先，拓展城市新业务落地需要产品统筹规划，不同城市支持不同的旧城区业务模式。

产品经理需求分级
产品经理需求分级是指将产品需求按照其优先级和紧急程度进
行分类，以便产品经理能够更好地管理产品开发和交付过程。

一般来说，需求可以分为三个级别：高、中、低。

高级别需求通常是指对产品成功至关重要的需求，如解决重要的客户痛点、提高产品核心功能的竞争力等，这些需求应该优先考虑。

中级别需求则是对产品有较高的贡献，但不是必需的需求，可以在高级别需求解决之后再考虑；低级别需求则是一些次要的功能或者改进，可以放在后续进行。

在进行需求分级时，产品经理需要综合考虑各种因素，如市场需求、客户反馈、竞争情况等，以保证产品的开发和交付能够顺利进行。

同时，产品经理还需要与开发团队密切合作，确定每个需求的实现难度和工作量，以合理安排开发进度和资源分配。

总之，产品经理需求分级是产品开发过程中非常重要的一环，能够帮助产品经理更好地管理需求，提高产品交付的质量和效率。

- 1 -。