County IT operations wants a multi-month production freeze on the public-health clinic booking product, arguing that any change risks an outage during flu season. The freeze would stop validated appointment improvements. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A total freeze is like closing the clinic so nobody can catch a cold in the waiting room — safe, and useless. The job is safer change, not no change. Risk-based releases keep the lights on without locking value in the basement.
Full Explanation
Internal operations stakeholders legitimately care about stability on a public-health clinic booking product, especially during flu season. A blanket multi-month production freeze, however, blocks inspection of valuable Increments and treats risk as binary—either freeze everything or ignore risk. The Product Owner should negotiate a risk-based release approach that protects stability while still delivering validated appointment improvements through smaller releases, feature toggles, defined rollback, or explicit release criteria. Safer change, not zero change, maximizes civic value.
Accepting the freeze as an absolute stakeholder mandate fails because it pauses all empiricism and leaves patients stuck with known appointment friction. Moving Developers onto a shadow environment indefinitely fails because work that never reaches operations cannot be inspected as real value. Asking the Scrum Master to overrule operations and ship regardless of risk fails by concept: risk management is a product decision, not a facilitation override, and reckless shipping harms patients.
Exam caveat: Stability risk is real; the professional response is risk-based delivery, not freeze-or-force extremes. Operational check: Co-design with county IT a release playbook for clinic booking that names max blast radius, rollback, and which appointment improvements may ship during flu season without a total freeze.