Clinic directors, council aides, and a vendor all email the public-health Product Owner with just-add-this-field requests and expect them to appear at the top of the Product Backlog. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A receptionist writes down every order; a Product Owner decides what is worth cooking. Just add this field is a suggestion, not a promise. If the inbox runs the backlog, nobody is managing value.
Full Explanation
The Product Owner is not a receptionist who appends every email to the top of the Product Backlog. When clinic directors, council aides, and a vendor all email just-add-this-field requests and expect them at the top, the Product Owner should refuse the receptionist role and keep ordering work by value toward the Product Goal. Appending every request to the top in email-arrival order replaces strategy with inbox chronology. Forwarding each request to Developers and letting them decide during the Daily Scrum misplaces ordering accountability and turns the Daily Scrum into intake. Creating a request-ticket service level so stakeholders get a guaranteed Sprint for each ask institutionalizes thrash. Exam caveat: intake channels can exist for transparency; intake is not automatic top-of-backlog placement. Operational check: capture requests as candidate items, evaluate them against the Product Goal and evidence, order only what maximizes public-health portal value, communicate declines or deferrals clearly, and inspect outcomes rather than request-response SLAs. Keep civic stakeholders focused on inspectable outcomes for residents and operators rather than inbox politics or vanity metrics.