方法

MVP

最小可行产品

能让你判断「这个想法是不是错的」的最小版本。不是「能发布的最小版本」，而是「能教会你东西的最小版本」。

最近审阅: 2026-05-24 审阅人Kevin Riedl wiki ↗

MVP 里 Viable 这个词承担了几乎全部的重量，而几乎所有人都理解错了。Viable 不是「最终产品的精简版」。Viable 是「足以验证这个产品是否值得继续做的假设」。带 Waitlist 的落地页可以是 MVP。带三个功能的可运行产品可能是比落地页更糟的 MVP。

最常见的失败：去做你六个月前想象中的那个 MVP，而不是去做能验证「本周最不确定的那个假设」的 MVP。每一周「应该验证的假设」都在变。多数 MVP 在发布前就已经过时。

Wavect 的 Discovery 阶段一部分就是用来修复这件事。在划定 MVP 范围之前，我们先命名它要验证的假设。如果假设是「用户想要功能 X」，那 MVP 就不是一个被打磨光滑的功能 X，而是「最便宜的方式去找出答案」。

// FAQ

常见问题

常见问题

Prototype 是给团队内部看的演示，目的是探索可行性。MVP 是给真实用户用的产品，目的是验证一个商业假设。把 Prototype 当 MVP 发出去，得到的反馈基本是垃圾；把 MVP 当 Prototype 关在内部，浪费时间也学不到东西。
看「你要验证什么假设」。验证「有人愿意付钱」的 MVP 可以是一个 Stripe 链接加落地页，一周搞定。验证「这套技术架构能跑通」的 MVP 可能要四到六周。先命名假设，再决定时间。反过来做永远超期。
去做六个月前你想象中的那个 MVP。市场每周都在变，「最该验证的假设」也每周在变。多数 MVP 在发布前就已经过时。Wavect 的 Discovery 阶段就是用来强制重新命名假设，而不是直接开始写代码。