The Difference between Product and Technical Debt, It's not what you might think
Imagine a startup. Not your typical startup, a kind of “old school” startup. A startup relentlessly pursuing growth despite no clear path to revenue. Nonetheless, there is an investment opportunity. It’s in a great market, growing exponentially over the past years. The opportunity is there, but it can’t seem to capitalize.
This company has a product that serves the “Freelance Economy.” The “Freelance Economy” is a market. It contains customers and suppliers. The “Freelance Economy” requires that two different customers find a way to connect. This is the market problem. The company has a product that attempts to solve this market’s problem. However, discovering a market with a problem is different than uncovering the problems of the constituents.
People use products, not markets.
A market’s needs and a customer’s needs are different. Y Combinator’s motto is build something people want, not build something a market needs. By not understanding the customer needs and not focusing on personas, it inevitably built the wrong product.
The Oprah Winfrey show’s producers gave their customer a name and a persona. They called her Suzie. Suzie is best described as the 1980’s & 1990’s middle-aged suburban housewife. When the producers were coming up with ideas for shows, they would often ask themselves, “Would Suzie like this?” Imagine if instead they asked, “Is this entertainment?” The show would have looked radically different. The ratings-shattering Oprah weight loss show is not entertainment, TO ME. But, Suzie clearly thought differently.
Entertainment is a market. There are many different personas for entertainment customers. Not every person is going to like every show, but that is okay! Actually, it’s great. It allows companies to specialize. It allows companies to make great products for the people that need them.
The product didn’t have a clear customer vision, instead it solved a general problem that didn’t resonate with customers.
This is what I call “product debt”. This is a concept I derived from the software engineering term, “technical debt”. Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. “Technical debt” can be acceptable in engineering. Engineering solutions are often binary. It either works or it doesn’t.
“Product debt” and “technical debt” are fundamentally different, though. The company cannot accept this type of “debt” in a product. A product’s goal is to find a solution to a problem. Let’s modify 5 words in the technical debt definition to apply it to product.
Product debt is “a concept in product that reflects the extra solution discovery work that arises when a solution that is easy to find in the short run is used instead of discovering the best overall solution”.
With this definition, I am saying that if a product debt exists, the creators built a lousy product. Maybe 20 years ago, the company could accept product debt. But in an environment where the barrier to entry for engineering products is low, product debt becomes exceptionally expensive. Quick acting competitors with a more useful and customer-minded solutions will usurp incumbents with debt. An optimal solution creates a sustainable competitive advantage.
Put another way, “Product debt” is the delta between product market fit and the current product. For example, our company built a platform that allows for users to request and offer services in an open market place. The solution that was implemented was to treat offerers and requesters with the same set of tools. Fiverr, a successful “freelance economy” platform, notes, in their 2015 year in review, that 75% of their requests come from small to medium sized businesses and 76% of service providers are millennials. This proves an offerer and a requester are two different segments of the market. The company cannot ignore that, but they did. Consequently, the features they implemented didn’t work. They simply are not right for our customers. You can always buy low quality users with advertising, but you can’t buy retention. Until the company fixes this product debt, it won’t achieve a sustainable business or product market fit.
What do they do next?
Technologists should get excited about product debt. It is a chance to start from scratch, reframe the problem, and optimize the solution. The company cannot ignore product debt. It’s similar to building a house on a faulty foundation🏚. Designing and building products is not a new discipline. There are paradigms that have been pioneered and studied to help prevent product debt. Imagine someone tried to architect a structure without even attempting to learn architecture. That would not be a building I would want to habitat. Build with thought and purpose. Look to successful product people to find what works. I suggest Nir Eyal’s book Hooked or Julie Zhuo’s 3 product deign questions developed at Facebook. Identification is half the solution. And when the going gets tough, the tough get creative!
If you enjoyed, Don’t forget to click and hold the 👏 so other people can find the article. Incentive Theory is a publication that focuses in data science and direct to consumer strategy.
