After a city reorganization, it is unclear whether resident accounts, payments, and notifications are one product or three, and three people claim Product Owner accountability. What should the Product Owner insist on first?
Select an answer to reveal the explanation.
Short Explanation
If nobody can say what the product is, three “Product Owners” are just three people arguing over a unlabeled box. After a reorg, draw the product boundaries and the accountability first. Everything else—vendors, roadmaps, extra teams—will multiply the confusion.
Full Explanation
Reorganizations often leave product identity and Product Owner accountability ambiguous. After a city reorg, when it is unclear whether resident accounts, payments, and notifications are one product or three, and three people claim Product Owner accountability, ordering conflicts and duplicate backlogs follow. The Product Owner should insist leadership clarify product boundaries and Product Owner accountabilities before more delivery structure is layered on. Velocity contests and delayed boundary decisions make the structural mess more expensive.
Launching three separate vendor contracts before clarifying products fails by locking confusion into commercial walls. Letting each claimant order a shared backlog until velocity reveals a winner fails by substituting a contest for leadership clarity. Writing a two-year feature roadmap to postpone the boundary question fails by decorating ambiguity instead of resolving it.
Exam caveat: After reorgs, clarify product boundaries and single Product Owner accountability first. Operational check: Facilitate a leadership decision that names whether accounts/payments/notifications are one product or several, assigns one Product Owner per product, and retires competing backlog claims.