产品经理需求太多1个思考流程,C端产品轻松规划优先级

1、先抛出几个问题：产品为什么要进行需求管理？需求管理的核心是什么？如何规划优先级？然后带着这些问题，聊聊我是怎么思考 C 端产品需求规划的。“总是做迫在眉睫的事情，会让人丧失目标”引用 B 端产品经理必修课书中的一句话，简明扼要的说明了需求管理的目标和意义。需求规划的意义，是通过需求筛选的方法选择出可以在恰当的时间开发上线的需求，使产品团队工作更条例，最大化利用开发资源，同时帮助个人、团 队或公司产生间接价值。产品经理日常工作每天接触大量的需求，成熟一点的团队、公司，也都有针对自己产品需求的管理方法，甚至从需求挖掘、筛选、规划优先级都也自己 的一套方法论。C端产品从0到1的时候，通常专注做 MV

2、P,这时产品的需求量其实并不 大，只围绕产品目标和核心体验来发掘和规划需求。随着产品发展，有些产品 改变了定位，不再满足做一个单纯的工具类产品，而是拓展成一个用户服务平 台，通过各种功能来满足广大的各类用户群体。功能越多，服务的用户也就越多，收到的需求反馈自然也就越多，当同时面对上百个、甚至上千个需求，如何快速进行优先级规划，自然就需要一些高 效的方法了。需求管理通识性的方法论，产品经理们应该大多都比较清楚，但是这些方法论，都多多少少会带有主观意愿。比如运用 SWOT 分析需求的优缺点和竞争力时，对于这个需求，哪个优缺点才是客观的？又或者哪些点是真正有竞争力的？在运用波士顿矩阵来对需求进行分类

3、时，仅通过用户体验、公司战略两个维度，似乎又缺乏客观判断。再比如 KANO 模型可以对产品需求进行分类，有必备型、期望型、兴奋型、无差异型、反向型等需求类别，正常在需求管理时，可以根据这些分类再加上紧急重要程度来判断优先级即可有些方法论工具，为了强调需求规划的客观性，还会基于模型规划的需求进行打分评级策略，试图将这些需求的规划尽可能具备科学性、合理性。运用波士顿矩阵规划需求但是，每个人的专业认知和想法都不同，一千个产品面对一千个需求就会有一千个观点，方法论模型没问题，只是运用模型的人要对产品的定位、目标用户相当熟悉甚至可以深刻洞察，才可以基于模型对需求进行准确的分类。就算是这样，往往也抵不过老

4、板的一句话：我不要你认为，我要我认为”当同时面对需求清单里的上百、上千个需求，想要对这些需求进行快速优先级规划。试想一下，哪怕一个有着丰富经验的产品团队，直接套用以上方法论，再加上打分评级的步骤，或许可以完成，但也还是需要比较大的时间成本，更不用说那些只有一个产品经理的公司。对于他们的工作来讲，除了要考虑工作效率，还要考虑需求管理的方法是不是很科学。总之，这项看似基础的工作并不轻松。产品开发流程里面有一个 “门径管理流程” ，通过设置多个阶段和多个筛选关口，将最初收集的产品创意通过层层筛选把控，在最后开发上市阶段，最大程度降低产品项目风险。此处引用这个思路，通过以下优先级规划层级，可帮助产品团

5、队成员快速、准确的筛选出可行性需求，并根据客观判断依据，对需求进行优先级排序，提高工作效率和产出价值。需求优先级规划层级根据需求优先级规划流程，可迅速筛选出符合产品定位和公司规划的需求，并通过判断需求类型、价值，来决定需求的策划优先级，同时为产品开发团队输送高质量的产品需求。通过需求优先级规划层级，可以为自己建立一个系统的需求规划方法，对于专业的产品团队，又可以让团队成员按照标准化的思路来进行需求管理。同时根据需求优先级的规划思路，方便产品团队成员可以根据产品特性来选择相应的方法。收集用户需求后，先搞清楚用户等级以及产品的使用程度，明确当前需求方是否为产品核心用户群体，保证需求的真实性。如果是

6、产品内部发掘的需求，可直接明确需求的目标是否与产品目标一致，以及该需求是否未开发，即确保当前需求的真实有效性。进行基础判断后，再识别该需求属于前台需求还是后台需求，通常直接将需求单纯的进行优先级规划是不太准确的。而是需要将该需求放到具体的频道或模块下，关联产品模块去整体思考要不要做。该层面可以通过多个方面来体现需求的价值：结合产品规划，判断该需求是否与现有版本规划同步，或该需求相关功能模块是否在规划内，通常符合规划的需求更容易被开发，也更容易进行需求验证；同时围绕整体产品生命周期来判断这个需求的价值，同样的功能在产品不同运营阶段上线，产生的产品价值自然也不一样。还可以把当前需求放到产品的使用流

7、程上，思考是想要完善体验来提升用户价值，还是修复bug 来保证产品功能的完整性。将可行性判断放到价值考量之后，是为了促进产品的价值导向，从长期角度来看，更有利于通过开发更多有价值而不是比较容易的需求，来获得用户价值和产品价值。经过上述判断，已经筛选了一类需求，当把既符合产品规划，又对当前产品有价值的需求筛选出来后，那么就要进一步思考这些需求的可行性。该层面可通过宏观环境去判断当前需求的竞争力和投入产出比，同时判断这个需求如果开发上线后，有多大的影响面，可满足多少用户的核心利益，可对多少用户产生价值。确定可行性后，就要对筛选出来的可行需求进行优先级排序，可先将需求分类，如紧急 BUG 解决、功能

8、体验完善、新增亮点、未来规划，分别对应KANO 模型中的必备、期望、兴奋、无差异、反向类需求。通常紧急的产品 BUG 是最先需要解决的，同时因为是产品的必备型功能，对于用户来讲功能体验完善类的需求也是最应该解决的。新增的亮点可以满足用户的期望型需求，未来规划对于大多数用户来讲是无感知的，因此按照产品规划的节奏即可。这个阶段需要特别注意无差异需求和反向需求，尤其对无差异需求的判断要谨慎认真，否则会不知不觉耗费大量的精力开发这种没有太大价值，且性价比低的需求。最后分类出来的需求，还需要结合重要程度判断优先级，为保证客观准确，可针对同一级别、同一类型的需求进行打分，再次细分需求优先级。判断出优先级后，就需要分别给需求进行标注级别，提供两种需求级别：P0-P3， P1-P10。常规优先级级别是P0-P3,但是在目前实际操作中需求清单中需求太多，需求级别太少无法将需求分层细化，故还可以采用P1-P10。但同时缺点也比较明显，优先级层级较多时，就会导致越靠后的优先级定义越模糊。如果给需求评级时没有清晰的优先级定义，那在具体执行时就比较费劲。因此建议可以采用