Engineer’s guide to convincing your Product Manager to prioritize technical debt
Aligning it with the business strategy and demonstrating its direct impact is the key!
Intro
We, as engineers are here to provide as much business value as possible and that doesn’t include only working on new features.
With things changing SO fast in our industry → being able to make adjustments with confidence is also a huge asset for the business.
And that’s why it’s important to mitigate and spend time working on resolving technical debt.
Luckily, we have a special guest today with us, Robert Ta, Product Lead, Distinguished Fellow at Dayforce and author of
newsletter.Robert will provide us with his insights from the PM's perspective about how to partner with the PM as an engineer and focus on resolving tech debt.
Let’s get straight to them!
Bridging the gap between PM and engineering
I’ve worked with so many engineers in the past who feel so tired of their codebase piling up with bugs and technical debt.
It slows them down. It feels pretty awful and sluggish to do your work. It just doesn’t feel right… and we all know there’s a better way.
If only we just had time to prioritize technical debt versus shiny new features. We know it’s there. It’s making our work harder and the codebase more brittle.
But convincing a product manager (PM) to prioritize it over shiny new features? That’s a whole different challenge.
The reality is, product managers are measured by the value they deliver to the customer and the business.
Their focus is often on what’s new → features that customers can see, use, and love. They’re juggling the business requirement of capturing more market share NOW.
Meanwhile, the code quality, maintainability, and developer velocity that matter most to engineers might be invisible to them.
A lot of times, they are just unaware that the tradeoffs they’re making for shiny new features vs. technical debt will actually slow them down in the long run.
So, how do you bridge that gap as an engineer?
In this newsletter, I’ll walk you through a process you can use to convince your PM to prioritize technical debt (from a PM!) → by aligning it with the business strategy and demonstrating its direct impact.
First… how to position tackling technical debt as a value proposition
To truly sell the idea, you need to understand the language of business strategy.
Here’s how you can position technical debt in a way that resonates with product managers:
Developer velocity
Highlight how technical debt is dragging down productivity. Frame it as a blocker that’s preventing the team from shipping features quickly and efficiently.
Time to market
Show how addressing technical debt will lead to faster release cycles, which directly ties to business growth and customer retention.
Customer experience
Connect technical debt to user pain points - whether it’s slow performance, frequent bugs, or downtime. Emphasize that reducing debt will lead to a smoother, more reliable product experience.
Long-term scalability
For businesses looking to scale, technical debt can be a ticking time bomb. Position your argument around how addressing it now will prevent costly rework and ensure the product can scale with demand.
By framing technical debt in terms of these value drivers, you shift the conversation from “engineering needs” to “business outcomes,” making it easier for your PM to see why it should be prioritized.
Now that we’ve learned how to map technical debt to value, let’s get into a specific framework.
The key to convincing your PM lies in positioning it as a value proposition that directly ties to business outcomes.
So… How to do that? I got you covered! Here is a 5 step process that will help you with this.
Step 1: Align with the business strategy
Before you approach your PM, dig deep into the product and business goals.
Ask yourself…
What’s the overarching business strategy? (e.g., growth, customer satisfaction, new market entry - if you don’t know, ask your manager, ask your PM, ask corporate strategy!)
How is the ever growing technical debt currently impacting these goals?
How might the technical debt impact these goals in the future?
How does developer velocity factor into the product roadmap and release cadence?
Example: if your company is scaling rapidly, highlight how technical debt is hampering the team’s ability to deliver features quickly.
Example 2: If the focus is on customer retention, show how technical debt is leading to bugs that hurt the user experience.
Example 3: frame it as support costs rise, operational burden increases. That costs both time and money and could be avoided if we spent time on resolving technical debt.
Step 2: Quantify the problem
 | A guest post by
|