从最小的价值闭环开始

产品的第一个版本应该验证一个闭环，而不是整个愿景。

闭环包含用户、行动、结果和再次使用的理由。如果闭环薄弱，增加页面只会给问题更多藏身之处。

功能不等于闭环

一个功能可以存在而不改变行为；闭环必须让人从意图走向结果。

例如，“创建仪表盘”是一个功能；“经理在周一会议前看到三个受阻项目”才是一个闭环。后者更容易判断，因为它有时点、用户和结果。

有用比完整更重要

完整系统构建成本高，修改成本也高。有用的闭环更容易测试。

第一个问题不应是“它能变成什么”，而应是“如果明天消失，哪一个最小的部分会被人想念？”

应该删掉什么

删掉一切无助于闭环完成的内容：

• 只服务于未来边缘场景的设置
• 没有对应定期决策的仪表盘
• 解释用户尚无法使用功能的入门文案
• 核心流程尚未能手动跑通之前的集成

应该保留什么

保留能提供证据的部分：真实输入、真实输出、真实审核节点，以及真正关心结果的用户。

闭环有效之后，扩展就更安全，产品也有了重心。