In a pressurized system that contains a liquid or gas, when the pressure is too high the system can rupture at its weakest point, causing a halt to operations, damage to the system and, possibly, leakage of dangerous materials into the environment. To protect against this, people install relief valves. The valves guard against excessive pressure and wrong-way flow. One type of relief valve vents into the atmosphere. It is used in applications that do not have hazardous liquids or gases. Another type can direct dangerous fluids to an alternate route, possibly collecting them in a reservoir of some sort, while protecting the system from damage.
In large organizations that use an "agile" process with a formal role similar to the Product Owner (PO) role defined in Scrum, a common problem is that the individuals assigned as POs are asked to work on more projects concurrently than they can handle with due diligence. Often, they are simply asked to add PO responsibilities to their existing workload. Thanks to the historical preoccupation with maximizing individual resource utilization in management "science," the PO’s existing workload usually does not provide any slack. In short, they are already too busy to begin with.
The POs do exactly what one would expect them to do under the circumstances: They focus on the projects that are of highest importance to them, and let the remainder languish. There are only so many hours in the day, after all. Unfortunately, despite the emphasis on self-organization in the canonical "agile" approach, in large organizations teams do not feel empowered to deal with the lack of support from their PO. The typical behavior is that a team tries to manage its own product backlog and to understand requirements and accceptance criteria without input from their PO.
It strikes me that the situation is analogous to the overpressurization of a closed fluid system. Without a mechanism to deal with it, when the PO becomes overloaded the system ruptures, useful progress is interrupted, and the system suffers damage. Projects go forward on an ad hoc basis in the interest of keeping all the "resources" fully utilized. At that point, the business outcomes of the projects are random. You might get lucky and deliver something useful. Yes, you might. Good luck.
The proper action when the PO disengages is to halt work on the project until the PO re-engages with the team. In this way, we can avoid proceeding on the basis of assumptions and guesswork, which would likely result in defects, re-work, and misalignment with stakeholder needs. That action requires courage on the part of the team; another of the canonical "agile" values that is often slighted in large-scale implementations.
The action of halting work has the same general effect as a relief valve has in a pressurized fluid system. The PO is overloaded because of decisions management makes above the PO’s pay grade. That level of management is focused on resource utilization rather than on throughput. Their career success to date has been based on maximizing resource utilization. The metrics they are accustomed to using to track progress are based on measuring utilization and not value delivered. It is not easy to teach them to think differently. A relief valve can help them learn.
We want the relief valve to be of the type that vents into the atmosphere, so that management will see clouds of steam bursting forth from troubled projects. Like the proverbial donkey, managers are teachable; you just have to get their attention first. So, when you halt work due to PO disengagement, do it noisily. Management will want to know why in the world the teams aren’t trying to push forward as best they can. The teams need the courage to explain the reasons why. Managers will next turn their wrath on the PO. The PO needs to be able to explain the negative business impact of trying to juggle too many balls at the same time. The projects that are properly supported will progress well and deliver good value. This will become obvious to management in time. The hard part is guiding them through their initial misunderstanding of the dangers of utilization thinking.
How can we tell which projects deserve our immediate focus? Initially, when the system is operating without controls, we can use the PO’s observed behavior as a guide. We can assume the projects the POs choose to focus on are the right ones. (Yes, that is an assumption, and we all know what that can mean; but it’s probably the least risky assumption available.) Later, when senior management gets a handle on throughput thinking, they will be equipped to make explicit choices about which projects deserve focus.