City strategy now includes food-pantry nonprofits as partners on the public-health benefits portal. Partners still email spreadsheets because the product has no partner workflow. What should the Product Owner do?

Partner strategy is real only when partners can work inside the product. When city strategy includes food-pantry nonprofits as partners on the public-health benefits portal yet partners still email spreadsheets because there is no partner workflow, the Product Owner should order concrete backlog items that let pantries intake, update, and hand off cases inside the product. Adding a slide about partnerships to the vision deck and waiting for a future digital-transformation program is strategy theater. Telling nonprofits to keep emailing spreadsheets so the Scrum Team can stay focused on resident self-service only ignores the partner channel the city already chose. Asking the Scrum Master to facilitate a partner working group that writes the Product Backlog misplaces ordering accountability. Exam caveat: partner workflows should still be sliced into inspectable Increments toward the Product Goal—not a separate shadow backlog owned by a working group. Operational check: add partner intake/update/handoff items, refine them with pantry users, order them against resident self-service work transparently, and inspect whether spreadsheet email volume falls after Done Increments. Preserve a single ordered Product Backlog so municipal stakeholders can inspect opportunity cost without shadow lists or vanity launch calendars.