PM technical concept: what technical debt is and how it accrues

You are interviewing for a product manager role at Coinbase, and the interviewer asks you to define technical debt. Give a definition you could use with both engineers and business stakeholders, and show that you understand where technical debt comes from and how it affects a product team's work. ```hint Follow the metaphor Real debt has a principal, interest payments and a reason someone borrowed in the first place. Work out what each of those corresponds to in a software system before you reach for examples. ``` ### Clarifying Questions - Should the definition be pitched at engineers, or at business stakeholders and executives who have to fund paying it down? - Do you want only the definition, or also how I as a PM would decide when to pay debt down instead of shipping features? - Should technical debt include design, data and documentation shortcuts, or only code and architecture? ### What a Strong Answer Covers - A precise definition built on the future cost of change, not on "messy code". - The difference between deliberate and accidental debt, and between debt and plain bugs or missing features. - Concrete examples and the symptoms through which the interest shows up, relevant to a product where reliability and security matter. - How debt is made visible and measured, and how a PM weighs paying it down against new work. ### Follow-up Questions - Engineering asks for a full quarter to rewrite a core service. How would you evaluate the request? - When is taking on technical debt on purpose the right call, and how do you make sure it gets repaid? - How would you show an executive that slowing delivery is caused by technical debt, and what evidence would you bring?