功能少，所以不能收费？有一个漂亮演示，所以已经可以收费？
这两种判断都省略了更具体的问题：客户付的钱，买到的那件事能不能被好好完成。
“最小可售产品”就是从这个角度看早期版本。它不是一个统一认证，而是一种工作上的说法：范围可以小，但收费对应的结果和必要交付要成立。
设想一个门店销售汇总工具，第一版只有一种输入模板、一个报表样式，没有复杂图表，也没有手机端。只要目标客户确实需要这一项服务，功能少本身未必构成问题。反过来，即使页面有二十个按钮，导出的数字无法核对，也很难说交付已经准备好了。
我理解的“最小”，是减少需要同时完成的事情。对已经承诺的部分，要求并不会因此消失。
例如，假设产品明确只支持表格，收到图片时给出清楚提示，就符合边界。如果把图片也收进去，再返回看似完整、实际不可靠的数字，问题就不是功能暂时不全，而是让用户误以为已经完成了处理。
收费还会把一些平时不显眼的环节带到前台：失败后怎样得到回应，已提交的材料能否取回，结果与约定不符时如何处理。早期不一定需要复杂系统，人工服务也可以，但能力和说明得对得上。
Y Combinator的Michael Seibel在访谈中区分了获得最初用户的早期产品，与产品真正适合市场这两件事。访谈来源 这提醒我们，开始有人尝试，不能直接用来证明需求已经广泛而稳定。
第一笔订单可以带来收入，也会带来新的认识。客户可能在演示时没问什么，实际使用后才发现输入要求太复杂；也可能觉得功能虽然少，却刚好解决了工作里的一项麻烦。早期的判断，需要给这些情况留出空间。
对于AI应用，我尤其在意结果从“看起来完成”到“真的能交付”的那段距离。生成成功不等于信息正确，信息正确也不保证格式能被接收方使用。
因此，可售与否并没有一条简单的按钮数量标准。它对应的是一个有限但清楚的承诺，以及完成这份承诺所必需的那些部分。