B端产品经理的需求分析进阶之道

沈这 2024-08-22 20:21:30

“产品经理收到用户需求的第一时间应该做什么？”

记得这个问题还是10年前我的领导问我的，那么10年了，我们收到需求之后到底怎么做才是相对比较成熟的产品的做法呢？

相信最开始做产品的我们，在第一步往往是直接思考业务的需求能不能做？怎么做，不好实现的或者没有思路的还会去“参考”竞品，负责的产品还会抄袭几个设计方案让业务选择，非常专注和热衷的往往是怎么设计，原型，按钮，文档，并且心里暗自窃喜：又完成了一个需求。

那么换一个思路，多少产品会深入业务实际本质思考，这些需求实现了是不是能解决业务的问题，业务的问题到底是不是这个问题，解决方案只有这一种吗？

不做，有没有别的方式可以解决业务的需求。直接不分析就开始做的做法虽然简单，但是大多数情况是不能解决或者不能彻底解决业务的问题的，带来的产品后果往往是迭代返工，甚至产品重构。

那为什么会发生这种情况呢？主要是业务对产品的理解往往是局部的，片面的，仅仅知道和熟悉自己经常使用的功能，别的功能都是盲区，业务的需求和思考往往不成体系，流程也是区间的流程，并不是上下游完整的全流程，假设我们不深入本质分析，那么我们对需求的本质并没有理解，在不理解需求本质的情况下去做产品设计，结果可想而知。

如何深入实际，深刻的理解业务本质并且将产品设计的细节渗透到业务的本质问题上面去呢？今天跟大家分享一下个人的一点思考和总结。

第一步：掌握业务本质，剖析需求价值

当我们收到业务提出的需求时，初级产品往往直奔主题，恨不得马上就设计出原型和文档，马上拉开发评审，即刻上线。而一款糟糕的B端产品就是这么一步一步积累下来了“病根”，稳妥的做法是什么呢？成熟的B端产品不着急问业务做什么，怎么做？而是先分析需求的本质，比如可以先通过提问的方式分析本质，以下4个方面的问题可以参考：

1. 了解背景

哪些用户？在什么场景下？遇到了什么困难、问题或者不方便？影响多少人？影响多少业务金额？情况发生的频率如何？

2. 优先解决实际问题

目前是怎么解决这些问题的？试图帮助业务通过别的方式解决问题。

3. 了解用户期望

询问业务期望通过什么方案解决？是否有建议的解决方案？通过业务实践的现象了解实际业务本质，通过本质设计解决方案。

4. 分析需求价值

任何需求都有它对应的价值，当然也有对应的投入。投入产出比是衡量一个需求价值的指标。最明显的就是需求实现之前和实现之后的对比。也就是实现之后对比实现之前带来了哪些效率的提升，成本的降低，风险的规避或是收入的增加。

第二步：需求做不做？问题总要解决

这个需求要不要做不是最重要的，最重要的是业务的实践问题要解决，如果需求要做，要怎么做？不做，业务遇到的困难怎么办？

我们作为B端产品，是要和业务一起去实现业务的成功实践的，没有帮业务解决问题，那我们的产品就就失去了价值，同时也失去了【产品经理】这个职位赋予的价值。带着第一步的问题和答案，我们可以深入到业务的场景中分析其价值，从而得到要不要做的结论。

不管需求做不做，业务实践遇到的问题要解决，假设有“不战而屈人之兵”的方法，那是最好的解决方案，不动“一兵一卒”就解决了业务的问题。大家都知道B端的产品，不管是自研还是购买，一旦有需求要做，必然会产生对应的研发费用，如果做得需求不能给业务带来实践价值，那么投入的研发成本就成了亏本的生意，如果这种亏本的功能做的太多了，不仅业务效率未能提升，而且还白白支出了产研费用，最终受损的还是公司的利益，我们都知道，做企业不是做慈善，企业存在的意义就是为股东谋取盈利，企业背后的资本也是逐利的，一款有价值的B端产品一定是企业盈利的加速器。

第三步：需求怎么做？投入产出最大化

规模小的B端产品往往用户体量小，功能单一，产品设计的发挥空间往往很大，而复杂的B端系统，为了降低用户的学习产成本，提高研发的效率，往往具有专业的UE和UI团队来统一输出各种交互要求和控件组件，按钮颜色，风格，页面布局，交互样式，交互逻辑往往高度保持统一，产品经理在思考实现方案的时候不能不顾实现成本，一味的满足需求，就像“女人的衣柜里永远缺少一件衣服”一样，在用户的眼里，“我们的产品也永远缺少了一个功能”，缺少就缺少呗，千万不要为了满足而满足，而是要分析投入产出比。

B端功能的投入产出比如何衡量呢？可以从以下两个方面做衡量对比。

第一个方面是投入的成本，这个不管是自研还是外包研发，亦或是采购SAAS服务，可以评估一个相对靠谱的成本，假设成本是1万元。

第二个方面就是产出，产出无非从以下4个方面分析。