Product Debt
Technical debt, or tech debt, is a term coined by Ward Cunningham to describe “those internal things that you choose not to do now, but which will impede future development if left undone” in software projects (Sundaram). The term derives itself from financial debt, and is similar in many ways. Technical debt, like financial debt, “incurs interest payments, which come in the form of the extra effort that will have to be done in future development because of the quick and dirty design choice” (Ries). Tech debt can be accrued in two ways: intentionally and unintentionally (Chen). Intentional tech debt is often created when companies consciously choose to optimize for the present. For example, product managers may set a deadline that requires faster implementation at the expense of future flexibility. Unintentional tech debt is usually formed as an unavoidable by-product of time passing. For example, infrastructure that was well suited to provide product functionality at an earlier time might become inadequate as the product grows. Regardless of how the tech debt is formed, it impacts the health of the software system by increasing its complexity and making it more difficult to add new elements.
Since tech debt is so often the result of product requirements, it makes sense to carry this paradigm to the product level. In many ways, product debt is to the product what tech debt is to the code base, but this relationship does not hold in all situations, particularly on the dimension of visibility. Where tech debt is largely internal and is therefore invisible to the user, product debt is embedded into the product and therefore plays a large role in how the user experiences the product. This difference between product debt and tech debt forces the definition of product debt to be more specific than the definition of tech debt given in the introduction. Concisely, product debt is the user-facing elements of the product that impede future development.
Each product consumes resources as part of its value proposition. In fact, a product can be thought of as a function that takes resources as input and creates value as output. Similarly, a user’s expectations can be modeled by a function defined over the same resource space to the same value space. In this context, the difference between the product and the user’s expectations is important. Product debt can be mathematically quantified as the summed difference between the expectation function and the product function. In particular, when a certain level of value created by the product requires more resources than the user is expecting to have to allocate, the magnitude of the discrepancy is the magnitude of product debt.
For example, a user expects a task to take a certain amount of time to complete. If the product takes less time to complete the task than the user was expecting, then the product has negative product debt, and the user is thrilled. If, on the other hand, the product takes more time to complete the task than the user was expecting, then the product has product debt, and the user is dissatisfied.
Product debt is created when product elements, or features, inefficiently or unnecessarily consume the limited resources available to the product. Features high in product debt impede future development by leaving less resources remaining for new features to utilize. For example, a website application has a limited space resource, the amount of area that it has to place elements on the screen. Existing product elements that use this space inefficiently leave less area remaining for new product elements to utilize. If the product team adds features that require more space than they are implicitly asking the user to allocate more of the space resource to their product, perhaps in the form of scrolling. As is the case with most scarce resources, the marginal cost of the space resource tends to increase as more is requested. Products with high levels of product debt will find that many of their features go unnoticed or unused because users aren’t willing to invest the resources required to find or take advantage of them.
Creating intuitively useable products is a challenging process. Part of this challenge comes from the fact that product creation is such a highly domain-specific undertaking. Product debt provides a strong abstract foundation for analyzing the aspects of products that disrupt usability. Since disrupting current usability is synonymous to impeding future product development, product debt is a useful paradigm for designers to consider as part of the production creation process.
I plan to explore the product debt paradigm further in future blog posts…
More on Resources #
For users of the product, input resources can be thought of as costs, and like costs can be subdivided into two categories: fixed and variable. Fixed resources are the minimum amount of resources required by the product to produce any value at all. People that aren’t willing to front the fixed costs won’t use the product, and therefore the designer can assume a certain level of fixed resources when creating the product. Variable resources are the additional resources that users allocate towards a product. What makes variable resources so important is that they are under the control of the user; it is up to the discretion of the user to decide the magnitude and makeup of these resources. This variability is what allows products to conceptually grow or shrink to meet the needs of each individual user. Managing variable resources is of utmost importance when designing flexible products for overlapping market segments.
Time and Transparency #
When considering the product function, the resources required to create a certain level of value will change with time, so time is an important dimension to consider. In particular, as a user gets to know a product better, the product efficiency should naturally increase. This effect is known as the learning curve. The learning curve is an additional element that designers should consider as part of the product creation process. The most important part of this is transparency into the product function. The first thing many users do after installing a new mobile app is investigate the settings page. They do this because it provides insight into the scope and capabilities of the product, which in turn provides insight into the estimated learning curve. By providing a high level of transparency into the purpose of the product, the designer can better convince users to allocate the required time to reach parts of the learning curve with higher product efficiency.
Types of Product Debt #
Similar to tech debt, product debt can be classified into two categories: unintentional and intentional. Unintentional product debt is created when previously made design decisions no longer mesh with the current conceptual model of the product. Unintentional product debt is often difficult to remove because existing users have become accustomed to it. Intentional product debt is created when poorly designed features are added to the product, usually as part of a conscious tradeoff for in some other product dimension (such as being able to release the feature sooner). A special subset of intentional product debt is the debt created by testing the viability of new features in the main product. This type of intentional product debt is costly for a company because it represents wasted product, engineering, and design effort both implementing the feature and dealing with the aftermath of failed attempts.
Reducing Unintentional Product Debt #
Unintentional product debt is the thorn in the side of product designers. It’s difficult to get rid of, and impossible to direct blame towards, and always present, impeding the evolution of the product. Its difficulties derive from the fact that unintentional product debt is a natural result of product evolution. Features that were once validated by external circumstance can not be equally viable as external circumstances change. This change can be so subtle that at times it leaves product managers questioning their original justifications for implementing the feature in the first place. The simple fact is that those justifications were sound, but leave the inevitable clean up problem as circumstances change. One way to solve this problem is through modularization. As the product evolves to fit different circumstances, pull out the aspects that are no longer compatible with the new circumstances into a separate product that is limited in usage to the earlier circumstances. This is a strategy that Facebook is taking with large parts of their complex product infrastructure (e.g. Messenger, Paper).
Reducing Intentional Product Debt #
Intentional product debt is a tradeoff. In its most common form it’s a tradeoff between moving faster now and incurring more product debt (inhibiting future growth) or moving slow now and incurring less product debt (potential to move faster later). This tradeoff can’t be escaped, but strategies have been developed to push the exchange rate in the designer’s favor. For example, Eric Ries’ Build-Measure-Learn loop is a strategy for reducing the cost of finding intentional product debt, thus improving the ratio between moving fast now and the potential to move fast later. Build-Measure-Learn is an abstract strategy, and can be implemented in different ways depending on the type of feature being validated. One special case of this is split testing. Split testing is the practice of implementing and releasing multiple versions of the same feature, and then letting metrics decide which version ultimately gets kept and which gets thrown out. Split testing is a powerful decision making tool for product managers to use on the class of low implementation effort, high subjectivity decisions.
Shifting the Expectation Function #
Obviously one way of decreasing product debt is to increase the efficiency of product features. Another way of decreasing product debt, however, is to change the expectations of the user. Since both the product function and the expectation function move up and to the right, this can be done by either shifting the expectation curve up, or shifting the expectation curve right. Shifting the expectation curve up is essentially convincing your user base that they desire a greater value that your product can provide. Since this is often accompanied by an increase in required resources, the situation is similar to process of a company heading “up-market” to reach “higher margins” that Clayton Christensen describes in The Innovator’s Solution. Shifting the expectation curve right is essentially convincing your user base that the level of value that they desire deserves more resources than they were originally intending on allocating. This can be done several ways, one of which is through gamification. Gamification essentially creates new value dimensions (perhaps fun, or competitiveness) out of thin air, and then uses them as justification for additional resource allocation. Another way this could be done is through marketing.
Flow #
It’s not necessarily true that in all situations the goal is to maximize the product function. Just as using products too high in technical debt can feel useless or impossible, using products too low in technical debt can feel boring or unimportant. That also doesn’t mean that the product function should be designed to meet the expectation function. Rather, the amount of discrepancy between the product function and the expectation function should be considered as part of the product creation process. This is somewhat meta, as the discrepancy between reality and expectations can also be modeled in terms of reality and expectations. In The Design of Everyday Things, Donald Norman discusses the concept of flow, which is the state of a user when performing a task at the appropriate level of difficulty that they can become totally immersed in it. For many products, the process of design can be seen as a means for finding and optimizing for flow.
Product Runway #
I think negative product debt can be thought of as a product’s runway, in a similar sense to Eric Ries’ startup runway, which he defines as number of the startup’s remaining viable pivots. To this extent, a product can be designed to optimize for runway length, or in other words, ease of product transition. For example, consider two features A and B that have each been validated. When deciding which feature to implement first, it’s useful to consider the direction of implementation (above and beyond considering just the marginal product value that each feature adds) as it relates to product runway. Is it easier to transition the product from A to B, or B to A? Does implementing A first leave a longer product runway than implementing B first? These are important questions to consider as part of the product creation process.