The Product Owner With a Title but No Decision Rights
At Northwind Retail, a 7-person digital store operations squad supports 420 stores. The product owner was promoted from store operations six months ago. A five-person steering committee-merchandising, supply chain, finance, IT, and customer care-meets biweekly and resets the sprint priorities. The PO cannot say no to any director; average age of top backlog items is 97 days. Sprint review requires sign-off from four stakeholders, and the team waits an average of three days for answers. Two of the last four sprints missed the sprint goal because work changed mid-sprint. The team has 45 refined items, but only six are connected to any stated outcome. The CIO says the PO 'owns the backlog' but also says the committee 'owns prioritization.' The team is competent and frustrated.
1. Diagnose the decision-rights problem. What authority must the product owner have, and how should the PO establish it without alienating the committee?
Read the worked answer
The symptom is not a weak PO; it is an unresolved decision-rights design. A committee can own strategic constraints, funding, and cross-portfolio trade-offs, but one person must own ordering of the team backlog and the sprint goal. Without that, the team cannot forecast, and the 97-day age of top items shows the cost. Recommend a written decision-rights charter: the committee sets product goal, budget envelope, and policy constraints; the PO orders the backlog, accepts stories, and can say no within those constraints; urgent mid-sprint changes go through the PO and require an explicit trade-off. Agree an escalation SLA-for example, two business days-so the three-day wait does not become normal. Use a RACI or authority matrix for backlog, sprint scope, acceptance, and stakeholder requests. The PO should not demand authority abstractly; propose the charter to the CIO with evidence from the missed sprint goals. This makes accountability match control and gives directors a legitimate route for influence.
2. How should the product owner handle the requirement for four-stakeholder sign-off at sprint review?
Read the worked answer
Sprint review should be an inspection and adaptation event, not a four-person approval gate. If four stakeholders must sign off, the team is optimizing for consensus rather than learning. Recommend moving acceptance to the story level: agree acceptance criteria and Definition of Done before development, have the PO accept work, and use asynchronous review for stakeholders who need visibility. Keep the sprint review for demonstrating an integrated increment, discussing outcomes, and collecting feedback. If governance genuinely requires sign-off, define one accountable approver and a time-boxed response, with silence treated as acceptance after a stated period. Pre-brief the approvers on scope and evidence so the review is not the first time they see it. This preserves stakeholder input while removing a structural blocker that contributes to the three-day waits and mid-sprint churn.
3. What should the PO do in the first 30 days to improve flow and accountability?
Read the worked answer
First 30 days: create a single product goal and a visible outcome map for the squad. Take the top 10-15 backlog items and trace each to a store-operations outcome, a customer outcome, or a compliance obligation; park the rest rather than pretending they are prioritized. Draft the decision-rights charter with the CIO and committee, including how urgent requests are handled and the escalation SLA. Establish a weekly stakeholder intake and a published decision log so directors see where their requests stand. Protect the sprint goal by requiring any mid-sprint change to come with a trade-off: what comes out. In parallel, change sprint review to a demo and outcome conversation, with asynchronous acceptance. Measure the intervention: sprint-goal success, average age of top items, wait time for decisions, and percentage of backlog connected to outcomes. Review after four sprints with the CIO. This sequence addresses authority, transparency, and flow rather than blaming the team.