technical debt is a product decision

PMs love to say “we’ll clean it up later.” Engineers hear this and translate it accurately: “we will never clean it up.”

Technical debt is not an engineering problem. It is a product problem. It determines how fast you can ship next quarter, how reliable your product is for users today, and whether that feature your sales team promised is even possible to build. If you treat it as something that lives on the engineering backlog and gets addressed “when there’s time,” you are making a product decision — you are deciding to slow down.

After working with hundreds of product teams, I can tell you the pattern is consistent: teams that ignore technical debt ship fast for two quarters, then grind to a halt. Teams that manage it deliberately ship at a steady pace for years. The compound interest works both ways.

What technical debt actually is

Ward Cunningham coined the term in 1992, and people have been misusing it since. Technical debt is not “bad code.” It is a deliberate or accidental trade-off where you accepted a suboptimal technical solution to gain something else — usually speed.

The metaphor is financial debt. You borrow against future engineering time to ship something today. Like financial debt, it accrues interest. The longer you leave it, the more it costs to pay back — and at some point, you are spending all your capacity servicing the debt instead of building new things.

There are three types, and they matter because each requires a different response.

Deliberate debt. You knew the right solution and chose a faster one. “We’ll hardcode these three payment providers for the launch. We know we need a plugin architecture, but that’s a month of work and we launch in two weeks.” This is healthy when tracked. It becomes toxic when forgotten.

Accidental debt. You did not know better at the time. The team was junior, the architecture was designed for 100 users and now you have 50,000, or the technology choice made sense three years ago and no longer does. Nobody made a bad decision — the world changed, or your understanding improved. This is the most common type in Indian startups that scaled faster than their engineering maturity.

Bit rot. The code was fine when it was written. Then dependencies changed, security requirements tightened, the operating system updated, or a third-party API deprecated its v1 endpoints. Nobody touched the code — it just aged. This is the type most teams forget to budget for, and it shows up as “everything broke on Tuesday and nobody changed anything.”

Why this is your problem, not just engineering’s

Here is the conversation I hear in every other sprint planning:

The PM in that meeting was not wrong to prioritise revenue. They were wrong to treat the refactoring request as optional maintenance instead of what it was: risk mitigation for the very deal they were trying to close.

Technical debt becomes your problem the moment it affects any of these:

Delivery speed. “Why does every feature take twice as long as we estimated?” Because engineers are working around brittle code, duplicated logic, and undocumented dependencies. That “simple” API change touches fourteen files because nobody built the abstraction layer two years ago.

Reliability. Every P1 incident your team fights instead of building features is a product decision. Users do not care that the root cause was a database migration someone skipped in 2023. They care that the app was down for three hours.

Capability. Some features are impossible to build on top of debt-ridden systems. Your eng lead saying “we cannot build SSO without refactoring auth” is not being difficult. They are telling you the foundation cannot support the structure you want to put on it.

How to quantify it for people who do not care about code quality

Your VP of Sales does not care that the codebase has inconsistent API contracts. Your CEO does not care about test coverage percentages. You need to translate technical debt into language they understand.

The pattern is the same in every example: translate code quality into time, money, or customer commitments. Never walk into a leadership meeting and say “the codebase needs refactoring.” Walk in and say “this debt is costing us two extra weeks per feature, and it will cost us the Infosys deal if we do not address it before Q3.”

Three quantification methods that work:

1. The delivery tax. Track how much longer features take versus their estimates. If your team consistently overruns by 30-50%, ask engineering what portion of that overrun is caused by working around existing debt. Put a number on it. “Technical debt adds 35% to our delivery time” is a sentence a CEO understands.

2. The incident cost. Track engineering hours spent on incidents caused by known debt. Multiply by fully loaded cost per engineer per hour. In Bangalore, a senior engineer costs the company roughly ₹1,500-2,000 per hour when you include benefits and infrastructure. If your team spent 200 hours on debt-related incidents last quarter, that is ₹3-4 lakh spent fighting fires instead of building product.

3. The opportunity cost. Identify the features you cannot build because of debt. “We cannot offer multi-tenancy, which means we cannot serve enterprise customers, which means we are locked out of a ₹50 crore market segment.” This is the most powerful argument because it ties debt to revenue you are not earning.

The 20% rule

The single most effective practice I have seen across hundreds of teams: allocate 20% of every sprint to technical debt. Do not ask for permission every time. Do not write a business case every sprint. Just do it.

This works because:

• It is small enough that nobody panics about “lost” feature velocity
• It is large enough to make meaningful progress over a quarter
• It removes the negotiation overhead that kills most debt-reduction efforts
• It creates a steady drumbeat of improvement instead of a heroic “cleanup sprint” that never happens

The 20% is not optional. It is not “if there’s time.” It is a line item in sprint capacity, the same way you account for meetings, code reviews, and on-call rotations. If you have a team of five engineers delivering 40 story points per sprint, 8 points go to debt. Every sprint. No negotiation.

Some teams do it differently — one full sprint per quarter dedicated to debt, or a rotating “tech health” engineer each sprint. The specific mechanism matters less than the commitment. What kills teams is treating debt reduction as something that competes with feature work for priority every single sprint. It should not compete. It should be budgeted.

How the PM makes this happen: You do not need your VP’s approval to allocate sprint capacity. You need your engineering lead’s agreement. Frame it as a joint commitment: “We are going to dedicate 20% of every sprint to tech health. I will protect this from stakeholder pressure. You prioritise what gets fixed.” Then actually protect it. The first time a stakeholder asks you to “borrow” from the tech debt allocation, say no. The second time, say no again. By the third sprint, the team trusts you.

When to pay it down vs live with it

Not all debt needs to be paid. Some debt is cheap to carry. Some systems will be replaced before the debt matters. The decision framework is simple — I call it the Reversibility Razor.

Ask two questions:

1. Is this debt in the critical path of what we are building next?

If yes, fix it now. You will pay for it in the next feature anyway, and paying while building is more expensive than paying before building. If the auth system needs refactoring and your next three features touch auth, the refactor is not optional — it is a prerequisite.

If no, it can wait. Debt in a system you will not touch for six months is carrying cost, not blocking cost. Track it, but do not prioritise it over features that matter.

2. Is this debt getting more expensive over time?

Some debt compounds. A poorly designed database schema gets worse with every table you add on top of it. A fragile deployment pipeline slows down more as the team grows. If the cost of fixing it is increasing, fix it early — the longer you wait, the more it costs.

Some debt is stable. A hardcoded config that should be in a database is annoying but does not get worse. Fix it when you are in the neighbourhood, not as a special project.

India-specific: why debt accumulates faster here

I have worked with startups in Bangalore, Mumbai, Delhi, and Hyderabad. I have also worked with teams in the US and Europe. Indian startups accumulate technical debt at roughly twice the rate, and it is not because Indian engineers are less capable — many are among the best I have worked with. It is structural.

Hiring velocity. When you go from 5 engineers to 30 in eighteen months — which is common in Indian startups post Series A — you get fifteen different coding styles, three different approaches to error handling, and zero shared understanding of the existing architecture. Every new engineer adds code that works but does not fit. This is accidental debt at scale.

The jugaad instinct. Jugaad — the Indian ethos of creative improvisation with limited resources — is a genuine competitive advantage in zero-to-one. It becomes a liability at one-to-ten. The hack that got you your first 1,000 users is not the architecture that serves your next 100,000. Many Indian startup founders resist this transition because jugaad worked. The skill is knowing when to stop improvising and start engineering.

Service-to-product transitions. A significant number of Indian tech companies started as services firms (building software for clients) and transitioned to products. Services code is written to meet a spec and move on. Product code is written to evolve over years. When you build your product with a services mindset — “ship the feature, close the ticket” — you accumulate debt that a product-first company would never create.

The “we’ll fix it after funding” trap. I hear this constantly. “We know the code is messy, but once we raise our Series A, we’ll hire senior engineers and clean it up.” This never works. Senior engineers join, see the mess, and either leave or spend their first year fighting fires instead of building. The debt does not wait for your fundraise.

None of this is a criticism. It is a description of the environment you are operating in. If you are a PM at an Indian startup, you need to be more aggressive about managing technical debt than your counterpart at a similarly-sized US startup — because the forces creating debt are stronger.

Working with engineering: making the case without giving homework

The worst thing a PM can do is walk into a standup and say “we need to reduce our technical debt.” Engineers hear this and think: “Great, the PM read a blog post.”

Your job is not to tell engineering to fix debt. Your job is to create the conditions where fixing debt is possible. That means:

Listen to what engineers are already telling you. In most teams, engineers have been flagging debt for months. They mention it in retros. They grumble about it in standups. They add TODO comments in the code. If you are not hearing these signals, you are not listening — or worse, you are dismissing them as “engineering wants to gold-plate.”

Protect the time. Engineers do not need you to prioritise which debt to fix. They know. They need you to give them time and protect it from being stolen by the next “urgent” feature request. When you say “20% of this sprint is for tech health, and I will fight anyone who tries to take it,” you are doing your job.

Connect debt to product outcomes. Engineers are more motivated to fix debt when they understand the product impact. “This refactor will let us ship multi-tenancy, which unlocks enterprise customers” is more compelling than “this refactor will make the code cleaner.” Your job is to provide the product context that makes the engineering work meaningful.

Do not ask for a business case every time. This is the fastest way to kill engineering trust. If your eng lead says “we need two days to fix the CI pipeline,” do not ask for an ROI calculation. The CI pipeline affects every engineer’s productivity every day. Trust engineering judgment on technical matters. Save the business case conversations for large efforts — a full quarter of refactoring, a platform migration, a rewrite.

The decision: when debt blocks a deal

Audit your team’s debt

Where to go next

• Build the PM-engineer relationship that makes debt conversations productive: Working with Engineering
• Plan sprints that balance features and tech health: Sprint Planning
• Write PRDs that account for technical constraints: Writing PRDs
• Fit debt reduction into your roadmap without losing stakeholder trust: Roadmapping and Prioritisation