最小产品的任务不是“尽快做出一个像样的版本”，而是以最低成本验证一个可证伪的需求假设。真正需要回答的不是用户是否喜欢创意，而是：目标用户是否在具体场景中反复遇到问题，是否愿意投入时间、数据或金钱解决它，以及产品能否以可控成本交付结果。

先验证问题，再验证功能

一个合格的需求假设应当足够具体：某类用户在某种场景下，因某个高频问题产生明确损失，并愿意通过某种方案改善结果。若只能描述为“大家需要更高效的工具”，就无法判断该做什么，也无法解释用户为什么不购买。

验证顺序应从低成本证据开始。访谈适合确认问题和现有替代方案，手工服务或模板适合观察用户是否愿意接受结果，最小软件版本则用来测试关键流程。若人工交付已经无人愿意使用，直接开发完整产品通常只会放大错误。

关注行为证据

点赞、口头认可和“听起来不错”属于低强度信号，因为用户几乎不需要承担成本。更有价值的证据包括：

• 用户主动提供真实数据或业务场景；
• 用户完成安装、配置或核心操作；
• 用户愿意付费，或持续投入时间使用；
• 用户的问题集中在细节，而不是反复追问产品有什么用；
• 用户把产品用于真实任务，并因此改变原有流程。

不同产品的验证周期和信号并不相同。一次性模板重点看购买与交付，分析工具要观察持续使用，教育产品要关注完成和实践，平台产品还必须验证供给与需求能否同时出现。上线速度不能替代验证速度。

给实验设置停止条件

发布前就应写清楚实验要验证的假设、关键行为、分发方式、时间上限和维护边界。若用户无法理解价值，核心行为长期没有发生，需求不断分裂，或支持成本持续上升，就应暂停，而不是用新增功能掩盖证据不足。

停止并非失败，而是排除一个方向。最小产品的价值，正在于让创业者尽早获得真实反馈，并把沉没成本控制在可承受范围内。能明确知道“这次实验验证了什么、证据有多强、下一步最多投入多少”，才算真正完成了需求验证。