Residents keep requesting a virtual park ribbon-cutting feature that analytics show almost no one would use, while a high-value trail-condition alert remains unfunded. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Popular is not the same as valuable — think of a parade that fills the comments and empties the park. If evidence says almost nobody would use the ribbon-cutting gadget, it is stealing time from trail alerts people actually need. Opportunity cost is the quiet tax on every feel-good request.
Full Explanation
Request volume is not the definition of value. When residents request a virtual park ribbon-cutting feature analytics show almost no one would use, while a high-value trail-condition alert remains unfunded, the Product Owner should kill the popular-but-unused request and order trail-condition work higher based on unrealized value versus cost. Building the ribbon-cutting feature first because request volume supposedly equals value maximizes noise. Averaging the two items into one Product Backlog entry so both groups feel heard creates a muddled item that serves neither outcome well. Asking the mayor to assign business-value points and treating that score as order substitutes political scoring for evidence. Exam caveat: evidence of use and impact outranks raw request counts on PSPO II value questions. Operational check: compare expected impact and cost of delay for trail alerts versus ribbon-cutting, show the analytics, order the alert work, and transparently decline or defer the unused vanity feature. Evidence of unrealized trail-alert value beats raw request volume for unused ribbon-cutting features; kill or defer vanity work transparently. Compare cost of delay and expected impact, then order the alert path first.