For a digital building-permit system, one leader sets permitting policy while another ranks the software backlog each Sprint. How should those roles be distinguished?
Select an answer to reveal the explanation.
Short Explanation
Policy boss versus backlog boss—don’t mash them. The process owner steers how permitting works as a business process; the product owner decides which app features come next. Same project neighborhood, different job descriptions.
Full Explanation
For a digital building-permit system, when one leader sets permitting policy while another ranks the software backlog each Sprint, those roles should be distinguished: the process owner sets permitting policy; the product owner prioritizes the permit-app backlog—different accountabilities. Confusing policy ownership with product backlog ownership creates conflicting direction on civic digital products and blurs who decides ordinances versus who orders Sprint work.
Claiming both titles always mean the same person with identical daily duties fails conceptually because process policy and product backlog prioritization are distinct accountabilities even if one person sometimes wears both hats temporarily. Claiming the product owner writes municipal ordinances while the process owner only merges code reverses and muddies the roles. Claiming neither role exists on civic products so developers invent policy and backlog order alone fails because civic products still need clear policy and backlog authority.
Exam caveat: Process owner is not the same as product owner; policy versus backlog priority are separate concerns associates should keep straight. Operational check: publish a simple accountability note that permitting policy sits with the process owner and Sprint backlog order with the product owner, and escalate conflicts through governance rather than silent dual command.