How do you separate the 'what' from the 'how' with a Product Owner?

WHAT THIS TESTS: This tests your understanding of Scrum roles: the Product Owner owns the 'what' (the problem and business value), while Developers own the 'how' (the implementation). The interviewer is assessing your communication and influencing skills. Can you uphold Scrum principles and advocate for a better technical solution diplomatically, without creating conflict? It's a test of collaboration over correctness.

A GOOD ANSWER COVERS: A strong answer has four parts. First, express curiosity to understand the PO's underlying goal. Second, validate the user problem you are both trying to solve. Third, present the engineering alternative by translating its benefits into business terms the PO cares about: cost, risk, speed, or quality. For example, "This approach reduces future maintenance costs by an estimated 30%." Fourth, propose a low-cost way to decide with data, like a short spike or proof-of-concept.

COMMON WRONG ANSWERS: The biggest red flag is immediately confronting the PO about overstepping their role ("That's not your job"). This is adversarial and breaks collaboration. Another common mistake is arguing the technical merits in engineering jargon, which alienates the PO. A third weak answer is simply agreeing to build the prescribed solution without discussion, which abdicates the engineering team's responsibility for building a sustainable and robust product.

LIKELY FOLLOW-UPS: "What if the PO still insists?" Your answer should focus on principles, not personalities. Suggest involving the Scrum Master to coach on roles, or propose a small, time-boxed experiment to compare the two approaches empirically. "How do you prevent this?" A good answer here is about proactive education and trust-building, like inviting the PO to tech discussions or demonstrating the cost of technical debt from past decisions.

ONE CONCRETE EXAMPLE: "Our PO specified using a specific, slow, and expensive API. We asked about the core user need, which was 'real-time pricing.' We proposed using our internal data cache instead. We framed it as 'This will be 10x faster for the user and save $5,000/month in fees.' We offered a 2-hour spike to prove it. The PO agreed because we focused on user experience and cost, not just the technical implementation. It's about translating 'how' into 'what' value."