I’m now going to make a lot of my developer friends upset. In this article, I will explain why building tech debt actually can be a good thing. Especially in stages with high uncertainty like the early stages of a startup or when doing other innovations. If you do it right you might even be able to write off some of the debt you created.
I learned the usefulness of tech debt the hard way a couple of years ago when building a digital startup of my own. The startup didn’t take off and the main reason was we did not leverage tech debt enough.
But let’s first settle on the definition of debt.
What is debt?
According to Wikipedia, it is:
Debt is a deferred payment, or series of payments, which differentiates it from an immediate purchase.
– Wikipedia
Ok. That makes sense. We get something we want upfront with a handshake that we will pay for it later. That sounds like a pretty good setup for everyone involved. And actually, it is as long as it is done in healthy doses. It keeps commerce going by providing liquidity. And commerce makes everyone wealthier as Adam Smith wrote in The Wealth of Nations.
But if you ask a general person on the street they probably say debt is something bad. We have a lot of proverbs in Sweden about debt. Like “The one who is in debt is not free”. When I started researching this subject I found that our relationship with debt goes back a long way in history.
The rich rule over the poor, and the borrower is slave to the lender.
Proverbs 22:7, the Bible
Who wants to be a slave? It does not sound too good to be the borrower. Debt is a double-edged sword. And a pretty sharp one. Correctly used, debt allows you to create leverage. This is true in finance as well as in business- and product- development.
Let’s explore how to wield that sword like a master swordsman in the realm of product development.
Accumulating debt is human nature
Why do we accumulate debt? The most high-level answer to why we take on debt has to do with human nature. As beings, we want to have the results now without doing the full price. We are impatient. Awareness of this inclination in our nature will help us make better decisions.
This is true for people who take loans to buy the latest Tesla model or for a developer who doesn’t cover all the code with automated tests and instead pushes the code to the users early. Even the average person who postpones the needed dietary changes and exercise regime to improve her health is taking also taking on a type of debt.
We can always write those tests later, let’s get the feature out there. I need that car now, how else am I going to drive to work? It’s ok to not have the physique to take four flights of stairs without having a feeling of an impending heart attack. You get the point.
But keep in mind that all debt comes with interest. And we need to pay this interest or it starts to accumulate and your debt grows even more. And with that the future interest too. This is the concept of interest on interest.
A pretty vicious cycle. So why on earth would we even want to take on debt in the first place? Every situation is unique of course, and we make an informed decision. In the next section, we will look at the structure of debt in product development.
A crash course in digital product development
But before we dive into the concept of debt in product development we first need to understand the basics of it. Let’s do a 101 product development course together. Don’t worry, you will be a product professional in 2 minutes.
Digital product development is the craftmanship to solve a user’s needs with software. This involves complex activities all the way from discovering and understanding the need to put a fully functional piece of software in the hands of the users. For our 101 crash course it’s enough to understand a few key high-level aspects:
- Product development is not a one-time linear process going from A to B. It is an iterative process, that repeats again and again with improvements on each iteration.
- The purpose of each iteration is to gain insights and learnings.
- Some parts of the process are more time-consuming than others. Sometimes you can take a shortcut and skip parts of it to get to the insights faster.
Get your ideas in the hands of users as early as possible to get insights
Ideas/sketches/conversations with customers are cheap to execute and can often get you the insights you need to push your business forward. It doesn’t take that much effort to create a low-fi prototype of your idea.
Remember, it’s about learning and insights. If the purpose is to get feedback a simple enough sketch might just do the trick. Compare showing the rough sketch to some customers to all the work involved with building the final product which includes:
- building a database structure
- backend integrations
- frontend implementation
- HIFI designs
- tracking metrics of user behavior and usages of the service
- automated tests
Let’s stop right there listing things involved with building digital products as this could easily take us down a very deep rabbit hole.
The effort to get insight into your ideas grows almost geometrically the closer to a finished product you want to get before putting it in the hands of customers.
Product development is all about mitigating risks
We need to understand that our goal early on is to mitigate risks. This is true both in mature companies as well as startups. That’s right, you heard me. Mitigate risks. Not making money, selling our product, raising money, or solving some fancy technical challenge.
Let’s consider these risks:
- We will not be able to create an attractive user interface for our service
- The app will not be able to fetch the user data to be displayed in the mobile app
- We will not be able to raise money from investors for our new idea
- The customers are not interested in paying for the combined bird trap and cat feeder.
Which one of these risks should be focused on for our insight activities? The risk around the customer needs should be the focus. If there is no unsatisfied need that our product addresses no hot design, ingenious technical implementation, or expensive marketing will be able to make your product succeeds.
If you want to dive deep into this subject of developing products, “The Startup Way” by Eric Ries is a must-read. It is a virtual bible for product professionals describing both processes as well as organizational setups.
Now we have a common understanding of the core of product development. It’s time to get to the tech debt part in the next section.
Examples of tech debt and its effects
On a general level, debt in product development is when you are postponing solving a problem which results in you paying interest on it going forward. We owe our organization/customers/tech stack (software) work that should have been done. It actually doesn’t have to be tech debt, it can also be design debt as articulated in the article “What is design debt and why you should treat it seriously”.
The effect of accumulating debt is a form of interest we have to pay going forward. It could take the form of:
- Slower development of new features
- Bugs/customer complaints
- Non-compliance with regulations
- Lack of insights on where to put our focus forward
During my time as a startup founder, we created quite some debt in our business. And I’m not talking about monetary debt. Unfortunately, it was not tech debt either but a debt in insights. In the next section, I will share a short version of those mistakes so you don’t have to redo mine.
How the crusade to minimize tech debt killed my startup
We were building a mobile app and community, CrowdStory, where fictional writers published a living story with input from their readers. New chapters came out every week based on voting and discussions with the readers.
Early on we identified that writing a lot of text on your phone is tedious so we created a web interface for the writers to input their text. This web interface was a full-fledged React app with large unit test coverage. Our product should live up to high engineering standards. Something to be proud of. Two man-months were spent on building this web interface.
We launched the service and onboarded users and writers. But the user growth didn’t really take off. And after a while, we decided to pivot away from having a distinction between writers and readers. Everyone should be able to participate in creating the stories if they wanted in a more decentralized manner. For this, we didn’t need the web interface but instead only the mobile app.
If we had found some ways to cut the corners on the web interface and accept tech debt, maybe some bugs also, we could have saved a lot of time and energy. Our most precious resource. Surely our writer would have been ok to use a somewhat buggy application being beta users. We knew them personally and they were a part of our extended team. Or we could have uploaded the chapters manually to the database for them.
When it is the right time to create some leverage with tech debt
Of course, there are examples where we can’t have crashing MVPs. Consider these situations:
- Life-threatening applications, healthcare, self-driving cars
- Monetary transactions
But be aware of the fact that it’s more fun to build things in our safe bubble than getting the ideas shot down by talking to actual customers. Or we might feel ashamed to show them unfinished things. The inclination to keep polishing the product is strong in us.
Let’s take on some debt in the tech stack to create leverage on our ideas!
Build something that doesn’t work perfectly. Launch it, if the users are early adopters they’ll be OK with not having a perfect experience. If they are not we are not bringing something that’s 10x better than current products and we will have trouble competing for their time and money anyway.
If we do it this way we take on some debt that we might be able to write off and not repay at all. It looked like debt at first, as we thought we needed to write all those tests, write that documentation, and so on. But we could discard that feature idea after testing it out in the easiest way possible.
Conclusion
Taking on debt is part of human nature. It is when we get the benefits of a transaction now while postponing the full payment for later.
There is interest connected to debt. This interest can keep accumulating if we are not careful.
When developing digital products we can create debt in our product in the tech stack and design. Even a debt of insights can be accumulated. Be mindful of the type of debt you accumulate.
In projects and businesses with high levels of uncertainty, we should aim to get insights as fast as possible. This could often be achieved by leveraging tech debt.
It might turn out that the debt you accumulated does not need to be paid at all.
