MVP
最小可行产品
能让你判断「这个想法是不是错的」的最小版本。不是「能发布的最小版本」，而是「能教会你东西的最小版本」。
MVP 里 Viable 这个词承担了几乎全部的重量，而几乎所有人都把它理解错了。Viable 不意味着「最终产品的精简版」。Viable 意味着「足以测试这个产品值得构建这一假设」。一个带 Waitlist 的落地页可以是一个 MVP。一个带三个功能的可运行产品可能是比那个落地页更糟的 MVP。
举个实际例子：一位创始人确信他的假设是「用户会为自动化的发票对账付费」。本能是花三个月去构建对账引擎。测试真正这一假设的更便宜的 MVP 是一个手动的：一个落地页、一个价格，以及一个人在幕后用手做对账（一个 Wizard-of-Oz MVP）。如果没人为手动版本付费，那个引擎本会是浪费掉的三个月。构建只在付费意愿被证明之后才开始，而这正是一段发现阶段所做的那种去风险。
有一个值得知道的奥地利资助褶皱。aws Preseed 及类似拨款常常围绕达到一个「原型」或「MVP」里程碑来框定，创始人有时让拨款的定义来支配构建，把 MVP 塞满那些勾选资助框、而不是测试假设的功能。用这笔钱学得更快，而不是去造一个比学习所需更重的 MVP。拨款奖励一个里程碑；市场奖励一个被验证的假设，而这两者并不总是同一个产物。
最常见的失败是去构建你六个月前想象的那个 MVP，而不是去测试本周最不确定假设的那个 MVP。每一周最有风险的假设都在变，而多数 MVP 在发布前就已过时。诚实的取舍：一个 MVP 有意地造得不足，所以它在你脑中那个打磨光滑的东西旁边会显得不起眼，而那份不适正是快速学习的代价。如果构建阶段跑过 8 到 12 周，你造的就不是一个 MVP，而是一个用更友善名字包装的 V1。Wavect 跑朝向 MVP 的短 Agile 周期，并在给构建定范围之前先命名假设。相关：Fractional CTO 奥地利 端到端覆盖 MVP 领导。