Last week I attended a conference kindly organized by Outbrain, a start-up company located in Netanya, Israel. Outbrain’s VP R&D, Itai Hochman, described their engineering philosophy, which includes—among other things—avoiding “broken windows”. The Broken Windows Theory (popularized by the decline of crime in New York in the 1990’s) suggests that having broken windows in a neighborhood quickly escalates into more severe crime. The engineering analogy would be that unattended “issues” in the product would similarly result in more global deterioration of quality.
The broken windows metaphor is appealing. But, a metaphor from the economics world—that of a debt—may provide a few more tools to handle product gaps.
In many parts of the world, it is common to take loans to finance large purchases, such as a house or car. Interestingly, most people can typically pretty easily understand the concept of a loan, or debt. There’s the net cost of what you want to buy (say $100,000). Rather than paying the net cost upfront, one pays some down payment (say $20,000), and then pays back the remaining portion in installments over a period of time (say $2,000 monthly). The eventual sum paid incorporates some interest, which means that the overall price paid is higher than the net price. Most people get the concept, and can even handle the math with some basic calculators.
What’s interesting is that when creating software, a similar phenomenon occurs. And, as the recent economic meltdown has proven, taking more debt than one can afford can have a detrimental effect.
Here’s how the analogy works.
In the software world, and especially with software-as-a-service, software creators oftentimes launch bare-bones products, with known “gaps”, which can be business gaps or technical/architectural gaps. These gaps create ongoing cost within the organization (sales, support, engineering); these cost items are analogous to the interest paid on the “debt” used to launch the product.
Product debt may be created at any level in the organization. For example:
- The product team may not be fully assembled; the sales team may not be fully up to speed (commonly CEO level issues)
- The target market may not be fully identified, or the pricing may not be completely finalized (commonly Product Management level issues)
- The product may not be stable enough or feature-complete (commonly an engineering and support issues)
- The architecture may not be robust or scalable (commonly an engineering issue)
Naturally, the product gaps create hidden cost elements throughout the organization, when people fill in the gaps—analogous to financial interest. What’s interesting, though, is that in the software world, one does not get a monthly bill asking for the next installment. So, the interest can easily go unnoticed. And, unless the gaps are closed, there’s a hidden ongoing cost structure that’s easy to overlook.
The analogy of debt in the software world is typically attributed to Ward
Cunningham, who coined the term technical debt. Having this analogy helps plan one’s execution strategy:
- In planning mode, do not be tempted to base decisions just on the initial cost for product launch. In other words, the house costs $1,000,000 even if the down payment is only $200,000. In more cases than not, it makes business sense to launch bare-bones products and make investments in chunks (more on that below), but one must be aware that the full investment will eventually be made. And interest will accumulate.
- Be ready to pay back interest. Get the right staff to fill in the gaps (e.g., address support issues) or be prepared to invest more elsewhere (e.g., less effective engineering process due to wearing code). And, plan to invest in closing the gaps to reduce the debt.
- Plan the right level of debt. As most finance people will state, determining the proper amount of debt for an organization is a delicate process.
- Debt is great if you don’t need to pay back. Launching bare-bones products into immature markets or to an uncertain customer base is a great way to take debt. You will only pay back the debt if the product is successful, and the debt may otherwise be dropped. This approach (oftentimes referred to as Minimum Viable Product) is like taking a loan from a lender that may not be around to collect the money when it’s due.
Either way, I believe that awareness is the key. One does get monthly bills for product debts, so you must be aware of the outstanding debts and be conscious of the interest paid so you can incorporate these considerations into the product planning process.
NOTE (Oct. 2, 2011): I bumped into this post (Aug. 2011), which outlines some thoughts on when Product Debt (or Technical Debt) is desirable (to a certain degree).