When the Process Works and the Product Doesn’t
A release that shipped four days early and met ninety-one percent of its committed objectives, a feature two hundred and eleven people used against a forecast of forty thousand, and why a process that runs perfectly can carry you with great confidence in the wrong direction.
We shipped the release four days ahead of its committed date, and I was proud of it at the time.
The numbers around that release were the kind a programme is supposed to want. We had met ninety-one percent of our Program Increment objectives that quarter, and our predictability measure had stayed above eighty percent for a year. Every system demo had run on schedule, every ART sync had happened, and the inspect and adapt workshop had produced a tidy list of improvement actions that were tracked and closed. By every measure the methodology handed us, the programme was in good health. The feature we had built across four Program Increments was used, in its first quarter in the field, by two hundred and eleven people. The business case had forecast forty thousand.
The distance between two hundred and eleven and forty thousand is the subject of this essay. That distance did not open up because something had gone wrong in delivery, since delivery was the part of the programme that had gone right. We had built the thing we set out to build, on close to the schedule we had promised, and to the quality we had defined. The process did everything it was designed to do, and the product still found almost nobody.
A scaled method like SAFe is a Stated System of unusual completeness. It tells you how to plan, how often to synchronise, how to demonstrate working software, and how to examine your own performance and adjust it. When an organisation runs the method well, it generates a steady supply of evidence that it is running the method well, and all of that evidence is real. Objectives are met, demos are held, dependencies are surfaced and managed, and a predictability number trends in a reassuring direction. Every piece of it answers one question, which is whether we are following the method as it was designed. None of it answers the separate question of whether the method is aimed at something worth building.
The gap between those two questions is what I call the Drift, the distance between the system an organisation says it runs and the system it lives inside. Most of the time the Drift hides in the difference between a documented process and a far messier reality. This was the stranger version of it, where the documented process and the lived reality matched almost perfectly, and the Drift had moved somewhere much harder to see, into the space between a programme running correctly and a programme building the right thing.
Two kinds of green
Running a process well creates a particular hazard, which is that the health of the process is easy to read while the health of the product is not. Process health arrives every week, in formats designed to be legible to anyone glancing at a board. Product truth arrives quarters later, out in the field, long after the increment that produced it has closed and been celebrated. The two signals run on different clocks, and the faster, louder one is the one that comes from the method.
When the cadence is green, almost everyone reads it as the programme being green, including the people senior enough that they ought to know the difference. I read it that way for most of a year. The board told me a coherent and encouraging story every week, and the story was true as far as it went. What it could never tell me was anything about the forty thousand people who were, at that point, an assumption in a spreadsheet rather than anyone we had spoken to.
Where the objective comes from
Program Increment objectives feel like the beginning of the work, although they sit closer to the middle. They arrive already shaped by a roadmap, and the roadmap arrived already shaped by a business case that somebody wrote long before any of us could have known whether it would hold. The ceremonies of the method are very good at turning an objective into working software. Not one of them is built to ask whether the objective deserved to exist in the first place.
There is a place in the method for the question of whether we built the thing right, and the system demo and the definition of done both serve it well. There is also, on paper, a place for the question of whether we are building the right thing, which lives in the feedback the system demo is meant to gather and in the customer involvement the framework recommends. That second place is the first one to be skipped when a programme is busy, and a healthy programme is busy without interruption. The question that most needs an answer turns out to have the weakest hold on the calendar.
A predictable programme is one whose reality matched its plan, and a plan can be predictably and confidently wrong.
The year I did not ask
My role was to keep the trains running, and I kept them running well. The questions I brought to planning were about capacity, sequence, dependencies, and risk, and they were good questions to bring. Every one of them took for granted that the objectives in front of us were worth delivering. I never stood up in a planning event and asked who the forty thousand were, or how we knew they wanted what we were about to spend a year building. Asking it belonged to no role on the train, which meant, by the ordinary logic of organisations, that it belonged to no one.
The feature shipped on time and to specification. The system demos had looked strong because the software did what the stories described, the stories did what the features described, and the features did what the roadmap described. Every link in that chain was sound. The chain was bolted, at the far end, to an assumption about demand that nobody had returned to in eighteen months, and a sound chain anchored to the wrong wall will hold a great deal of weight in the wrong place.
One of our engineers, late in the third increment, put a question to me that I could not answer well. She said: do we know anyone who is waiting for this. I said: it is on the roadmap, and it tested well in the review. She said: that is not the question I asked you. She was right, and I changed the subject, because the honest reply was that I did not know a single person who was waiting for it, and I had never thought of that as a gap in what I was supposed to know.
The diagnostic
The question that finally made me look at the programme honestly was a count rather than a judgement. How many of the objectives we committed to over the last four Program Increments had changed because of something we had learned, rather than because of something we had planned? I went back through the records and counted them properly. Of thirty-eight objectives across four increments, thirty-seven traced in a straight line to the roadmap as it had stood at the start of the year. Exactly one had changed in response to evidence from a real user, and it had changed only because the engineer who put that question to me had gone out of her way, outside any ceremony, to watch somebody try to use what we had made.
A feedback loop that produces a single course correction in a year is not a feedback loop in any working sense. It is a roadmap with ceremonies arranged around it, and the ceremonies were doing their job beautifully. They were converting a fixed set of assumptions into shipped software at a steady and predictable rate. The predictability I had been proud of was, read in this light, a measure of how faithfully we had executed a plan that we had never once tested.
Take the objectives your programme has committed to across its last three or four increments and sort them into two piles. In the first, the objectives that came straight from the roadmap as it already stood. In the second, the objectives that exist because of something the programme learned from a user, a customer, or the field after the work had begun. Count both piles before you defend either of them. Where the second pile is empty or close to it, a strong process is carrying you somewhere nobody has checked, which is a more comfortable position than a weak process and a considerably harder one to notice.
What changed when I started asking
What I changed was small, in keeping with the fact that the process did not need rebuilding. I began reserving the first fifteen minutes of one planning event each increment for a single question, put to the people in the hall before any objective was confirmed: what have we learned since last time that should change what we are about to commit to. For the first two increments the answer was close to nothing, because no one had been given the job of learning anything between increments, and you cannot report findings you were never resourced to gather.
The question kept being asked, increment after increment, and because it kept being asked it slowly began to attract answers. People started arriving with small pieces of evidence, a recurring support theme, a thing a customer had said in passing, a number from the field that did not match the forecast. The objectives began, in modest ways, to bend towards what we were learning. Our predictability measure dipped for a couple of increments while this happened, and that dip was the first time I understood that falling predictability can be a programme starting to listen rather than a programme starting to fail.
The methodology was never the villain of this story, and tearing it out would have cost us the one thing we were genuinely good at. A process that runs well is a real achievement and worth protecting. What a process cannot do, however well it runs, is tell you whether the thing it is building deserves to be built, and the better it runs the more confidently it will carry you past the point where you ought to have stopped to check. The green that means the method is healthy and the green that means the product is wanted are two different colours, and learning to tell them apart is most of the work.
The scenes in this article are anonymised and, where necessary, composited from multiple professional contexts. The figures are illustrative of the pattern rather than drawn from a single team. They are intended to describe an organisational pattern, not a specific employer, programme, or team.
The distance between a process that runs well and a product worth building is one thread of the Drift framework, the spine of my forthcoming book Leading Agile When No One Agrees, which works through it across twenty-two chapters of scenes drawn from fifteen years inside agile transformations. The book is in final preparation for a Summer 2026 publication. If this piece resonates, the companion worksheets may be useful in the meantime, starting with the five-question Drift Check. For anyone who would rather work in a terminal, drift-cli runs the same check locally and never sends the result anywhere.
More writing and book launch updates at kylehauslaib.com.