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

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

有用的简报完成三项工作

1. 明确遇到问题的人

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

2. 为第一版划出边界

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

3. 定义接下来的证明

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

在设计屏幕前写下什么

• 首位用户：一个角色、一种情境和一个痛苦的权宜办法
• 核心循环：创造价值且可以重复发生的最小操作
• 发布边界：第一版明确不在范围内的内容
• 信任要求：用户行动前必须看到、控制或理解的内容
• 下一个验证点：值得再进行一轮构建工作的行为或对话

我使用的范围测试

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

简报的目标不是记录你可能构建的一切，而是让下一项构建决策一目了然。

我在产品启动时使用的一条规则

我在 Sirajov 如何使用它

在为构建报价前，我会把创始人的想法变成一页范围说明：一个用户、一个核心循环、支持它的屏幕和基础设施，以及应当改变下一次决策的证据。这份文件成为策略、设计、工程和发布之间的交接，也是在新功能试图混进第一版时的参考点。

常见问题

MVP 简报应该多长？

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

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

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

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

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

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

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