什么是 MVP

很多人在做新产品时，会陷入一个误区：把 MVP 理解成「做一个简陋的半成品」。于是交付出来的东西功能残缺、体验粗糙，用户试了一次就再也不愿回来。这和 MVP 的本意相距甚远。

MVP 的核心诉求从来不是「少做」，而是用尽量小的代价去验证一个关键假设——你 believed 用户需要的东西，他们是否愿意用。这篇文章会系统拆解 MVP 的定义、起源、核心原则、常见类型，以及它和原型、POC 的区别，帮助你在动手开发之前想清楚该验证什么、怎么验证。

一、MVP 的定义与起源

1.1 Eric Ries 的原始定义

MVP（Minimum Viable Product，最小可行产品）这个概念因 Eric Ries 在 2011 年出版的《精益创业》（The Lean Startup）一书而广为人知。Ries 给出的定义是：

MVP 是新版产品的一种形态，能让团队以最小的投入，收集关于目标客户的最大量的有效验证（validated learning）。

— Eric Ries, The Lean Startup (2011)

这个定义有三个关键词需要拆开理解：

• 最小投入（minimum）：花最少的时间、金钱和人力。能一周做完的事不要拖到一个月。
• 可行（viable）：产品至少要能让用户体验到核心价值，能跑通一个完整的流程。一个连基本功能都无法工作的东西不叫 MVP，叫残次品。
• 有效验证（validated learning）：MVP 的目标不是赚钱、不是拿融资、也不是发新闻稿，而是获取「经过事实检验的认知」。用户说「这个想法不错」不算验证；用户注册、付费、持续使用才算。

1.2 精益创业的大背景

MVP 是精益创业方法论的核心工具之一。精益创业的整体框架可以概括为一个循环：构建 → 测量 → 学习（Build-Measure-Learn）。

1. 构建（Build）：把想法变成一个可以测试的东西——MVP。
2. 测量（Measure）：把 MVP 交给真实用户，收集数据和反馈。
3. 学习（Learn）：根据数据判断最初的想法是否正确。如果正确，继续优化（persevere）；如果不正确，调整方向（pivot）。

这个循环的速度决定了创业团队的效率。MVP 的意义在于让每一轮循环的成本尽可能低、周期尽可能短，从而在有限的资源内跑更多轮验证。

1.3 更早的思想源头

虽然 Eric Ries 让 MVP 这个词流行起来，但类似的想法早就存在。丰田汽车在 20 世纪中叶推行的「精益生产」（Lean Manufacturing）就强调消除浪费、快速迭代。Steve Blank 在 2000 年代初期提出的「客户开发」（Customer Development）方法论也主张在写代码之前先找用户验证需求。Ries 的贡献是把这些散落的实践整合成一个清晰的框架，并赋予了 MVP 这样一个容易传播的名字。

二、MVP 的核心原则

理解了定义之后，我们需要把握 MVP 背后的几条核心原则。这些原则帮助你在具体操作中做出正确的取舍。

2.1 验证假设优先

做 MVP 的第一步不是画界面、写代码，而是列出你当前最大的假设。一个产品想法通常包含几类假设：

MVP 要针对其中风险最高的那一个假设去设计验证方案。多数产品失败不是因为技术实现不了，而是因为做出来没人要。所以价值假设往往是第一个需要验证的。

2.2 快速迭代

MVP 不是一个一次性动作，而是一个持续的过程。你的第一个 MVP 可能验证了「用户确实有这个问题」，但第二个 MVP 需要验证「他们愿意用这种方式解决」。每一轮迭代都应该比上一轮更接近产品的完整形态，但每一轮仍然要保持「最小」的原则。

2.3 最小投入，而非最少功能

「最小」指的是验证假设所需的最小代价，不是功能的最少。如果一个需要 3 个功能才能让用户理解产品价值的场景，砍到只剩 1 个功能就不是「最小」，而是「无效」。

举个例子：如果你想验证「用户是否愿意在线买鞋」，Zappos 的创始人 Nick Swinmurd 的做法是去实体店拍鞋子的照片，挂到一个简单的网页上。有人下单，他就去店里买下来寄出去。这个 MVP 只有一个页面、手动发货，但它完整验证了「用户愿意在线购买鞋子」这个核心假设。

2.4 面向真实用户

MVP 必须在真实用户面前测试。给同事、朋友看不是验证——他们的反馈往往偏向鼓励，缺乏参考价值。把 MVP 放到目标用户会去的地方（社区、论坛、社交媒体），观察他们的真实行为：是否点击、是否注册、是否愿意付费。

三、MVP 的主要类型

MVP 的形态取决于你要验证的假设和所处的阶段。以下是几种常见的 MVP 类型，以及各自的适用场景。

3.1 落地页型 MVP（Landing Page MVP）

做一个简单的产品介绍页面，放一个注册按钮或邮件订阅表单。用户看到页面后，如果你能收集到一定数量的注册或订阅，就说明市场存在兴趣。

适用场景：验证「有没有人关心这个问题」。

典型做法：

• 一个页面讲清楚产品解决什么问题
• 一个行动召唤（CTA）按钮
• 收集邮箱或让用户加入等候列表

3.2 单一功能型 MVP（Single-Feature MVP）

只做一个核心功能，把这个功能做到可用。其他所有功能都先不做。

适用场景：你已经确定用户有某个需求，需要验证「这个功能是否好用、用户是否持续使用」。

典型案例：Spotify 最初只做了音乐流媒体播放这一个功能，没有播客、没有社交分享、没有歌词显示。它先验证了「用户是否愿意在线听音乐」这个核心问题。

3.3 手动服务型 MVP（Concierge MVP）

前端看起来像是一个产品，但背后的服务完全由人工手动完成。用户知道有人在手动为他们服务。

适用场景：技术实现复杂，但你想先验证需求是否存在。

典型案例：Zappos 的创始人手动拍照、手动买鞋、手动发货。在验证需求之前，他不打算建库存系统。

3.4 绿野仙踪型 MVP（Wizard of Oz MVP）

和手动服务型类似，区别在于用户不知道背后是人工操作。前端看起来像是一个完全自动化的产品，但后端实际上由人来完成。

适用场景：你希望测试完整的用户体验，但自动化技术还没准备好。

典型案例：早期的一些 AI 聊天产品，前端是聊天界面，后端实际上是真人在回复。目的是验证用户是否愿意和这类产品交互。

3.5 众筹/预售型 MVP（Pre-order MVP）

在产品做出来之前，让用户提前付费或承诺购买。

适用场景：验证「用户是否愿意为这个东西付钱」。这是最强烈的需求信号之一——愿意掏钱比愿意注册更能说明问题。

典型案例：Kickstarter 上大量产品在还只是概念阶段时就开始众筹，本质上就是用预售来做 MVP 验证。

3.6 邮件营销型 MVP（Email Campaign MVP）

给一批潜在客户发送描述产品概念的邮件，看有多少人会回复或点击链接。

适用场景：你已经有一个用户邮件列表，想快速测试一个新想法的吸引力。

3.7 拼装型 MVP（Piecemeal MVP）

用现有的工具和平台拼凑出一个可用的产品，而不是从头开发。

适用场景：资源极其有限，但需要快速验证。

典型案例：Groupon 最初用 WordPress 搭网站、用 FileMaker 生成优惠券、用 Apple Mail 发送——所有组件都是现成的，没有一行自研代码。

MVP 类型对比

四、MVP vs 原型 vs POC

这三个概念经常被混用，但它们的目的、受众和产出完全不同。搞清楚区别，可以避免在错误的阶段做错误的事。

4.1 概念定义

POC（Proof of Concept，概念验证）：验证一个技术方案或想法在技术上是否可行。POC 通常由开发团队内部完成，不面向用户，产出一个「能不能做」的结论。

原型（Prototype）：将产品设计可视化、可交互。原型关注的是用户体验和界面流程，通常由设计师完成，用于和利益相关者或目标用户讨论「产品应该长什么样、怎么用」。原型没有真实的后端逻辑。

MVP（Minimum Viable Product）：一个可以工作的产品，具备核心功能，面向真实用户发布，用于验证市场需求和商业假设。

4.2 核心区别对比

4.3 三者的协作关系

POC、原型和 MVP 不是互斥的选项，而是产品开发不同阶段的工具。一个典型的产品从零到一的过程会依次经历：

1. POC 阶段：先确认核心技术能不能实现。比如你想做一个 AI 实时翻译耳机，先用几天时间测试语音识别 + 翻译 API 的延迟能否控制在可接受范围内。
2. 原型阶段：技术可行后，设计师画出产品的界面和交互流程，找一些潜在用户测试，看他们能否理解产品的使用方式。
3. MVP 阶段：设计和交互验证完成后，开发一个具备核心功能的产品，发布给真实用户，观察他们是否使用、是否持续使用、是否愿意付费。

4.4 什么时候可以跳过某个阶段

并非每个项目都需要走完 POC → 原型 → MVP 的全流程。如果你的技术方案已经成熟（比如用现有的 LLM API 做 AI 写作工具），POC 可以省略，直接进入原型和 MVP。如果你面对的是一个已有成熟设计模式的产品类型（比如电商、SaaS），原型的投入也可以减少。

判断标准是不确定性在哪里：不确定性在技术层面就先做 POC，不确定性在用户体验层面就先做原型，不确定性在市场需求层面就直接做 MVP。

五、好 MVP vs 坏 MVP

同样是做 MVP，有些能帮你节省数月时间，有些则白白浪费精力。以下是好 MVP 和坏 MVP 的关键差异。

六、不同产品适合的 MVP 类型

不同类型的产品，验证的重点不同，适合的 MVP 类型也不同。下面按几个常见的 AI 产品出海场景给出建议。

七、经典案例

案例一：Dropbox —— 用一段视频验证需求

Dropbox 的创始人 Drew Houston 在 2007 年想做一个文件自动同步工具。这个想法面临两个挑战：一是技术难度高，文件同步涉及操作系统底层，开发周期长；二是市场上已有类似产品，投资人不认为还有空间。

Houston 没有直接花几个月开发完整产品，而是录了一段大约 3 分钟的屏幕录制视频。视频里他展示了 Dropbox 的工作原理——在一台电脑上修改文件，另一台电脑自动同步更新。视频是专门为技术社区（Hacker News、Digg）制作的，里面藏了不少只有技术人员能看懂的彩蛋。

这段视频在一夜之间带来了约 75,000 个注册申请。Houston 从中得到了两个关键信息：第一，用户确实有文件同步的需求；第二，技术社区对这个方案感兴趣，可以作为早期推广的突破口。

Dropbox 的 MVP 是一个典型的「视频型 MVP」——产品还没有完全做好，但通过视频演示验证了市场需求。这比花半年开发出一个完整产品再推向市场要高效得多。

值得注意的细节：Houston 在视频里并没有展示一个已经完工的产品。很多画面是模拟的，甚至有些交互在当时的技术条件下还没有完全实现。但这不影响验证——他需要验证的是「用户是否需要这个功能」，而不是「这个功能能不能完美运行」。

案例二：Buffer —— 两页网站，七天拿到付费用户

Buffer 是一个社交媒体定时发布工具。创始人 Joel Gascoigne 在 2011 年有了这个想法后，没有直接开始写代码，而是做了一个非常精简的两步验证：

第一步：他做了一个简单的落地页，介绍 Buffer 的概念——「以更聪明的方式安排你的 Twitter 更新」。页面上有一个注册按钮。用户点击后，会进入一个提示信息页面，告诉他们产品还在开发中，可以留下邮箱获取上线通知。

这一步验证了：有人对这个产品感兴趣。答案是肯定的——有一些人注册了。

第二步：Gascoigne 在落地页后面加了一个定价页面。用户在看完产品介绍后，会看到不同的付费方案和价格。如果用户点击了付费方案，说明他们不仅感兴趣，还愿意付钱。

这一步验证了：有人愿意为这个产品付费。答案也是肯定的。

从想法到第一个付费用户，Buffer 用了大约 7 周时间，其中落地页的设计和测试只花了几天。Gascoigne 在这个过程中几乎没有写任何产品代码——他把所有时间花在了验证「用户是否需要」和「用户是否愿意付费」这两个最关键的假设上。

值得注意的细节：Gascoigne 把验证分成了两步。如果他只做一个落地页，他能知道用户「感兴趣」，但不知道用户「愿意付费」。两步分开做，让他能够逐步确认更强的需求信号。这个思路值得借鉴——MVP 验证不一定一步到位，可以分层递进。

八、MVP 的完整思考路径

在动手做 MVP 之前，按照下面的流程走一遍，可以帮你避免大多数常见错误。

预览代码

复制SVGPNG源码

流程图画布 · 115%

重置全屏

Mermaid 流程图加载中...

这个流程的关键在于：在构建 MVP 之前就定义好成功标准。很多团队做完 MVP 后不知道该怎样判断结果，就是因为跳过了「定义成功标准」这一步。

九、MVP 设计检查清单

在开始构建 MVP 之前，对照以下清单逐项检查。如果有任何一项回答不上来，建议先想清楚再动手。

• 我能用一句话说清楚 MVP 要验证的核心假设是什么
• 我知道这个假设当前最大的风险在哪里（技术风险 / 市场风险 / 商业风险）
• 我选择了和假设匹配的 MVP 类型，而不是因为我擅长某种方式就只用那种
• 我定义了明确的成功标准（比如：7 天内 200 个注册、10% 的点击率、至少 5 个付费用户）
• 我的 MVP 只包含验证假设必需的功能，没有加入「以后可能有用」的东西
• 我的 MVP 可以在 2-4 周内完成构建
• 我知道目标用户在哪里，能够把 MVP 推到他们面前
• 我有收集用户反馈的机制（数据分析、表单、访谈计划）
• 我清楚 MVP 验证通过后的下一步计划
• 我清楚 MVP 验证失败后的应对方案（调整假设 / 换方向 / 停止）
• 我的团队成员对 MVP 的目标和范围有共识
• 我准备好了不因为情感因素而忽略负面数据

十、常见误区

最后补充几个容易踩的坑，帮你在做 MVP 时保持清醒。

误区一：MVP = 廉价产品。MVP 的目的不是省钱，是用最小的代价获取最大的认知。如果花 10 万块做一个 MVP 能帮你避免花 100 万做一个没人要的产品，那这 10 万就花得很值。

误区二：先做 MVP 再想假设。有些团队先做了一个东西出来，然后反过来找它可以验证什么假设。这完全颠倒了顺序。MVP 的起点是假设，不是产品。

误区三：一次 MVP 验证所有事。MVP 应该每次只验证一个核心假设。如果你的 MVP 同时想验证用户需求、技术可行性和商业模式，你无法判断结果到底是由哪个因素决定的。

误区四：MVP 之后就跳过迭代。有些团队把 MVP 发布出去，拿到了一些反馈，就直接开始做「正式版」。MVP 的思维方式应该贯穿产品的整个生命周期，而不是只在最初阶段使用。

误区五：把用户说的当作用户做的。用户在访谈中说「这个产品很棒，我一定会用」不能算验证结果。观察用户的真实行为——是否注册、是否使用、是否付费——才是有效的验证数据。

参考资料

1. Eric Ries. The Lean Startup. Crown Business, 2011. — MVP 概念的原始出处，Build-Measure-Learn 循环的完整论述。
2. What Is an MVP? Eric Ries Explains — Lean Startup Co. — Eric Ries 本人对 MVP 的解读。
3. Minimum Viable Product — Wikipedia — MVP 概念的百科概述及历史背景。
4. How Dropbox Started As A Minimal Viable Product — TechCrunch, 2011 — Dropbox 视频 MVP 案例的详细报道。
5. Idea to Paying Customers in 7 Weeks — Buffer — Joel Gascoigne 亲述 Buffer 如何用落地页 MVP 在 7 周内获得付费用户。
6. PoC vs MVP vs Prototype: What's the Difference? — Software Mind — POC、原型和 MVP 三者的系统对比。
7. Nine Minimum Viable Product Examples — Antler — 包含 Airbnb、Zappos、Uber 等多个经典 MVP 案例分析。
8. 9 Types of MVPs for Startups — KeyUA — MVP 类型的系统分类与说明。