精益创业就是通过不断地尝试在真实世界中验证产品想法，其中一个重要的实践是最小可行产品（Minimum Viable Product，MVP），我们这次就把这个实践展开讨论一下。
什么叫最小可行产品？就是“刚刚好”满足客户需求的产品。客户需求好理解，怎么算“刚刚好”呢？其中的关键在于理解“最小”和“可行”。
最小代价
首先，我们必须清楚一件事，我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。
第一步，我们要验证这样一个想法是否可行。我们做了一个产品文档，就好像我们已经有了这个产品一样，让负责销售的同事拿着这个文档给客户讲讲，看看客户对这个想法的反映。
验证了方向上的想法，我们开始进入到具体的产品设计阶段。这个阶段我们想验证的是，我们给出的产品设计用户是否可以接受。于是，我们决定把这个产品的交互做出来。
得益于原型工具的快速发展，我们用一个原型工具做出了相对完整的用户界面，而且把各种交互流都做出来了。在用户看来，这几乎就是完整的软件了。
经过多轮测试下来，团队有了一大堆的用户反馈，而且是来自真实用户的反馈。接下来，就是整理这些用户反馈，决定哪些可以真正的开发出来，这时候，团队才真正进入到开发阶段。
不知道你注意到了没有，迄今为止，这个团队验证了一大堆的想法，而代码却是一行都没有写，所有花费的工作量都是有针对性的验证。
开发软件是一件成本很高的事情。如果只是验证想法，无论是创业方向，还是产品设计，我们可以找到各种各样的手段，不用写代码。
可行路径
但从产品可行的角度，我们需要转换一下思路，不是一个模块做得有多完整，而一条用户路径是否通畅。
于是，我们做了一个决定，第一个版本只包含贷款能力。是的，这个版本只能贷款，不能还款。因为用户一个月之内不会用到这个功能，你从页面上，完全看不出这样的能力缺失，因为一个月内，根本没有任何用户有可还的款项。
就这样，几个月之后，我们就逐步上线了一个功能相对完整的 P2P 平台。在这个过程中，我们每个阶段都会上线新功能，从用户可见的角度，他看到的始终是一个完整的平台，其中的变化只有站在内部实现者的角度才能看得清楚。
和大家分享这个例子，主要是想破除大家对于一个“完整”系统概念的认识。当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡。
站在开发团队的角度，我们怎样把 MVP 理念运用在自己的工作中呢？当产品经理有一大堆要实现的功能时，我们就可以根据 MVP 理念，从这些产品功能中找出一条最小的可行路径，重新安排一个合理的开发计划。
产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。最小可行产品就是“刚刚好”满足客户需求的产品。
想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。最小的代价就是能不做的事就不做，能简化的事情就简化。
网友评论