We are running pilot teams inside a large product organization, testing a way of working its leadership believes in. The framework was sound before we started. Almost nothing else survived contact.
The plan assumed we could pick the work. We wanted pilot teams running one kind of product work so the results would compare cleanly. That broke in the first weeks. Teams are where they are in their lifecycle, and you cannot schedule reality around a study design. The fix was to trade constraints for guardrails: reach for the new tooling first, hold the quality bar, make work across functions. Guardrails travel. Constraints do not.
We expected the friction at adoption. The loudest signal came from somewhere else entirely: the quality of how work gets defined before anyone touches it. When production gets fast, a vague work definition fails faster and louder than it used to. And the bottleneck moves downstream. When generating is cheap, reviewing becomes the constraint, and nobody had planned for that.
The most expensive gap is the one between wanting to contribute and making a first real change. People across functions wanted in. Almost none of them had a clear path to a first working contribution, and each one stalled at a different small obstacle. A plain ten-step guide to a first real change turns out to be worth more than any amount of vision.
One finding we did not expect: the teams that went furthest in reported better collaboration across functions, not worse. The tooling did not isolate people. It gave them a shared way to show each other work.
None of this is in the framework, and that is the point. A framework is a hypothesis. Pilot teams are the evidence.