On a building-permit portal, clerks want fewer clicks per review while residents want clearer status and fewer office visits. Each group says the other's request is not valuable. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
The clerk at the counter and the resident in the driveway are both in the story—they just keep score differently. Pretending only one scoreboard exists just starts a food fight. Name both kinds of value, put them on the table, and let the order show what is actually being chosen.
Full Explanation
Civic products often have internal operators and external beneficiaries with different value definitions. On a building-permit portal, clerks want fewer clicks per review while residents want clearer status and fewer office visits; advanced Product Ownership makes both sets of measures explicit and orders work transparently rather than silently picking a winner. Staff efficiency that shortens cycle time can serve residents, and resident-clarity work can reduce clerk load, but those links must be evidenced in Product Backlog order. Always preferring resident requests because internal staff are never users erases clerks as real users of the civic workflow. Always preferring clerk requests because staff time is the only measurable cost ignores resident outcomes the city exists to deliver. Averaging both wish lists into one frozen MoSCoW sheet for the fiscal year hides real conflict and freezes learning. Exam caveat: the Product Owner remains accountable for a single order; stakeholder measures inform that order—they do not replace accountability with consensus theater. Operational check: define clerk-efficiency and resident-outcome metrics, show both beside candidate items in refinement and Sprint Review, record the ordering rationale, and inspect whether the next Increment moved either measure without pretending the trade-off disappeared.