MVP：做一半就上线？不，是做对了才上线

你做过这种事吗——

需求文档写了60页。评审会上讨论了4小时。开发排期3个月。设计稿改了7版。

上线那天，团队鼓掌，老板点头。

一周后看数据：日活涨了2%，三天后回到原点。

三个月的工作量，换来一条平线。

问题出在哪？不是不够努力，不是不够细致。而是——你花了三个月验证了一个本可以三天就验证的假设。

这就是 MVP 要解决的事。

先讲三个故事

故事一：一个视频，7.5万注册

2008年，有个人想做云存储产品。但云存储的技术门槛很高，开发要几个月。

他没有写代码。他做了一个3分钟的视频。

视频里演示了：拖文件到文件夹→文件自动同步到云端→在另一台电脑打开。流畅、酷、解决了痛点。

他把视频发到技术社区。24小时内，7.5万人注册了等待名单。

这个人叫 Drew Houston。产品叫 Dropbox。

那时候一行代码都没写。但他已经验证了最重要的事——有人真的想要这个产品。

故事二：不进货，先拍照

1999年，有个人想在网上卖鞋。

但他不确定：有人会在网上买鞋吗？尺码合不合适？颜色对不对？

他没有进货、没有建仓、没有搭供应链。他去实体鞋店拍照片，把照片传到网上，标价。

有人下单了。他就去实体店原价买这双鞋，加价寄给客户。

这个人叫 Nick Swinmurn。产品叫 Zappos。后来被亚马逊以 12亿美元 收购。

故事三：气垫床+早餐

2007年，旧金山开设计大会，酒店全满。

三个室友把自己的客厅气垫床租出去，加了早餐。做了个简陋的网页。

3个人来住了。他们验证了：有人愿意住陌生人的家，如果比酒店便宜。

这个产品叫 Airbnb。

三个故事的共同点：没有人在第一天就把产品做全。 他们用最少的时间、最少的资源，验证了最关键的假设。

这就是 MVP。

MVP 到底是什么

提出者：Eric Ries，《精益创业》（The Lean Startup），2011年出版。 原始概念由 Frank Robinson（2001年）提出，由 Eric Ries 发扬光大。

定义：

MVP 是能够以最小开发量完成一次完整"构建-测量-认知"循环的产品版本。

注意三个词：最小开发量、完整循环、认知。

最小开发量——砍掉一切非核心功能。不砍到不能再砍为止。

完整循环——MVP 必须能跑通"做出来→给用户用→收到反馈→学到东西"这个闭环。不能跑通的，不叫 MVP，叫半成品。

认知——MVP 的目的不是上线赚钱，是学到东西。验证你的假设对不对。

Eric Ries 说了一句我觉得比定义本身更到位的话：

"MVP 不是你产品的缩小版，而是你学习的最大化版。"

产品经理最容易踩的 4 个坑

坑一：MVP = 做一半就上线

最常见的误解。功能砍了一半，体验粗制滥造，上线后没人用——然后得出结论"这个方向不行"。

但不是方向不行，是你的 MVP 太烂了。

MVP 的 V = Viable = 可行。 它必须能用、能跑通核心流程、能让用户体验到核心价值。

一个烂产品没人用，你学不到任何东西。

• ❌ 不是 MVP｜✅ 是 MVP
• 砍了核心功能的产品｜保留核心功能、砍掉非核心的产品
• 粗制滥造的半成品｜体验粗糙但核心流程跑通
• 为了快速上线而妥协｜为了快速验证假设而精简

坑二：MVP 不做验证就加功能

有些团队做了 MVP，数据不好，第一反应是"加功能"。

但 MVP 数据不好，你要做的不是加功能，而是重新审视假设。

是用户群选错了？需求理解错了？价值主张不成立？

MVP 的价值在于验证假设。假设错了就改假设，不是在错误的假设上加功能。

坑三：把 MVP 当成最终产品

MVP 是起点，不是终点。

Dropbox 的 MVP 是一个视频，但 Dropbox 的最终产品是一个完整的云存储平台。Airbnb 的 MVP 是气垫床，但最终产品是全球民宿平台。

MVP 验证的是"方向对不对"，不是"产品长什么样"。

坑四：不定义"验证标准"

最致命的坑。做了 MVP，然后呢？什么数据算"验证通过"？什么数据算"方向不对"？

如果你在上线 MVP 之前没有写下"什么结果算成功"，那你上线后会陷入"数据解读无限争论"的陷阱。

写验证标准，是在做 MVP 之前。

怎么定义你的 MVP

第一步：写出你最重要的假设

一个 MVP 只能验证一个核心假设。不要贪多。

• 产品｜核心假设｜MVP 怎么验证
• Dropbox｜"用户想要跨设备同步文件"｜3分钟演示视频→看注册量
• Zappos｜"用户愿意在网上买鞋"｜拍鞋店照片→看有没有人下单
• Airbnb｜"有人愿意住陌生人的家"｜气垫床+简陋网页→看来人住不住

你的核心假设是什么？写下来。如果写不出来，你还没准备好做 MVP。

第二步：砍到只剩核心价值

问自己一个问题：

"如果砍掉这个功能，用户还能体验到核心价值吗？"

• 砍掉，用户还能体验核心价值 → 砍
• 砍掉，用户体验不到核心价值 → 留

Dropbox 的核心价值是"文件同步"。注册流程、付费体系、移动端、分享功能——全砍。只留"同步"这件事，做到能用。

砍到不能再砍，就是 MVP。

第三步：定义验证标准

在 MVP 上线之前，写下：

"如果 _____ 指标达到 _____，说明假设成立，继续做。否则，调整方向。"

• 例子｜验证标准
• Dropbox｜7天内注册量 > 5000
• Zappos｜有至少1个真实订单
• Airbnb｜至少3个人来住

没有验证标准的 MVP，就是"做完看看"——"看看"不是策略。

第四步：定一个时间限制

MVP 的"M"不只是 Minimum（最小），也应该是 Months 的限制。

给自己 2-4 周。 超过这个时间还没做出来，说明你又在加功能了。

构建-测量-认知：MVP 的心脏

Eric Ries 提出的精益创业核心循环：

`` 构建 (Build) ↓ MVP 上线 ↓ 测量 (Measure) ↓ 收集数据 ↓ 认知 (Learn) ↓ 假设对不对？ ↙ ↘ 对了 错了 ↓ ↓ 继续做 转型 ``

MVP 不是终点，是这个循环的起点。

跑完一圈后：

• 假设成立 → 加资源，继续迭代
• 假设不成立 → 转型（Pivot），换方向重新跑

转型不是失败。不转型才是失败——因为你还在往一个错的方向上堆资源。

怎么判断"可行"在哪

MVP 的精髓在于 Minimum 和 Viable 的平衡。砍多了，不可行。留多了，不够最小。

`` 功能太多 合适的 MVP 功能太少 ←─────────────●─────────────→ 浪费资源 验证假设 验证不了 上线太慢 学到东西 学不到东西 ``

判断标准：

1. 用户能不能完成核心流程？能 → Viable。
2. 用户能不能感受到核心价值？能 → Viable。
3. 你能不能收集到验证假设的数据？能 → Viable。

三条全满足，就是合适的 MVP。少一条，要么砍多了，要么留多了。

4 个经典 MVP 案例

• 产品｜MVP 是什么｜验证了什么｜结果
• Dropbox｜3分钟演示视频｜"有人想要跨设备同步"｜24小时7.5万注册
• Zappos｜拍鞋店照片放网上｜"有人愿意网上买鞋"｜有真实订单→12亿被收购
• Airbnb｜气垫床+简陋网页｜"有人愿意住陌生人家"｜3人来住→千亿市值
• 微信｜1.0版只有文字聊天+语音｜"用户需要一个跨运营商的通讯工具"｜次日留存超50%→用户暴涨

注意一个共同点：没有一个 MVP 是"做了一半的产品"。每一个都完整地验证了一个核心假设。

Dropbox 的视频不是"做了一半的云存储"。它是一个完整的验证工具。

今天就能做的 3 件事

1. 写下你的核心假设

一句话。格式："我认为 \_\_\_（用户群）会愿意用 \_\_\_（产品），因为它解决了 \_\_\_（问题）。"

写不出来？那你还不到做 MVP 的时候。

2. 砍到只剩核心价值

把你的需求清单拿出来，对每一条问："砍掉它，用户还能体验核心价值吗？"

能砍的全砍。剩下的是 MVP。

3. 在上线前写下验证标准

"如果 \_\_\_ 指标达到 \_\_\_，继续做。否则，转型。"

不写验证标准就上线 MVP，等于做完试卷不批改——你什么都没学到。

一句话

MVP 不是"做一半就上线"。MVP 是"做对了才上线"——做对的核心假设、最小的功能、最大的学习。

做完三个月才发现方向错了，和做三周就发现方向错了——区别就是 MVP。

前者叫浪费，后者叫精益。

思考题

1. 你当前产品的核心假设是什么？用一句话写出来。如果写不出来——你不知道自己在验证什么。
2. 你上一次上线花了多久？如果超过4周，你是做产品还是做 MVP？
3. 如果明天你的产品只能保留一个功能，你留哪个？那个功能就是你的 MVP 核心。

上期回顾：第02讲 · 北极星指标——如果你只能看一个数字，看哪个？ 下期预告：第04讲 · 网络效应（Network Effects）—— 为什么用户越多产品越值钱，以及什么时候这是陷阱

参考：Eric Ries《The Lean Startup》(2011) · Frank Robinson MVP 原始概念(2001) · Dropbox/Zappos/Airbnb 公开创业案例 · 百度百科 MVP 词条