Every Product Manager out there knows about the struggle that is tech debt. Some teams call it component ownership, other times it will come up as a code refactor, but one of the most challenging parts of the job as a Product Manager is building trust with your engineering partners, and prioritizing what tech debt needs prioritizing.

What is tech debt?

ProductPlan defines tech debt as “what results when development teams take action to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.”

“Technical debt can be compared to monetary debt. What does it mean? If technical debt is not repaid, it can accumulate ‘interest’ making it harder to implement changes later on.”

Some of my biggest mistakes when I first became a Product Manager was not listening enough to my engineer teammates who brought up tech debt they’d like to take into the next sprint.

While it isn’t always easy, you must take the time to understand the ask, understand the near term impact to the customer, and if that is not apparent enough, dig in to what the longer term impact to team throughput / morale can be.

Engineering team morale is critical in order to maintain and improve as a Product Manager, and prioritizing the right tech debt at the right time can sometimes be the key to unlock that treasure.

Deciding how and when to prioritize tech debt is no easy thing, and it can’t be left until the very last minute like that term paper in your sophomore year of college either. Aaron Kechley published a pretty great framework for prioritizing tech debt.

OK, so tech debt is a bummer, how about this long lost cousin you speak of?

What is design debt?

Design debt is similar to tech debt, in that it is just as hard to prioritize. However where tech debt’s main cost is that it slows the engineering team down, design debts main cost is an inconsistent website.

Design debt is any small inconsistency across your eCommerce website from a design standpoint. It could be that one line of text is the wrong font size, that there is too little or too much padding in an area, that something is not aligned correctly, or maybe it is using an inconsistent typeface.

Photo by Annie Spratt on Unsplash

What are the short term costs of design debt? Similar to tech debt, there really aren’t any. The vast majority of customers won’t notice a thing (unless they work in design for someone else). Some misalignment or padding issues can be a bit rough around the edges but overall in the short term things are fine.

Similar to tech debt however, design debt has similar long term consequences. Over time these 1,000s of little cuts build up to excruciating pain. An inconsistent look and feel for your site can drive a lack of trust from customers that eventually will hit the bottom line of your business.

And how about prioritization? Just like tech debt, prioritization is incredibly challenging for design debt. Like taking the time to prioritize a ticket and have engineering parachute in to change the font size on a line of copy is bringing a Ferrari to a tricycle race. It just doesn’t make sense.

How to solve the prioritization dilemma of design debt:

Here are three methods we’ve tried, some of which work better than others depending on the task, time of year, or which way the wind is blowing that day.

1. Acceptance testing

Ideally, design debt would never show up in the first place. Some teams practice acceptance testing, or user acceptance testing (UATs). This is the idea that when something is close to code complete, UX and design partners review the experience and identify tweaks that the engineering team then fixes before deploying.

This can be great for a team with embedded UX, but can really slow things down when UX is not on the same page or a centralized resource that often moves completely away from your space.

2. The “under the hood” approach

Photo by Tekton on Unsplash

While not the cleanest, oftentimes you can fit unrelated design debt into other features as they come up, as long as they are in the same space. Including design debt changes as acceptance criteria in existing feature requests for the engineering team can give them a centralized source to pick up quick fixes along the way.

However including extraneous details in often complex technical tickets can increase team confusion and decrease throughput. Be careful when doing this!

3. Bug bash, but for design

The last method I have seen work is a bug bash, but for design. Step 1 here is gathering all of the design tweaks the team wants to make. Then you block off half a day of time and any front end engineers that want to partake, and you host a design bug bash. By doing this periodically, you can keep the look and feel of the site consistent, keep design happy, and provide focused attention to design debt. The main challenge here is just finding the time for it.

Regardless of how you tackle design debt, know it is real. Just as tech debt can slow team throughput down, design debt can over time erode customer confidence. Make sure you pay attention to it!

A big thanks to Mike Markowski at Trunk Club for introducing me to the idea!