Planning, Fire, and Public Works each want their own concurrent Product Vision for the city's single building-permit portal. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
One product is one street map — two maps at once just send people down different roads. The permit portal needs a single coherent vision, not a stack of department slogans. Departments can still bring needs; those needs get ordered against one direction.
Full Explanation
A single building-permit portal needs one coherent Product Vision, not concurrent departmental visions from Planning, Fire, and Public Works. The Product Owner should insist on that one vision and use it to align conflicting narratives so the Product Backlog has a single ordering logic. Publishing three concurrent Product Visions and letting each department order its own slice fragments the product into three competing backlogs. Folding the three into the city's enterprise mission poster and stopping product-level direction leaves the portal without a usable filter. Asking the Scrum Master to pick one vision in the Sprint Retrospective misuses the Retrospective and dodges Product Owner accountability for vision. Exam caveat: one product, one Product Vision—departmental stakeholders contribute, they do not each own a parallel vision. Operational check: facilitate alignment on primary citizen and staff outcomes for permitting, publish one vision, map departmental needs as backlog themes under it, and refuse separate ordering authorities per department. One permit portal means one Product Vision aligning Planning, Fire, and Public Works narratives under shared citizen and staff outcomes. Departmental needs become backlog themes under that vision, not separate ordering authorities.