产品总监Sarah在内部会上摔了一份需求文档。过去18个月，她的团队提了同一个功能5次，工程师每次交付的东西都和预期差一截。不是代码有问题，是理解从根本上就歪了。

这事像点奶茶备注"少糖"——店员听成了"少冰"，杯子上标签没错，喝一口你就知道完了。Sarah发现工程师们从不问"为什么要做这个"，只问"做什么"。需求文档写得越详细，他们越像执行指令的打印机，而非解决问题的搭档。

她后来改了打法：每次开需求会只给场景，不给方案。让工程师自己推导技术路径，再反过来问她"用户这时候最疼的点是不是这个"。「以前我以为说清需求是我的工作，现在发现让工程师真正听懂才是。」

三个月后同一批人，同样的复杂需求，一次过。没人加班重写，也没人私下吐槽"产品又变卦了"。

Sarah把这次经历写进了晋升答辩材料，标题叫《The Foregone Solution》——预设答案的解法，从来都不是解法本身。