上一章我们把死结画成了五个方框，还剧透了一句话：真正的锁不在方框上，在箭头底下那些没人明说的假设。这一章就来撬锁。
每根箭头都藏着一个「因为」
云图里每一根「要想…就必须…」的箭头，读起来都天经地义。可只要你在后面追问一句「为什么必须？」，那个天经地义就会露出它站立的地基——一条没说出口的假设（assumption，你默认成立、于是从没质疑过的前提）。撬锁的第一步，是把这些地基一条条挖出来。
手法很机械：把箭头补成一句「要想 X，就必须 Y，因为______」，然后拼命往那个空里填理由，能填几条填几条。挨着救火小组那朵云的每根箭头来：
- 「要想客户觉得被重视（B），就必须把需求都马上接下来现在做（D）——因为……」
因为客户的『被重视感』只能靠『立刻动手做』来兑现；因为只要不马上做，客户就会觉得被忽视、会流失。 - 「要想质量进度可预期（C），就必须限制同时开工、排队（D′）——因为……」
因为人的注意力有限，同时开的活儿越多，每件都做得越糟越慢。 - 那根最硬的——D 和 D′ 直接打架——底下也压着假设：「把需求接下来」就等于「立刻开始做它」；接单和排队，是同一件事的两种做法，只能二选一。
挑：哪条假设不是铁律
挖出一堆假设后，第二步是挨个质问：这条，永远成立吗？有没有哪种情况它是假的？你要找的不是「大部分时候对」的假设，而是那条被你当成物理定律、其实只是习惯的假设。它一破，压在它上面的箭头就塌，冲突的一条腿当场松开。
逐条过：
「同时开的活儿越多、每件越糟」——这条基本是真的，注意力确实不能凭空复制，先放过。
「不马上做客户就觉得被忽视」——真吗？想想你自己当客户的体验：让你觉得被重视的，到底是对方立刻埋头开工，还是对方认真听你说完、给你一个靠谱的时间、然后真的按时兑现？多数时候是后者。这条假设有裂缝。
再看那条最硬的：「接下来」就等于「立刻做」。这条经不起一戳——接受一个需求，和立刻开始做这个需求，根本是两回事。你完全可以当场把需求郑重接下来、登记进一个看得见的队列、给它一个可信的交付日期，然后并不立刻动手，等前面的活儿做完再按序做。「接」和「排队」原来不是二选一——把它们当成二选一，只是一个从没被质疑过的习惯。
这就是撬锁的一声脆响。一旦「接受 ≠ 开工」这条假设破掉，D 和 D′ 就不再水火不容了：你可以全都接（满足 B，客户被认真对待），同时严格排队、控制开工数量（满足 D′、满足 C，质量进度回来了）。两个需求同时吃饱，那片乌云凭空散了。这不是各退一步的折中，是双赢——冲突根本不存在了。
把破洞变成一个具体做法：注入
假设破了，还只是一个「原来可以这样」的顿悟。得把它落成一个能写进现实的具体做法，这个做法就是注入（injection，一个一旦成真、就能让双赢成立的新举措）。围绕刚才那个破洞，注入长这样：
建立一条公开透明的需求队列：任何需求都当场接收、登记、排进队列，并给出一个基于当前队列算出来的、可信的交付时间；同时严格限制在做的活儿数量（做完一个才拉进下一个），需求按序推进，而不是一拥而上。
检验一个注入合不合格，就一条：把它放回云图，B 和 C 是不是都被完全满足了？放回去看——客户每次都被即时接待、拿到明确承诺（B 满，甚至比以前更满，因为承诺开始兑现了）；团队一次只专注少数几件事、按序交付（C 满，质量进度回来了）。两条腿都站稳，注入过关。
撬锁没有唯一的口
有件事要说清楚：一朵云有五根箭头，每根底下都有假设，撬哪一根都行。我们这次撬的是「接受≠开工」那根；换个团队，也许更容易撬「被重视感只能靠立刻做」那根，于是注入变成「一套让客户随时看到进度的透明看板」。没有标准答案。原则是：挑那条你最有把握证明它是假的、而且对应的注入你最使得上劲的假设下手。
回头看这两章干了什么：冲突图让你看清死结的结构，挑假设让你找到撬开它的那个新做法。这就是「改成什么样」的核心——不是在旧的两难里选边，而是找到一个让两难消失的注入。
可你有没有一点不放心：这个注入是我们在纸上推出来的，凭什么相信它放到真实系统里，就真能把第三章那七条 UDE 全治好、还不惹出新麻烦？这份不放心是对的。接下来两章——未来图和负面分支——就是专门用来消除这份不放心的。