Technical Debt Is Overhyped. Let’s Talk about Product Debt

Decision shortcuts made in the past might have some expensive long-term consequences.

András Juhász
Oct 7 · 5 min read
Image for post
Image for post
Image by StartupStockPhotos from Pixabay

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 vision 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, the other is a monolith. The challenge 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 were 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.

After awareness

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 weights 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 subscription.

Awareness is a good start. Once you consider these questions, start by focusing on the ones you answered in the negative.

The Startup

Medium's largest active publication, followed by +732K people. Follow to join our community.

András Juhász

Written by

Product Manager at Emarsys — passionate about great user experiences, product strategy & outcome-focused delivery.

The Startup

Medium's largest active publication, followed by +732K people. Follow to join our community.

András Juhász

Written by

Product Manager at Emarsys — passionate about great user experiences, product strategy & outcome-focused delivery.

The Startup

Medium's largest active publication, followed by +732K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store