Thanks to Ward Cunningham, the metaphor technical debt is quite a well-understood concept. It means you are borrowing time by writing messy code, not worrying about scaling, documentation or other items required for a quality release. You go quick and dirty to release early but all that bad code will incur debt. And there will be a time when you need to pay that debt back - with interest.
I think the parallel with the product design world is a welcome addition. I frequently find myself using the term product debt but I also get the sense that very few people know what I am talking about. Like technical debt, product debt is incurred when you make short term product decisions that led to expensive long term consequences.
Let's look at some examples:
Suppose Account Management calls and says "We have our biggest client threatening to leave if we don't add this feature. We need this asap." Adding the feature the right way will take 6mo, but you only have 1. So the compromise is to create a hack so only this customer has access to the feature. The interface does not support the feature so you make an exception "just for this one". The data model is completely incompatible with the request so you create a new one. You deliver the feature in one month but in order to clean up the mess that you created, you need to work on it for 12mo. Continue to make this mistake and your product will be an unmaintainable, bloated mess. At that time all engineers and designers will tell you that it's easier to start from scratch than to change anything. You are pretty much screwed.
That is a typical example of debt created by business pressure. But debt can be acquired by other means. The other classical example is adding too much into a release. "We can’t release without these 10 critical features". The more you add, the more hard it will be for engineers to estimate, you will miss deadlines, you will cut corners and collect a great deal of debt. You are (again) screwed .
Product debt is as important, if not more important than technical debt, because bad strategic product decision can have a even worse technical decisions.
Not unlike the Alcoholic Anonymous (AA), the first step is to be aware of the problem. One simple way to get better at this is to ask yourself this question whenever you are designing something: "How will this decision impact us when (1 or 2 years from now) we will get to that other project (the one you know you will need to get to)? Will this continue to work or we will have to throw this away and start fresh?"
Ranking debt
So what are some types of debts? In the order of their severity:
- Lots of features
- Custom features
- Data/Model related hacks
- Flow related hacks
- Interface hacks
Let's briefly discuss them:
Adding features
Adding too many features in a release ... Oh what a classic! We talked about this a few paragraphs earlier. Too many features is the surest way to accumulate debt. It may not even be that the features are badly implemented. You can have the most well designed product. The more features you bake into it the hardest it will be to remain agile and iterate. This usually happens when product people are not sure what the exact problem they are solving. So they bake in as many features in there to make sure the release is a success. They are not sure what the target is so they build a bomb big enough to make sure they hit whatever it is we are aiming for. That can happen because they have been lazy and not identified the real problem they are solving or the market they are addressing. Or by getting conflicting messages from "high management". Or both.
Custom features
Another one we exemplified earlier. There are very few cases where doing this makes sense. Almost anything custom is cancer in the long term. The only time where this makes sense is when you do it to validate an assumption: "We know this does not makes sense long term but we want to see if this feature will solve this particular problem". In that case make sure you plan on paying the debt by either killing the feature( if the experiment failed) or by putting a plan in place to pay the debt a.s.a.p.
Data/ Flows/ Interface Hacks
You can cut corners in lots of ways. But not all are equally expensive. Adding features that change the data model of the app are way more expensive that creating a button that appears inconsistently in "that section of the product". There is also a difference in interest for features that affect the product user experience. Creating new inconsistent flows are more expensive than (say) adding a new set of icons.
I hope that by now I made you aware of the importance of this concept. But to complicate things even more … worrying a lot about debt can also have some negative effects:
The danger of premature optimisation
The danger one faces once s(he) understands product debt is in optimizing products that are not well proven. If one is testing a concept, or worse is trying to figure out the real problem that the product is solving, worrying about this topic can mean the death of the company. You don't want to build a beautiful product that nobody wants. Understanding the problem is key. Nothing is more important than that. If building the crappiest product validates some of your assumptions than do it.
The danger of over abstractization
Another one is taking all concepts a step too far. Say you work on a product for invoice management but there is a strategic decision to expand the feature set at some point in time to manage all sorts of financial documents. So you, as a good product manager who is trying to avoid debt, makes the decision to create an abstract model called document and go with that for now. That is usually a bad decision because it is most likely the decision will be confusing for the user: "What is a document? Is an invoice a document or that is something different?" It's one thing to avoid debt but if that comes by taxing the user, it is not worth it.
That is it. Thank you for reading this far. As always I welcome your feedback.