The Intangibles of Product Debt

Let’s talk about debt.

You’re most likely aware of technical debt. You’ve possibly heard of UX debt. You may have even heard of product debt.

If you’re not familiar with these terms, let’s use the following definitions:

Technical Debt: those internal things that you choose not to do now, but will impede future development if left undone

UX Debt: those things that you choose not to do now, but will impact the user’s ability to interact with your product.

Product debt: the combination of technical and UX debt.

In this post I’d like to spend a bit of time talking about the not-so-easily identifiable debt. The intangibles, if you will. This debt can exist in all of the types listed above, and affects everyone who touches the product: designer, developer, product owner, and finally – and most importantly – the user. But sometimes we don’t consider how impacting this debt can be.

There is an interplay between technical and UX debt. Oftentimes one will cause the other. Poorly written code may cause an application to load slowly. Brittle code may prevent the implementation of a better user onboarding experience. An unresearched, elaborate design may make development shortcuts necessary to meet deadlines. And the list of examples goes on.

Some debts are fun when you are acquiring them, but none are fun when you set about retiring them. – Ogden Nash

It’s important to keep in mind that not all debt is bad. Sometimes sacrifices must be made to get your work into the world. Remember, it’s not a product until it ships, and MVP is not a four letter word. The debt that you are accruing might be the only thing that keeps you on track to actually make money and – hopefully – go back to pay down the debt.

No one ever says “Sure, but just these 94 times”, but if you start with “Just this once” you’ll get there eventually. – @destraynor

Your app makes me fat

In her excellent post, Kathy Sierra discusses the fact that willpower and cognitive processing shares a single pool of resources. Once those resources are gone, so is self-control. The result of this is that we make poor choices, snap at family or co-workers, or are simply drained of willpower and focus.

Imagine being a product owner whose product has significant debt. Your cognitive resources are being depleted by those background mental threads asking, “was that the correct choice?”

This is a picture perfect example of the paradox of choice. Having more choices does not always lead to a better experience. This also applies to users. Foisting choices upon the user because the product team refuses to make an informed decision nearly guarantees a less-pleasurable experience.

As a designer or developer, keeping track of all the landmines in a codebase, or what shortcuts have been taken will drain cognitive resources and can result in decisions that actually introduce new debt to the system.

This is when we choose to eat cake instead of carrots. Or make other choices that we wouldn’t have made with sufficient willpower.

Right in the feels

Raise your hand if you like working on products that drain your will to live?

*crickets*

Yeah, neither do I.

Requiring a good designer or developer to take shortcuts or continually work around bugs is like fingernails on a chalkboard. Imagine your product causing piles of complaints to fill your inbox because it does not work as expected.

As a consumer, have you avoided a retailer because you can’t seem to ever successfully check out and buy something from them online? I know I have.

All of these things are morale killers. And eventually, people will prioritize their happiness and cognitive capacity over continuing to slog their way through the morass that is the product they’re facing. Designers, developers, and product owners will find other jobs, and users will find other products that are less taxing and a better value for their money.

Ain’t nobody got time for that

Remember that we charge more than money for the use of our products. Users also pay with their focus and time. In a busy world of instant gratification, these costs are not insignificant.

Product owners need to know where to focus their efforts. If the current experience sucks, it is very difficult to measure and predict future user behavior, and this removes the ability to gain news insights for product direction. Having a clear UX allows us to better define the future of our products, instead of rehashing the past and going over what needs to be fixed.

Decision-making takes time. Keeping track of all of the debt as the owner/designer/developer and deciding what to work on next, or thinking over the breadth of choices I can make as a user, means that it will take more time to make a decision (Hick’s Law).

Everyone has a maximum of 24 hours in their day. We have to prove that our products are worth some of that time. Otherwise, users will just abandon us like the hundreds of other apps that litter their computers and phones. Even when there is a great onboarding and first use experience, if usage requires too much time or effort the end result is the same.

Users owe us nothing; we owe them our best

Users do not owe us their time – or their cognitive resources – to learn our applications. It is our responsibility to make products better for them. This means we must be aware of the debts that can accrue over the lifespan of projects. While these debts cause drag on a product’s development, there are also wide reaching ramifications that affect who matters most: the user.

If we’re not making the product for them, what’s the point of making it in the first place?