How do you handle an unavailable Product Owner?

WHAT THIS TESTS: This question tests your ability to proactively diagnose and solve process problems beyond your immediate coding tasks. It assesses your leadership, communication skills, and understanding of Agile principles. Interviewers want to see if you take ownership of the team's overall success and can navigate interpersonal challenges constructively, rather than just complaining or blaming.

A GOOD ANSWER COVERS: A strong answer outlines a measured, multi-step approach. First, you gather objective data. This means tracking the number of blocked tickets, the hours lost per sprint, and specific examples where a lack of clarity caused rework. Second, you initiate a direct, private conversation with the Product Owner, presenting the data not as an accusation, but as a shared problem to solve. Third, you collaboratively propose concrete solutions, such as establishing daily 30-minute 'PO Office Hours', designating a proxy for tactical questions, or improving story readiness criteria. Fourth, you explicitly mention involving the Scrum Master, whose job is to remove impediments. Finally, you state that escalation to management is a last resort, only to be used if sprint goals are consistently missed and all other avenues have been exhausted.

COMMON WRONG ANSWERS: A major red flag is suggesting an immediate escalation to the PO's manager or your own. This shows poor conflict resolution skills. Another common mistake is suggesting the engineering team should just make product decisions on their own; this usurps the PO's role and introduces significant business risk. Simply blaming the PO in the sprint retrospective without having tried to solve the problem during the sprint is a passive-aggressive approach that signals a lack of leadership. Finally, saying you would do nothing and just wait is a sign of a junior, passive mindset.

LIKELY FOLLOW-UPS: Be prepared for follow-ups like: "What if the Product Owner becomes defensive when you present the data?" or "What if your company doesn't have a Scrum Master?" or "At what specific point do you decide it's time to escalate? What metric would trigger that?"

ONE CONCRETE EXAMPLE: "On a previous project, our PO was stretched thin, and we calculated we were losing about 15% of our sprint capacity to blocked stories. I brought this data to our Scrum Master, and together we met with the PO. We proposed a new system: we'd batch non-urgent questions in a shared doc for async answers, and we scheduled two 45-minute protected 'PO Sync' blocks on the calendar each week for urgent clarifications. This reduced our blocked time to under 5% within two sprints and made the PO feel more in control."