MVP（最小可行产品，Minimum Viable Product）是埃里克.莱斯在《精益创业》一书中提出的理念，在互联网公司中被广泛接受并实践。
它的目的主要是验证两件事：
- 一是产品满足用户需求；
- 二是产品能够创造商业价值。
最常见的定义是产品有足够的功能满足早期客户的需求，并为未来的开发提供反馈。但这种说法常被误解，人们通常只做到了前半部分，而忘了后半部分。
MVP不是发布基本功能的堆砌，然后等待下一次迭代，用户的信任是非常脆弱的，一旦就打破，就很难重建。
误解一：MVP只要有基础功能就可以了
很多人的认知里会认为MVP只有实现基础功能就可以了，至于产品存在的BUG、可靠性、易用性等，留到下一个版本慢慢迭代就好了。
这里还是那句话：用户的信任是非常脆弱的，一旦就打破，就很难重建。
如下图模型，是由澳大利亚的设计师Jussi Pasanen提出来的。它非常明确地说明了MVP应该如何定位，并在快速使用户获得产品的同时，不让用户失望。
根据模型可以看出构建最低可行产品的方法是建立一个切片，而不是一次构建一个层。
这个切片既要满足有细分用户，和此用户对应的用户需求，不仅提供产品功能，还要保障产品的可靠性、易用性和体验性。
所以，MVP不是我们理解的只包含一个可以使用的基础功能就可以了，而是需要有用户、有需求、有功能的产品，并且这个产品还得好用。
任何MVP都必须具有一系列为用户提供的价值特征，不然就无法验证其商业价值并持续迭代了。
误解二：MVP的底盘基础是产品功能
产品功能是产品所有价值的底层，但MVP不是。MVP除了是产品，还有一个重要特性：必须是可行的。
可行的意思就是满足用户需求，并且用户乐于使用。所以MVP的金字塔底层是用户，而不是产品功能。
如下图，我们可以看出产品的受众范围越广，其所对应的用户需求和问题就越多，必须构建的功能就越多，产品便会变得越复杂和越难于使用。
所以根据MVP的定义范围，如果我们想快速完成一个MVP，那没有什么比划定用户范围，更能显著地减少开发时间了。
误解三：C端产品的MVP落地方法可以套在B端产品上
下图是一个非常经典的MVP路径图，我们只知道它很简单易懂地说明了MVP的经典路径，但却误以为适合所有的产品研发。
试想一下，如果B端产品按此步骤来进行MVP，那便意味着，每下一个版本的研发都是重构。而B端产品一旦投入市场使用，拥有使用客户之后，重构几乎都是灾难性的。
假如C端产品是建平房小别墅，业主需求更多来源于感性，想怎么来就怎么来。建筑周期也比较短、平、快，架构师调整起来也非常容易。
那么，B端产品就更像是在盖高楼大厦。假如基础没打好，推倒重建就等于毁灭。一旦被客户使用，调整和做减法的难度极大。
所以，B端产品和C端产品的MVP是有很多的不同的。
to C的产品MVP最重要的是验证需求是否存在，商业模式是否成⽴？基于验证需求来实现最简MVP，然后在迭代开发演进，侧重点是用户体验。
to B的产品由于业务以及逻辑都是极其复杂的，所以大多数情况下的to B产品不是为了验证需求是否真的存在，而是让产品以最小的代价、在最短的时间面市，支持客户和业务抢占市场，再让市场用户需求不断驱动研发。
这样不仅可以提高产品与市场的匹配度，更能避免闭门造车出来的产品与客户的实际业务及期望南辕北辙。
不管是B端还是C端产品，其实都是可以进行MVP的，但别忘了MVP产品核心精华：live or die , but quickly.
