Everyone laments technical debt like it were a high-interest credit card. But just like how your CFO uses debt as capital for the business, the intelligent Product Manager knows that technical debt can help finance your path to market if you know how to manage it well.
Product managers who choose when and where it's acceptable to take on technical debt to overcome limited budget, constrained resources or critical deadlines, and budget their resources to resolve that debt at reasonable points in the future, avoid those nightmare scenarios. They recognize that taking on some debt can deliver real benefits so long as it's managed.
Finding the sweet spot between avoiding all technical debt and leveraging the right amount to get to market on a timeline that matters is a key skill for successful product teams.
Don't Build Too Little … or Too Much
Speed to market is a constant driver for product teams, with a high focus on feature delivery that can lead to an anemic architectural ramp. This is the source of technical debt that most teams are used to seeing. All the velocity is on features, and architecture "just happens" (or doesn't). Features are delivered that are not fully fleshed out, and the foundation they are built on won't support the actual feature requirements. While this is fine for an initial feature release to get feedback, repeated iterations result in a brittle product.
While a lot of technical debt comes from investing too little in supporting architecture, we see too many teams swing the other way and build far too much "infrastructure" upfront. Trying to anticipate everything a feature will ever need to do and build out the most beautifully architected backend for high-scale perfection before a single feature ships.
If the team is building too much enabling architecture at the onset, it's setting itself up for technical debt resulting from a change in requirements. Failing to get features out the door, the team doesn't get feedback until a lot of code is built. If you've got it wrong, you end up with a ton of technical debt in the form of an architecture that will never result in value to the customer.
There are, of course, feature sets that require a large amount of enabling technology. Features that have significant, complex components across multiple application tiers often resist iterative, MVP-style implementation. There are times when the MVP requires a lot of backend capability just to get the most basic version of the feature out the door. These are great cases for a buy/partner/open-source approach. Yes, you may accept some technical debt in the form of integration or "someone else's code," but if there is any risk around feature requirements, technical debt will pay dividends in the short term as you validate the feature. Place finite resources, including talent, toward solutions that could be resolved more efficiently by third-party options instead is another way technical debt mounts.
In the simplest term, reasonable technical debt is a trade-off. It's the result of identifying what's acceptable now that's worth addressing later. That's wholly manageable. What's unforeseen or overlooked that demands attention later is technical debt that every product manager wants to avoid.
To solve this and other varieties of technical debt, choose off-the-shelf options, either at the project's beginning or when they're needed. As noted above, embedded analytics allows managers to place solutions right into the development pipeline and move on. Time and talent spent focusing on other areas of the project offset the costs of buying a solution.
Debt Equilibrium
Technical debt is acceptable and even desired in some instances. When creating a genuinely trendsetting product, getting it to market as soon as feasible is the best way to obtain crucial user feedback. Addressing every possible way the new product will be used may be impossible to predict. So, creating an operational framework with simple, adaptable features that can be reliably built out into a compelling business solution for the client is a terrific way to identify and accept technical debt and leverage it for a project's benefit.
Identify technical debt and prepare for it to eliminate unpleasant surprises. Avoid it where possible and accept it where the benefits outweigh its drawbacks.
Manage and pay down debt by planning for it, choosing where and when it serves project purposes. This will ensure team momentum, the efficient delivery of products with state-of-the-art functionality, and expand the number of viable solutions to consider for addressing technical debt on projects in the future.
The Latest
The journey of maturing observability practices for users entails navigating peaks and valleys. Users have clearly witnessed the maturation of their monitoring capabilities, embraced DevOps practices, and adopted cloud and cloud-native technologies. Notwithstanding that, we witness the gradual increase of the Mean Time To Recovery (MTTR) for production issues year over year ...
Optimizing existing use of cloud is the top initiative — for the seventh year in a row, reported by 62% of respondents in the Flexera 2023 State of the Cloud Report ...
Gartner highlighted four trends impacting cloud, data center and edge infrastructure in 2023, as infrastructure and operations teams pivot to support new technologies and ways of working during a year of economic uncertainty ...
Developers need a tool that can be portable and vendor agnostic, given the advent of microservices. It may be clear an issue is occurring; what may not be clear is if it's part of a distributed system or the app itself. Enter OpenTelemetry, commonly referred to as OTel, an open-source framework that provides a standardized way of collecting and exporting telemetry data (logs, metrics, and traces) from cloud-native software ...
As SLOs grow in popularity their usage is becoming more mature. For example, 82% of respondents intend to increase their use of SLOs, and 96% have mapped SLOs directly to their business operations or already have a plan to, according to The State of Service Level Objectives 2023 from Nobl9 ...
Observability has matured beyond its early adopter position and is now foundational for modern enterprises to achieve full visibility into today's complex technology environments, according to The State of Observability 2023, a report released by Splunk in collaboration with Enterprise Strategy Group ...
Before network engineers even begin the automation process, they tend to start with preconceived notions that oftentimes, if acted upon, can hinder the process. To prevent that from happening, it's important to identify and dispel a few common misconceptions currently out there and how networking teams can overcome them. So, let's address the three most common network automation myths ...
Many IT organizations apply AI/ML and AIOps technology across domains, correlating insights from the various layers of IT infrastructure and operations. However, Enterprise Management Associates (EMA) has observed significant interest in applying these AI technologies narrowly to network management, according to a new research report, titled AI-Driven Networks: Leveling Up Network Management with AI/ML and AIOps ...
When it comes to system outages, AIOps solutions with the right foundation can help reduce the blame game so the right teams can spend valuable time restoring the impacted services rather than improving their MTTI score (mean time to innocence). In fact, much of today's innovation around ChatGPT-style algorithms can be used to significantly improve the triage process and user experience ...
Gartner identified the top 10 data and analytics (D&A) trends for 2023 that can guide D&A leaders to create new sources of value by anticipating change and transforming extreme uncertainty into new business opportunities ...