把一个想法，变成真正能解决的问题

大多数想法一开口就是解决方案：「我想要一个能自动回复客户的系统。」这种说法很自然，也正是项目在第三个月卡住的主要原因。没有明确问题的解决方案是一个移动的靶子：会议桌旁的每个人脑子里想的都不一样，任何争论都没有办法收尾。

三个必须落到纸面上的问题

是谁，在一天中的哪一刻。不是「客户」，而是那位打开工单、花八分钟在文档里翻找的客服。描述越具体，系统该做什么就越清楚，更重要的是，不该做什么也越清楚。

现在的解决办法是什么。任何问题都已经有解法，哪怕很糟：一个表格、群里的一句提问、大家都去问的那位老员工。那才是你真正的对照基线。

成功换算成数字是什么。处理时长、无需人工即可结束的比例、每周省下的分钟数。如果说不出一个指标，这个想法还停留在感觉阶段——这没关系，但下一步应该是调研，而不是开发。

一页纸的文档

写第一行代码之前先写下：使用者与场景、现有办法及其短板、成功指标、三个真实的输入与期望输出的例子，以及第一版不做什么的清单。

三个例子是关键。它们把抽象的争论变成对一个具体案例的讨论。如果这三个例子写不出来，那本身就是结论：关于系统该返回什么，团队还没有共识。