全链路产品方案设计，一定要做好供给分析

本文介绍笔者做供给分析时，采用的四个判断，希望能给你带来启发与思考。enjoy~

在依赖供给的业务场景下，PM做产品方案之初必须要充分对是否依赖供给，供给是否能够获取以及如何获取进行判断实验。单纯地认为供给一定存在势必会在项目启动后给项目的进展带来一定程度的麻烦，如果真的无法取得供给，项目也会因此必须关闭，造成资源浪费。

我在进行供给分析时，目前采用如下的四个判断。如果有更好的方法，欢迎大家在评论区告诉我们。

判断1：项目是否依赖供给？

依赖供给的业务中也存在并不受供给影响或者影响供给的项目，如果本身不依赖供给，接下来的判断就没有必要进行下去了。

但从我之前的工作看，在O2O这样的业务中，包括用户体验产品在内，大多数的项目都不容易和供给完全脱钩，真的感觉完全脱钩了，也要想想是不是虽然不依赖供给但是会影响供给，更要想想是不是自己在项目方案设计中忽略了什么？然后再做谨慎的判断。

判断2：供给是否可以有除了采购以外的快速获取方式？

在确认项目需要依赖供给时，需要认真考虑，项目所依赖的供给可以从哪些渠道获得？

除了常规的商务手段覆盖谈判外，需要充分的思考是否可以通过运营和产品手段创造所需要的供给，这种供给是否可以长期存在？是否会伤害上下游中某些角色的利益？

如果可以创造但会伤害B端其他角色的利益 （比如私自的通过出让毛利造低于商家价格体系管理要求的XX专享产品，破坏了商家的价格体系），那么这种供给只可以用在需求验证的阶段，验证后仍需要通过覆盖、招商的办法去获取供给。在验证供给获取的可得性之前，不可轻率的扩量，否则会因为损害B端利益而遭到较大规模的反对，从而使项目无法顺利开展。

如果可以创造供给且不会对B端其他角色产生影响 （比如提供“0押金信用住”，前期可以由公司承担押金垫付，并不会对B端造成影响），则可以在验证需求之后，边扩大范围边判断是否需要通过覆盖去替代已有的供给方式（押金的垫付会对公司的资金状况产生影响，已经验证信用为前提的免押金，产生的损失可控并可以带来明显收益，这时就可以逐步的切换供给来源）。

如果没有办法创造， 就需要充分地考虑在哪儿试，要尽可能的缩小范围，在小范围内充分覆盖满足用户供给，然后验证用户需求，再通过已经验证的小范围的结果，逐步的进行扩张。

判断3：重点先验证需求还是先验证供给可得？

在这个问题上，需要对供给的可得性先有一个基本的判断，供给是不是容易取得的？推动BD取得供给的前提和阻力在哪儿？

但无论如何我都建议，要先和BD以及B端供应商有充分的实质的接触，这是判断供给可得性关键的必要前提，否则任何的判断都可能是不准确的，那么结论也就无法被相信。

如果经过接触，发现获得供给的主要因素在于推动BD覆盖采购，而对于商家来说提供供给难度不大甚至多家供应商都表示出了不错的积极性，那么验证用户需求的优先级和重要程度就会高于验证供给可得。验证了用户需求确实存在后，拿着需求的验证结果和流量数据以及流量可以为BD带来的业绩结果预测去推动BD采购覆盖。

这里，我主张通过利益驱动合作伙伴（BD）而非通过组织内部的管理推动，前者事半功倍，后者事倍功半，而且在没有验证收益前贸然通过管理手段推动BD，可能会指错地儿，让组织和BD都承受损失。

如果判断认为供给可得性存疑，那么供给可得性验证就是项目中优先级最高的部分，需要如上文中所说，和BD团队共同确认实验范围，小范围重点覆盖，确认是否可以拿到足够供给，再来验证需求是否存在。

在没有明确需求下拿供给，势必存在商家积极性问题，需尝试通过适当的优待政策来鼓励商家并逐一的进行谈判。有流量后的覆盖难度会逐步降低。

如果初期在给予优待政策下，仍然无法获得足够供给，就需要认真思考项目中是否损害了B端利益以及认真调研B端的反对意见并先加以解决。

判断4：扩量前供给可得性是否被充分验证了？

这个问题是需要充分考虑的，在做判断四之前，通常在某个区域中的实验已经得到了预想成果。但在扩量前，必须要对现在的供给进行充分的审视——

确认清楚现在的B端是否拿到了收益，还是因为其他原因（比如为了和公司合作，出于其他考虑选择配合而非真的获得收益）。拿到了结果的B端有哪些特点是不是在更大的规模内可以找到？

在判断清楚了供给在线的情况以及收益后，认真地建立标杆，然后再开始逐步的向其他区域进行推广。

以上是我的方法的框架，还有很多不成熟的地方，我会逐步的进行补充。

你有什么更好的方法呀？快来和我们分享吧！

 

作者：倪老大；美团资深产品经理

本文由 @倪老大  原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议