创业想法很容易从“可以做一个应用”开始，真正需要验证的是谁在什么情况下愿意改变现有做法。
本文使用移动产品的假设案例与手工经营模型。这里讨论产品验证方法，不叙述未经记录的创业成绩。用户、订单和费用均为演算变量；商业假设需要访谈、行为数据与真实交易分别支持。
1. 从现象推到机制
把用户分组、触发场景、当前替代方案和损失分别写下来。访谈中问过去发生过什么，比问“你会不会用”更接近行为证据。口头认可不能等同付费意愿，也不能用少量熟人反馈代表目标市场。
图中的四个节点分别表示目标用户、真实场景、手工服务、行为证据。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
选择一个窄场景，先用手工服务完成一次价值交付。保留拒绝原因，尤其观察用户为什么仍选择原来的工具。
1
2
3
4
segment = "一类具体用户"
trigger = "最近一次真实任务"
alternative = "当前解决方式"
evidence = [frequency, time_cost, paid_behavior]
先把计算过程放入一张普通表格，保留原始分母、时间范围和渠道。改变一个变量观察结果，再用实际采样替换假设值；没有观测数据的地方应保持待验证。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 用户说功能不错 | 仍不能据此判断会持续使用 |
| 手工服务也无人使用 | 应先重审问题和触达 |
| 某一细分群体反复使用 | 可继续缩小目标人群验证 |
对照 1：用户说功能不错
仍不能据此判断会持续使用。观察时记录最近一次真实问题与行动。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：手工服务也无人使用
应先重审问题和触达。观察时记录邀请人数与实际参与人数。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：某一细分群体反复使用
可继续缩小目标人群验证。观察时记录按人群分层后的重复行为。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
需求验证应保护参与者隐私，只保留与假设相关的匿名信息。样本来源与招募方式也要记录，避免把关系支持误读成市场需求。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“某一细分群体反复使用”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
