Your product team has an ambitious plan to build something cool.
Good news: customers are genuinely eager to use this cool thing!
Bad news: building it will require your team to dig into that horrible part of the legacy codebase that was written by contractors many years ago, has no tests that you can trust worth a damn, and is based on a data model that is a malevolent joke against your current reality.
I will make a bold prediction: this specific flavor of technical debt is never going to go out of style.
The inimitable Edmund Jorgensen (who I quote, um, kind of a lot in the book), frames this in a blog post:
"Proposing the rule of the golden cesspool: the closer code is to the heart of a business’s domain, the worse the code will be." (The Golden Cesspool)
In my experience, Edmund is totally right.
Almost all companies seem to have some genuinely hideous mass of code sitting at the beating heart of their business.
Over the years, tons of complex business logic has been shoved into that cesspool.
The most critical processes of the business are tied to data updates in the cesspool.
All sorts of state gets updated in all sorts of deeply non-obvious ways in its murky depths.
Your engineering team likely already thinks about this morass as a prime example of tech debt, and are itching to rewrite it.
They may, in fact, resist an attempt to methodically build visibility and then incrementally improve things.
Instead, they'll make the faux-economic argument that it'd be better to just commit to a ground-up rewrite of that core system.
They'll claim that it will be both faster and cheaper to do so from scratch rather than through a slow, incremental shift.
Once that rewrite is fully finished, the things the product team are asking for will be super easy to build!
What could go wrong?
Please see our later chapter:
The Giant Rewrite: Only Undertake If You Wish To Later Be Fired Midway Through a Long & Painful Death March
(Or see the still-very-relevant blog post I wrote almost 15 years ago: How To Survive a Ground Up Rewrite Without Losing Your Sanity)
Therein you can find some tips on how one can gradually rewrite such systems.
But as a brief teaser: the core trick is to convert this from a technical investment to a product investment.
The product team already thinks there's value here – they just don't realize there's more of a cost than usual.
Making those risks and costs visible and then gradually wearing them down is something you can do with your product counterparts.