Why You Should Advertise Your "Tech Debt"
Why You Should Advertise Your "Tech Debt"
How to Rethink "Tech Debt" in Terms of Customer Value
Introduction
You don't need to sacrifice features for the sake of "Tech Debt". One of your primary roles as a product manager is to be an interpreter. You are the “seer stone” that translates technology outcomes into business outcomes and customer value. “Tech debt” is a prime example of this. I love this topic of “tech debt” because it is often controversial, but it doesn’t have to be.
What is it?
Engineering teams use this term liberally to describe an area of the code, architecture, or process where a shortcut was taken, has reached critical mass, and needs to be remediated. Why? “Tech debt” is typically incurred because speed and time to market outweigh perfection. You can optimize software performance and implement best practices at a later stage. The rationale is sound; you need customer feedback to iterate on and you don’t need to solve problems you don’t have yet.
“Tech Debt” vs. Features
There is no need to put “tech debt” at odds with “features”. Tech debt is a sign of maturity. The beauty of software is that it is malleable, we don’t have the same luxury when building hardware products. You can release software that you’re not entirely proud of and will not solve all of the current or future problems your user base faces, but it will solve at least one problem. The heart of building great software is the team’s ability to experiment, test, release, and iterate in short, rapid cycles. Don’t waste cycles contemplating the universe and what potential problems customers may or may not have. Form a hypothesis using the data you have, place a bet on solving that problem, build it, release it, get feedback, and iterate. This is how you optimize software for customers (the demand side) not only your business (the supply side) and avoid analysis paralysis.
Where does it come from?
This software delivery model inherently introduces “tech debt” that may or may not need to be addressed in future releases based on customer feedback, that’s the beauty of it. Rather than viewing “tech debt” as a drag on the team, view it as an opportunity to positively impact the scalability of your business and customer experiences. It is an anti-pattern to try and solve all the problems and potential future problems your customers have in a single release. As risky as it seems, we know the best way to build software that customers love is to “move fast and break things”, “big bang” releases are riskier and more error-prone. Smaller, more frequent releases deliver faster and more manageable chunks of feedback that can be introduced into future releases faster. You’re not going to know how to future-proof your software when you build it, so “tech debt” just becomes an inherent component of building software to account for. And rather than framing it as “tech debt”, frame it as improving the overall quality, scalability, security, sustainability, and maintainability of the software you’re shipping.
What to do about it?
Reframe “tech debt” in your backlog in terms of customer value. Shipping features and addressing “tech debt” is a common tension point between product and engineering cohorts, but it doesn’t need to be. Items labeled as “tech debt” should be framed in terms of customer value (e.g. scalability). For example:
Engineering Terms: Engineering brings up a “tech debt” scenario of refactoring all of the config data and config processes.
Product Terms: Frame this to customers in terms of value, e.g. “We can now deploy regions x times faster, with y% fewer errors leading to an increase in z% uptime and security for customers”.
Additionally, consider these guidelines:
When shipping products, communicate tech debt in a manner that demonstrates customer value.
Involve product managers in prioritizing “tech debt” alongside features.
Avoid siloing “Features” as the PM’s job and “tech debt” as engineering’s job
My Ask
Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!
Like this article by using the ♥︎ button at the top or bottom of this page.
Share this article with others.
Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it