Technical debt has become recently become a major topic of discussion in product development and product management worlds. Some believe that technical debt is necessary and even healthy for a developing product, while others say that technical debt is more likely to create problems than it is to solve them. What exactly is technical debt? What is a product manager’s responsibility to technical debt?
What Is Technical Debt?
In the simplest terms, technical debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, creating problems down the line, for example, making it difficult for developers to add new features or innovations to the product. In terms of software, if a change is made in the most basic code of the software, it will have rippling changes throughout the rest of the code. It is called “technical debt” because development teams often “take out a loan” on some aspects of the project in order to move ahead with other parts of the project (usually in order to meet a release date).
Is Technical Debt a Bad Thing?
There are essentially two camps when it comes to technical debt. One camp believes that any kind of technical debt is bad for a product. Essentially, they believe that you should not put off until tomorrow what can be done today. And that’s true—in some instances, it is a very bad idea to take out technical debt on a product, especially if there is no real intention of every paying that debt back. Just like a real debt, technical debt accrues interest. Those rippling changes in the example above affect not just work that has already been done, but any future work that needs to be done. If never addressed, it can bankrupt a product.
The other camp would say that technical debt is a necessary part of any product development process. Taking time to make necessary changes that will stall or even kill development or progress is not always a good idea. As long as the development team eventually gets back to and repays that debt, having some technical debt can ensure that a product moves forward and does not get stuck in a quagmire of rewriting code that has already been written.
What Is a Product Manager’s Role Concerning Technical Debt?
In short, a product manager’s role is basically a balancing act. A product manager must ensure that the product keeps moving forward while providing ongoing value to the customer. This means that innovation is as important as paying back technical debt. Many believe that a product manager has no responsibility at all when it comes to technical debt. But when the debt is not addressed, a product can only progress so far before the underlying framework can no longer support new features or innovations.
This means that a product manager has to be at least somewhat concerned with the technical debt in his product, even if it simply means making sure that the product development team is devoting at least a little time to repaying that debt, as well as developing new features. If you think about your engineers and their time as technical money, you’ll see that devoting all of your technical money to the debt is just as dangerous as not paying any of the debt back at all. Balance has to be struck.
Most product managers know that their product will never really be finished and that, therefore, there will always be some measure of technical debt that will have to be addressed. A functional product, one that stands the test of time, will be continually changing, both at the base level, and at the top level with new features. In order to implement new features, technical debt will be created. In order to change the codebase, technical debt will be created. Trying to eliminate it altogether is a fool’s errand—impossible and a waste of time.
That doesn’t mean, of course, that devoting any time to technical debt is a bad idea. The product has to support its own weight. If the proper gaps aren’t filled or if stop gaps, instead of real solutions, are employed, larger problems that will take more time to fix are inevitable down the line. If a product’s code is already fairly messy, however, it might not seem like a big deal to employ a shortcut, instead of actually fixing the problem. What this can lead to, however, is a mindset among engineers that code doesn’t need to be clean, since it is probably going to be “fixed” by dirty code anyway.
Technical Debt as “Cracks in the Sidewalk”
Think of gaps in your product’s development like cracks in sidewalk. A small crack doesn’t really create a problem, and the sidewalk is still fully functional. As the years go on, however, water invades the crack and when winter comes, the water freezes and expands, making the crack wider and introducing new cracks into the sidewalk. If never addressed, those cracks continue to spread and spread until the concrete has been turned to rubble.
A product manager can ensure that these smaller gaps don’t become bigger problems in the future by making sure there is enough technical money (read: engineering time) devoted to paying of technical debt. This doesn’t have to be the majority or even a large percentage of the time spent on the product, but the fixes made do have to be quality fixes that can continue to support the weight of developments and innovations being added on top of the existing product.
Addressing technical debt without ignoring innovation is the only way to create a product that is both functional and flexible. Delivering new features is definitely more exciting than delivering a patch on the existing product, but delaying those new features in order to make sure that what already exists is solid enough to support those features can ensure that users are much happier with the entire product, instead of simply being blinded by a new addition.
A product manager doesn’t have to pay technical debt herself but she should make sure that it is being paid and being paid correctly, without halting the product’s development. It can be a difficult balance to strike, but one that will ultimately make the end result much higher quality.
So You’re The First Product Manager? Next Post:
What Product Managers Can Learn From Customer Support