Feature locks are sold as focus, and they do deliver it — but the focus lands on the wrong question. Before the lock, market evidence arrives as a challenge to the plan: a customer asking for something unexpected forces the team to ask whether the plan is still right. After the lock, identical evidence arrives as a scoping problem. The question quietly shifts from “is this the right thing to build” to “does this fit what we already decided to build,” and whatever fails the second test gets filed as out of scope rather than as disconfirming. The information never stops flowing. Only its filing category changes, and nobody notices, because out of scope is a legitimate answer a healthy team gives many times a week.

Picture a scheduling‑software company that locked its roadmap around a redesigned calendar view. Over the following months three enterprise prospects asked, independently, about shared availability across contractor networks — a capability the locked roadmap did not contain. Each request went into the backlog under post‑launch consideration. Nobody flagged them, because none was a defect, a blocker, or a broken promise; each was simply a thing not being built yet. The redesign shipped polished and on time into a market that had spent those months learning to ask a different question.

The costly part came afterward. When growth disappointed, the team had no record of a warning, because the warnings had all been correctly logged as scope decisions. A backlog full of deferrals looks like discipline in a retrospective; it reads as a team that stayed focused. Recovering the signal means going back through what the lock excluded, and by then the exclusions have been sorted, tagged, and buried under the assumption that scope was the issue. Focus is not the enemy here; the unexamined lock is — a decision that keeps making decisions long after anyone remembers making it.