怎样用最小可行性产品验证市场需求？

嘿，你听过MVP吗？这是一个超级酷的概念！简单来说，就是通过最小的代价来验证你的产品需求是否真实存在。

举个例子，如果你想做一个电商网站，那么你只需要在最初的阶段开发核心商品和支付功能，其他的内容可以什么都不做。

这样做的好处是，首先可以快速验证市场需求，看看用户是否真的需要你的产品；其次，可以节省成本，因为你只需要花费最少的时间和资源来上传核心产品和建立网站。

但是，实际上很多人都会本末倒置。比如我的一个朋友，去年想做一个外贸B2B询盘站点，卖泉州的鞋服。我建议他只做一个单页，并在上面加上询盘表单，服务器都不需要购买。然后，用精准流量测试单页的转化率，收集第一手数据。如果反馈还可以，再花大成本去建网站并快速迭代。

可是，这位朋友好像不太听我的建议，花了大价钱购置了网站基础设施，还请了第三方代运营公司去帮他建站，产品罗列了一大堆，浪费了一个多月的时间和精力。

我并不知道最后的结果如何，但最近看到他在朋友圈发了一条说生意不好做的消息。

用最小可行性产品验证市场需求

这只是一个例子，但事实上，我们身边很多人都会犯这样的错误。他们一开始只是凭空臆想一个需求（或者是自己有一家工厂），然后想当然地认为自己的产品能完美解决用户需求，最后在没有充分调研的情况下，大干快上。

当然，大干快上并没有错，但在此之前，你必须要搞清楚几个问题：你是怎么发现用户需求的？你发现的用户需求是否真实存在？你如何验证用户需求的真实性？你的产品真的能够满足用户的需求吗？你又如何验证你的产品能否满足用户需求呢？

这些问题其实并不难，但需要有数据支撑，需要形成一个逻辑闭环。这也是我推荐MVP理论的原因。

最近我看到了一个有趣的新视角，叫做最大可行性产品，与最小可行性产品相对。最小可行性产品在迭代时往往会不自觉地增加功能，导致产品变得臃肿。

因此，最大可行性产品提出了一个新的观点，即在产品所服务的场景中设置最大边界，并不断聚焦于核心功能的打磨。

这就是对产品功能开发的一种克制，以确保后续的功能都围绕核心需求展开，并将团队精力聚焦在核心功能上。当然，这种“大处着眼，小处着手”的方法对整个团队的能力要求非常高。