Product debt

Tech Debt has always been the term most people refer to when it comes to debt created by building a product. But there's also UX and general product debt. All of this debt is created by a similar process: when you didn't overthink a problem, and it ended up delivering value. To keep things simple, we'll call it all Product Debt.

Similar to debt, product Debt is not a bad thing. There is good and bad product debt, just like there is good and bad personal debt.

Product debt occurs when our understanding of the problem outgrows the understanding reflected by the code or UX. This is not a bad thing, it's just that our 202107112013 Our solution (code and UX) should be evolving. A debt-free solution that doesn't deliver value is much worse for the business than a debt solution that delivers value.

The creator of the term technical debt, Ward Cunningham posted a video explaining the metaphor. In the video he says:

With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you'll be paying interest. I thought borrowing money was a good idea,** I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program** to reflect your experience as you acquired it. ^[1]

Paying off debt

The most important thing to remember is that this debt is the same as any other debt. It's a risk. This means that it may not always materialize or have an impact.

Prioritization questions

• What happens if we don't pay off this debt? (the impact to customers, users, developers, and designers)
• How severe is it?
• When will we see the impact of this debt? Is it immediate, or the next time we touch this code.
• What happens if we defer paying off this debt?

Who owns prioritizing paying off debt?

• Paying off debt is about decreasing risk and increasing the ability of the team to delivery value.
• This is the bread and butter of the product manager, they need to prioritize the current and future work to deliver the most value to our customers and users.

Thoughts

• Product debt means you were able to deliver value sooner
• Product debt means what you did resulted in value, and it's now worth doing it better
• Need to explore what is bad code and how a PM can tell

Tech Debt

Code

• when you copy and paste code, duplicating the logic in two spots
• import libraries for a single requirement
• If this is bad code, should it be considered tech debt? How do you define bad code?

Architectural

Data

Resources

https://ganotnoa.com/who-owns-the-technical-debt/