If you’ve spent any amount of time around developers you should be familiar with the term technical debt. Technical debt comes from hacking things together quickly and moving on. It accumulates over time. It can come back to bite you in the ass (if you scale to the point where the debt becomes obvious). It’s also inevitable. Every startup has some amount of technical debt.

In my experience developers hate technical debt. That’s why you’ll often hear them talk about refactoring code, which is about doing things in a better way and eliminating debt. You’ve got to allot some time for removing technical debt, but you also have to balance that against new feature development and product progress. If you spend all of your time resolving technical debt you’ll have a sounder, better, more scalable solution, but it probably won’t matter to your users and customers (because you probably haven’t hit the pains of scale yet). Accruing technical debt needs to be a conscious choice that you make as a team (founders, product managers, developers, QA) to cut some corners and get things out the door quickly. Then make sure you pay it back so you don’t suffocate under its weight.

Turns out, there’s another kind of debt. I’m calling it “product debt” (I’m not the first one to use this or similar terms; see Andrew Chen on product design debt and Vijay Sundaram on user experience debt).

Product debt isn’t something you hear a lot of startups talk about, but it happens to everyone. When you’re building small chunks/features iteratively you’re going to run into situations where you don’t have the “perfect experience” mapped out for everything, where you haven’t fully thought about how the product should function immediately or months from now as more features are added. You want to be deliberate in your thinking and efforts, but you also need to get features out the door so you can test them. So you sacrifice parts of the user experience in order to move quickly. That’s OK, as long as you’re doing it consciously and you recognize that you’re accruing product debt.

Product debt is obvious when you see differences where there shouldn’t be any. Why are the error messages formatted differently in different parts of the product? Why are the form fields organized differently on two separate pages? Why do you have three ways of doing the same thing inside your product? It doesn’t take long to turn a simple product into a complex one.

Consistency in product design is critical. Things should look, feel and work the same way unless there’s a specific reason for them not to. Users will learn how your product works very quickly, and if you don’t have a high enough level of consistency you will confuse and frustrate them. Changing people’s behavior is hard enough; don’t make it harder on yourself with an inconsistent product.

Most product debt is not taken on consciously (whereas I think a lot of technical debt is, because developers are more attune to it). Product debt comes from making rush decisions. It comes from lazy product thinking and design. It comes from the hope that adding “just one more feature” will solve all of your problems. It comes from wanting to push features as quickly as possible.

When taken on unconsciously or not admitted to, product debt will make future product development much more challenging. Everything will take longer to do because there’s no consistency; your team won’t have a solid template to build from and the debt will get worse.

You need to invest in paying down your product debt on a regular basis. I suggest doing it over time as you’re adding to or changing the product. If you’re adding a new form into the product take the time to design it the way you want, then go back and redesign the others. Make sure you’re doing this consciously, otherwise no one will understand why a simple feature is taking a lot longer to do. Make sure product management, design, development and QA are all aligned. Don’t go fixing product debt without everyone agreeing–it’ll just frustrate the entire team.

As your product matures and you realize that adding a million more features won’t solve all of your problems (it always takes people some time to figure this out), you can invest entire product cycles (1 week? 2 weeks?) to clearing out product debt. You should do this at the same time as you invest in technical debt and bug fixing. Do an entire release for paying down your debt–in my experience product, design and development teams find this really rewarding because the debt’s been gnawing at them. And while it might not feel like you’re improving the product for users, don’t be so sure–the consistency you put into the product can help engagement and usage (just like solving technical debt can improve things like performance and scale).

Photo from carnagenyc.