On the city’s building-permit product, residents seeking faster lawful permits, counter staff who operate the workflow, and the development-services director who funds the work all claim to be “the customer.” How should the Product Owner distinguish those roles?

In civic products the beneficiary, operator, and funder often differ, and collapsing them hides the trade-offs advanced Product Ownership must make explicit. On a building-permit product, residents seeking faster lawful permits typically receive the outcome value; counter staff operate the workflow as users; the development-services director funds and sponsors the work. The Product Owner must hear all three voices, but value decisions should not automatically follow the loudest funder or the most frequent operator request. Distinguishing beneficiary, user, and sponsor-funder keeps the Product Goal aimed at resident outcomes while still respecting operational and political constraints.

Treating the director as the only customer fails because budget authority is sponsorship, not the definition of citizen value. Treating counter staff as the customer and residents as downstream testers fails by optimizing internal comfort over beneficiary outcomes. Collapsing all three into one stakeholder class fails because it erases trade-offs the backlog must surface.

Exam caveat: In government products, “customer” is rarely one role; name beneficiary, user, and funder. Operational check: Label each major permit backlog theme with who benefits, who operates it, and who funds it, then order primarily by beneficiary outcomes constrained by usable staff workflow and sponsor risk.