Â
Â
Not all technical debt is the same.
Knowing and classifying this aspect of technical debt can help product managers and engineering teams better prioritize technical debt, depending on the stage the startup is in.
Pre-PMF startups should not bother with technical debt because the key focus should be to build features that solves the user’s problems and delivers value.
However, some types of technical debt can come in the way of user experience. And by identifying the user impact of technical debt, we can better prioritize solving them:
Direct user impact:
Improving performance and load time
If your website takes a long time to load due to unoptimized code (technical debt), the user will experience slow loading times, causing frustration and possibly leading them to abandon the page. This is a direct impact, as the result of the technical debt is immediately felt by the user.
For example at Hashnode, we ended up prioritizing a feature called Incremental Static Regeneration.
Accessibility
Depending on the type of product, accessibility can also be an important.
SEO was a big part of the Hashnode value-add. And accessibility is a big part of Lighthouse scores. It not only improves the user experience for specially-abled users but also has the added benefit of improving SEO scores and the overall experience for all users
Indirect user impact
Clear up technical debt so coding can happen faster
If technical debt slows down the development process—such as when developers are constantly fixing bugs instead of creating new features—this can cause your product roadmap to stagnate or slow. While users may not see this impact right away, over time they may notice a lack of updates or improvements, which could lead to dissatisfaction and migration to competing products.
Experiments can run faster - feature flags
Let's take a mobile app that uses feature flags to quickly test new features as an example. If technical debt has made the app's codebase messy, implementing these feature flags becomes more time-consuming and complicated. While users may not directly feel this, they may notice a slower rollout of new updates and enhancements. This delayed innovation, a result of the technical debt, could eventually lead to dissatisfaction and decrease user retention.
No user impact
Getting rid of unused code that doesn’t impact load time or performance
Suppose your team has accumulated technical debt in the form of messy or unorganized code. This may not impact your end-users at all, as long as the application is functioning correctly. However, it could significantly hamper your development team's productivity
So, it's clear we should put the user first, rather than getting hung up on less important details like having prettier code.
Final Thoughts
In conclusion, understanding the layers of technical debt and its varying impacts on users gives us a practical, user-centric approach to prioritization. Directly or indirectly, the user experience invariably feels the ripple effects of technical debt.
Even in cases where there is no apparent user impact, it's worth considering the potential downstream consequences. By putting our users first and focusing on their interaction with our product, we can approach technical debt in a way that not only improves our codebase but also drives user satisfaction and product success.
Â
If you liked this post, subscribe to my newsletter:
Â