最便宜的功能，是不必开发的那个

客户会议上常听到：“如果能对接我们的系统，我们就买。”销售把需求交给产品，工程估算六周。还没人弄清究竟什么阻碍成交，任务就已进入计划。

集成确实可能必不可少。但同一句话也可能意味着不愿手动迁移数据、没有预算、新供应商批不下来，或者只是礼貌结束对话。六周开发无法提前区分这些原因。

先说清假设，再选择方案

RAT — 最高风险假设测试 是一种检验高风险假设的方法。按照 Next Move Theory 的表述，先明确事项依赖哪些条件，再根据判断错误的后果、不确定性和获取证据的成本选择验证。

不要只写“客户需要集成”，而应写具体命题，例如：“每周审批采购的连锁企业财务负责人，如果无需重复录入就能传入现有申请，愿意支付 40,000 卢布进行试点。”买家、情境、价格和可观察行为都明确了。

现在可以验证的不只有需求。数据可访问吗？谁授权？结果能否回到现有流程？实施成本后还有利润吗？成功依赖多个条件，每个都需要自己的证据。

根据未知因素选择验证方式

以一个假设的采购服务为例，团队认为集成的主要价值是自动导入申请，于是向一位合适客户提供有限试点：客户导出文件，团队手动转换格式，用户在产品中获得结果。

必须提前说明人工处理部分，让客户知道哪些已可运行、谁处理数据，以及适用条件。试点验证结果是否有用和客户是否愿意配合，但不证明尚未开发的集成可靠。

如果主要风险是技术性的，例如 API 缺字段或更新太慢，讨论价值并不能消除风险。需要在授权数据集上做短期技术测试。低成本实验只有回答了正确问题才有用。

不要混淆不同信号的强度

“听起来有意思”只说明对话中没有拒绝。愿意安排员工参与试点，是更强承诺；确认付款提供了预算和购买流程信息；反复使用则有助于判断价值是否持续。

这些信号不能互相替代。一个付费试点不能证明市场规模；免费试点不能验证定价；在创始人指导下成功，也不能证明下一位客户可以独立完成。

验证卡可以包含五项：

• 假设： 继续推进必须成立的条件。
• 参与者： 具体测试谁，以及他们为何合适。
• 观察： 能够记录什么行为或结果。
• 决策门槛： 什么结果意味着继续、改变方法或停止。
• 结论边界： 这个实验不能回答什么问题。

根据经济模型和下一步成本，在测试前设定门槛。否则团队几乎总能找到理由，把得到的数字解释成好结果。

拒绝也需要解释

假设客户认可价格，却拒绝传文件，因为导出需要 IT 协助，而 IT 没时间。团队得到的不是“没人需要产品”的结论，而是发现了一项具体上线依赖。

仍有选择：寻找其他传输方式，从已有导出文件的客户开始，或重新设计情境。如果障碍覆盖整个细分且绕过成本过高，就暂缓该方向；如果只影响一种实施类型，就不应过早放弃全部创意。

关键是书面结论：哪个假设改变了，什么现在可以视为已知。否则，一个月后失败的验证可能换个名字再次进入需求列表。

如何处理需要六周的需求

评估完整集成前，让产品、销售和工程师做一次简短讨论。明确决策、列出未知因素，选择最先可能改变计划的证据。

讨论后，集成仍可能进入开发，但会有具体情境、已验证约束和清晰验收方式。也可能客户只需要另一种导出或现成报告。无论哪种，投入工程时间都有了更明确依据。