What Product Managers Can Do to Minimize Technical Debt

Most product managers, like myself, do not care much about technical debt when overseeing a product. We think it’s an engineers’ thing and as such do not pay attention to it. To be fair, sometimes that’s true (it can be an engineers’ thing), but sometimes it’s not. Moreover, we can benefit from understanding what it entails.

If you want to discover one more way to build a better product and be closer to your engineering team, keep reading!

History of the Term “Technical Debt”

“Technical debt” is a metaphor coined by Ward Cunningham. It describes a framework on how best to deal with cruft, by thinking of it as financial debt. The extra effort it takes to add new features is the interest paid on the debt.

How does it Appear?

Everything here is pretty simple. Sometimes we ask engineers to build things “as fast as possible” because we should’ve released a new feature earlier.

Think of it like this: peers help us and create new rooms in our building (the product in question), they do not erect strong walls, build a bed only for one person and other unexpandable things. When the room is initially built at the time of the request, it looks good - we test our hypothesis and get valuable data from users, etc. But, what happens next? We desire to extend this room (an added feature in our project) by asking for a few improvements, and we notice something goes wrong.

A simple change, for some reason, takes significant time and uncovers new bugs to our previously sound logic. How come we face this? What’s wrong with our nicely (for a customer at least) built room? If we had an opportunity to look inside, we’d find out that our room, which looks perfect on the outside, has weak walls that are close to destruction. And what’s more? we notice that there are now three grizzlies trying to have a rest on this one-person bed — total chaos, in other words.

Does “Technical Debt” have any Consequences Beyond the Difficulties of Extending Features?

Sure! Imagine you’re a painter trying to decorate the outer part of this structure. You made the first attempt, checked the result, and saw a few сracks. You’re OK to fix this for the first time, but what will it look like the fifth Or maybe the tenth time you have to fix the cracks? Of course, you’d hit the ceiling and start finding a way to avoid working with this structure altogether. The same happens with engineers and teams in general, all members become less inspired, and performance drops.

But is it necessary to clear technical debts as soon as possible? Some would say yes, but I can’t agree with this statement. And the reason is pretty straight - it all depends on the situation and the debt type.

If it doesn’t prevent you from moving forward and you can pay interest without any effort, think of it positively like a garage for rarely-used things. One that allows you to keep your house free of unwanted stuff, a home for unused construction material.

Moreover, you can continue improving your home or even renovate it - you already have a room for things you don’t use frequently.

Let’s consider another situation - establishing a foundation. If a foundation wasn’t designed for a multi-story building, say it was built for a two-level house, you wouldn’t be able to build a multi-story structure. A scenario like this would lead you to struggle with interest payments on a technical debt and as such the debt should be attended to as soon as possible.

Common Approaches for working with Tech Debt

OK, now we have a rough idea of what is hiding beyond the “technical debt” term. Let’s figure out what we can do with it.

Devs’ Priority

Most of us are familiar with the first way: On some days, we have a chat with our tech lead, he claims that we’ve had some “refactoring” tasks in our backlog that we haven’t paid attention to for a long time. Considering the estimation for its resolution is nearly a month, we start asking why we should work on it, what happens if we postpone refactoring for extra time? etc.

Typically product managers do not want to spend such time on the strange activity of refactoring — we already have an enormous amount of desired features in backlogs — and occasionally, engineers can’t explain why we should work on tech debt asap. So, we continue building a multi-story product on a foundation for a two-level house.

You already can imagine the consequences of such a decision.

Fixed Time

The second approach can be more productive for closing debt. Just allocate fixed time (or story points) in a sprint to accommodate refactorings, architecture improvements, etc. Heading this way may lead you to a stable product life with an anticipated and manageable amount of technical issues.

Looks good, doesn’t it? so why shouldn’t we choose this strategy? We can! but it’s not the most optimal way for your product. Using this technique leads to more spending on things you do not want to improve. Here, engineers usually choose what we should refactor, and that’s the point, they may not know what we’re looking to build exactly and choose a garage for renovation instead of a foundation redesign when we want to erect a skyscraper.

Proactive approach

We’re moving smoothly (I hope) to the third method. It requires more of the product managers’ time, but it has its pros, for one, we get to improve our product’s technical health consciously and optimally. So what should we do?

I have put the following list together as a guide:

• Keep in mind that engineers are savvy folks. They very well know how to build a product but sometimes have difficulties with what exactly they should be building.

• Remember, as a product manager, you know your customers, their needs, your company strategy, product metrics, and other business-facing specifics. In other words, you understand what you want to build and why.

• Combine the first two ingredients! Always share with your team (it will be helpful and not only for engineers) everything you can about product plans. You can also educate the team on customer obsession and product responsibility. Do not hold prospects of a particular feature —

  whether it’s a test, code for which you may delete in the future, or already a stable solution — your team should understand the difference.

• Look at your product development like you’re building a house on a plot of land. Your team will create rooms, floors, decorations, etc. But they also will dismantle some parts of it and build over again. And while your folks are involved in the reasons and consequences of different features, your product will consistently become better, not only from the business perspective but also from the technical point of view.

In addition to the points above, encourage the engineers to take initiative and choose the best part of tech debt to clear per time.

No more difficult conversations with your tech lead, no more refactorings in the wrong product places - deep team synchronization does its work.

Outro

For final words, love your customers, love your team, make the world around you better. And remember, the way you create products is unique and no one else can do it quite like you.