The Part-Time Product Owner and Three Shadow Backlogs
You are the Product Owner for a B2B payments platform used by 1,200 merchants. You also manage the customer support team, which consumes roughly 60% of your week. To keep delivery moving, you have asked a senior engineer to order the backlog and to answer most stakeholder questions. Three stakeholders-sales, compliance, and operations-each escalate conflicting priorities directly to that engineer. The last two sprints included six unplanned compliance items, and the team missed its Sprint Goal both times. Sales has promised a large merchant a custom reconciliation report next month. Compliance says the report may create an audit risk if it stores card data. The engineer is respected but has no authority over budget or contractual commitments. Your manager wants you to stay close to the team but not to reduce your support duties.
1. What is wrong with the current allocation of Product Owner accountability, and which parts of the role can and cannot be delegated?
Read the worked answer
The role has been split into visible and invisible authority. The engineer is doing backlog ordering and stakeholder handling without the accountability, decision rights, or availability of the Product Owner. That creates a shadow Product Owner and three competing intake channels. Product Owner accountability for maximizing product value cannot be delegated away; it can only be supported. Some work can be delegated: refinement facilitation, technical analysis, user research, and routine stakeholder communication with clear boundaries. What should not be delegated is final ordering of the product backlog, acceptance of the increment, and the trade-off decisions that commit the product to a direction. The engineer can recommend priority, but the Product Owner must own the decision and its consequences. The current arrangement also makes the engineer a bottleneck and exposes the team to conflicting demands that no one is resolving.
2. How should you handle the conflicting demands from sales, compliance, and operations in the next Sprint?
Read the worked answer
Bring the three demands into one transparent decision forum rather than allowing escalation to the engineer. First, separate compliance risk from sales opportunity: the audit risk is a constraint that may change the design, not a normal feature request. Ask compliance for the specific data-handling requirement and whether a spike or design review can resolve it before building. For the sales promise, establish whether the commitment is contractual and what the merchant actually needs, not just the report label. For operations, quantify the pain and the cost of delay. Then set one Sprint Goal that addresses the highest risk and value, possibly including a compliance spike plus a thin report slice. Communicate explicitly what will not be done this Sprint and why. A single prioritized backlog with visible trade-offs is the only way to stop the team from absorbing three conflicting priorities as unplanned work.
3. What concrete changes would you propose to make the Product Owner role effective without abandoning your support responsibilities?
Read the worked answer
Propose a bounded redesign, not a heroic workload. Name a support team lead with clear operational authority so you can reserve protected Product Owner time, for example two fixed blocks per week for refinement, stakeholder decisions, and Sprint Review. Create a single intake route with a published decision cadence, and stop the practice of stakeholders going directly to the engineer. Define which decisions the engineer may make and which must return to you. Use a weekly product decision meeting with sales, compliance, and operations to resolve trade-offs before Sprint Planning. Make your availability and decision latency visible as a service level. If support truly requires 60% of your week, ask your manager to choose between reducing that load and accepting slower product decisions; both cannot be optimized indefinitely. The goal is not to be closer to the team in hours, but to be reliably available for the decisions only the Product Owner can make.