Product debt

I’ve spent a lot of time in the past two years researching and thinking about technical debt. In most of that time, I’ve thought about it as something that’s an implementation detail of the code. It’s probably fair to keep it defined to that context, but that leaves a lot of places for debt to be introduced before any code is ever written.

A recent post on the Instigator Blog discussed the concept of “product debt” (also referred to “design debt” or “user experience debt”). One of the key indicators of this sort of debt are differences between, for examples, different forms within a product. I’d argue that the ability to reuse documentation between products (e.g. installation instructions) is an inverse measure of debt.

The post is a great introduction to the concept, but as I re-read it, I realized that I didn’t like using the term “product debt” for what the author describes. Most of the discussion is around user experience design. While UX is obviously very important to successful products, it’s not the only consideration. Similarly, there are other kinds of design apart from UX design.

I have given the matter some thought, and I’ve come up with the start of a taxonomy for debt. “Why create a taxonomy?” you may ask. Firstly, because if we can use a common vocabulary, we can communicate more clearly with each other. Secondly, because having a way to categorize debt can allow project/product managers to manage debt payment. Finally, it could be a launching point for academic studies of debt in order to better guide the debt payments in the second point.

So here’s a first draft of a debt taxonomy. The categories below are all components of a total product debt.

  • Technical debt. This is the debt that occurs in your code as implementation details.
  • Architecture debt. This is the debt you incur from design decisions, including the API.
  • User experience debt. This debt is basically the debt described by to in the linked post.
  • Documentation debt. This debt accrues when your documentation is missing, incorrect, or unreadable.

Leave a Reply

Your email address will not be published. Required fields are marked *