Tech Debt is an Investment, not a burden. AI changes it for Product

Like any investment the earlier you get in the higher your risk and payoff

Product / Growth Managers have to expand their knowledge profiles a lot. One of those is how to manage tech debt. It’s a really sticky situation and far from any fun but if you ignore it you risk your product and team’s influence.

The one thing you can get buried by easily in tech is debt. Tech debt.

The typical cycle of “I’ve been here for 2 years and my backlog is an unmanageable avalanche, I need to quit”

Understanding it as a form of investment can unlock your velocity hard for your product team in the long term. Some key components are changing now due to AI and you should be prepared to deal with them or you get swooped up.

Product Managers are getting buried by tech debt more often than not.

I wrote another article (paid) on the original topic here.

Let’s set the scene. What hasn’t changed in the past months is who your ally is in any organization. It’s still your engineering manager, the VP of Product/Engineering, or the CTO.

What has changed and will accelerate is how your engineers are operating. They become more efficient. And some of our antiquated processes don’t work anymore. More efficiency doesn’t mean necessarily more impact though.

I had a particularly interesting discussion with a PM who told me that their teams seem to use ChatGPT without disclosing it at times in places where they shouldn’t. Responding to tickets and PRDs and while it seems this way it’s getting harder and harder to spot. The problem is not the usage of ChatGPT but those responses just eating up time without producing too much tangible outcomes.

Point estimations are also completely useless now for some types of stories and tickets.

What’s the connection to tech debt?

If we’re thinking about the classical cycle of having a hypothesis, tying this to an OKR or Strategy, and then building features to address those we usually also need to decide on the scope of them.

“How solidly do we build them, and how well is the feature maintainable? How much of an MVP should it be? Do we fix it afterward?”

The number of MVPs

The more MVPs you produce the more tech debt you introduce by definition. And you can do this intently by understanding that some of these MVPs will yield a lot of impact, compensating for the others.

If we assume that your teams will produce more with less this number is starting to steadily increase.

Another compounding factor is that every company now wants to potentially add “AI” to their pricing page so there are a ton of feature requests coming in left and right. The need for cadence has increased dramatically.

The quality of MVPs

But as we said, if tech debt is an investment then it comes at a cost. Every MVP introduces a little bit of interest that you have to pay back. Unfortunately, early anecdotal reports are pointing in a not-so-good direction. While it’s easier to produce something, the quality is not necessarily better.

What we still haven’t solved with AI is the integration of whatever code it finds into an existing codebase. You still need to make it work on a bigger scale and integrate it well. Code doesn’t just work by itself, it’s a part of a bigger codebase no matter how clean it looks from the outside.

This creates an unfortunate effect: the hit rate of your MVPs to generate meaningful impact with your customers is going down. That means you should more often than not not even ship anything simply because the underlying code is not good enough anymore. The other problem is that QA is becoming a nightmare:

QA for MVPs

Ok, we produce more at a worse quality by definition. While QA for code snippets may have arguably become easier - actual QA for interfaces and overall flows has become harder.

I also have never met anyone that particularly enjoys QA duty and oftentimes product teams are structured nowadays in a way that whoever builds something is running it. Meaning that engineers are starting to do more QA work than engineering work.

How that shift turns out we’ll see but if the majority of your day is assigned to architectural firefighting and QA this might not be the job you signed up for originally. A decrease in morale never helped code quality overall.

The big killer for PMs. Validation

Bringing it all together this kills most PMs day to day. On one hand, the market is flooded with competition to no end and is projected to accelerate due to further advancements in AI. So it gets harder to find the right things to build to develop any impact.

An antidote to that is to get a tight grip on validating your outcomes. That takes time, a lot of time. Solid hypothesis, post-experiment analysis. Maybe you freed up some time yourself due to AI by not having to write that many PRDs (I doubt it though) but this is an additional burden.

At the same time, you have much more output to validate.
So what are you supposed to do?

Do less, but better? Or do more and just close your eyes on quality?

The solution is in metrics and the pulse from your engineers. Let’s look at how to leverage this in an OKR and what potential Health Metrics could look like, they will save you.

Have a plan, leverage that debt

Look beyond your short-term planning. If you’re fortunate to work in an A/B testing-driven culture you probably have already a framework to measure success.

What’s often forgotten is a dedicated resource that deals with introduced tech debt.

But just dedicating 20% of your time never works in an industry that struggles with tieing anything to hourly attendance rate.

So what are you left with? Your old companion, outcomes. You definitely can do a rough analysis of how flipping annoying it is for your engineers to deal with certain problems. From the obvious benefits like happier people, you can actually put numbers to this.

If we focus on our outcomes and customer success in the number of tasks they do with our products with can do the same for our engineers.

Don’t start to measure the number of lines they produce, a surprising metric here is the subjective opinion of engineers working with specific systems. Engineers are exceptional at knowing what they actively hate working with.