最低可行产品（MVP）

最小可行产品（MVP）是指产品的最小版本，它能让团队了解客户是否需要该产品的关键信息，这一概念由埃里克·里斯在其著作《精益创业》中提出并推广。MVP 的关键特征并非在于其体积小或成本低，而在于它是为了回答一个特定的问题而构建的，并且这个问题关乎对客户行为的验证性学习，而非内部对可行性的意见。

最常见的误用是将其视为功能较少的首个版本。在时间压力下，团队会缩减范围，发布不完整的产品，称之为MVP，然后不进行任何具体的衡量，这既没有产生好的产品，也没有带来任何有用的经验教训。区分MVP的关键在于，该版本要验证的具体假设是什么，以及什么样的结果会促使团队改变方向。如果不存在答案，那么该版本就是一个小产品，而不是最小可行产品。

“可行的”这一概念也常常被忽略。一个功能精简但无法正常运行，或者连它应该实现的唯一功能都无法完成的版本，只能反映出实现方面的问题，而无法反映市场需求。如果客户因为产品运行缓慢、存在缺陷或令人困惑而拒绝使用，这并不能告诉团队产品的核心价值主张是否成立。因此，即使功能范围大幅缩减，最终包含的内容也必须足够好，能够对产品理念进行一次公平的测试。

一些成熟的模式无需构建完整产品即可解答需求问题。例如，礼宾式服务模式会先手动向早期客户提供服务，了解他们的实际需求，然后再进行自动化操作。而“绿野仙踪”式实现则提供一个可运行的界面，但其背后由人工完成。落地页测试则用于在开发开始前评估用户对产品方案的响应情况。这些方法都能提供行为证据，其效力远胜于调查和访谈中收集到的关于假设产品的陈述意向。

这种方法在某些场景下比其他场景更适用。在受监管行业、安全关键型系统以及企业销售中，一次糟糕的第一印象就可能导致多年市场流失，因此故意发布不完整的软件所带来的成本远远超过从中学习到的经验。在这些情况下，与其公开发布一个最小化的产品，不如通过原型、有知情参与者的试点项目以及分阶段向有限受众推广等方式来应用同样的逻辑。

预先确定团队停止开发所需的结果，是这项工作意义所在，也是最常被忽略的步骤。如果没有预先约定的阈值，任何结果都可能被解读为令人鼓舞：低使用率被归咎于市场营销问题，低留存率被归咎于用户引导问题，项目最终会以任何能使其继续下去的理由继续进行。在发布前，明确记录下达到何种采用率或留存率水平才算继续，达到何种水平才算需要改变策略，以及达到何种水平才算彻底停止，可以将发布变成一次真正的测试。这样做也能保护团队，因为由利益相关者共同商定的书面阈值远比事后做出的判断更容易执行。

如果运用得当，这一概念能够让团队正视构建和学习之间的区别，尤其在需求不确定性极高的情况下，它的价值更为显著。在实践中，假设和证据标准是通过以下方式建立的： 产品研究构建与 产品开发预先定义何种结果会触发方向转变，正是这种方法与单纯提前启动的区别所在。 初创公司 具体来说，这种纪律决定了有限的跑道是用来学习还是仅仅用来消耗。