Ｂ端产品需求的3个层次，你都了解吗？
作为一个B端产品经理，
日常工作中，“需求”一词，可能是我们听到过和说过频次相对比较高的词语了。
比如，
1.假设你刚进入一家做企业服务的Sass公司，领导告诉你，公司产品要解决的业务问题是帮助中小餐饮企业解决引流、转化、私域流量运营等相关的问题，最终助力中小企业业绩增长，做好生意。
2.你在和餐饮门店经理交谈业务问题的过程中，他希望当用户进入商城以后，可以增加商品曝光的次数，以此提高用户的购买转化。
3.根据第3点，你梳理并将需求进一步拆解，得出：可以在商品详情页、支付成功页、订单页面等相关页面增加智能推送合适的页面。
以上提到的3点都属于需求吗？
是的，都属于需求。
不过，
它们分别属于需求的3种不同层次。
3种不同层次的需求分别是：
1.战略性需求
2.用户需求
3.产品需求
这种需求的划分方式很大程度上代表了需求工作的3个不同阶段，通过对需求3种不同层次思维模型的理解、运用，会对需求工作带来很大的帮助（我亲自运用过，用起来非常有用）。
接下来，
我将一个一个的详细说明。
01
战略需求
战略需求是指软件系统的北极星指标，也就是设计、开发软件的目标是为了什么。
战略需求是软件设计、开发的原点，是指导软件往下设计和开发的最高层次需求。
如何发现战略需求？
可以从客户现状与理想状态之间的落差角度来发现战略需求，战略需求来源于落差。
比如客户现在一年赚1个亿，明年希望2个亿，那么现在和明年之间就有了1个亿的落差。
如何增加营收一个亿，这就是客户的战略需求。
在具体落地找软件战略需求的过程中，不同的软件类型有不同的思考方法。
这里，我把B端软件主要分为两种：
1.项目型软件，也就是开发出来软件只是给一个企业使用的；
2.产品型软件，也就是开发出来的软件是给多个企业使用的。
项目型软件找战略需求的过程，一般是来源于公司老板或者是高管在参观、考察行业相关企业、竞争对手分析、学习行业内标杆企业、参考其它行业等的时候结合公司自己的业务提出来的需求。
比如：
假设，你是在一家提供体检业务服务的连锁门店做产品经理，门店现在的工作流程是全手工状态，靠每个门店的负责人来管理，没有办法保证每个岗位都按标准化流程来执行任务。
未来几年内，老板的期望会把企业做大，开更多的门店服务用户，有一次老板参观了一家标杆连锁医院后，发现医院通过信息化系统解决了病人就医流程固化的事情。
于是，老板回公司后告诉你，现在想要开发一套信息化系统，把体检业务流程进行固化，为以后开更多的门店，奠定基础。
“开发一套信息化系统，把体检业务流程进行固化”，这就是老板通过参观、考察行业内标杆企业以后，向你提出的战略需求。
产品型软件找战略需求的过程，就复杂了许多。
1.首先要考虑外部大环境（政治、经济、技术、社会等）各方面的变化对公司要服务的行业的影响；
2.以及有哪些通用的业务问题，可以让提供Saas服务的公司来解决；
3.在商业的战场上，通过对竞争对手、自己、客户的分析，能不能找到独特的价值点来规避竞争。
找到的这个“独特的价值点”，就是战略需求，也可以叫产品的价值主张或者是战略指导方针。
想了解更多如何梳理战略指导方针相关的细节问题，可以参考我之前的文章《To B业务如何进行战略梳理？》。
02
用户需求
用户需求，就是在战略需求指导的基础上，用户提出的，希望使用软件完成什么任务的需求。
通常来讲，用户的需求，需要我们通过各种方式主动去挖掘获取。
获取用户需求的方法有很多，
比如：
1.通过用户访谈的形式获取需求，
访谈一线工作人员、部门负责人、高管及老板等相关角色，访谈用户的工作流、用户关注点、用户希望使用软件来解决什么问题以及会担心使用带来什么样的负面影响。
2.通过用户调查的方式获取需求，
当软件服务的企业、服务的角色过多时，产品经理不太可能每一家服务的企业都面对面，一个角色一个角色的去做用户访谈，这个时候，可以通过用户调查的方式去获取需求。
3.通过观察的方式获取需求，
可以深入企业一线，去当学徒，去参与实际操作与观察来获取需求。
4.通过会议沟通的方式来获取需求，
和部门相关成员会议沟通、和各部门老大及高管会议沟通，通过沟通获取完整需求与确定需求。
5.通过可行性测试分析来获取需求，
有的需求，用户可能并不知道他有这个需求，这时可以做个小的MVP，做可行性测试分析。
6.通过竞品分析的方式来获取需求，
通过分析行业的领先者和先行者，或者是直接或间接的潜在对手，分析产品形态相似的产品。
在竞品分析中，可以分析竞品的功能结构图、信息结构图、业务流程设计、业务场景分析、用户群体细分等方式来获取需求。
以上6种，
一般情况下，根据我的经验来看，1、3、6用户获取需求方法最常用。
不过，
不管通过什么方法，最终我们获取到的用户需求，可能会来自于不同部门、不同角色、不同颗粒度且零散的需求。
这时就需要对需求进行整合、分析、归类，进入下一步软件需求工作环节。
这里做一个补充，
有时候，我们通过用户访谈，用户可能会提出一个解决方案式的需求。
这时我们需要引导用户说明问题，说明要解决什么业务问题，为什么要做这个东西？
而不是说解决方案。
我们要自信，能选择最佳解决方案的是我们产品经理，被访谈的用户代表需要做的是把问题说清楚。
因此在收集需求时，经常要问为什么，才能找到真正的用户需求。
比如，
有一家做电商Saas的公司，产品经理在做用户访谈的过程中，用户告诉产品经理，他想要在消费者下单支付成功的页面推荐近期销量不错的商品。
一般的小白产品经理可能会把这个需求画出来，然后就交给技术开发了。
然而，资深一点的产品经理，面对这个解决方案式的需求，就会进一步往下问用户，为什么像这样做，想解决什么问题呢？
用户可能会回答：可以增加商品曝光的次数，以此提高用户的购买转化。
你看，
这才是用户的真实需求，围绕此需求，产品经理才能给出更合适的解决方案。
03
软件需求
在用户需求环节讲到，
不管通过什么方法，最终我们获取到的用户需求，可能会来自于不同部门、不同角色、不同颗粒度、且零散的需求。
这时就需要对需求进行整合、分析、归类，进入下一步软件需求工作环节。
软件需求主要分为2种，功能性需求和非功能性需求。
第一种，功能性需求，
在梳理功能型需求时，大概的一个梳理思路如下图：
首先我们会把获取回来的用户需求，合在一起形成需求集；
然后根据业务流程的梳理与分析，业务场景的梳理与分析，把需求归类到不同类别的需求集里面去（业务流程的梳理与分析，业务场景的梳理与分析方法，这里我就不细讲，下次我会重新写一篇文章来进行深度讲解）；
根据需求形成功能模块，然后完成功能架构的搭建；
根据搭建好的功能架构，拆分功能单元；
接着根据拆分的功能单元，拆解出功能单元包含的信息元素；
再将信息元素汇集 ，形成信息架构图；
最后就可以进入原型设计阶段了。
第二种，非功能性需求，
一般情况下，很多产品经理，容易把这部分内容给忽略掉，要想打造出一个吸引人的产品，非功能性需求也是我们要特别注意的点。
非功能性需求是一个系统的特征，获得非功能性需求的方法是访谈客户对系统的期望是什么。
以下非功能性需求清单，
该清单来自于国际标准组织，该组织在2011年发布ISO/IEC25010软件质量模型：
当然，
上面这张图并不是说所有的软件都要有图中的所有非功能性需求，这只是提供一个挖掘非功能性需求的参考。
具体还需根据每家软件的需要来确定非功能性需求。
最后，
我相信：通过以上3种不同层次需求的整体理解与运用，
产品经理在获取需求、分析需求，听到需求相关的各种概念以及进行产品落地设计时，
会做到心中有数，不慌不乱，高效产出结果。