Building Technical Debt Work Into Roadmap, Quarterly and Sprint Planning
Company: Coinbase
Role: Product Manager
Category: Product / Decision Making
Difficulty: medium
Interview Round: Other
As a product manager, explain how you view technical debt within the overall planning process. Cover what you treat as technical debt, how it gets surfaced and represented when the team plans alongside roadmap work, and how you keep the balance between paying debt down and building new capabilities healthy over time.
```hint Think of it as a loan
Debt is borrowed speed, and its cost is paid every time someone works in the affected code. Ask how planning could make that ongoing cost visible next to the value of roadmap items, and whether every piece of debt is worth repaying.
```
### Clarifying Questions
- Which planning level should I focus on: long-range or quarterly roadmap planning, sprint planning, or how the two connect?
- Should technical debt include only shortcuts in the code, or also aging infrastructure, missing tests and monitoring, and outdated dependencies with security exposure?
- Is the product mature and slowing down under its debt, or early enough that taking on debt deliberately to learn faster is still reasonable?
- In the team you have in mind, does the PM decide the plan alone, or jointly with the engineering lead?
### What a Strong Answer Covers
- A clear stance on what technical debt is, including when taking it on is a deliberate and acceptable choice.
- A mechanism for making debt visible and sizing it in business terms so it can be planned against roadmap work.
- How capacity for debt is set at each planning level, and who owns that decision.
- The signals that show whether the balance is right, and how the plan adjusts when they move.
- How the approach is explained to stakeholders outside engineering.
### Follow-up Questions
- Engineering wants a full quarter for a rewrite while sales has already committed customer dates. How do you run that planning conversation?
- How would your view change for a product that holds customer funds and operates under financial regulation, where some debt is a security or compliance exposure?
- What would you track to show leadership that the time spent on debt paid off?
- Engineering has a backlog of debt items and product has a queue of feature requests, all drawing on the same engineers. How do you compare and rank the two in a single plan when one mostly removes an ongoing cost or risk and the other promises new value?
Overview: A product manager interview question on how technical debt should be represented and resourced in planning, from long-range roadmaps down to sprints. It tests whether a candidate can make debt visible in business terms, set and adjust capacity for it with engineering, and explain the balance to stakeholders.