How do you quantify the cost of not addressing technical debt?
Tests your ability to translate technical issues into business impact. A good answer quantifies the slowdown, calculates the 'tax' on new features, and proposes a specific, time-boxed plan. A red flag is complaining about the PO without providing data.
What's really being asked
This is a test of your ability to influence, communicate, and translate technical concerns into business terms. The interviewer wants to see if you can partner with product, not just complain about them. They are assessing your understanding that engineering's role is to enable the business, and that technical debt is only a problem when it has a material business cost.
The full answer
A strong answer articulates the problem as a business decision. First, quantify the cost of the debt using data. Don't just say 'it's slow'; say 'Features in this part of the codebase take 40% longer to deliver than similar features elsewhere.' Second, frame this as a 'tax' on every future feature. For example, 'Every new feature we build in this area will cost us an extra 2 story points until we fix this.' Third, propose a concrete, time-boxed solution, not a vague 'refactoring sprint.' Suggest 'Let's allocate 20% of our capacity for the next two sprints to address this specific module. We estimate this will take 30 story points.' Finally, present it as a business trade-off: 'We can continue paying this tax indefinitely, or we can invest 30 points now to make all future work faster and more predictable.'
The mistakes people make
A major red flag is an adversarial tone ('The PO just doesn't get it'), which shows a lack of collaboration. Another is demanding a 'tech debt sprint' or a fixed percentage of capacity (e.g., 'we should always spend 20% on tech debt') without a specific, data-backed reason tied to the current problem. Vague complaints like 'the code is messy' or 'it's hard to work with' are weak because they lack the quantitative business impact the PO needs to make a decision. Suggesting you'll work on it 'on the side' is also a red flag, as it devalues the work and hides its true cost from the business.
What usually comes next
'What if the Product Owner still says no?' (A: Discuss breaking the work down into smaller pieces, finding a compromise, or accepting the decision and continuing to document the ongoing cost). 'How would you measure the success of the refactoring?' (A: Post-refactoring, measure the cycle time for a new feature in that area and compare it to the pre-refactoring baseline).
A concrete example
'In my last role, our checkout flow was built on an old framework. New A/B tests that should have taken 3 days were taking 2 weeks—a 230% slowdown. I calculated that over the next quarter, we'd lose 40 developer-days to this friction. I proposed a 2-sprint project, costing 50 story points, to upgrade the framework. I presented it to the PO as: We can spend 50 points now, or we can lose 80 points of feature work over the next two quarters. They agreed to prioritize the refactor.'
Interview question
When presenting a technical debt issue to a Product Owner, which approach best demonstrates an understanding of business impact and effective communication?
- a.Providing data on how the debt increases feature delivery time, framing it as a recurring business cost, and proposing a time-boxed solution with measurable outcomes.Correct
- b.Expressing frustration with the existing architecture and demanding immediate prioritization of a large-scale refactor to prevent future issues.
- c.Detailing the technical challenges developers face and requesting a fixed percentage of future sprints for continuous refactoring.
- d.Emphasizing the code's poor quality and advocating for a dedicated "tech debt sprint" to improve maintainability.
Why? this is the answer
A strong answer quantifies the cost of technical debt using data, frames it as a recurring business 'tax' on future features, and proposes a concrete, time-boxed solution. Option A directly aligns with this, while other options represent common pitfalls like vague complaints, demanding resources without data, or an adversarial tone.
Just read this? Test yourself on what you have been reading.
Read the original → mountaingoatsoftware.com
- #agile
- #product-management
- #technical-debt
- #prioritization
- #influence
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
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