Eventually, everything you ship will become product debt.
This idea surfaces whenever a product manager laments they haven’t “finished the thought” on a product or feature. The moment code hits production — arguably, even before a production deployment — it becomes, in its earliest, rawest form: product debt. The concept of product debt proposes there is a perfect product, a perfect way to build said product, and you can know this before you ship the product. Absent the limits of time or money, perhaps? But there’s an argument to be made that even without those constraints, we are far better off shipping today and living with the product debt we create.
Technical debt = Product debt
The Venn diagram overlap between tech debt and product debt is so great it’s rarely worth differentiating between the two. Using the phrase “tech debt” enforces a concept that code, on its own, becomes obsolete without people coming up with new ideas for how that code should work or what it should produce. Even in the instance where you need to update libraries referenced in code, that is, one might imagine, so that the product continues to function, therefore rendering the change “product debt.” Recognizing and naming it product debt should reinforce that maintaining a code base is an integral part of the products you develop.
Everything is product debt
Across industries and geographies, the immutable refrain from technology teams is: we have too much product debt. If only we tackled that debt, whittled it down to the smallest pile of code, we could move faster, ship smarter, and make our P&Ls sparkle. Product development is a team effort and in software development, when there’s an insistence that a refactor to address product debt is necessary, your inclination as a product manager should be to believe those statements; teams build and ship great products when there’s a high level of trust. However, product debt is subjective and there’s a reason for that: the only person for which the code is easy to maintain is the person that authored the code.
There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It’s harder to read code than to write it.
This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.
If you are considering a refactor, here are a few questions to ask ahead of tackling that particular type of product debt:
- What will be gained by addressing this now and how will the outcome be measured?
- How will delaying the refactor impact the business?
- If time and money were not considerations, is this the first thing the team would address?
Eat at your own restaurant
Although you and your colleagues are not your users, it’s paramount to keep your product development focused on your customer and eat at your own restaurant. That means using your product, as if you were a customer, and evaluating all aspects of the experience, including the service, not just the meal purchased. There are a few flavors of this adage, but the restaurant experience resonates most in software development; you are not building a house in which to live, which might require more rigorous elimination of product debt, but rather crafting a delightful experience that your customers will talk about and return to, expecting something similar, if not superior to that first interaction.
While you should be listening to your customers and observing what they do versus what they say, using your product — eating at your own restaurant — will help you find the areas of good and bad UX friction. Identifying these areas and moments will contextualize the outputs from your user research and frame questions about product debt:
- What aspect of the user experience is relieved by addressing this debt?
- Is this part of the user experience helped or hindered by the debt you are addressing?
- How will you measure the impact on the user experience of addressing this area of product debt?
Ship it, today.
Roses are red,
Violets are blue,
Ship it now,
Fix it in v2
Product development requires constant risk assessment; what’s the risk of missing this deadline; what’s the risk of shipping without that feature; what’s the risk of not addressing that bug in production until the next sprint. When you have the opportunity to test, you reduce the level of risk involved in any new endeavor and there is no better place to test than production. Shipping early and often will develop your bias for action, helping you hone how to react when things don’t go as planned (e.g. discussing & defining a roll back plan) and craft go-to-market templates for releases of all sizes to key user groups (e.g. leveraging feature flags and user segmentation).
If you find yourself holding back deployments because a product or new feature isn’t ready, here are a few questions to consider first:
- What will you learn from people interacting with the product or feature in its current state?
- What will you learn from people reacting to the concept, if they won’t be able to interact with the product or feature?
What if prioritising paying off tech debt *by itself* not coupled to building new/better stuff for the business…
… was an indication that we had more money, more people, more time than what we really needed?
And perhaps not having this luxury makes for more pragmatic choices?
There’s a time and place to address product debt: when it will provide measurable benefit to your product and business. Tackling product debt simply because you’ve uncovered something that could be refactored isn’t a reason. Use the questions surfaced here to guide your decision about product debt and comment to share how you approach product debt.
