Prioritizing technical debt
In the pre-product / market fit stage, products can accumulate technical debt very quickly - but knowing what & why to tackle is a challenge. Here are two tools to help identify, mange, and prioritize technical debt by aligning it with customer value.
Lean startups rack up technical debt each iteration
One of the side-effects of taking a “lean startup” approach to finding product / market fit is you will accrue technical debt in the process.
But first, the concept of technical debt is better described by Ward Cunningham here, and he has a nice quote to sum things up:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.
When taking a “done is better than perfect” approach you are explicitly trading off the “right” technical solution in lieu of gaining an understanding of what customers want; so technical debt is inevitable.
No one likes taxes and black boxes
As a product person, managing this can be opaque and frustrating. In researching how others do so, many have approached it from an engineering perspective, and have even devised frameworks to categorize it.
What I found were generall two classes of answers. First, avoid it all together by building things “right” the first time — which is impossible to do in a startup that is searching for product / market fit, since you don’t know what you’re building yet. Second, is to develop some kind of “tax” whereby a proportion of every development iteration is allocated to paying down debt — similar like putting aside some fixed monthly amount to pay back your students loan or mortgage.
Unfortunately, technical debt is not quite like a mortgage or student loan; it’s not one big blob, and not every item has the same priority. The alternative is to leave it up to the discretion of the development team, but doing so makes product & development play in separate sandboxes, and shifts the problem rather than directly addressing it.
Instead we need a way that aligns technical debt around a common touch point of the customer. Here are two tools for you.
1) The debt equation: “what to tackle”
Technical debt is not something to avoid — if you you make a great meal, you’ve got to clean the kitchen…and you’re not going to clean the inside of your oven after every meal. So, you’ll always have some technical debt to contend with.
The key question is what items should you deal with and when. Thinking of this in terms like real debt helps:
- Principal - cost to fix the item
- Interest - the incremental impact if the item is not fixed
- Probability - the likelihood that you will actually incur the interest, treated as a discount factor to the interest value. This term is put here since you may never need to tackle that debt item if the product moves in another direction.
Therefore, you should only worry about items where the expected value of the interest exceeds the principal or: P < E(I).
Said simply, tackle debt items where the cost of fixing your previous hacks / hardcodes (should you even need to) takes longer than to just move forward with the new feature / enhancement.
2) The RAMESES mnemonic: “why to tackle”
When you develop your short list of “what” to do, in order to prioritize alongside your other development initiatives, it’s necessary to categorize technical debt in a manner that is directly attributed to customer value.
Here are seven categories, inspired by the Consortium for IT Software Quality (CISQ), that conveniently form the mnemonic “RAMESES” — after the Egyptian Pharaoh Rameses II, who was arguably one of the greatest builders of cities, temples, and monuments in the dynasty.
- R: Reliability
- A: Availability
- M: Maintainability
- E: Efficiency
- S: Scalability
- E: Extensibility
- S: Security
Let’s look at each one…
Reliability
In this category we’re looking to ensure the product remains fault tolerant, and performs consistently without degradation. Think about how often you reboot your system when it gets slow or corrupted. From this standpoint, you can start to develop metrics of how the customer experience will be impacted with repeated use, or for customers who come in long after a “reboot” of your system.
Availability
In the world of putting all things in the cloud, it becomes increasingly important to have proper backup and disaster recovery scenarios in place. From a customer standpoint this category refers to ensuring your system is “up” when customers need it.
Maintainability
How often have you heard one of your team members complain about touching a certain piece of code that is now a nightmare to do anything with? Thus they want to refactor it.
As a product manager, you can weigh this category as an investment of decreasing your trim to market for features touching this codebase in subsequent iterations.
Efficiency
This category refer to the speed / responsiveness of the service, which is very easily correlated to customer value.
Scalability
As your system grows, you’ll want to be sure to handle the load of new customers / requests. Many issues really only manifest themselves at-scale where small <1% errors can impact a large number of customers with growth.
Extensibility
This category refers to taking on net new development to extend the capability of the system to new areas. So from a product perspective, items here can be weighed as a “time to market” for specific functions and features in the product.
Security
I think this one is most clear of all, in that you’ll want to protect your customers, and their data, from rogue attacks and privacy.
Align on the customer
Together, the debt equation and the RAMESES mnemonic are helpful tools to avoid the opaqueness of simply setting aside a “flat tax” each iteration.
Instead, we should quantify the most important items and classify them to one of the 7 categories, so that they can be weighed alongside all features and fixes. This then ensures that all development initiatives are aligned on the customer.
