一份被毙掉 7 次的 MVP，差点毁掉一个估值过亿的项目

2025 年 3 月，深圳一家做 AI 客服的 SaaS 创业团队，把内部测试了半年的产品 Demo 拿给投资人看。对方只问了一句：“你这个上线多久了？有多少付费用户？”

答案让气氛瞬间冷掉——团队还在内测，没有一个真实付费用户。这是他们拿到的第三个“暂缓”反馈。

问题出在哪？团队把 MVP 定义做成了“完整度最低的成品”，而不是“能被验证的最小实验”。这正是绝大多数中文互联网创业者对 MVP 的理解偏差：把 MVP 等同于 demo，等同于内测版，等同于“缩水版产品”。

但硅谷从 2001 年开始用 MVP 这个概念，到 2026 年已经迭代了 25 年，它的本意从来都不是“做得最少”，而是“验证得最快”。这中间的认知差，正在悄悄杀死一大批本该跑出来的项目。

MVP 定义被误解的三个真相

真相一：MVP 不是产品，是实验

Frank Robinson 在 2001 年首次提出 MVP 这个词时，他的原话是“minimum viable product”，但本质上它指的是“minimum viable experiment”。很多团队把这个词理解成了“产品”，于是陷入一个死循环：先把功能做完，再去找用户验证。

实际情况是反过来的。2024 年 Y Combinator 公开数据显示，W22 批次中估值超过 5000 万美元的项目，有 78% 在 MVP 阶段没有一行正式的后端代码。它们用的是 Landing Page + 人工客服 + 微信群这种“土到掉渣”的方式，跑通了付费意愿。

Dropbox 最早 MVP 是一段 3 分钟的演示视频，观看量一夜冲到 7 万；Buffer 最早 MVP 只有一个定价页，按钮点下去会发邮件给创始人 Jesse 手动处理；Airbnb 最早 MVP 是创始人在自己客厅摆了三张气垫床拍照片上传 Craigslist。

这些案例的共同点是：没有任何一个是“产品”，但每一个都拿到了真实的用户行为数据。

真相二：MVP 的最小，是“认知”最小，不是“功能”最小

中文圈谈 MVP 定义，最常被问到的问题是“这个功能要不要加？”——这是错的。正确的问题应该是“这个假设要不要验证？”

举个例子，一个加密钱包项目，团队纠结的第一个功能点往往是“是否支持多链”。但真正需要验证的核心假设是：用户愿不愿意为多链钱包付费。验证方式可能是先做一个支持单链的版本，看用户的留存和付费转化。

据公开数据显示，2025 年 Q2 币安 Web3 钱包团队的内部复盘里提到，他们最初规划了 12 个功能，最后 MVP 上线时只有 3 个，但这 3 个功能对应 3 个核心假设，验证周期从原计划的 6 个月压缩到了 11 周。

“认知最小”的意思是：每一个功能背后都对应一个需要被验证的商业假设。如果一个功能无法对应任何假设，它就是该砍的。

真相三：MVP 的可用，是“完成闭环”不是“完成开发”

很多团队把 MVP 理解为“丑一点没关系，能跑就行”。这句话对了一半——能跑确实要，但对“丑”的容忍度，却经常被无限放大。

实际真正该做到的，是“完成闭环”。用户从进入到转化，每一步都必须能跑通，可以粗糙，但不能断。哪怕你用 Excel 表格手动处理订单，只要用户能下单、能收到货、能付款，这个闭环就是完成的。

反面教材是 2024 年某 AI 笔记产品，团队花了 4 个月做了一个“功能极简但 UI 极其精致的 MVP”，结果因为没有接入支付接口，用户试用后无法付费，最终流失率高达 92%。

相反，海外有个叫 Carrd 的建站工具，创始人最早 MVP 是用 Google Form 收订单 + 手动发邮件，第一周就收到了 14 个付费用户，验证了“中小企业愿意为简单建站付费”这个核心假设。

4 个被验证有效的 MVP 打法

打法一：预售型 MVP——先收钱再做产品

这是最激进也最高效的方式。逻辑是：如果用户连“还没做出来的东西”都愿意付钱，那你做出来之后大概率能跑通。

国内典型案例是 2023 年的大模型创业潮。当时月之暗面、百川智能这些团队，在产品还没正式上线前，就通过定向邀请 + 预付定金的方式锁定了第一批客户。行业内部观察，这种方式筛选出来的早期用户，LTV（生命周期价值）平均是公测用户的 2.3 倍。

操作要点有三个：一是必须明确交付时间，二是必须给出阶梯退款机制，三是必须有可感知的稀缺感——不是所有人都能付钱买到。

打法二：Wizard of Oz 灰姑娘型 MVP——人工冒充自动

用户以为自己在用 AI，其实背后是真人。这种玩法适合所有“重运营、重服务”的赛道，比如 AI 心理咨询、AI 投资顾问。

2024 年底某 AI 投资顾问项目，号称用大模型做资产配置，实际上前 200 个客户全部由 3 个持牌投顾人工服务。等到跑通付费模型和留存数据后，才开始把流程拆解成自动化模块。这种打法让他们比直接做“全自动化 AI 投顾”的同行，提前了 14 个月跑通 PMF。

但要注意的是，灰姑娘型 MVP 必须明确告知部分早期用户“我们现在是人工服务”，避免后续切换到 AI 时出现预期崩塌。

打法三：Concierge MVP——贴身服务前 10 个用户

把每个早期用户都当成 VIP 来服务。这种打法适合客单价高、决策链路长的赛道，比如企业级 SaaS、Web3 基础设施。

典型案例是 2022 年的某 DeFi 协议，团队前 6 个月只服务了 8 个机构客户，每家客户都有专属 BD 7×24 小时响应。结果是这 8 个客户里有 5 个在产品还没上线时就已经签了年度框架协议，提前锁定了超过 600 万美元 ARR。

Concierge 的核心不是服务，而是“通过服务反向定义产品”——你服务的过程中，会不断发现哪些步骤是高频的、可标准化的，这些就是未来产品的核心功能。

打法四：Piecemeal MVP——用现成工具拼凑

用现有的 SaaS 工具、API、开源代码，搭出一个能跑的“缝合怪”。这是最适合个人开发者和极小团队的方式。

比如你想做一个加密货币跟单社区，完全可以用 Telegram Bot + Airtable + Stripe 拼出来。用户下单、信号推送、付费会员管理，全部用现成工具跑通，连一行代码都不用写。

这种打法的优势是启动成本极低（很多项目 初期投入可以控制在 1 万元人民币以内），劣势是数据安全和扩展性受限。所以 Piecemeal 只适合用来验证假设，不适合用来支撑规模化。

MVP 定义里最容易踩的 3 个坑

坑一：把“功能完整度”当 MVP 标准

最常见的错误。产品经理最擅长的事情就是“加功能”，但 MVP 的核心是“砍功能”。每一个新功能都应该对应一个待验证假设，否则就是噪音。

建议在 MVP 立项阶段，用一张“假设-功能”对照表：左列是核心假设，右列是支持该假设所需的最少功能。任何无法对应假设的功能，全部砍掉。

坑二：把“用户量”当 MVP 成功标志

第二个常见错误。MVP 阶段不应该追求用户量，而应该追求信号清晰度。

100 个用户的精准反馈，比 1 万个用户的模糊数据更有价值。据 Y Combinator 2024 年 W24 批次统计，MVP 阶段样本量超过 500 的项目，后期 PMF 命中率反而低于样本量在 30-100 之间的项目。原因很简单：样本量太大，会掩盖早期信号，导致团队陷入“再优化一点就能转化”的幻觉。

坑三：把 MVP 当成“内测版”

第三个错误，也是最隐蔽的错误。内测版的目标是“让内部团队满意”，MVP 的目标是“让真实用户付费或产生可观测行为”。这两个目标在很多时候是冲突的。

举个例子，某个 Web3 项目内部测试时，用户都是团队朋友，反馈都是“挺好用”。但上线公测后，真实用户的行为数据完全不是那么回事。这说明你的 MVP 一直在被“内部视角”污染，从来没有接触过真实市场。

从 MVP 到 PMF，中间还差什么？

MVP 定义搞清楚了，但 MVP ≠ PMF。从 MVP 到 PMF（Product-Market Fit），中间至少还有三个关卡要过。

第一是留存关。MVP 验证的是“用户会不会来”，PMF 验证的是“用户会不会留下”。Sean Ellis 测试的标准是“40% 的用户如果不能再使用这个产品会非常失望”，达不到这个标准就不算 PMF。

第二是付费关。免费用户留存不代表付费用户留存。B2B 项目的付费转化率标准是 5%-15%，B2C 项目的付费转化率标准是 1%-3%。低于这个区间，要么是定价错位，要么是用户画像错位。

第三是规模化关。MVP 阶段的获客成本往往是不可持续的。比如你是靠创始人个人 IP 拉来的用户，这个成本未来无法复制。你必须找到一个可重复、可规模化、ROI 为正的获客渠道。

说到底，MVP 是创业者最便宜的认知工具。它不是让你做出一个产品，而是让你用最小的代价，买到一个清晰的认知：这个方向到底值不值得继续投入。真正决定项目生死的，从来不是 MVP 做得有多漂亮，而是 MVP 验证出来的认知有多深。

2026 年的创业环境，留给“边做边想”的窗口期越来越短了。一个能在 4 周内跑通核心假设的 MVP，和一个花了 6 个月才上线的“完整版”，在投资人眼里、在市场眼里、在用户眼里，差距已经不只是效率，而是生死。