EP. 03 –Technical Debt is a Product Decision
Ramblings of B × C
32 views
Who owns technical debt and do product and engineering even mean the same thing when they talk about it?
In this episode of Rambling of BxC, Chinedu and Bosun discuss the statement: “Technical debt is a product decision.” What starts as a yes-or-no question becomes a conversation about what teams ship, what they leave for later, and what happens when “later” never comes.
Chinedu starts with refactoring, database migrations and engineering cleanup in mind. Bosun brings another perspective: the product decisions that lead teams to defer work, accept shortcuts and keep moving to the next priority.
Such a fun conversation. Both learn in real time, adjusting, adapting and revising opinions they held at the start. They don’t agree on everything, and that’s part of what makes it worth listening to.
The discussion covers:
• How product and engineering view technical debt differently.
• Why deferred features and temporary fixes linger in the backlog.
• The tension between shipping new features and improving existing systems.
• When performance, reliability and scaling issues make the work urgent.
• Leaving code better than it was found—and the practical limits of doing that.
• How AI coding agents can help clear technical debt while creating new problems.
• Why engineering work can be difficult to justify without a clear business case.
• Comparing the cost of fixing debt with the cost of doing something else.
Bosun shares examples involving workflow patches, caching and traffic spikes, while Chinedu explores what it takes to make those engineering concerns meaningful for product priorities and business goals.
One question keeps coming back: what is it going to cost if that debt is not paid?
Listen in, and share your perspective in the comments: who owns technical debt on your team, and how does it get prioritised?
Subscribe for more conversations with Chinedu and Bosun on Rambling of BxC.
Chapters
00:00 What happens if technical debt isn’t paid?
01:06 Is technical debt a product decision?
08:44 Deferred work: the product-manager perspective
16:50 When engineering debt should beat a new feature
21:44 AI coding agents: faster cleanup, new debt
24:13 Why technical debt is hard to sell
25:15 Opportunity cost and the cost of doing nothing
31:38 Final reflections: revisiting assumptions
#TechnicalDebt #ProductManagement #SoftwareEngineering
EP. 03 –Technical Debt is a Product Decision
Ramblings of B × C
32 views
Who owns technical debt and do product and engineering even mean the same thing when they talk about it?
In this episode of Rambling of BxC, Chinedu and Bosun discuss the statement: “Technical debt is a product decision.” What starts as a yes-or-no question becomes a conversation about what teams ship, what they leave for later, and what happens when “later” never comes.
Chinedu starts with refactoring, database migrations and engineering cleanup in mind. Bosun brings another perspective: the product decisions that lead teams to defer work, accept shortcuts and keep moving to the next priority.
Such a fun conversation. Both learn in real time, adjusting, adapting and revising opinions they held at the start. They don’t agree on everything, and that’s part of what makes it worth listening to.
The discussion covers:
• How product and engineering view technical debt differently.
• Why deferred features and temporary fixes linger in the backlog.
• The tension between shipping new features and improving existing systems.
• When performance, reliability and scaling issues make the work urgent.
• Leaving code better than it was found—and the practical limits of doing that.
• How AI coding agents can help clear technical debt while creating new problems.
• Why engineering work can be difficult to justify without a clear business case.
• Comparing the cost of fixing debt with the cost of doing something else.
Bosun shares examples involving workflow patches, caching and traffic spikes, while Chinedu explores what it takes to make those engineering concerns meaningful for product priorities and business goals.
One question keeps coming back: what is it going to cost if that debt is not paid?
Listen in, and share your perspective in the comments: who owns technical debt on your team, and how does it get prioritised?
Subscribe for more conversations with Chinedu and Bosun on Rambling of BxC.
Chapters
00:00 What happens if technical debt isn’t paid?
01:06 Is technical debt a product decision?
08:44 Deferred work: the product-manager perspective
16:50 When engineering debt should beat a new feature
21:44 AI coding agents: faster cleanup, new debt
24:13 Why technical debt is hard to sell
25:15 Opportunity cost and the cost of doing nothing
31:38 Final reflections: revisiting assumptions
#TechnicalDebt #ProductManagement #SoftwareEngineering