章节 35

路线图吞掉了用户

为什么团队明知没用，却还在继续做

路线图不再是计划，而成了你服务的对象。

这个转变很容易被忽略。发生时，它听起来很负责任。团队不再问用户需要什么，而开始问，如何兑现三次规划会议之前许下的承诺。

这里谈的是对计划本身的承诺：日期、范围、里程碑，以及已经许下的诺言。路线图在会议室里的分量，开始超过后来收到的用户证据。

承诺开始替你思考

Barry Staw在 1976 年描述了承诺升级。觉得自己要为之前决定负责的人，在情况变糟之后，反而会投入更多资源。他写道：“当人们需要为负面后果承担个人责任时，他们向先前选定的行动方案投入的资源最多”（译自英语）。

路线图在公司内部，就可能变成这样。它不再让人觉得只是一个粗略估计，而开始像一串公开承诺。一旦如此，改变方向就不再像是对产品有了新认识，而像是失败。

Kahneman和计划谬误在这里很重要，因为计划总是带着虚假的信心出现。团队想象工作应该怎样推进，而不拿它与同类工作通常如何推进作比较。路线图一开始就过度自信，之后又被当成现实来捍卫。

所以，路线图的语言很快就会变得危险。日期和里程碑一旦写下来，就不再像暂定的，而开始像是已有充分根据。团队忘了，计划是在先前条件下作出的猜测，转而把它当成了未来必须遵守的东西。

FBI 在 Virtual Case File项目上花了五年和 1.7 亿美元。工程师警告过问题。外部评审人员警告过问题。证据不断进来。项目却仍然往前走。2005 年 4 月，FBI 放弃了它，甚至没有部署。

这个案例的重要之处就在这里。项目继续推进，不是因为价值突然变得更清晰。而是因为计划、金钱、政治分量和组织认同，都已经绑在了把它做完这件事上。

路线图可以不断把旧承诺变成新压力。

大多数产品团队永远不会负责那么大的项目。但在更小的会议室里，机制一样。规划时宣布了一个功能。销售听到了。营销把它放进演示稿。管理层在评审时重复了日期。然后新的用户证据来了，却没人想成为那个说“这个承诺该撤回”的人。

这时，功能不再是对问题的回应，而变成了团队觉得自己必须兑现的诺言。一旦发生这个转变，改变方向听起来就像不忠，而不是明智。

路线图一旦定死，用户问题就开始从讨论里淡出。

你不再问“我们还该做这个吗？”，而开始问“第三季度怎么把它交付出去？”你不再问这个功能是不是正确答案，而开始问在那个日期之前，哪个版本可行。内部视角接管了判断。团队对计划的细节很熟，于是计划开始比后来收到的用户信号更像现实。

我见过这样的团队：房间里每个人都知道某个功能很弱，却仍然只从交付风险的角度谈它。那时，路线图已经赢了。

语言也会在这里暴露问题。人们开始说“我们需要履行承诺”，或者“已经走得太远，不能再重新讨论范围”。听起来很有纪律。有时，却只是事实变了以后，大家还在捍卫一个计划。

在日历上安排一次不谈进度状态的会议。用它重新问一遍问题。

问题应该很简单：如果今天开始，带着我们现在知道的一切，这件事还会在路线图上吗？不是“我们按计划推进了吗？”那个问题只衡量对计划的忠诚。要问的是，这个承诺是否仍然值得存在。

如果答案是否定的，就改路线图。这不是偏航。这就是工作。

如果答案是也许，就让这个也许明确摆到桌面上。太多路线图评审，从进度汇报直接跳到互相宽心。有用的会议，会先把不确定性摆出来，免得大家在尚无把握的情况下继续投入，让改变越来越难。

如果你连“我们没有两周前那么确定了”都不能说，否则整个房间就紧张起来，那路线图已经太强大了。我参加过这样的会议。话还没说完，就能感觉到气氛绷紧。

用户不在乎承诺是在哪个季度许下的。他们只会遇到最终上线的东西。