Technical Debt Is Overhyped. Let’s Talk about Product Debt
Product decision shortcuts made in the past might have some expensive long-term consequences. Do not only put engineering in the spotlight with technical debt.
👋 Hey, it’s András here! Every two weeks, I write about product management concepts, hot takes, and frameworks to help you build better products. Subscribe to The Product Principle to get each article delivered to you when it’s published!
As a product owner, you would like to go ahead with that shiny new feature that makes everybody excited — even your customers — but your technical lead comes to you with some bad news that goes something like this:
“It’ll take a lot of time. Our MySQL database is not that scaleable, that code we need to work on is like spaghetti, and we would anyways need to upgrade our JavaScript framework…”
In similar cases, we often mention the institution of technical debt.
Technical debt arises when a development team takes technical shortcuts repeatedly that prioritizes speed over quality. Instead of aiming for perfect code or technology, the team settles for quick and dirty.
Suppose technical debt is not kept in check. In that case, it will result in bugs, bad user experience, slowness of solution delivery, and in most cases, even demotivates the team itself.
But the more we talk about technical debt, the more we assign the blame, even if unconsciously, to software developers. The expression contains the word “technical,” so it should have nothing to do with product and UX people. That makes sense, right?
And that’s where we get it wrong.
The concept of product debt
For the purposes of this article, “technical debt” refers to the technological part of software development. But there’s something else we should consider: product debt.
Product debt is all the past decisions that were made without a clear product vision or sufficient consideration about the long-term effect of a change.
Building up a product debt is easy and, unfortunately, very expensive. Shortcuts in decisions, lack of care, or multiple people with different visions managing the same product can all contribute to that.
I also have experience with product debt, something that I inherited. Two products were built to do practically the same thing, but one runs on a modern microservices architecture, and the other is a monolith. The challenge is that they’re different enough not to replace one with the other, and feature parity would still take multiple years.
But you don’t have to go too far away to find popular examples.
If you look at Google’s messaging efforts, you’ll find plenty of product debt.
The Google Chat-Hangouts-Messenger-Duo-Allo-Chat product
Google has a simple aim with its messaging product: to provide a reliable way to text, voice, or video call acquaintances. Even though this goal seems manageable enough, the corporate giant took many turns over the years, introducing and deprecating various applications.
Back in 2018, The Verge assembled a timeline of Google’s messaging efforts, which I extended below. While it’s a long list, it perfectly illustrates the confused product vision, which resulted in product debt.
- August 2005: introducing Google Talk (aka Google Chat)
- October 2008: Google Talk integrates SMS with the launch of Android
- June 2011: Google+ launches with Huddle group messaging and Hangouts video chat apps
- May 2013: Google Hangouts merges other Google messaging and video chat applications
- September 2014: Google Voice gets integrated into Hangouts
- November 2014: Google Messenger launches with support for SMS
- April 2015: Project Fi launches, also integrating with Hangouts
- January 2016: Google Messenger becomes the default SMS client on Android
- June 2016: Google Talk and Google Chat discontinued
- August 2016: Google releases Duo, a video chat application
- September 2016: Google releases Allo, a new texting app
- February 2017: Google Messenger is renamed to Messages
- March 2017: Google announces Hangouts is becoming “Hangouts Chat,” an enterprise-focused messaging client
- January 2019: Google announces plans to shut down classic Hangouts for corporate users, moving them to Hangouts Chat
- May 2019: Google shuts down Allo
- April 2020: Hangouts Chat and Hangouts Meet changes their name to Google Chat and Google Meet
In 15 years, we’ve come a full circle.
The search giant started with Google Chat in 2005. After several changes, they brought back the same name for their previous Hangouts product.
The lesson here?
Google didn’t have a clear, company-wide product vision for messaging. Instead, multiple teams might have been competing internally, hence the product debt.
Managing product debt
Product debt is a silent killer of your product. But a very slow one.
Do you have a clear product vision? One that not only tells you what to focus on but also highlights what to steer clear of?
Both organizations and product owners can fall victim to operating a feature factory. If you don’t see the context and what value you’re bringing to your customers, you will only build the things right.
Instead of building the right things.
Look at Airbnb, Twitter, Uber, or Spotify. You don’t question what these products do because they made conscious decisions regarding what they offer and what they don’t — thereby managing their product debt.
While it’s not possible to avoid it altogether, product debt is only dangerous if you let it pile up over time. The most important is to recognize its existence.
Do we have product debt?
To get a sense of how your product is doing, consider the following questions:
- Are your teams trusting the product vision (suppose you have one)?
If not enough, the lack of confidence might lead teams to wander off to new territories, building features that will result in a divided product. - Do you (and others) understand the value generated by the product?
Delivering features is one thing. Delivering value is another. In order to do the latter, first, you must understand what your customers call value. - Do you validate hypotheses before they turn to decisions?Putting enough time and resources into validating ideas is a must. The less reversible one idea is, the more confidence you should build up.
- Do you occasionally remove features that are not used?
Maintenance usually weighs more in the total cost of ownership (TCO) of a feature than the actual development. Consider what you carry on. - Do you have the right metrics for the product?
Beyond measuring the bottom line, focus on other metrics that might even predict if your users are going to renew or cancel their subscriptions.
Awareness is a good start. Once you consider these questions, start focusing on the ones you answered with a “no”.
