由于产品对象与场景的不同，所以C端产品需求与B端产品需求是截然不同的，如果以C端产品思维去做B端产品，那结果可能是相当“难以言喻”的。那细化到B端产品，怎么去规划B端产品的需求，怎么去判定产品需求的优先级呢？本文将告诉你答案。
世上本没有优先级，资源紧了，计划多了，自然就有了。
前篇文章，《需求太多？1个思考流程，轻松规划C端产品需求优先级》对C端需求优先级规划做了一个系统的梳理和决策思路。
根据规划层级的逻辑去思考，将需求关联到具体频道、模块下，结合整个核心模块流程来思考需求的价值，这种方法是相对完整和客观的，既避免了因需求评估维度单一导致错过真实需求，又可以通过层层思考，抽丝剥茧筛选出真正符合产品当下规划的需求，还可以锻炼产品经理的抽象能力和系统思考能力。
因为笔者目前所在公司的两款核心产品，正好一个是面向个体用户的用户端产品，一个是面向组织、团体的协同OA产品，因此在工作中经常接触C端和B端的产品需求，最近在做需求规划的时候，也总结了两者的相同点和不同之处。
1. 相同点
1）需求管理的目的相同
都是为了集中当下优势资源为服务对象提供有客户价值的需求，对内提高资源利用率，保证产品开发团队良性运营；对外通过提供切实的服务，满足市场和用户需求，从而为公司创收，因此任何形式的产品，需求管理的本质是相通的。
2）需求规划的方法类似
在实际工作中，很多从C端转行到B端的产品经理，经常会用C端的工作思路去做B端的需求规划，虽然产品类型不同，但需求规划、分析的方法确实有相同之处；
在做需求规划时，通常都会优先思考与公司战略和规划相匹配的需求，其次是可以直接或间接为公司带来业务发展和收入增长的相关需求。
而且下图所示的一些思考层级和工具，在B端也同样可以使用，比如可以使用SWOT分析优劣势、KANO模型进行需求分类等等。
2. 不同点
1）因为产品面向的服务对象和场景的性质不同，因此需求本质也就不同。
按照C端产品围绕核心路径打造极致体验的思路，作为产品经理们，可以按照自己的需求认知，将不利于核心场景的需求拒之门外，也可以义正言辞的说：此类需求严重影响产品核心体验，不予采纳；
而B端产品需求规划的思路，是围绕核心业务场景完善业务闭环。B端需求基本来自真实的业务场景，1个需求可能来自10个业务方的反馈，10个需求可能满足100个业务场景，因此B端的需求基本都有客户价值，也就无法像C端那样只需抓住核心功能将体验极致优化；
2）因为B端产品通常是为企业直接提供商业化服务，最直接的目标就是企业通过购买系统软件为企业降本增效。因此考虑需求优先级时，需要深入某个业务流程或场景中，那些可以降低成本、提升效率的需求自然要比提升用户体验的功能点更加重要。
3）
C端需求从下到上，发掘每个典型目标用户的核心痛点，由点到面向上满足整个产品的用户体验需求。
B端需求从上到下，需要优先深入相关的业务操作场景，先满足业务场景的可用性需求，再满足业务场景下具体的操作体验
4）B端产品定位清晰，哪怕是在引入期的产品，MVP模式也可以明确产品定位，当前产品是为什么类型的客户角色，提供什么样的支持服务，因此需求不确定性较弱。
之所以在同一个市场上，明明都是为了解决某个特定业务场景下的痛点，但很多公司却提供不同的解决方案，产品创意五花八门，其中很大一部分原因，也是因为公司自身规划和资源、以及对客观业务场景理解程度的不同。
二、B端需求规划模型
根据两者的相同点和差异性，在原先C端思路的基础上，整理了B端的需求规划思路模型，既避免重复造轮子，又可以根据不同特性和需求快速运用。
由于B端产品的行业特性，在进行需求划分之前需要对需求进行顶层思考，通过对产品所在行业、产业发展以及外界环境进行综合判断，已最大程度降低外部环境对产品的影响。
比如最近受疫情影响，各大企业服务商借势营销自家OA，如钉钉、企业微信、华为云等，均大力推广自己产品在远程协作中可以提供的解决方案以及客户价值。
因此在此阶段，如果公司有产品近期的运营规划，就需要重点思考协同OA在远程办公的核心场景中，可以提供的价值点，进而筛选出符合当下产品规划的需求。
三、如何快速运用
顶层思考：
PEST分析：因B端产品规划通常受外界市场、经济环境影响，可通过对当前需求进行宏观分析，从政治、经济、社会、技术等方面宏观判断需求的可行性；
产业环境：了解产品所属行业发展状况，当前需求能否支撑产品在相关产业上下游发挥更大的价值；
产品定位：明确产品的目标客户群体，以及需要解决的核心业务场景；
供给侧需求：充分了解B端产品行业的供给侧状况，如目标客户群体中，大部分中小企业当前的痛点是利用邮箱发公告、或收集员工工作成果效率太低，那么在规划产品需求时，就需要针对这个痛点着重规划相关需求。
1. 需求定位
明确需求是来自软件的操作使用者还是采购决策者，这一点很重要，不同于C端，C端是个体行为，通常只要满足用户自身的需求就会买单。
但是B端是群体在特定业务场景下的行为，而且使用者和决策者通常不是同一个群体，所以满足采购决策者的业务需求和痛点，是B端需求优先级规划的重点。
其次是基础判断，识别该需求是否未开发，即真实的有效需求，然后判断该需求属于前台需求还是后台需求，将该需求放到具体的频道或模块下去思考要不要做。
2. 需求价值
B端需求来自业务场景，因此也应该在具体的业务场景中产生价值，考虑是否是简化了业务流程上的操作步骤，还是可以产生一个颠覆式的解决方案，两种价值在需求优先级上自然不同；
同时可以围绕整体产品生命周期来判断这个需求的价值，把当前需求放到客户业务场景或使用流程上，是想要完善体验来提升工作效率、降低企业运营成本，还是要开发一个高级功能模块转化付费来增加产品收益；
3. 可行性判断
经过上述判断，当该需求既吻合产品规划，又对当前产品有价值，那么就要思考可行性；
通过对比市场去判断当前需求的竞争力和投入产出比，同时判断这个需求如果开发上线后，有多大的影响面，可对多少客户产生极大价值。
因为B端产品需求通常是在真实业务场景下产生的，因此还应该重视“客户反馈次数”，客户反馈的次数越密集，说明该需求在其业务场景中越需要解决。
4. 需求分类
确定可行性后，就要对筛选出来的可行需求进行优先级排序，这个层级与C端产品类似。
可先将需求分类，如紧急BUG解决、功能体验完善、新增亮点、未来规划，分别对应KANO模型中的必备、期望、兴奋、无差异、反向，最后结合重要程度判断优先级，同时为保证客观准确，可针对同一级别、同一类型的需求进行打分，再次细分需求优先级。
5. 需求级别
判断出优先级后，就需要分别给需求进行标注级别，提供两种需求级别：P0-P3，P1-P10。
常规优先级级别是P0-P3，但是在目前实际操作中需求清单中需求太多，需求级别太少无法将需求分层细化，故采用了P1-P10，但是缺点也比较明显，优先级层级较多时，就会导致越靠后的优先级定义越模糊。
需求优先级没有清晰的定义，在具体执行时就比较费劲，因此建议可以采用优先级别较少的方法，如统一级别的需求较多，还可以按照以上方法再次分解。
四、总结
运用产品管理的思路，需求规划的本质其实也就是需求资源配置的过程，通过需求组合管理，合理配置资源和平衡市场机会，从而实现产品商业价值最大化。
B端产品需求较多，因此更加需要通过需求管道来过滤和筛选，确定正确的需求数量，已达到业务需求和可用资源的最大平衡。
再直白一些，需求优先级组合就是对软件需求的轻重缓急+价值组合，搞明白轻重缓急，可以充分利用市场环境和内部资源，至于价值，那就是当产品经理在经过缜密的需求组合之后，能否利用产品机会为公司、客户产生短期或长期价值。
