MVP 简报：你的第一个产品决策

最好的 MVP 简报并不长。它决定产品服务谁、第一版明确不做什么，以及什么证据值得投入下一周的工作。

简短回答

一份有用的 MVP 简报会在设计开始前做出三个决定：产品服务谁、第一版将刻意省略什么，以及什么用户证据能证明下一笔投入合理。这就是简报不是文书工作的原因；它是第一个产品决策。

创始人常带着一份实际上只是想法说明的简报而来：几段市场介绍、一个功能清单，以及一句关于产品未来可能走向何处的话。它足以开启对话，却不足以据此发布产品。构建团队需要一份更小、更聚焦的文件，把雄心转化为一系列可验证的选择。

有用的简报完成三项工作

“小企业”是一个市场，不是首位用户。一份好的简报会明确这个人、他们所处的时刻，以及他们今天使用的临时办法。试图填补明天取消预约的诊所经理，与正在寻找新预约的患者面对的是不同问题，即使两者都属于医疗领域。首位用户越具体，越容易决定产品下一步该做什么。

功能清单告诉你人们设想了什么；范围边界告诉你将构建什么。用一句话写下核心循环，然后列出让它可靠运行的工作：主屏幕、一个有意义的操作、背后的数据，以及告诉用户它成功了的反馈。其他一切都是以后再考虑的候选项，不是发布时默认的要求。

“发布后看看会发生什么”不是学习计划。决定你期待在最初几周观察到什么：完成的工作流程、重复操作、付费转化，或创始人与特定类型用户进行的访谈。这个衡量不必复杂；它需要足够接近用户行为，才能改变下一个产品决策。

逐一审视每项拟议功能，并问一个问题：它会不会让核心循环更可能为首位用户成功？如果答案是否定的，就把它移出第一个版本。如果答案是可能，写下它在保护的假设，并找一种更便宜的方式测试该假设。这样可以防止一项有用功能成为永久拖延产品的借口。

简报的目标不是记录你可能构建的一切，而是让下一项构建决策一目了然。
— 我们在产品启动时使用的一条规则

MVP 简报应该多长？

应当短到能一口气读完，又具体到足以做取舍。当它明确了首位用户、核心循环、发布边界、信任要求和下一个验证点时，一到两页通常已足够。

简报应该包含完整的功能清单吗？

包含让核心循环运行所需的功能，然后把其他内容放在后续想法部分。单独的搁置区能保护好想法，又不让它们悄悄变成发布要求。

如果目标用户仍不确定怎么办？

写下最有力的两个候选人，以及能区分他们的证据。不确定性在明确时是有用的；隐藏在宽泛产品范围中时就会变得昂贵。

设计开始前必须完成简报吗？

它应该清晰到足以指导第一轮设计，而不必永远冻结。设计可以揭示更好的问题，但每项改变都应更新范围以及你正试图收集的证据。