资源有限时，把产品所有功能都做完整再上线，往往等不到上线就已经错过时机。MVP（最小可行产品）提供的是另一种思路：先用最小的功能集合验证产品是否真的被需要，再决定后续投入。
核心思路
MVP 不是“只做一半”，而是用最少的功能验证一个关键假设。所以在动手之前，必须先想清楚：这次要验证的到底是什么。如果连假设都不明确，做出来的最小版本就只是残缺版本，验证不了任何东西。
三个要素
第一是明确要验证的核心价值，也就是用户最根本的那个诉求；第二是在功能上做减法，只保留能跑通核心流程的部分；第三是建立可以量化的观察指标，让结果能够被判断，而不是靠感觉说“效果还行”。
常见误区
把体验残缺的半成品当成 MVP，是典型的误用；只看点击、下载这类表层数字，不去理解用户为什么这么用，会得出错误结论；后续迭代时随意添加功能，让产品偏离最初的定位，也是常见的失误。
适用边界
MVP 适合不确定性高、需要快速试错的场景。如果需求本身已经很清楚，过度追求“最小”反而会拖慢进度，让原本可以一次做好的事情反复返工。
MVP 是一套决策方法，不是缩减成本的借口，也不是跳过系统设计的捷径。