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!

---

DevStats (sponsored)

With DevStats, you can get the metrics you need to make informed decisions. You get all of the important info regarding:

• developer experience,

• business impact,

• visibility across multiple projects and teams.

I have personally been using DevStats for some time now and I am getting a LOT of value from it!

Check out DevStats and sign up for a 14 day trial (no credit card required).

Let’s get back to this week’s thought.

---

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

ABCs for Growth by Robert Ta

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:

1. 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.

2. Time to market

Show how addressing technical debt will lead to faster release cycles, which directly ties to business growth and customer retention.

3. 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.

4. 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

PMs are more likely to prioritize work if they see the numbers. Period. So make sure to gather the data to back up your argument.

Here are some examples:

• Time wasted

Calculate how much time is spent on bug fixes, manual workarounds, or firefighting due to technical debt. Swag it - you don’t need to be 100% accurate.

• Cycle time

Measure how long it takes to go from code commit to deployment. Highlight areas where technical debt is causing delays.

• Production issues

Track the number of incidents, bugs, or performance issues linked to technical debt. Just count them. Then make a swag of how much time and money it costs.

Not sure how to estimate or quantify the problem?

Use these rules of thumb to start:

1. For a true swag, I like using 1 Developer = 250k / year

2. Then 1 Developer Sprint (2 weeks) = ~10k USD

3. If a bug takes 1 Developer Sprint, that’s 10k USD in opportunity cost

4. If technical debt is slowing you down and making it take 2x the Developer Sprints to get 1 shiny new feature out, that means the cost of not doing the technical debt now will effectively slow down future delivery by 2x the time and ~20k USD more in cost

Use metrics to paint a clear picture of how technical debt is eroding developer velocity and affecting the bottom line.

Step 3: Relate the technical debt to business value

Here’s where you make the connection between technical debt and business outcomes.

Position your argument in a way that shows your PM how reducing technical debt will lead to.

• Faster time to market → cleaner code and reduced debt lead to quicker feature releases.

• Improved customer experience → fewer bugs, better performance, and more reliable systems.

• Greater team efficiency → less time spent on rework means more time spent building new features.

Example: By addressing this technical debt, we could reduce our release cycle time by 30%, allowing us to deliver features faster and improve customer satisfaction.

Use those rules of thumb you just learned!

Remember, paper napkin estimates → NO estimates.

Step 4: Solution

Now that you’ve laid out the problem, offer a solution. Break the technical debt into manageable pieces and present a phased plan.

Make it easy for them to say YES.

Example:

Phase 1: Refactor the API layer to reduce code complexity and decouple logic.

↳ Expected outcome: 20% faster bug resolution time.

Phase 2: Address performance bottlenecks in the database.

↳ Expected outcome: 15% reduction in page load times.

Phase 3: Improve automated testing coverage.

↳ Expected outcome: 30% reduction in production incidents.

If you want to grease the wheels even further, break out the work into an Epic and Stories to tackle the debt.

Quantify the stories ahead of time so your PM knows exactly how much this will cost, and how they will slot it into the roadmap.

Step 5: Proposal

Finally, approach the conversation from a place of empathy and form your proposal in the language they understand.

Use a format that resonates the most and would be able to present this in the best way. This can be slides, documentation, or something else.

Package it up in a way they can easily understand, to make it easy to say “yes” to and frame your request as a partnership!

Example: I understand we're focused on delivering key features this quarter, and I believe addressing this specific area of technical debt can help us deliver those features faster and with fewer issues. Allocating some resources and time towards this will greatly improve our ability to deliver value to customers, faster.

Build that empathy in them for you (and future engineers who have to work on the codebase too)!

Why this process works

The process I’ve outlined works because it speaks to what product managers care about most: delivering value.

By aligning technical debt with business strategy, quantifying the impact on developer velocity, and proposing clear, measurable outcomes, you make a compelling case that’s hard to ignore.

And if you package it up nicely (by writing the Epic(s), Stories, doing the estimations, and speaking their language) you optimize your chances for success.

Last words

Thanks to Robert for his insights on this very important topic! You can find him on LinkedIn, Twitter/X and also make sure to check out his newsletter!

---

We are not over yet!

Senior Engineer to Lead: Grow and thrive in the role (announcement)

It’s getting close to the start of the September’s cohort-based course! It’s going to start on September 10. So excited for it!

I had a blast hosting the July’s Cohort and I am really looking forward to the September’s!

We discussed a LOT of different things and kudos to the great students for such insightful questions!

Here is what some of the July’s students have said about the course:

In the course, we particularly focus on the development of much needed people / communication and leadership skills in order to grow from engineer to leader!

Looking forward to seeing you there.

---

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Book a Coaching and Mentoring or Consulting and Advising call with me here.

• Take a look at the cool swag in the Engineering Leadership Store here.

Get in touch

You can find me on LinkedIn or Twitter.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

---

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.