🔨 构建 MVP
2 周而非 2 月,1 个功能而非 10 个

MVP ≠ 半成品。MVP = 最小可行产品 = 刚好能验证核心假设的产品。关键是最小,不是最多。本页包含 5 种 MVP 各配详细案例、2 周构建清单、质量 vs 速度决策树和 MVP 检查清单。

🎯 MVP 的真正含义

❌ MVP 不是

  • 做了一半的产品
  • Bug 多的粗糙品
  • 功能删减版
  • 先上线再修补
  • "先做了再说"
  • 给投资人的演示品

✅ MVP 是

  • 刚好能验证核心假设的产品
  • 一个核心功能做到极致
  • 让用户完成一个完整任务
  • 有意的限制,非无意的缺陷
  • "如果这个功能用户不需要,整个方向可能错了"
  • 学习的工具,不是交付的终点

📐 MVP 的数学本质

MVP 的核心逻辑是假设-验证循环

假设 (Hypothesis)
  → "如果用户有 X 问题,他们会用 Y 方案解决,且愿意付 Z 价格"

最小实验 (Minimum Experiment)
  → 用最低成本构建一个能测试上述假设的东西

验证指标 (Validation Metrics)
  → 定量:注册数、激活率、留存率、付费转化
  → 定性:用户反馈、使用深度、推荐意愿

决策 (Decision)
  → 验证通过 → 加倍投入,迭代改进
  → 验证失败 → Pivot(调整方向)或放弃
  → 不确定 → 缩小范围,更聚焦地再测一次
"如果你的 MVP 不让你感到尴尬,你发布得太晚了。" — Reid Hoffman, LinkedIn 创始人

🔬 5 种 MVP 类型(各配 2 个案例)

从最轻到最重,选择适合你的验证方式。核心原则:用最低成本验证最核心的假设。

🎭 Wizard of Oz MVP

$0-5001-2周

用户以为背后是自动化系统,实际上是你手动操作。名字来自《绿野仙踪》——"别看那个幕后的人"。

适合:AI 产品、自动化服务、需要验证"用户是否愿意用这个结果"

📋 案例 1:Zappos(1999)

电商$0 成本验证1周
背景:Nick Swinmurn 想验证"人们是否愿意在网上买鞋"。当时主流观点认为鞋必须试穿才能买。
MVP:他去本地鞋店拍照片,放到一个简单网站上。有人下单后,他去鞋店原价买鞋,再寄给客户。
验证数据:第一周就收到订单——验证了核心假设:人们确实愿意网上买鞋。
后续:Zappos 后来建立了真正的仓库和物流,2009 年被 Amazon 以 $1.2B 收购。
关键教训:
① 不需要先建仓库——手动操作足以验证需求
② 利润为负也无所谓——MVP 的目标是学习,不是赚钱
③ 最重要验证的是"有没有人要",不是"能不能规模化"

来源:Nick Swinmurn, Zappos origin story; Eric Ries, "The Lean Startup", 2011

📋 案例 2:Aardvark(社交问答,2008)

AI/社交手动匹配后来被Google收购$50M
背景:Aardvark 想做一个"问朋友的朋友"的问答系统。核心假设:人们愿意通过社交网络向陌生人提问并获得回答。
MVP:用户通过 IM 提问,背后是人工把问题路由给最合适的回答者——没有 NLP,没有算法,纯人工匹配。
验证数据:回答率 >80%,用户满意度高——验证了社交问答的核心价值。
后续:验证通过后才开发自动路由算法。2010 年被 Google 以 ~$50M 收购。
关键教训:
① AI 产品最适合 Wizard of Oz——用户只关心结果,不在乎背后是人还是机器
② 人工操作反而能更好地理解匹配逻辑——为后续算法提供训练数据
③ MVP 期间积累的数据 = 产品的核心资产

来源:Damian Kulash, Aardvark Engineering Blog; TechCrunch, 2010年2月

🤵 Concierge MVP

$01周

完全人工服务,一个一个客户手动满足需求。与 Wizard of Oz 不同的是,用户知道是人工服务。

适合:服务型产品、需要了解用户真实流程、B2B 产品

📋 案例 1:DoorDash(2013)

外卖配送手动跑腿后来IPO $72B
背景:Stanford 学生发现本地餐厅不提供外送,想验证"人们是否愿意为餐厅外送付费"。
MVP:创始人在 Page Mill Rd 的餐厅和客户之间手动跑腿送餐。用 Square 收款,用手机接单。
验证数据:第一周完成 10+ 单配送,客户愿意支付 $6 配送费——验证了付费意愿。
后续:逐渐增加餐厅数量和骑手,2013 年 YC 毕业后融资。2020 年 IPO,市值一度超 $70B。
关键教训:
① 手动服务让你深入理解用户流程——每个痛点你亲自体验
② "做不了"比"做不快"更好——先证明需求存在,再优化效率
③ 配送时长、出错率、客户满意度——手动阶段就能建立 SLA 基准

来源:Tony Xu, DoorDash Origin Story; Y Combinator Startup School, 2015

📋 案例 2:Food on the Table(2011)

食谱规划手动规划$0成本验证
背景:想帮助家庭根据超市促销规划食谱和购物清单。核心假设:家庭主妇愿意为"省钱的食谱规划"付费。
MVP:创始人 Manuel Rosso 每天手动为 1 个客户去超市看促销 → 选食谱 → 做购物清单 → 发给客户。
验证数据:第一个客户每周付 $9.95——证明有人愿意为这个服务付费。
后续:逐渐增加到 10 个客户,发现共性需求,然后才写代码自动化。
关键教训:
① 一个付费客户 > 一千个"感兴趣"的注册用户
② 手动服务帮你发现算法无法预见的细节——"哦,她对花生过敏"
③ 从 1 个客户到 10 个客户的过程中,标准化服务流程

来源:Manuel Rosso, Food on the Table story; Inc Magazine, 2012

💨 Smoke Test MVP

$0-2003-5天

用"假门"测试用户兴趣——展示产品价值,看有多少人愿意走进来。

适合:消费者产品、功能清晰的产品、需要快速判断市场兴趣

📋 案例 1:Dropbox(2007)

云存储3分钟视频等待名单5K→75K
背景:Drew Houston 厌倦了在电脑之间用 USB 传文件。但云存储市场已有 Mozy、Carbonite 等,投资人认为"又一个同步工具没戏"。
MVP:一个 3 分钟的演示视频,展示了 Dropbox 的核心功能——文件在电脑间自动同步。没有实际产品,只是一个 Demo。
验证数据:视频发布在 Digg → 一夜之间等待名单从 5,000 涨到 75,000(14 倍增长)。
后续:Dropbox 2018 年 IPO,市值 ~$10B。
关键教训:
① 如果一个 Demo 视频就能引爆需求 → PMF 信号极强
② "Show, don't tell"——视频比文字说明有效 100 倍
③ 75K 等待用户 = 市场验证 + 后续冷启动的用户池

来源:Drew Houston, MIT Commencement Speech, 2013; Dropbox S-1 Filing, 2018

📋 案例 2:Tesla Cybertruck(2019)

电动车概念车+预购$100定金
背景:Tesla 想进入皮卡市场,但皮卡市场极度传统——Ford F-150 统治了几十年。
MVP:发布一个极其前卫的概念车设计(不锈钢外壳、赛博朋克风格),同时开放 $100 可退还定金预购。
验证数据:发布后一周内收到 25 万+ 预购定金——验证了"有人想要不一样的皮卡"。
后续:生产多次延期(2023 年才开始交付),但预购数据给了 Tesla 信心和资金持续投入。
关键教训:
① 预购/定金是最强的 Smoke Test——用户用真金白银投票
② 极端设计筛选出真正的目标用户——"不喜欢的人不是我的客户"
③ Smoke Test 可以在产品存在之前就验证——Tesla 发布时连工厂都还没有

来源:Tesla Investor Relations, 2019年11月; Electrek, 2023

🌐 Landing Page MVP

$0-1002-3天

单页网站+CTA,测试价值主张和转化率。最轻量的定量验证方式。

适合:SaaS、订阅制产品、消费者 App

📋 案例 1:Buffer(2010)

社交媒体排程2页网站120邮箱注册
背景:Joel Gascoigne 想做一个社交媒体定时发布工具,但不确定用户是否愿意用。
MVP:两页网站——第一页介绍产品价值+定价,第二页"你还没准备好,留邮箱通知你"。
验证数据:获得 120 个邮箱注册 + 不少人点击了付费按钮——验证了付费意愿。
后续:6 周后推出产品,1 年内达到 $100K ARR。最终年化收入超 $20M。
关键教训:
① 两页网站就够了——不需要真实产品就能验证兴趣
② 付费按钮是终极验证——"感兴趣"和"愿意付钱"是两件事
③ 120 个邮箱 = 足够启动——你不需要 10,000 个

来源:Joel Gascoigne, Buffer Blog, "The Lean Startup journey of Buffer", 2013

📋 案例 2:Ghost(2013)

博客平台Kickstarter$300K众筹
背景:John O'Nolan 想做一个现代开源博客平台,替代 WordPress 的臃肿。
MVP:一个概念设计 + Kickstarter 众筹页面。没有代码,只有设计稿和愿景。
验证数据:Kickstarter 29 天筹集 £200,000(~$300K),远超 £25,000 目标。
后续:众筹成功后开始开发,Ghost 现在是全球最流行的开源博客平台之一。
关键教训:
① 众筹 = 超级 Landing Page——用户用钱投票,验证比邮箱注册更强
② 开源社区 + 众筹 = 双重验证(用户需求 + 社区支持)
③ 设计稿足够——如果价值主张清晰,用户能想象产品

来源:John O'Nolan, Ghost Blog; Kickstarter project page, 2013

⚡ Single Feature MVP

$500-5K2-4周

只做一个核心功能,做到可用。其他一律不做。这是最"重"的 MVP,也是验证深度最大的。

适合:已通过轻量验证,需要真实产品体验来获取深度反馈

📋 案例 1:Instagram(2010)

照片分享1个功能后来被Facebook $1B收购
背景:Burbn 是一个功能繁多的 LBS 签到 App(类似 Foursquare + 社交 + 照片),但用户只用"拍照+滤镜+分享"这一个功能。
MVP:Kevin Systrom 砍掉所有功能,只保留拍照 + 滤镜 + 分享。这就是 Instagram。
验证数据:上线首日 25,000 用户,3 个月 100 万用户——增长速度史无前例。
后续:2012 年被 Facebook 以 $1B 收购,当时只有 13 名员工。
关键教训:
① 数据告诉你哪个功能重要——用户行为比用户反馈更真实
② 做少做精 > 做多做全——Instagram 的核心体验从未改变
③ Pivot 不丢人——Burbn 到 Instagram 是创业史上最成功的 Pivot 之一

来源:Kevin Systrom, Instagram origin story; Instagram Blog, 2010

📋 案例 2:Notion(2015-2018)

生产力工具核心编辑器$10B估值
背景:Notion 最初想做"编程语言式的生产力工具",但太复杂了。2015 年发布的 1.0 版本几乎没有用户。
MVP(2.0 重构):砍掉所有复杂概念,聚焦一个核心体验:一个可以变成任何东西的文档(文档→表格→看板→Wiki)。
验证数据:2.0 发布后 ProductHunt 首日 #1,用户自发传播,等待名单暴增。
后续:2024 年估值 ~$10B,ARR >$1B。
关键教训:
① MVP 失败很正常——Notion 1.0 就失败了,2.0 才找到 PMF
② "做减法"是最难也最重要的决策——砍到核心价值
③ 文档作为最小共同界面 = 最广的适用范围

来源:Simon Last, Notion Co-founder interview; The Verge, 2018

📊 5 种 MVP 类型对比

维度🎭 Wizard of Oz🤵 Concierge💨 Smoke Test🌐 Landing Page⚡ Single Feature
成本$0-500$0$0-200$0-100$500-5K
时间1-2周1周3-5天2-3天2-4周
验证深度低-中最高
可规模化
用户知道吗不知道知道知道
适合产品类型AI/自动化服务/B2B消费者SaaS/订阅已验证方向
核心风险伦理/信任不可规模化虚假信号转化≠使用时间过长

🌳 质量 vs 速度决策树

MVP 应该做多好?取决于你的市场和用户。

Q1: 你的目标用户是谁?
├─ 企业 CIO/采购决策者质量优先——一个粗糙原型会永久损害品牌
│   └─ 但可以用 Concierge MVP(人工服务+高接触)绕过
├─ 中小企业/创业者Q2: 你的品牌有积累吗?
│   ├─ 有(连续创业者/知名团队)→ 速度优先——市场期待你的产品
│   └─ 没有 → Q3: 核心功能对可靠性要求多高?
│       ├─ 高(支付/安全/数据)→ 质量优先——出错的代价太高
│       └─ 低(内容/社交/推荐)→ 速度优先——犯错成本低
└─ 消费者速度优先——消费者容忍度高,注意力窗口短
    └─ 但 核心体验必须可靠——用户 3 秒内理解不了就流失

⚡ MVP 质量底线(不可妥协)

必须做好可以粗糙完全不做
核心功能可靠运行UI 视觉效果设置页面
用户能完成核心任务错误提示文案多语言
数据不丢失加载速度优化邮件通知系统
支付流程安全移动端适配API 文档
隐私和安全基本保障帮助文档积分/会员系统

📅 2 周 MVP 构建清单

这是给 Single Feature MVP 的计划。如果你的 MVP 需要超过 2 周,你的范围可能太大了。

任务产出关键提示
Day 1定义核心假设和唯一功能1 句话:如果用户 X,那么他们 Y写下来,贴在墙上
Day 2画线框图,确定最简用户路径3-5 个核心页面的草图纸笔 > Figma
Day 3-4搭建技术栈+核心功能开发核心功能可运行用现成框架,别造轮子
Day 5-7实现核心用户流程端到端用户能完成一个完整任务硬编码可以,先跑通
Day 8-9内部测试+修阻断性 bug无阻断性 bug找朋友测,不是自己
Day 10找 5 个目标用户测试用户反馈+行为数据观察行为,不只听反馈
Day 11-12根据反馈快速迭代V1.1只改阻断性问题
Day 13准备上线可公开访问的产品部署+域名+着陆页
Day 14发布 + 开始收集数据用户行为数据 + 反馈个人网络 > 公开发布

⚠️ 常见时间陷阱

  • 过度设计技术架构——MVP 不需要微服务,一个 Next.js 项目够了
  • 纠结 UI 细节——核心功能 > 像素完美
  • 过早添加功能——"要不要也加个 XX?" → 不!
  • 完美主义——"这个动画不顺滑" → 没人在乎
  • 用户测试拖太久——5 个用户就够了,不用 50 个

🧮 MVP 准备度评估器

评估你的 MVP 是否准备就绪——7 个关键维度。

📊 MVP 准备度自评

MVP 准备度
0/14

🛠️ MVP 技术栈推荐(2024-2025)

类型推荐方案成本理由
全栈框架Next.js / Nuxt / SvelteKit免费SSR+API 一体,部署简单
后端即服务Supabase / Firebase免费额度够 MVP免后端开发,5分钟搭数据库
AI 应用Vercel AI SDK + OpenAI/Claude按 token 计费streaming + 模型调用一体化
移动端React Native / Flutter免费一套代码双平台
部署Vercel / Railway / Fly.io免费额度零配置部署
支付Stripe Checkout / LemonSqueezy2.9%+30¢5行代码接入支付
分析PostHog / Plausible / Mixpanel免费额度了解用户行为
No-codeBubble / Retool / FlutterFlow$25-50/月非技术人员首选
数据库PlanetScale / Neon / Turso免费额度Serverless, 自动扩展
"你的 MVP 技术栈的唯一标准是:你最快能用什么做出来。不用考虑规模化,考虑速度。" — 创业工程师共识

⚠️ MVP 常见错误

🔴 致命错误

  • MVP 太大——2周变2月,2月变半年。"再加一个功能吧" → 死亡螺旋
  • 验证假设不清晰——做了产品但不知道在验证什么,数据来了也无法决策
  • 忽略核心功能可靠性——MVP 可以糙,但不能不能用
  • 过度依赖用户反馈——用户说想要 ≠ 用户会用。看行为,不只听嘴上说
  • 过早优化——MVP 阶段不需要 A/B 测试、SEO 优化、性能调优

🟡 常见误区

  • "MVP 就是不需要设计"——不需要精美设计,但需要清晰的信息架构
  • "先做给投资人看"——MVP 是给用户用的,不是给投资人看的 Demo
  • "失败了 = 浪费时间"——MVP 失败是最有价值的失败——低成本学到了真相
  • "竞品有 XX 功能我也要有"——你验证的是你的假设,不是复刻竞品
  • "我需要更多用户测试才能发布"——5 个用户能发现 85% 的可用性问题

✅ MVP 发布完整检查清单

📋 发布前

核心假设已明确定义("如果X则Y")必须
MVP 只包含 1 个核心功能必须
用户能完成一个完整的核心任务(端到端)必须
核心功能无阻断性 bug必须
已设置分析追踪(核心事件埋点)必须
有反馈收集机制(邮箱/表单/聊天)重要
已准备 5-10 个种子用户重要
验证指标已定义(达标/不达标标准)重要

🚀 发布日

产品已部署到生产环境必须
着陆页/介绍页已上线必须
注册/登录流程可用必须
错误监控已开启(Sentry 等)重要
已向种子用户发送邀请重要

📊 发布后第一周

每天检查核心指标(注册→激活→留存)必须
联系前 10 个用户做深度访谈必须
收集并分类反馈(阻断/重要/改进/忽略)重要
修复阻断性问题(只修阻断性的!)重要
一周后做 Sean Ellis 测试重要
⚠️ 免责声明:本页面内容仅供学习参考,不构成商业建议。案例数据来自公开来源,可能存在后续更新。