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

　　先抛出几个问题：产品为什么要进行需求管理？需求管理的核心是什么？如何规划优先级？
　　然后带着这些问题，聊聊我是怎么思考C端产品需求规划的。
　　“总是做迫在眉睫的事情，会让人丧失目标”
　　引用《B端产品经理必修课》书中的一句话，简明扼要的说明了需求管理的目标和意义。
　　需求规划的意义，是通过需求筛选的方法选择出可以在恰当的时间开发上线的需求，使产品团队工作更条例，最大化利用开发资源，同时帮助个人、团队或公司产生间接价值。
　　产品经理日常工作每天接触大量的需求，成熟一点的团队、公司，也都有针对自己产品需求的管理方法，甚至从需求挖掘、筛选、规划优先级都也自己的一套方法论。
　　C端产品从0到1的时候，通常专注做MVP，这时产品的需求量其实并不大，只围绕产品目标和核心体验来发掘和规划需求。随着产品发展，有些产品改变了定位，不再满足做一个单纯的工具类产品，而是拓展成一个用户服务平台，通过各种功能来满足广大的各类用户群体。
　　功能越多，服务的用户也就越多，收到的需求反馈自然也就越多，当同时面对上百个、甚至上千个需求，如何快速进行优先级规划，自然就需要一些高效的方法了。
　　通用方法论并非万能
　　需求管理通识性的方法论，产品经理们应该大多都比较清楚，但是这些方法论，都多多少少会带有主观意愿。
　　比如运用SWOT分析需求的优缺点和竞争力时，对于这个需求，哪个优缺点才是客观的？又或者哪些点是真正有竞争力的？
　　在运用波士顿矩阵来对需求进行分类时，仅通过用户体验、公司战略两个维度，似乎又缺乏客观判断。再比如KANO模型可以对产品需求进行分类，有必备型、期望型、兴奋型、无差异型、反向型等需求类别，正常在需求管理时，可以根据这些分类再加上紧急重要程度来判断优先级即可
　　有些方法论工具，为了强调需求规划的客观性，还会基于模型规划的需求进行打分评级策略，试图将这些需求的规划尽可能具备科学性、合理性。
　　运用波士顿矩阵规划需求
　　但是，每个人的专业认知和想法都不同，一千个产品面对一千个需求就会有一千个观点，方法论模型没问题，只是运用模型的人要对产品的定位、目标用户相当熟悉甚至可以深刻洞察，才可以基于模型对需求进行准确的分类。就算是这样，往往也抵不过老板的一句话：“我不要你认为，我要我认为”
　　当同时面对需求清单里的上百、上千个需求，想要对这些需求进行快速优先级规划。
　　试想一下，哪怕一个有着丰富经验的产品团队，直接套用以上方法论，再加上打分评级的步骤，或许可以完成，但也还是需要比较大的时间成本，更不用说那些只有一个产品经理的公司。对于他们的工作来讲，除了要考虑工作效率，还要考虑需求管理的方法是不是很科学。
　　总之，这项看似基础的工作并不轻松。
　　需求优先级规划层级
　　产品开发流程里面有一个“门径管理流程”，通过设置多个阶段和多个筛选关口，将最初收集的产品创意通过层层筛选把控，在最后开发上市阶段，最大程度降低产品项目风险。
　　此处引用这个思路，通过以下优先级规划层级，可帮助产品团队成员快速、准确的筛选出可行性需求，并根据客观判断依据，对需求进行优先级排序，提高工作效率和产出价值。
　　需求优先级规划层级
　　根据需求优先级规划流程，可迅速筛选出符合产品定位和公司规划的需求，并通过判断需求类型、价值，来决定需求的策划优先级，同时为产品开发团队输送高质量的产品需求。
　　通过需求优先级规划层级，可以为自己建立一个系统的需求规划方法，对于专业的产品团队，又可以让团队成员按照标准化的思路来进行需求管理。同时根据需求优先级的规划思路，方便产品团队成员可以根据产品特性来选择相应的方法。
　　如何快速运用
　　1。需求定位
　　收集用户需求后，先搞清楚用户等级以及产品的使用程度，明确当前需求方是否为产品核心用户群体，保证需求的真实性。如果是产品内部发掘的需求，可直接明确需求的目标是否与产品目标一致，以及该需求是否未开发，即确保当前需求的真实有效性。
　　进行基础判断后，再识别该需求属于前台需求还是后台需求，通常直接将需求单纯的进行优先级规划是不太准确的。而是需要将该需求放到具体的频道或模块下，关联产品模块去整体思考要不要做。
　　2。需求价值
　　该层面可以通过多个方面来体现需求的价值：
　　结合产品规划，判断该需求是否与现有版本规划同步，或该需求相关功能模块是否在规划内，通常符合规划的需求更容易被开发，也更容易进行需求验证；
　　同时围绕整体产品生命周期来判断这个需求的价值，同样的功能在产品不同运营阶段上线，产生的产品价值自然也不一样。还可以把当前需求放到产品的使用流程上，思考是想要完善体验来提升用户价值，还是修复bug来保证产品功能的完整性。
　　3。可行性判断
　　将可行性判断放到价值考量之后，是为了促进产品的价值导向，从长期角度来看，更有利于通过开发更多有价值而不是比较容易的需求，来获得用户价值和产品价值。
　　经过上述判断，已经筛选了一类需求，当把既符合产品规划，又对当前产品有价值的需求筛选出来后，那么就要进一步思考这些需求的可行性。
　　该层面可通过宏观环境去判断当前需求的竞争力和投入产出比，同时判断这个需求如果开发上线后，有多大的影响面，可满足多少用户的核心利益，可对多少用户产生价值。
　　4。需求分类
　　确定可行性后，就要对筛选出来的可行需求进行优先级排序，可先将需求分类，如紧急BUG解决、功能体验完善、新增亮点、未来规划，分别对应KANO模型中的必备、期望、兴奋、无差异、反向类需求。
　　通常紧急的产品BUG是最先需要解决的，同时因为是产品的必备型功能，对于用户来讲功能体验完善类的需求也是最应该解决的。新增的亮点可以满足用户的期望型需求，未来规划对于大多数用户来讲是无感知的，因此按照产品规划的节奏即可。
　　这个阶段需要特别注意无差异需求和反向需求，尤其对无差异需求的判断要谨慎认真，否则会不知不觉耗费大量的精力开发这种没有太大价值，且性价比低的需求。
　　最后分类出来的需求，还需要结合重要程度判断优先级，为保证客观准确，可针对同一级别、同一类型的需求进行打分，再次细分需求优先级。
　　5。需求级别
　　判断出优先级后，就需要分别给需求进行标注级别，提供两种需求级别：P0P3，P1P10。
　　常规优先级级别是P0P3，但是在目前实际操作中需求清单中需求太多，需求级别太少无法将需求分层细化，故还可以采用P1P10。但同时缺点也比较明显，优先级层级较多时，就会导致越靠后的优先级定义越模糊。
　　如果给需求评级时没有清晰的优先级定义，那在具体执行时就比较费劲。因此建议可以采用优先级别较少的方法，如同一级别的需求较多，还可以按照以上方法再次分解，直至拆分出最小迭代单位。
　　总结
　　C端产品的规划思路是围绕核心路径打造极致产品体验，需求收集后，一个需求从确认到原型策划之前，需要经历需求甄别、筛选、判断、优先级排序等阶段，产品需求管理的工作基础但极具价值。
　　任何方法论模型都无法保证适应每种产品的需求规划，如何能让自己高效的进行需求管理，还需要在工作中不断地实践、融合、举一反三。
　　此篇文章希望通过建立一个需求规划层级，帮助我们在平时进行需求优先级分析时，可以有一个完善的、系统的思考方式，让产品工作更有序。