产品经理的核心职责之一是对需求进行评估和决策，这不仅需要理论知识，更需要结合实际业务场景的敏锐洞察力。本文通过一个实战案例，详细展示了产品经理在面对需求时如何从技术可行性、业务可行性和投入产出比等多个维度进行全面评估。

产品经理如何进行需求分析？这是初/中/高级产品经理都需要面对的问题。知乎和公众号上面有很多的文章都在分享，这里不再展开。

这些文章里面大多都会介绍诸如马斯洛需求层次理论、卡诺Kano模型、四象限法则、PESTEL分析模型、波特五力以及SWOT等等的工具和方法论。

这些工具和方法论诚然都很不错，但就像“我们听说过无数的道理，却仍旧过不好这一生”，我们在分析具体问题的时候可能还是会感觉无从下手。

这里我通过一个案例，提供另外一种思路，供参考。

某食材B2B电商平台，运营为了提升销售额便制定了某营销活动，顾客采购满10万元可获赠X元商品，采购满20万元可获赠Y元商品，但门店客户冰柜/仓库太小又堆不下这么多的货，于是运营给产品提需求：客户购买的商品可以每月送XX件着送XX个月。

产品经理如果不接这个需求，那么运营人员KPI完成不了就可以用系统不支持名正言顺的甩锅给产品（很多公司都存在这种情况）。但如果要接的话，产品经理又该怎么来评估这个需求呢？

1.技术可行性

之前ERP和WMS是根据门店客户订单中的采购数量来进行的出库拣货发货凭证生成等，现在如果要做分次分批发货，则需要门店客户在订货端自己创建并生成要货计划，然后电商平台将此要货计划下推到ERP和WMS。之前是根据订单下推发货，现在是根据要货单下推发货，技术上是可行的。

虽然技术上是可行的，但做起来并不轻松。门店可能会在首次下单时要求先送XX件，后面的再根据要货单送货。也可能首次下单时不要求配送，后面需要的时候再配送。这2种场景都会有，都要设计规划相应的流程。

也不能限制或要求门店首次下单时不能要货，引导或者要求其订单支付后再通过要货单来要货，这种方式对于强势的平台可以，对于很多中小平台是推行不下去的。

2.业务可行性

很多技术上可行的功能或者需求，业务上并不一定可行。很多需求的多个使用部门或角色，他们的关注点或者需求点也可能是截然相反的。

举例说明。早些年我在某公司做在线客服系统产品规划时，客服部门要求可以在工作台上显示当前系统还有多少问题待处理，这样员工就可以松弛有度自己掌握回复节奏。管理部门则要求不显示该数字，这样客服员工就不知道还有多少问题堆积只需要埋头默默处理问题即可。

不同的岗位角色，不同的部门，在面对同一个事项的时候，可能会有截然不同的想法。很多传统公司内部搞信息化建设，上各种系统和功能，但实际推行的都不太好。

管理层是希望通过信息化的手段和工具降本增效，但每个功能或系统实施初期，都会打破部门岗位角色原有的舒适区，都会对他们已有的路径依赖造成冲击，进而本能的采取一些不配合甚至抵制的情况。

本文所述的这个问题同理，多次发货对于仓储而言影响了库存周转率，对于物流而言增加了组单拣货发货的次数提高了成本。

这时就需要评估并测算多次发货带来的销售额或利润增量，能否覆盖掉新增加的仓储和物流配送成本，如果不能则卖的越多公司亏得越多。

3.投入产出比

评估这个投入产出比的时候，需要站在以下几个角度来全面分析其产出比。

• 技术层面：该功能需要产品梳理完整的业务流程，需要整理出相关的功能点并设计出页面原型，同时还要能识别出关联的业务影响点，然后开发测试需要评估整体的工作量人天。
• 用户层面：虽然用户大多都有淘宝京东拼多多的购物经历，但1次购买多次发货且每次发货的时候需要选择发哪些商品，这个操作门槛对用户而言是有些高的，用户教育成本略高。同时客户还会有多次收货(自提)的情况，这个运费公司承担还是客户承担，或者按比例分摊，亦或者公司补贴部分？
• 仓储物流：上文说过多次发货会影响到公司的库存周转率，会增加仓储的拣货发货操作成本，同时也会影响供应链整体的效率。
• 资金风险：按照我国的会计准则，确认收入的节点是商品货权的转移即客户确认收货后才能确认营业收入，之前是一次性确认了收入例如12000元（最差30天内总能确认这部分收入），现在则可能会变成1-12月每个月确认1000元的收入，这极不利于公司的现金流管理，也不方便财务做账务处理和税筹规划。而且这里面还有资金成本，10个月前的1万元和现在的1万元，这里面就有资金现值和终值的计算，此处不展开。
• 采购风险：我国全国居民消费价格指数CPI基本上每月都有个位数的涨幅，有些商品的价格涨幅可能更大，如果客户预见到了某个商品比如猪肉在未来的几个月内会持续涨价，那么其势必会大量囤货，把原材料上涨的经营风险转嫁给了平台，因为有订单存在平台无法毁约，只能打碎了牙自己吞下去。

上面都是定性的投入产出比分析，如果要精确评估，可以针对每个细项进行测算然后再进行整体的评估。

有了上述3个部分的推演，业务部门可能自己就会把这个需求否定掉了，根本都用不到那些需求分析的工具和方法论。