> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 最小可行产品

> 最小可行产品（MVP）是指可以发布以测试市场假设的最小产品版本。了解如何构建能够交付价值同时最小化浪费的MVP。

<Info>
  **类别**: 方法<br />
  **类型**: 产品开发框架<br />
  **起源**: 精益创业运动，2008-2011年 / 埃里克·莱斯<br />
  **别名**: MVP、精益创业、验证原型
</Info>

<Note>
  **快速回答** — 最小可行产品（Minimum Viable Product，MVP）是能够以最少资源发布以测试产品核心市场假设的产品最小版本。埃里克·莱斯于2008年提出这一概念，MVP方法的核心在于构建足够小的东西来验证客户是否真的想要并愿意为产品付费，然后才进行完整开发。关键洞察是，从真实客户身上早期学习比构建没人要的功能能够节省大量时间和金钱。
</Note>

## 什么是最小可行产品（MVP）？

最小可行产品（Minimum Viable Product，MVP）是团队可以发布的最新产品版本，用于测试关于客户需求和市场需求的具体假设。团队不需要花几个月或几年时间构建完整产品，而是创建足够简单的功能来验证核心假设并收集真实反馈。

MVP概念源于精益创业运动，由埃里克·莱斯首创。核心洞察是深刻的：初创公司的存在是为了学习，而不仅仅是为了构建产品。MVP是一种学习工具——如果你不知道你的客户是谁或他们想要什么，花费资源构建完整产品就是浪费。相反，创建可能工作的最小东西，测量客户如何响应，并根据数据决定是坚持还是调整方向。

> "最小可行产品是允许团队以最少努力收集最多关于客户的验证学习的新产品版本。" — 埃里克·莱斯

MVP方法与传统产品开发形成鲜明对比，传统方法是在向用户展示之前花费大量时间和资源构建全面解决方案。通过尽早发布并根据真实反馈进行迭代，团队可以显著降低构建无人想要产品的风险。

### 最小可行产品的三层理解

* **入门**: 从识别关于产品的单一最重要假设开始。什么必须为真才能使你的产品成功？只构建测试这一假设所需的功能，不要更多。

* **实践**: 使用构建-测量-学习反馈循环。构建一个小版本，发布给真实用户，测量他们的行为和反馈，然后学习是迭代还是调整方向。跟踪验证学习，而不仅仅是虚荣指标。

* **进阶**: 应用创新记账——创建实际衡量目标进度的指标。使用分割测试比较不同方法。应用"单一指标"原则：专注于对你的业务假设最重要的那个数字。

## 起源

最小可行产品概念源于埃里克·莱斯在2000年代后期初创公司的经验，并在2011年他的《精益创业》一书中正式提出。莱斯观察到，传统产品开发方法正在让初创公司失败，因为这些方法假设团队在市场上测试这些假设之前就知道客户想要什么。

莱斯的灵感来自精益制造原则，特别是丰田生产系统对消除浪费的强调。在产品开发中，浪费表现为构建没人使用的功能、花费数月构建没人想要的产品、以及在验证之前就投资于假设。MVP的概念是作为一种工具，通过尽早获得真实反馈来最小化这种浪费。

## 核心要点

<Steps>
  <Step title="识别核心假设">
    在构建任何东西之前，阐述你的产品所依赖的关键假设。什么必须为真才能让你的业务运转？这一假设应该是具体的，可以通过客户行为来测试。
  </Step>

  <Step title="构建最小功能集">
    确定测试你的假设所需的最小功能集。只包含绝对必要的内容——除此之外的每个功能都是浪费。关注"必须有"与"最好有"的区别。
  </Step>

  <Step title="发布给早期采用者">
    锁定最有可能提供诚实反馈并容忍不完美的早期客户。这些用户应该代表你的目标市场，并愿意以早期不完善来换取产品更好的承诺。
  </Step>

  <Step title="测量和分析行为">
    不仅跟踪用户说什么，还要跟踪他们做什么。分析应该揭示实际的用法模式、转化率和参与度指标。区分虚荣指标和可操作的洞察。
  </Step>

  <Step title="学习并迭代或调整方向">
    使用数据做决定：如果假设被验证，继续构建和扩展。如果没有，调整方向——在保留所学内容的同时改变方法。目标是验证学习，而不仅仅是构建更多功能。
  </Step>
</Steps>

## 应用场景

<CardGroup cols={2}>
  <Card title="初创公司产品发布">
    初创公司使用MVP在投入大量资金或构建完整产品之前测试市场需求。这种方法使数千家公司能够快速验证想法，而不会烧光资金。
  </Card>

  <Card title="企业功能测试">
    大公司在现有客户群中应用MVP思维来测试新功能或产品。新功能可能会以"测试版"形式推出，功能有限，以在全面投资之前衡量兴趣。
  </Card>

  <Card title="移动应用验证">
    应用开发者经常发布简化版本来测试核心功能。MVP可能只包含一个关键功能，以验证用户是否认为它有价值，然后再投入开发完整应用。
  </Card>

  <Card title="SaaS产品迭代">
    软件即服务公司使用MVP来测试定价模型、功能集和目标细分市场。基本版本可能附带核心功能推出，以验证市场契合度，然后再添加高级功能。
  </Card>
</CardGroup>

## 经典案例

2008年，云存储公司Dropbox的创始人德鲁·休斯顿创建了一个简单的三分鐘视频，展示Dropbox的工作方式——展示产品概念而无需任何实际代码。他将视频发布在Hacker News上，24小时内，有75,000人注册了等候名单。这个仅使用视频和着陆页的MVP验证，显示了巨大的需求存在，然后公司才投入资源构建实际产品。Dropbox继续获得融资并构建完整产品，确信客户想要他们正在创建的东西。

## 边界与失效场景

MVP概念经常被误解和误用。一个常见的失败是构建功能过于丰富的MVP，本质上是"功能完整"的产品过早发布——这违背了用最小投资测试假设的目的。另一个失败是发布的MVP过于简单，无法提供足够价值让用户评估核心主张；这会导致误导性的负面数据。

一个关键的陷阱是混淆"最小"与"便宜"或"低质量"。MVP必须仍然提供足够价值来产生有意义的反馈。发布质量差或令人困惑的东西可能会损害客户对你的品牌印象。此外，某些产品需要显著的抛光才能展示其价值主张——在这些情况下，"MVP"可能需要比纯MVP理念建议的更多投资。

## 常见误区

<AccordionGroup>
  <Accordion title="MVP只是一个原型">
    虽然原型展示产品如何工作，但MVP必须为用户提供真正的价值。原型可以是模拟；MVP是实际解决真实问题的产品，即使很简单。
  </Accordion>

  <Accordion title="永远不应该给MVP添加功能">
    目标是构建、测量和学习——这意味着迭代是预期的。关键是确保每次迭代继续测试特定假设，而不是基于假设添加功能。
  </Accordion>

  <Accordion title="MVP只对科技初创公司有效">
    MVP原则适用于任何新产品或服务，从实体商品到专业服务。核心洞察——尽早验证假设可以节省资源——超越行业或产品类型。
  </Accordion>
</AccordionGroup>

## 相关概念

<CardGroup cols={3}>
  <Card title="精益方法论">
    一种系统性方法，旨在消除浪费同时最大化流程价值，源于丰田。MVP将精益思维应用于产品开发。
  </Card>

  <Card title="敏捷方法论">
    强调灵活性和客户反馈的迭代开发方法。敏捷实践通常能够有效支持MVP开发。
  </Card>

  <Card title="时间-boxing">
    为产品开发周期设定固定时间限制。时间-boxing帮助团队专注于只构建适合约束条件的内容。
  </Card>

  <Card title="假设驱动思考">
    将假设结构化为可测试的形式。这为知道MVP应该验证什么提供了框架。
  </Card>

  <Card title="PDCA循环">
    计划-执行-检查-行动为与MVP的构建-测量-学习循环一致的迭代改进提供了框架。
  </Card>

  <Card title="科学方法">
    通过观察和实验测试假设的系统方法。MVP将科学思维应用于商业。
  </Card>
</CardGroup>

## 一句话总结

<Tip>
  构建测试最大风险的最小的的东西——MVP让你在投资无人想要的功能之前，用真实客户验证假设。
</Tip>