最小可行产品

这是什么

MVP，全称"最小可行产品"（Minimum Viable Product），说穿了不是一个"缩水版的产品"，而是一台"用来做实验的装置"。

很多人误会了这三个字。他们以为 MVP 就是"先做个简陋版本上线，以后慢慢加功能"。错。MVP 真正要回答的问题只有一个：我脑子里这个商业想法，到底是不是真的？ 用户真有这个痛点吗？真愿意为它掏钱吗？你不是在造一个小号的产品，你是在花最少的钱、用最快的速度，去做一次能给出"是"或"否"答案的实验。造出来不是目的，学到东西才是目的。

所以判断一个 MVP 好不好，不看它做得多完整、多漂亮，而看它有没有用最低的成本，把那个"价值百万的问题"给回答了。

来历与出处

MVP 这个概念，真正把它打响、变成全世界创业者口头禅的，是埃里克·莱斯（Eric Ries）。他在 2011 年出版的《精益创业》（The Lean Startup）里系统地讲了这套方法，这本书后来成了硅谷乃至全球创业圈的"圣经"。

但根子要再往前追。"最小可行产品"这个词最早是弗兰克·罗宾逊（Frank Robinson）在 2001 年前后提出的，后来被史蒂夫·布兰克（Steve Blank）的"客户开发"理论吸收。莱斯当年在一家叫 IMVU 的公司当工程师，眼睁睁看着团队闷头开发了几个月、做出一堆自以为很棒的功能，结果用户根本不要——那次惨痛教训，逼他想明白了一件事：创业最大的浪费，不是做得慢，而是把东西做出来了，却发现根本没人要。 于是他把丰田的精益生产思想搬到了创业上，提出了那个著名的循环：构建—测量—认知（Build-Measure-Learn）。

解决什么真实问题

它治的是创业者最常犯、也最致命的一种病：先造一年，再问市场要不要。

典型场景是这样的：你有个自认为绝妙的点子，越想越兴奋，于是埋头开发。三个月、半年、一年过去，钱烧了、人累了、产品终于上线，结果——没人用。这时候你才发现，原来用户压根没有你想象的那个痛点；或者有，但没痛到愿意付钱。

最该用 MVP 的有这么几类人：一是手里资源有限的早期创业者，赌不起一次"全押"；二是大公司里想试新方向的团队，不想动用整个组织去验证一个还没谱的假设；三是做内容、做课程、做新产品线的人，想先小范围试个水。MVP 的本质，是把"要不要做"这个生死攸关的决定，从"开发一年后才知道"提前到"花一周就能知道"。

核心思想

打个比方。你想知道一锅汤咸不咸，你会把整锅汤都喝光吗？不会。你舀一勺尝尝就够了。

MVP 就是那一勺汤。你的商业想法里藏着一堆假设，而 MVP 的任务，是用最小的那一勺，去尝出整锅汤的味道。这里的关键是两件事。

第一，先打最危险的那个假设。 一个创业想法里，假设是分层的：用户有没有这个痛点（需求假设，最致命）、愿不愿意付钱（价值假设）、你的方案真能解决吗（效果假设）、获客成本扛不扛得住（增长假设）、能不能规模化（规模假设）。聪明人不会一上来就纠结"能不能规模化"——那是后话。他先打最不确定、又影响最大的那一个。需求都不存在，后面全是空中楼阁。

第二，实验之前先写死成功标准。 这是 MVP 最容易塌方的地方。如果你不提前定好"留 1000 个邮箱就算成立、不到 300 个就放弃"，那等数据出来，你一定会下意识地替它找理由——"虽然只有 200 个，但质量很高啊"。这就不是科学实验了，这是自我安慰。

MVP 有三种常见形态：落地页式（只做个介绍页，看有多少人留邮箱、点预约，验证"需求存不存在"）、人工式（俗称"绿野仙踪"，前台看着像自动化，后台其实是你手动在干，验证"流程和付费意愿"）、单功能式（只做最核心那一个功能，验证"核心价值"）。选哪种，取决于你要尝的是哪一勺。

完整案例

最经典的 MVP 故事，是 Dropbox。

2007 年，创始人德鲁·休斯顿（Drew Houston）想做一个能在所有设备间无缝同步文件的工具。这事在当时技术上极其复杂，真要把产品做出来，得砸进去海量的工程量和时间。可他面临的最大风险根本不是"做不做得出来"，而是一个更要命的问题——人们到底需不需要"无缝同步文件"这件事？ 万一做出来没人要呢？

换作别人，可能就闷头开发了。但休斯顿没写一行产品代码。他干了一件特别"取巧"的事：录了一段三分钟的演示视频，演示 Dropbox 同步文件的体验——文件拖进文件夹，另一台电脑上瞬间出现。视频里很多功能其实还没实现，但看起来天衣无缝。他把视频发到了 Hacker News 这类技术社区。

结果一夜之间，等候名单从 5000 人暴涨到 75000 人。

你看，这段视频就是一个不折不扣的 MVP。它没有产品，却完成了产品最该完成的那次实验——用接近于零的成本，把"需求假设"这个价值百万美元的问题，结结实实地回答了。从那以后休斯顿才敢放心去攻技术。他没有先造产品，他先造了答案。

常见误解与边界

第一个误解，也是最普遍的：MVP 等于低质量产品。 不对。MVP 是"范围最小"，不是"质量最差"。你砍掉的是非核心功能，但留下的那个核心体验，不能糊弄。一个又简陋又难用的东西，验证不了任何东西，只会让用户掉头就走，给你一个错误的"否"。

第二个误解：事后看数据找理由。 前面说过，这是 MVP 的头号杀手。成功标准必须实验前写死，白纸黑字，谁都改不了。

第三个要提醒的是边界：MVP 验证的是"假设真不真"，它不替你做"产品该长什么样"。先想清楚要验证什么（这往往需要先把产品定义、价值主张梳理一遍），再用 MVP 去打。MVP 是验证工具，不是设计工具。

最后一点，AI 时代有个新红利：过去很多"人工式 MVP"需要搭一个团队在后台手动运营，现在用 AI 工具，一个人就能撑起那个"看似自动化"的前台，成本直接砍掉九成。能用 AI 跑通的人工 MVP，优先考虑。

一句话记住它

你不是在造产品，你是在做实验——MVP 是那把尝汤的勺子，用最小一口，尝出整锅的咸淡。