The city publishes an OKR to cut childhood vaccination gaps by 15 percent. The Product Owner of the public-health clinic portal is asked to support the OKR with more portal features. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A city OKR is the scoreboard; a product hypothesis is the play you think might move the score. Slapping vaccination gap on every ticket is decoration. Pick a few portal bets you can actually test against that number.
Full Explanation
City OKRs inspire product hypotheses; they are not automatic Product Backlog labels or Sprint Goals. When the city publishes an OKR to cut childhood vaccination gaps by fifteen percent and asks the clinic-portal Product Owner to support it with more portal features, the Product Owner should derive testable hypotheses about which portal changes could move that OKR. Adding the city OKR as a label on every existing backlog item so reporting looks aligned is semantic theater without causal thinking. Promising the OKR as the next Sprint Goal regardless of what Developers can complete misuses the Sprint Goal and overclaims. Replacing the Product Goal with the city OKR word-for-word and stopping inspection of product outcomes erases intermediate product commitments. Exam caveat: product work should connect to strategy, but connection requires a hypothesized mechanism and measures—not slogans pasted onto unrelated items. Operational check: state hypotheses such as reminder or language-access changes lifting completion in gap cohorts, order thin experiments, inspect vaccination-related portal outcomes, and report contribution honestly without claiming the whole city OKR as one Sprint’s Done.