The real enemy is Product Debt

A Tech & Product debt primer for business-oriented people (including PMs)

There may be something in the air, but I see more and more “Technical Debt” becoming a common term also among non-technical people. Technical Debt (or Tech Debt) is nothing new and the concept that code can get “out of control” has been discussed among developers, product teams, and tech-savvy bloggers for some decades. What is indeed interesting, is to see it becoming a subject even outside of the “usual circles” and a subject discussed (yet not really understood) by a larger public. This is absolutely good news, and having business owners, CEOs, sales, and other less tech-initiated people aware and empathizing will topics that make product people struggle, is good for everybody.

At the same time, the topic is complex and I am seeing and reading many confused thoughts and shortcuts on the topic. For this reason, I decided the time to put together some notes I have been writing in the past, to sum up, some key elements of Tech Debt. Most importantly, I will try to clarify why Tech Debt is not really a problem per se, and I will argue that Product Debt is the real enemy!

But first of all, what is really technical debt? 

In plain English, we could say that Technical debt is the set of consequences on software (code and architecture), due to technical shortcuts and decisions taken to favor speed or release over a more future-proof code.

At the same time, those decisions may have different facets, including:

• Hardcoding values in the code, rather than using configuration files
• Integrating a deprecated/non-long-time supported (LTS) library or software development kit (SDK) (some of this, arguably, is inevitable in the long term anyway)
• Writing “fast code”, in a non-polished / more complex than needed way (spaghetti code)
• Writing code on a different development stack/language than the rest of the application
• Changes in the specs that are rushed into the code without reassessing the overall impact

While all these “tricks” may speed up the development, of course, they will create, over time, a situation that is increasingly more complex to manage. And this complexity grows exponentially over time, until the point where developing (or even just maintaining, debugging, and supporting) existing code becomes prohibitively expensive and frustratingly long. This is the reason why Tech Debt is often pointed out as a major enemy of speed and product/tech teams. And this is also why you may hear the engineering teams claiming the need to “stop and fix the tech debt”.

Does this mean that Tech debt is bad?

Well, not necessarily. Yes, growing technical debt can easily become a burden that can kill your product or at least your ability to evolve it. At the same time, just like financial debt, technical debt is not bad per se. It is actually a tool that can be very powerful to develop your product and the company itself. 

So, just as when you walk into a bank and get a loan you’re contracting debt when you decide to take a shortcut in software development, you’re contracting technical debt. Depending on how you are going to use and manage it, and how you’re planning to pay it back, both kinds of debt are potentially going to give you back much more than it costs. 

But the key words in this statement are “deciding”, “planning” and “manage”. In other words, contracting debt needs a strategy in the first place, and shall be a deliberate choice, and not just taken as a default path.

What is in for you when you decide to contract this debt, is that you get a sort of “booster” to make your product go faster for a few iterations or so. This is actually a great advantage, allowing you to iterate quickly, test product/market fit, and potentially… decide fast that you don’t need this feature altogether! Think about this, going fast and creating some debt now, can actually help you… avoiding debt. How is that? Going faster, understanding soon that you don’t need it, and removing it altogether immediately, means less code, less clutter, and less debt! That’s a big win!  

Also, another more subtle advantage is that getting some shortcuts can sometimes be useful to get to results fast, start “hitting the reward” (monetary, efficiency,..) coming from the new product/feature, and “reinvest it” back in the product to industrialize and reduce the debt.

So, what about the planning? Well, acknowledgment is definitely the first step. Understanding and aligning the teams on the fact that the debt is there and it will have to be paid back (sooner than later) is something that you really don’t want to miss. Also, factoring in a “decision milestone” (Kill or improve) as a result of your product experiment from the first moment, is also very good practice and ensures that this doesn’t go forgotten.

In conclusion, the main takeaway is that the only Technical debt that is the real evil, is the one that you didn’t need in the first place or that you took as a consequence of a non-deliberate choice.

Product Debt instead…

Now that we’ve seen what Tech debt is, let’s move to its less known (and arguably more dangerous) brother: Product Debt, and let’s start with my definition.

Product Debt is the cumulus of product features, functionalities, customizations, and inherent complexities that are presently not demonstrably and materially contributing to the realization of its mission or are coming out of past choices and commitments that are not in line with the vision. 

With this definition in mind, it should be immediately clear that Product Debt has some commonalities and some differences from Tech Debt:

As Tech Debt, Product Deb as well:

• It may be the result of shortcuts and tests done to validate a particular solution
• It may be deliberate or not
• Creates a burden on the product, the teams, and the company. 

Differently than Tech Debt, however:

• Product Debt can “build up alone”, even if you don’t do anything deliberately to do so. Just “adding stuff” that gets rusted and forgetting them, and you will have debt.
• It creates pain not only for the teams but also for the customer (who gets easily lost in complex offers, interfaces, too many options,…)
• Makes the onboarding process of new team members more complex
• “Prevents” new business opportunities. Eg. a small feature for one customer, incompatible with a new business model 
• Only you can fix it. You can hire a software agency to redo software architecture but you can’t ask an external company to decide… what you need or don’t need in your product. 
• It is usually the first consequence of choices taken on the basis of a “this is a low-hanging fruit” discussion. Decisions taken on the basis of what is easy today tend to hide “what is the lifetime maintenance cost” of a new feature or product.
• It’s more difficult to have people understand why it is bad (hence this article)

These differences make in my experience Product debt more subtle, and as a consequence, more complicated to identify and more dangerous, than Tech debt. Product debt is a silent killer. Paradoxically, an insidious reason for this silent killing comes from the service that has been around for a longer time and has accumulated expert PMs and users. By definition, being “experts”, they do not consider the service complicated and cluttered, because they are “experts” and can navigate through this chaos.

A few examples of “Product Debts” I witnessed myself in the past include:

• At a marketplace company, we had an exclusive agreement with one of our customers (a seller), such that we could only show a specific element for this seller’s items. Although he was a big customer, this exclusive feature prevented us from extending to other customers and, even worse, from giving valuable information to the buyers who wanted to buy from other sellers. We effectively tightened ourselves to bad customer experience. 
• Adding a payment method that is used by <1% of our target customers (who could very well have used another payment method). This created increased payment issues, more code to support, other financial institution relationships to manage, and… more clutter on our interfaces. 
• In one organization I worked at, we had two teams working on two different solutions for the same problem (which is ok!). As we never managed to get clear data about the winning solution to keep us… well, keep both and get the user to choose. Needless to say, that’s NOT what the user wanted, and dispersed our energies to the point that we had to kill both solutions. 
• In one case, I saw teams insisting on developing a given feature just because… well, it was on the backlog at a certain point, and … why not? After all, we do have some spare time, do you want X developers to be idle for a week? Well, this “unreflected work” is a great source of Product Debt. In product, creating is much easier than killing!

The main weapon you have against Product Debt are the following:

• Have a clear (and communicated) product vision, you can benchmark all your choices against
• Be upfront and consistent about prioritization, not trying to please everyone (especially when people do not adhere to the product vision in the first place)
• Measure, measure, measure. Have the right metrics and ensure that data are part of the decision to build (before) and to keep (later) any feature.
• Do have regular product reviews and cleanups, and – in general – kill by default rather than keep by default.
• Be clear about what you will do, and be even more clear about what you will NOT do with your product.
• Be naif, don’t be an expert: strive for simplicity and don’t fall into the “expert trap”. If you look at things with the eyes of an expert, you become blind to complexity.

Look also at these cousins…

In these notes, I tried to put together the different thoughts on the “debt” I accumulated over the last several years working on software products. One of the interesting things I noticed, is that the same notion of debt can be extended by analogy to other kinds of debt:

• UX / Design debt: a mix of “adding buttons”, features, and in general making the product feel more cluttered and difficult to use. Also, “trying to please everybody” and not taking choices usually play a role. This is a real time bomb for your digital products and can hit back in also in terms of adoption and conversion (think about “choice overload”)  
• People Debt: This is probably my favorite, or actually… most feared one. A “desperate” hire today, or an “Impossible promise” (do this crappy project now, it will lead to a promotion in X months), or a “promote to show an evolution” choice is usually bad for the company and bad for the employee. This leaves you with cluttered organizations and clueless and disempowered people. If people are your asset, People Debt is inflation.
• Business Debt: Exclusivities, bad pricing, aggressive discounting, customizations … and bad “unit economics”; all those things are often “easy to do, difficult to revert”. 

I will not extend those concepts further in this note, but I believe that the point is pretty clear. There is no free meal, especially in tech and product. Modern stacks and product methodologies allow us to go pretty fast… and booster options exist sometimes, although they often come with a (debt) caveat. Do use all the alternatives you have, leverage every opportunity and take shortcuts when it makes sense, but do take conscious decisions, take plan wisely and actively manage your options. 

Also, it’s important to note how those different kinds of debt often happen together and have an amplification effect: more Business debt leads to more features and more product debt, which in turn creates a fertile environment for tech debt, etc.

A final word about value, financials, and due diligence processes

I tried to put my notes in a format that is digestible and can speak out of the more technical and product circles, but I am aware that Product & Tech debt remains a pretty complex and technical subject.

Nevertheless, their business implication is direct and very material. Product/Tech debt is indeed a measure of the ability of a product (and a company) to effectively and efficiently continue to grow. Those are key indicators to keep in mind when talking about investments, acquisitions, and valuations. 

I found it astonishing how little attention is spent on this topic and how “light” many due diligences are on these aspects, especially when it comes to business where the actual execution and customer experience (as opposed to specific IP or deep technology) are the assets at stake.

I am curious to hear examples and experiences. Who can share the funniest (or worst) example of Product Debt?

---

A big thanks to Leonard Lin and my other “secret reviewers” for your precious help and so valuable insights. You know who you are 🙂