定义最小可行产品 (MVP) 和创业流程：假设驱动开发

现代持续交付方法要求使用假设而非需求来交付客户想要的产品。初创公司和开发者应该从一开始就拥抱持续的实验和调整。因此，我思考并研究了最小可行产品（MVP），并尽可能地将其记录下来，作为我对MVP流程或初创公司流程最贴切的定义。

首先，你应该有一个假设。你开发产品并非仅仅因为你能做到，而是要知道开发什么才是正确的，我的客户真正关心的是什么。此外，还要力求提出一个严谨、可衡量、清晰明确的假设。

然后你想搭建这个模型，理想情况下，你想搭建一个能够反驳该假设的最小模型；如果做不到，那就继续，然后你需要测量它，因为如果你不测量，就无法证明或反驳某件事。

一旦你开始测量，你就可以开始学习和迭代；随着迭代的进行，你将在第一阶段的基础上进行构建或修改。你可以看到，构建、测量、迭代是一个持续的过程，你会不断地循环往复。虽然上图末尾有一个刻度，但最好将其也视为构建、测量、迭代阶段的一部分，它们之间并没有真正的区别。

想想你想要达成的目标是否清晰，因为当你想要衡量某件事时，你需要的是一个单一且符合你目标的指标。我跟很多创业公司交流过，但当我问他们他们的产品/服务有什么优势时，他们往往会列出一长串清单。所以，最好是从一个非常清晰且单一的使命开始，一个你能为客户提供的、简洁明了的服务。

你要确保它是可衡量的。如果无法衡量，你就无法知道自己是否达到了目标指标，你可能也不知道应该达到的正确数值是多少，但你至少需要一个衡量标准来了解自己所处的相对位置。

假设对于你构建业务框架至关重要。

M{x}P

MVP 代表最小可行产品，它是你构建的第一个产品，也是帮助你的初创公司度过产品市场匹配阶段的产品。它不是原型，所以不要与原型混淆。原型是你为了验证你的想法是否可行而创建的，例如硬件创意，或者帮助你找到用户体验的最佳路径，让用户了解他们如何使用你的 Web 应用或移动应用。或者只是为了获得一个可视化的界面，让人们看到你想要构建的东西。因此，MVP 不是原型，在某些情况下，你会在构建 MVP 之前构建原型，或者你可能会同时拥有 MVP 和原型，以便进行一些额外的测试。

这是验证假设所需的最小功能数量，这一点非常重要，因为很多人都会过度开发他们的最小可行产品（MVP）。这种情况非常普遍，尤其是在那些从未接触过软件开发团队或从未在软件开发团队工作过的人当中，过度开发的情况更为常见。过度开发指的是开发的功能超出了验证假设所需的范围。

如果要举一个MVP的好例子，我们以Lyft为例。Lyft最初发布产品时想要解决什么问题？他们想验证点对点交通模式是否可行。因此，他们验证假设所需的最少功能是：

1. 司机可以注册并登录。
2. 骑手可以登录和注册。
3. 乘客可以请求司机，司机也可以找到该乘客。
4. 双方之间可以交换的一种支付方式，双方可以从中抽取各自的份额。

以上就是所有基本功能，不包括 Lyft 现在提供的所有功能，例如在社交媒体上分享行程、添加停靠点或数百种其他功能。如果他们在 MVP 版本中就包含这些功能，那就属于过度开发了。

还有其他类型或术语也指代最小可行产品：

可行：这是最常被提及的，它是一个全新的产品，用于测试产品的新维度。

可用性：最小可用产品是指将产品交付给客户，确保其可用性并获得早期反馈。

令人喜爱：如果你推出的是一款“最低限度令人喜爱”的产品，那就意味着你假定市场上现有的产品不受顾客欢迎。你推出这款产品，实际上是在说：我认为我能做得比某个竞争对手更好，原因如下。

可测试性：最小可测试产品适用于风险较高的商业假设，例如 Airbnb 或 Lyft。

“如果你对自己的产品第一版不感到羞愧，那就说明你发布得太晚了。”
——里德·霍夫曼，LinkedIn联合创始人

记住，它应该非常简洁，用户界面或用户体验的外观并不重要。它只需要功能齐全，因为你的目标是用最少的功能来验证一个假设。

我见过很多创业者都是完美主义者（我自己也是），但你不应该等到产品完美无缺才发布，而应该等到它至少在基本状态下功能齐全、实用之后再发布，让用户试用，看看他们是否真的喜欢。因为如果他们需要它，想要它，他们根本不会在意它的外观或美观程度。他们会立刻开始使用。有多少人真正关心 Lyft 的外观？很少有人会在意，因为当你需要用车时，你只需要用车。你为什么要关心它有没有一个叫车按钮？有没有支付司机费用的方式？很好，一切就绪。

所以，如果你是个完美主义者，团队里有人在你还没准备好之前就催促你发布产品，这其实是件好事。

让我们来看看你是如何构思你的假设或最小可行产品（MVP）的。你可以想象一个产品金字塔或堆叠结构，这就是你最终想要达到的效果。你希望所有功能都已实现，全部可用、有价值、可靠，当然还要可扩展，并为用户带来绝佳的用户体验。

我花了很多时间和那些尝试构建最小可行产品（MVP）的人在一起，我们都试图从中汲取灵感，逐步完善。如果你是设计师，很有可能从零开始，打造出一个非常漂亮的MVP；如果你是拥有基础设施背景的工程师，你会打造出一个极具可扩展性的产品；如果你是站点可靠性工程师，你的产品将非常可靠；如果你是业务人员，并且能够正确地提出商业价值主张，那么你的产品将非常有价值；如果你是应用工程师，你会打造出一个真正易用的产品。

但问题是我应该选择哪一个？最简单的解释是，如果你专注于其中一个，就不要把范围扩大得太广。

实际上，你需要面面俱到。所以，你可以这样理解：你的最小可行产品（MVP）需要涵盖所有方面中的某一部分，因此，思考构建这个最小可行产品所需的最小功能是什么至关重要。

产品演进

MVP 显然不是一个面向客户的术语，而你的第一批客户将是你的早期采用者，你的产品仍然需要改进。

如果我们想解决人们的交通出行问题，我们可以从滑板开始，然后是滑板车，再逐步增加更复杂的功能。这就是为什么最小可行产品（MVP）应该非常基础，它不应该只是车轮或轮胎，而且在真正拥有汽车之前不应该发布。那样就属于过度设计了。

不要被超出你研究范围的功能分散注意力，也不要被那些不能从根本上证明你的假设的事情分散注意力。

最好是拥有一个流畅且随着发展不断完善的方案。每个阶段都可以被视为一个产品。如果你在第一阶段制造轮子，第二阶段制造引擎，最终得到的却毫无用处。而在这里，我可以在第一个阶段就实现从A点到B点的转变（从滑板到自行车再到汽车），我仍然可以实现你想要的目标，将你的愿景从一个地方带到另一个地方，而且随着时间的推移，它会变得越来越好，每个阶段都仍然是一个最小可行产品。