How do you convince a PO to prioritize technical debt?
Tests your ability to influence without authority by translating technical issues into business impact. A great answer quantifies the cost of inaction (e.g., slowed velocity) and proposes concrete Scrum strategies like allocating 20% capacity.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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%.'
Interview question
When advocating for technical debt prioritization, which strategy is most effective in persuading a Product Owner?
- a.Quantifying its impact on business metrics like feature velocity or bug rates, then proposing a fixed percentage of sprint capacity for resolution.Correct
- b.Discreetly addressing the debt during regular sprint work without explicit backlog items to avoid disrupting sprint goals.
- c.Explaining that the code quality is deteriorating and will eventually lead to unmaintainable software if not addressed immediately.
- d.Requesting a dedicated "stop the world" sprint for a complete refactoring, highlighting the long-term benefits of a clean codebase.
Why? this is the answer
The card stresses the importance of translating technical debt into quantifiable business impact using data and proposing concrete, incremental solutions like allocating a percentage of sprint capacity. Shadow work, vague technical justifications, or demanding a "stop the world" refactor are explicitly identified as ineffective or detrimental.
Just read this? Test yourself on what you have been reading.
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles