If you’ve spent more than 5 minutes with an engineering team, you’ve probably heard about “Tech Debt”. This is the cost of making a choice that isn’t the best from an engineering perspective, but may be necessary due to market or external forces.
Contrary to popular belief, tech debt isn’t always a bad thing. It’s kind of like using your credit card – it’s a handy option as long as you pay it off each month. Unfortunately, it often turns into a big problem because the team never goes back and does it right. Just like a credit card, this debt accumulates “interest” and if not addressed soon enough, it can bring a product to its knees. The good news is that most product orgs are conscious of this risk and include it in their product planning and prioritization.
The bad news is that this isn’t the only kind of debt you can incur with a product. How many times have you been going over your roadmap or release plan and said things like:
“We don’t have time to implement Feature X in this release.”
“If we don’t add all of the design, it might not be as ‘usable’, but it will be functional.”
While you may not be incurring Tech debt, you are still incurring some form of debt. You are making a tradeoff that is compromising what your discovery efforts have told you. With my teams, we call this “Feature Debt” and “Usability Debt” and we talk about it just like we do with “Tech Debt”.
Most people seem to get Feature Debt. It’s pretty straight forward
- We identified a feature
- We wrote stories
- We did designs
- We scoped the effort
- We DIDN’T release it
Usually Feature Debt is handled in the backlog and since the product manager championed this idea and is managing the priorities, it usually gets addressed somewhere. (As much as I hate to admit it, product managers often don’t give Tech Debt the same sort of love.)
Usability Debt is a little trickier because the question of “What is usable?” can be fuzzier and often times it’s not consistent from one part of the experience to another. Do you really need to have the same level of usability for a feature that is used once a year, by one person as you do for something used hundreds of times a session by every user? Probably not, but it can be a slippery slope. We break things out in three levels:
- Functional: This means that the interface can trigger the server to do the task that’s intended. You know you’re in that land when you hear phrases like “It’s not pretty, but it works!“
- Usable: This is where it is not only functional, but it makes sense to the user and it helps them accomplish the task in a way that makes their experience positive.
- Delightful: Now, you’re in product/UX nirvana. You are surprising the customer and they not only have a positive experience, they “LOVE” the feature or product.
While I agree, we should all be shooting for delightful, the reality is that it’s not always realistic due to other market/company constraints. With that said, we should never just accept functional, because while it may save time, it always ends up hurting your product in the long run.
To help us manage both the different debt types and to ensure that we have a clear understanding of what are the acceptable levels of debt, my teams have instituted something called “Debt Floors“.
Instead of thinking of them as how much debt are we willing to accept and calling them “Debt Ceilings”, we want to instead think of them as limits on how much we are willing to sacrifice to still meet our objectives.
This allows us to establish a set of standards for technology, features, and usability that will ensure that we produce scalable, reliable software that makes it easy for our customers to do their jobs and evoke feelings of delight and joy. By defining these “Debt Floors” we can create a set of criteria to ensure we don’t compromise our definition of quality.