Stakeholders keep pulling 311 items that do not serve the published Product Goal of reducing repeat contacts for the top five request types. The Goal is rarely shown in planning conversations. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
If the destination is in a drawer, every side street looks reasonable. The Product Goal is the commitment for the whole backlog—hang it where people can see it and stack work that actually drives it. Random 311 wishes can wait their turn or get off the list.
Full Explanation
The Product Goal is the commitment of the Product Backlog; order should make progress toward that Goal inspectable. When stakeholders keep pulling 311 items that do not serve the published Goal of reducing repeat contacts for the top five request types—and the Goal is rarely shown in planning—the Product Owner should make the Goal visible as the filter and explanation for order. Hiding the Product Goal so stakeholders cannot argue with it removes the very commitment that aligns the civic product. Replacing the Product Goal each Sprint with a ranked list of department KPIs recreates a wish list and destroys focus. Allowing each stakeholder’s personal target to become a parallel Product Goal multiplies destinations until none is a commitment. Exam caveat: Goals can change when city strategy changes, but frequent churn without evidence is not adaptation—it is avoidance of saying no. Operational check: display the Product Goal in refinement, Planning, and Sprint Review; order 311 items by contribution to repeat-contact reduction; decline or defer pulls that cannot serve it; and inspect whether top request types’ repeat rates move after subsequent Increments. Keep the Goal language resident-centered—fewer repeat contacts—not a rotating scorecard of departmental vanity targets that dilute 311 focus.