最小可行产品不是删掉一半功能，而是用最少投入验证一个足以改变决策的假设。
本文使用移动产品的假设案例与手工经营模型。这里讨论产品验证方法，不叙述未经记录的创业成绩。用户、订单和费用均为演算变量；商业假设需要访谈、行为数据与真实交易分别支持。
1. 从现象推到机制
先说明本轮最不确定的事情：需求、渠道、履约还是收费。若要验证履约，漂亮首页并不能替代一次完整交付；若要验证触达，先做复杂后台也无法回答问题。每轮只把一个主要假设作为决策目标。
图中的四个节点分别表示核心假设、最小闭环、观察指标、下一轮。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用注册、提交需求、人工处理、结果确认四步构成闭环。可以人工完成后台动作，但必须向用户交付真实可用的结果。
1
2
3
hypothesis = "目标用户愿意为一次完成的服务付费"
experiment = "窄人群 + 单一服务 + 人工履约"
decision = "按预先约定的证据继续或调整"
先把计算过程放入一张普通表格，保留原始分母、时间范围和渠道。改变一个变量观察结果，再用实际采样替换假设值；没有观测数据的地方应保持待验证。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 只获得浏览量 | 只能支持触达而非服务成立 |
| 有人下单但无法履约 | 核心问题在服务交付 |
| 用户愿意二次购买 | 可进一步检验重复价值 |
对照 1：只获得浏览量
只能支持触达而非服务成立。观察时记录浏览到实际提交的转化。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：有人下单但无法履约
核心问题在服务交付。观察时记录处理耗时与失败原因。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：用户愿意二次购买
可进一步检验重复价值。观察时记录复购周期与真实付款。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
实验应有事先写明的停止条件。若结果出来后不断换指标，任何小数目都能解释为成功，就失去了验证意义。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“用户愿意二次购买”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
