How do you convince a PO to prioritize technical debt?

WHAT THIS TESTS: This question assesses your ability to influence without authority, your business acumen, and your pragmatic application of Agile principles. The interviewer wants to see if you can translate a purely technical problem into a business problem that a Product Owner can understand and prioritize. It's a test of partnership, not antagonism.

A GOOD ANSWER COVERS: A strong answer connects the technical problem to business outcomes and proposes concrete, incremental solutions. First, frame the issue in terms of business impact. Instead of saying 'the code is messy,' say 'our feature velocity has dropped from 20 story points per sprint to 12, and our bug rate for this module has increased 50% in the last quarter.' Second, present data to support your case, such as cycle time charts or bug count trends. Third, propose specific strategies within the Scrum framework. The most common is allocating a fixed percentage of sprint capacity, like 20%, to tech debt stories. Other options include using the 'Boy Scout Rule' or creating well-defined, estimable tech debt stories with clear acceptance criteria. Finally, show a willingness to negotiate, starting with a small percentage and measuring the results.

COMMON WRONG ANSWERS: The biggest red flag is suggesting the team should do 'shadow work'—fixing the debt without telling the PO. This destroys trust and transparency, which are core to Agile. Another red flag is blaming the PO ('they don't understand tech') instead of taking ownership of persuading them. Demanding a 'stop the world' refactoring sprint is also a sign of immaturity; senior engineers find incremental paths. Finally, using vague justifications like 'it will improve code quality' is not persuasive; you must link it to metrics like speed, cost, or risk.

LIKELY FOLLOW-UPS: Be prepared for 'What if the PO still says no?' A good response involves seeking to understand their concerns, bringing more data, or proposing an even smaller experiment. Another follow-up is 'How would you measure the success of this work?' You should be ready to name the same metrics you used to make your case: improved velocity, lower bug counts, faster cycle times, or even improved developer satisfaction scores.

ONE CONCRETE EXAMPLE: 'In a previous project, our payment processing module was so brittle that adding a new payment provider took 3 sprints. Our average for a similar-sized feature was 1 sprint. I presented this data to the PO, framing it as a 'cost of delay' of 2 sprints for every new payment feature. I proposed we allocate 15% of our capacity for one quarter to build an anti-corruption layer. We created specific backlog items for this work. After one quarter, our velocity for new payment features was back down to 1.5 sprints, and we had reduced payment-related production bugs by 70%.'