Nathan的周一：9:47前全绿，9:47后全崩

产品经理的待办清单平均存活时长不到3小时。Nathan上周五花了大半个下午打磨的路线图——色彩编码、依赖关系全清、利益相关者点头、RAG状态栏一片翠绿——在周一上午9:47分正式阵亡。

死因不是技术故障，是四连击。

第一击：销售负责人的Slack

「刚跟一个大客户聊完，他们需要X功能，能提前吗？」

没有上下文，没有替代方案，只有「能」或「不能」的二选一。Nathan还没回复，第二击到了。

第二击：CEO的回复全邮件

竞争对手在LinkedIn发了条动态，CEO转发评论：「我们也该做这个。」

没有需求文档，没有用户调研，没有资源评估。但有了CEO的注意力，这件事的优先级自动置顶。Nathan的Notion里那个叫「RAG状态」的列，开始有单元格变色。

第三击：工程师的Teams通知

「Sprint已经塞了两个计划外的Bug。」

容量是固定的。Bug是真实的。而那个「大客户需要的X」和「CEO想做的竞品功能」还没估点。Nathan的翠绿路线图，此刻像被泼了咖啡的财务报表。

第四击：那封没有上下文的转发

有人发来一篇文章：《为什么产品经理正在辜负他们的公司》。

没有评论，没有解释，没有发件人意识到这对收件人的皮质醇水平意味着什么。Nathan后来回忆，这封邮件的恶意程度堪比在手术室放《死神来了》。

到10点，他的路线图不再是路线图，是焦虑情绪板。

这种崩溃不是Nathan的专利。产品管理的日常本质是「计划-燃烧-重建」的无限循环。区别只在于：有人把燃烧当成异常，有人把它当成基础设施。

原文作者把这种现象叫「混乱大脑」（Chaos Brain）——不是待办清单有问题，是产品经理的大脑被训练成了火灾响应模式。每个新消息都是警报，每个警报都需要立即分级，每次分级都在消耗认知资源。

Nathan的周五计划之所以脆弱，不是因为他规划能力差，是因为规划本身在产品管理语境下是一种奢侈行为。真正的技能不是做计划，是做计划的同时预留被推翻的冗余。

那个全绿的RAG状态栏？它的问题不是不真实，是太真实了——真实到让人误以为稳定是常态。

10:15分，Nathan打开了一个新的Notion页面。标题还是「Q3路线图」，但第一行加了一列：「假设失效日期」。他给上周五的计划填上了9:47。

如果混乱是默认设置，你的工具箱里有没有专门处理「计划作废」的SOP？