The city's emergency mass-notification product must be ready every day, but it is funded by an annual project request that sometimes arrives after storm season. What funding model should the Product Owner push?
Select an answer to reveal the explanation.
Short Explanation
The fire station is not bid out every January in the hope the check clears before the first fire. Emergency notification is an always-on civic product. Standing capacity beats annual project begging that might miss storm season.
Full Explanation
Continuous critical products need standing capacity models so Current Value and Time-to-Market do not reset each fiscal year. The city’s emergency mass-notification product must be ready every day, but annual project requests that sometimes arrive after storm season treat a live emergency capability as a temporary endeavor. The Product Owner should push standing capacity for the continuous emergency-response product instead of yearly project theater. Disaster-declared restarts and folding notifications into an unrelated parks backlog hide the product and the required skills.
Continuing annual project begging and staffing a surge contractor the week a storm is forecast fails because readiness cannot wait on last-minute procurement. Pausing the product in quiet months and restarting when a disaster is declared fails by guaranteeing unreadiness. Folding emergency notifications into the parks events backlog fails by burying a critical capability in an unrelated product.
Exam caveat: Always-on emergency products need standing capacity, not annual project begging. Operational check: Replace the annual project request with a standing emergency-notification capacity line, keep a durable Product Owner and skilled team, and test releasable readiness before storm season.