Depending on your organization, as a Product Manager, you may be sitting right next to your dev team, in a different room, or even an other building.

I’ve experienced each of those situations.

It is essential for a Product Manager to be close to its users, understand them, their problems, how they think and what the expect. But it is even more essential for him to be close to and to understand its the dev team, on daily basis.

Doing that since a few years, there are some pro’s and con’s of course. A con is that you’ll need to isolate yourself sometimes, to concentrate on your own stuff just as much as to avoid disturbing the devs with loud phone calls.

A pro is that you’ll start understanding their strange language and vocabulary, and for instance exactly what they mean with Technical Debt. And that it’s not just a b… a fancy word for telling you why a feature wasn’t released in time.

What is a Technical Debt?

Wikipedia says:

Technical debt (also known as design debt^[1] or code debt) is a recent metaphor referring to the eventual consequences of any system design, software architecture or software development within a code base. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.

Right.

Going further, the technical debt can be quantified as a metric that estimates the amount of time one person would need to solve all of the product’s defects, in order to get the perfect, issue-free product.

Some tools, such as static or dynamic code analyzers, can give you an indication of that metric according to a pre-defined set of rules and best practices (which of course means that the estimate is bound to the coverage of that set).

Why should you care, as a Product Manager?

Product health

Well first of all, it’s a metric giving an essential indication on you Product’s health, like temperature would for the human body.

There are a few notions you need to be comfortable with in order to use this metric efficiently:

1. There is no way a project would ever manage to achieve a 0 technical debt:
   • Unless the majority of the development resources would be focused on solving issues rather than developing new features
   • Unless no new feature development would ever be violation/issue free
2. Comparing a technical debt value estimate between two products is tricky
   • It is bound to the size of the code base
   • It is bound to the architecture and technology choices, and may therefore have different relevance level of the best practices from which originate the estimate
3. The technical debt metric must be monitored over a period of time, only its evolution is relevant. When the technical debt rises or drops, ask yourself why would that be.
   • Did new team members work on the project? You may consider giving them extra training and/or background information on the project.
   • What did the new release(s) contain? Were there large new features or essentially debug?
   • If the technical debt rises since a few releases, are your business objectives balanced with your technical resources?

Not controlling that metric will anyhow at some point make you realize its importance, when the velocity of your team drops.

High technical debt, crippled roadmap

I’ve already heard people comparing Technical Debt to the Jenga game. You have those wooden blocks to build a tower, and once you used them all, you remove them and balance them at the top, making the tower higher but more unstable.

Well I never had a product that actually “fell to the ground”, even if I like this metaphor. Of course, the service may drop, some nasty bugs might disable important features. A patch here, a stitch there, and you get stuff back going, because business requires it. But the situations I’ve seen weren’t much nicer.

Products with uncontrolled technical debt are a pain as soon as you want to add or modify even the smallest feature. No matter how good they are, your developers will just struggle in getting your user stories “done”. Just because it will be highly complex to add/reuse the code, but also because they just might not want to leave some dirt behind. And there you end-up in the scary spiral of continuous refactoring.

You just wanted to add a new form on a page? Well, you’ll have the choice between having it done the same old dirty way, or have your developers rework all of the other similar forms before you get the new one. And no, having it done cleaner just for that new one shouldn’t be considered as an option, because it’s in the end the best way of getting your technical debt to sky-rocket. Having different way to do the same thing in a code base is evil.

Watch out for a Franken-product

Well, increasing technical debt doesn’t necessarily mean that you’ll reach that horrifying stage. But the ghost is still somewhere near, if you don’t worry about it soon enough.

It is pretty obvious that your customers adoption is going to be pretty low once you’re there and that they can see it or  experience it.

Now there’s an other side-effect that you’ll have to deal with. Besides the fact that your devs will struggle working with that code base, it will as well impact their eagerness. When you like beautiful tech, you don’t want to stitch Franken-code every five minutes. You could argue that hey, wtf, its their job! But would you really enjoy having to cope with a poorly designed product (especially if the initial design isn’t yours) and try to build on top of it?

Save your debt, save your devs.

What should you do?

1. Talk about it with your dev team!
2. Track it from the very first line of code written to make your product real. If you don’t know where to start to have that metric, get back to point 1.
3. If you work with Scrum, always plan some slack to control the technical debt. Don’t try to book the full sprint’s velocity in new features. Actually your velocity should at some point adapt to the fact that developers will always do some work on the debt.
4. If your product’s debt is already high, talk about it with business stakeholders
   • For the sake of the product, it may be worthwhile having a lighter roadmap, and giving more focus to decreasing the debt
   • You might want to consider purely dropping some features (no code=no debt?). But first check their usage rate and if they’re not business/marketing critical.
   • Well, that’s rarely seen as an option looking at the investment cost: re-start from scratch?

Featured image by Jose Hernandez