这轮验证的边界
可以确认
- 客户是否愿意为结果付费
- 交付需要哪些输入与步骤
- 哪些需求会在多个客户中重复出现
还不能确认
- 客户会购买自助软件订阅
- 人工流程可以直接自动化
- 服务客户代表完整软件市场
从一个可交付结果开始
服务方案需要写清楚客户提供什么、你交付什么、周期多长、价格多少、哪些内容不在范围内。选择客户已经在处理的具体任务，避免把完整平台愿景包装成咨询项目。
设计短周期付费试单
- 绑定一个具体工作流或业务结果
- 使用客户的真实材料完成交付
- 提前约定验收方式和时间
- 保留人工步骤，不承诺尚未存在的自动化
- 试单结束后询问继续购买的条件
每次交付都形成过程记录
| 记录项 | 要回答的问题 | 对产品决策的用途 |
|---|---|---|
| 输入 | 客户必须提供哪些数据、权限或判断 | 决定上手引导和集成范围 |
| 重复步骤 | 哪些动作在不同客户中相同 | 识别可能自动化的部分 |
| 例外 | 哪些需求每次都不同 | 避免过早标准化 |
| 结果使用 | 客户拿到结果后实际做了什么 | 判断输出是否进入真实工作流 |
| 再次购买 | 客户愿意在什么条件下继续 | 区分一次性帮助和重复需求 |
出现哪些信号再考虑产品化
- 多个客户为相似结果付费
- 主要输入和验收方式趋于稳定
- 重复步骤占据明显交付时间
- 客户愿意在没有创始人全程参与时继续使用
- 自动化能降低交付成本或提高结果一致性
服务与软件证据分开
服务付款支持的是当前结果、交付方式和客户关系。软件还需要单独验证自助使用、持续频率、订阅价格和支持成本。产品化前保留这条边界，可以避免把创始人亲自交付的价值误认为软件价值。
常见错误
- 免费定制过多，无法判断购买意愿
- 每个客户范围完全不同，却直接建设通用平台
- 没有记录人工交付时间和例外
- 把咨询关系带来的信任当成产品自助转化
- 在第一次交付后就投入完整自动化
今天可以完成的最小动作
从软件设想中选出一个客户可独立验收的结果，写成一页付费试单：目标客户、输入、输出、七天周期、价格和边界。发给三位正在处理该任务的人，请他们对真实购买条件作出回应。
证据强度与适用边界
先卖服务，再决定是否做软件
有跨来源支持先用人工交付确认客户愿意为结果付费，再判断哪些重复步骤值得产品化。
不能说明：软件一定有市场先人工跑通，再自动化
有跨来源支持在投入自动化之前，用人工后台验证输入、输出和交付频率。
不能说明：自动化后必然留存重复交付后再产品化
案例中重复出现只有在多个真实交付中重复出现的步骤，才进入模板、流程或产品。
不能说明：标准化不会降低质量