干货来了：送你一份需求分析方法论，该方法论是由网易云音乐产品总监在他的书中提的：

上图是我读书笔记整理的，根据其说法，确定需求优先级从两个维度：

一个是重要程度，另外一个是紧急程度。组合起来就有三种可能：重要且紧急，紧急但不重要，重要不紧急。一般我们都是根据这个进行划分产品的迭代版本。

怎么确定重要程度呢？当燃是从你这个需求的商业目的出发，能够给公司带来什么样的商业利益。

怎么确定紧急程度呢？这个一般是从项目的安排和用户体验角度出发，比如说一个网易云音乐非常小的下载功能出现bug，这个功能对于公司商业利益不大，可是对于用户的产品使用体验影响非常大，就需要紧急解决。

不知道我说清楚了没有：另外贴出我的这篇的读书笔记希望可以帮助到你：

需求方法论笔记

产品需求三维度考虑

商业价值：是否能可持续发展（估算多种成本，如开发成本、交易成本、机会成本等）

技术价值：是否推动产品质量（BUG解决、代码优化、规范、可扩展复用等）

用户价值：是否解决用户问题（满足用户更好体验，或是否产生了用户利益损失等）

决策时不要拍脑袋，可以参考下面公式

理性的逻辑+感性的同理心+自己的经验+大家的异见+数据参考

这个是在前一段时间我也在思考的内容，后面慢慢还会慢慢深化，先总结浅显的讨论下：

正如1楼所说，万变不离其宗，重要性，紧急性是衡量一个需求优先级的重要标准；但是不能简单的就说完这些就结束了，这样并不能给我们带来任何帮助，所以如何判断一个需求的重要性和紧急性是非常重要的；

这里面会插入一个重要的概念：就是产品所满足用户的核心诉求，注意：核心诉求只有一个，他可以是一个动作，也可以是一组动作；也可以是一个流程，每个产品都不同，你要理清楚自己产品的核心诉求；那么核心诉求中所涉及/影响的需求就是最重要的需求（紧急性会单独拿出来考虑）；从核心诉求为中心的位置进行扩散，离它越远的重要性逐级降低；

接下来我们再来说紧急性：紧急性通常是另外一个维度，这个其实从业务上出发会更具像一些；举个例子：业务要调整架构，那么这种需求对产品来说重要性通常都是不高的，但是业务要跑起来，在你产品这卡住也是非常尴尬的事情，所以一要记得扩展产品的灵活性，另一方面这种需求基本上可以说是最紧急的需求；

那么重要性、紧急性说完了，我们还要引入一个概念：成本；因为每个公司资源有限，所以成本是我们绕不过去的一个问题，我建议通常在确定版本之前把需求尽可能地和开发同学一起讨论，拿到毛估成本后会更加的帮助你做决策；这里推荐你个项目管理的书：敏捷项目开发/设计冲刺；就这些...

个人认为，梳理产品的优先级，先考虑下几个点，可能会重合：
让个人成长的需求（做了有所精进）＞ 公司/领导近期看重的需求＞能带来数据或效益的需求＞日常优化体验需求＞无关紧要待定需求

摘抄了其他大佬的方法：

一、根据商业价值和客户价值画四象限图进行需求评估：

1. 高商业价值+高客户价值的，必做，且优先级高

2. 高商业价值+低客户价值的，不能做（针对B端）

3. 低商业价值+高客户价值的，可以做

4. 低商业价值+低客户价值的，尽量不做

二、根据KANO进行需求优先级排序：

一般分三种就够了（必备型>期望型>兴奋型）

是不是可以分为4个维度去思考这个需求：

1.  广度：这个需求覆盖的面有多广，还是只是单一用户；

2. 频度：这个需求被使用的频度有多高，是高频需求还是低频需求；

3. 强度：如果无法满足客户的这个需求，对于客户来说，有多痛，是完全无法使用还是不痛不痒；

4. 战略匹配度：对公司来说，这个需求是否在战略范围内，比如广度、频度、强度都不高，那么是不是属于基于未来的战略投入；

既然在评估需求优先级，那代表这个需求已经分析完了，是确定要做的。那对应的这个需求属于什么需求就有了清楚的定位，一般，公司战略>商业价值提升收益>挽回损失或降低成本>使用效率>体验

我们需要从综合全局的角度来判断一个需求的优先级，有以下几个因素：

• 产品的长期战略以及短期战略。产品的每个阶段都需要一个基准线，为了让产品目标在公司层面形成一致，否则在做需求判断和外部沟通的时候会浪费很多时间。
• 需求的用户价值。这一般基于对单个用户的价值乘以需要的客户数量，功能对单个用户的价值可以根据操作的高低频，以及这个功能涉及到的业务对客户的重要度来进行计算。
• 开发的成本周期。需求方的人一般对产品和技术是没有概念的，所以需求的开发周期评估是很重要的优先级判断的基准。
• 功能成功的可能性。如果新开发的功能是探索性质，不好确定是否能获得有效的收益或者达成目标体现价值。就要与业务方确认和讨论，明确需求的目的，是不是业务方从自身角度提的需求，如果功能上线了你们准备如何使用？会带来哪些收益？能不能达成你们想要的业务目标？把握有多大？这一步也就是让业务方想清楚，确认这不是拍脑门的需求。所以评估成功把握也是一个影响优先级的因素。

既然讲B端，就要看产品的阶段。可以从战略往打法，自上而下的想。

如果产品的下限（基础功能/模型效果等）没有搭好，优先做基础，这会让你的产品不比别人差，才有了B端的入行门槛；

如果产品的下限达标，开始攻上限。上限即能让你产品脱颖而出的需求，把人力和优先级聚焦在这些功能上。至于下限的东西，维稳即可。

投入产出比

1、需求上线后预计产生的收益是什么？（在多大程度提高效率、降低成本、产生收益）
2、需求开发需要投入的资源？（多少个技术配合，所耗的工时要多久）

3、最直接，抛给你的上级（老板），让他来拍板！

mvp 最小可行产品，再多品品

楼主不觉得b端范围太大？

是离散型业务还是流程型业务？离散型的和c端方法差不多、流程型找业务节点、确保关键流程走通