最小验证不是把产品做得更小，而是把待确认的关键假设拆得更小，并用最低成本获得真实行为证据。对一人公司而言，验证的目标不是证明想法正确，而是尽快判断：问题是否真实、客户是否匹配、现有替代方案是否不足，以及对方是否愿意为改变现状投入资源。

先定义要做出的决策

在接触客户前，先写清楚两句话：出现什么信号就继续验证？出现什么信号就停止或调整？例如，至少有几位同类客户在最近一段时间遇到相似问题，并且已经用表格、脚本、人工流程或外包处理，才进入下一步；如果多数人只能说“以后可能需要”，却没有具体经历和行动，就不能把礼貌性反馈当成需求成立。

这一步的价值，在于把访谈从意见收集变成决策实验。验证对象也应先收窄到一类具有共同场景的人，而不是泛泛询问“所有潜在客户”。

用行为证据替代口头判断

最有效的问题通常围绕过去的真实事件展开：最近一次问题发生在什么时候？当时如何处理？多久发生一次？造成了什么影响？为解决它已经投入过什么？

重点不是对方是否认可你的方案，而是他是否能描述具体场景，是否已经付出时间、金钱或精力，以及是否因此产生延误、返工、加班或机会成本。问题低频但损失较大，仍可能值得验证；问题高频却几乎没有成本，则未必形成付费动力。

“你愿意购买吗”往往只能得到假设性回答。更好的追问是：如果做一个小范围验证，你愿意提供什么？可以是脱敏样本、一次流程测试、下一次演示，或一笔与验证范围匹配的小额费用。真实投入比口头承诺更接近购买意愿。

设计最小交付，而非急于开发

验证通过后，不要立即开发完整产品。先设计一个可以人工完成的最小交付，例如让客户提供一份真实资料，在约定时间内完成处理，再确认结果是否达到标准。连续几次交付出现相似流程，才说明其中可能存在产品化机会。

每次验证都应记录事实与解释：对方说了什么、采取过什么行动、问题造成何种影响，分别独立记录。完成一组同类访谈后，再判断继续、调整还是停止。若问题真实但付款方不清楚，应验证决策链；若客户需求高度分散，应缩小场景；若始终没有具体案例和行动，就应停止投入。

最小验证的核心不是降低标准，而是缩短错误投入的路径：用一次小行动，替代一轮大开发。