A municipal utilities billing product has no new resident-facing screens planned this quarter. Finance warns that a single payment-processor outage would halt water-bill collection for days. Developers can reduce that risk with failover work that residents will never see as a new feature. How should the Product Owner treat that work?

Product value includes benefits realized relative to cost and risk, not only new resident-facing functionality. On a municipal utilities billing product, reducing a material operational risk—such as a payment-processor outage that would halt water-bill collection—can be more valuable than another visible screen even when residents never see the failover as a feature. That work still belongs on the Product Backlog so the Product Owner can order it transparently against other bets and keep opportunity cost visible. Rejecting the work because value only counts when a new screen appears for residents invents a feature-only definition of value that Scrum and advanced Product Ownership reject. Hiding it as a story-point buffer that Developers burn without a Product Backlog item conceals capacity use and breaks forecasting. Parking it on an IT risk register that never competes with the Product Backlog understates true cost and invites local optimization. Exam caveat: not every risk item automatically outranks every feature; compare impact, likelihood, and unrealized value—but do not exclude risk reduction from the value conversation. Operational check: add an explicit Product Backlog item for payment failover, state the risk and outcome measure (for example collection continuity), order it against current feature work with Finance and operations present, and inspect residual outage exposure after the Increment meets the Definition of Done.