Product Debt: The Hidden Drag on Innovation
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub dive into the concept of product debt: what it is, how it differs from technical debt, and why it matters.
They unpack how hidden or forgotten product features can quietly slow down innovation, complicate modernization efforts, and create pitfalls when deciding whether to refactor or rewrite. With real-world stories, from duplicate onboarding flows to forgotten VIP requirements, they illustrate how product debt can entangle engineering teams and impact business decisions.
Along the way, Scott and Brad explore:
- The fine line between product debt and technical debt
- Why modernization efforts often uncover forgotten landmines
- The risks of rewriting from scratch versus stepwise refactoring
- How product and engineering leaders can spot and address product debt
- Why acknowledging product requirements (even undocumented ones) is essential
Whether you're a CTO, product leader, or engineer, this conversation offers practical insights into managing complexity, making smarter trade-offs, and leading modernization initiatives with eyes wide open.
- 00:00 Introduction and Host Welcome
- 01:18 Defining Product Debt
- 04:25 Examples of Product Debt
- 05:51 Technical Debt vs. Product Debt
- 10:20 Challenges in Modernization
- 18:07 Avoiding Future Issues
- 18:34 Challenges of Stepwise Refactoring
- 19:02 The Hubris of Rewriting
- 20:24 Undocumented Requirements
- 21:42 Real-World Examples of Refactoring
- 24:16 The Complexity of Tech Debt
- 26:17 Rewriting vs. Refactoring Debate
- 32:39 Empowering Conversations with Product Debt
- 33:28 Closing Remarks and Call to Action
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCtos #Podcast #Ctos #CtoPodcast #Technology #Engineering #SoftwareDevelopment #TechLeadership #EngineeringLeadership #ProductDebt #TechnicalDebt #InnovationChallenges #RefactorOrRewrite #ProductManagement
Brad: Ultimately, when we refactor the opacity of undocumented requirements,
they are opaque to us and we can look at the code to try to understand those requirements.
But if we don't actually have the enumeration of the requirements,
the code is cryptic and we don't know why the code was written that way.
Scott: everybody to this week's friendly happy episode of how many CTOs does it take?
I am your host or co-host Scott Porad and my trustee host and or co-host is and
Brad: Brad Hefta-Gaub.
Scott: this week we have got an interesting topic.
Well we always have interesting topics to us because we're nerds about this stuff.
Brad: That's true.
Scott: But the topic that has come up,
Brad said something to me recently, and I didn't quite know what he meant.
And I said, Brad, I want to talk about that on the pod.
He said, and I might be paraphrasing you wrong, so I'm just going to say the sentence,
then you just run with it.
Scott,
you have to acknowledge product debt.
Product debt is real.
And I was like, we got to talk about that,
Brad.
What is product debt?
Brad: Cool. Well,
I think of product debt as it's the type of thing that it really informs technical debt and it's part of kind of the debt that an ongoing enterprise has been around for a while that's got some piece of their business is built and is doing something. There's this type of debt that you have all of these known or unknown or long since forgotten.
features and requirements that exist in your product that also slow you down in maintaining and innovating. So I think of technical debt as
You know, the the code itself is written in such a way that it is hard to maintain.
But that's different from product debt where you may have features like a really good example of this is you might have features that are contrary or contradictory to each other,
like two features that basically are at odds with each other and they exist in your product and they're in there.
And you've built around those features,
you know, you've kind of added all the different special cases.
And it's not that the code is necessarily complex, although the code can often be complex to deal with this, but it's the very nature of the existence of the feature or the features that makes the debt,
not the code, but the features. And that's what I mean by product debt.
Scott: it's like the cost it's not quite what i'm going to say it's not quite dead but it's the cost of ownership right it's almost like yeah
Brad: Yeah, and we had that great early episode where we talked to John Helm about,
like, is it debt or is it calls of, you know,
Scott: yeah
Brad: and stuff like that. So I don't necessarily want to get into the big debate about whether it's debt or cost of ownership and whether the word's the right word. But the thing...
Scott: I think it comes conceptually.
Brad: Yeah, conceptually, I think we're all used to the idea of tech debt and we generally think of that as, you know, kind of the existing code that we have that makes new code hard to add or.
bugs in the existing code hard to fix those are the things that we talk as technical debt and i i just want i just think it's important for us to be realistic about the fact that sometimes it's actually the
product requirements that the customers or the business have,
the expectations around those product requirements,
that is actually the source of this drag or this debt or this, you know, inertia that gets in our way when we try to optimize, improve,
innovate,
whatever.
Scott: Yeah, like let me give you an example.
Um,
we have a partner,
TaskRabbit, I work at a company called TaskRabbit, we have a partner that's a special partner,
and we have made a custom landing page and workflow for them.
Brad: Yep.
Scott: And so if we want to update something about our booking experience on TaskRabbit, we have to update it in two places.
Brad: Yep.
Scott: And eliminating that second flow is not technically possible,
but from a business product perspective,
it's not possible because we have an arrangement with this partner to,
as part of doing business with them,
we have to offer them something tailored for them.
Brad: That is a great example of product debt.
And product debt like that can also come along with it can kind of drag in technical debt.
Right.
So, for example, in this particular case, you're like.
Yeah,
the way we implemented it is we have two slightly different onboarding flows,
one for the one for the product ask and one for the kind of the normal front door.
Scott: Right.
Brad: And the way we manage that is we have two different flows that we have to keep updating whenever we make changes. Right.
And so that's that's a piece of product debt that also kind of resulted in technical debt.
Scott: Well, let's explore that for a second.
If it is, let's just imagine that both of these flows have a date picker on them.
Brad: Mm-hmm.
Scott: And if they share a component for the date picker, then,
well,
phrase it the other way around.
If they each have their own date picker components,
now we've sort of got some tech debt.
If they've got one date picker between the two,
then...
You know, you want to update the date picker because of, you know, whatever reason you get it in both places.
Brad: Yeah, and that's a great example where a technical choice to implement this piece of product requirement could be done in a.
a less technical debt way or a more technical debt way,
but regardless of the implementation, you still have this product debt where you have to always think about those two front doors.
Scott: Yeah, that's right.
And then there's another piece of this, right? Sometimes what we say is
Okay, we've already got a landing page and we got this one special customer,
they're writing us big checks and they want a custom landing page.
So sometimes we say, okay,
we're going to make them a custom landing page and we have product dev.
And sometimes we say,
okay, we're going to make our one landing page kind of do double duty,
right?
Somehow, something
Brad: that some templatization or like there's like a there's like a config file that makes it look slightly different when it comes in through this other domain or something like that yeah
Scott: like that, which maybe that's a technique that maybe you still have your product debt because you still have both versions of it.
You've maybe minimized some of your tech debt because it makes it easier to share.
between them but you've introduced something new which is complexity now i've got these flow which maybe it has if else statements in it right um or or it has the configuration file you mentioned which has to be managed and you gotta have a configuration file system kind of whole situation and
Brad: Yeah,
and I think this is a good example where it's like.
Where did the complexity come from? Did it come from engineering decisions that were orthogonal to product requirements?
Or did the challenge first get introduced at the moment of the product requirements,
right?
And this dual landing page is a great example where...
If there hadn't been, let's do a slightly different variation of this. Let's just say, oh,
we're going to have a landing page.
And product has not come and said, hey, you've got to have two landing pages.
We've got VIP customers.
They're going to want customized landing pages and everyone else is going to get the standard one.
Like nobody in product ever asked for that feature.
Scott: Mm
Brad: But
Scott: -hmm.
Brad: the engineering team was like,
oh,
I can imagine a day when they might ask us to have special VIP landing pages. So when I first do my design statement,
I'm describing it in these with this this.
a configuration template and you built out this configuration template but you only ever have one template right and that in my judgment would be a great example of pure tech debt you created complexity for a feature you were not asked to build
And it makes it every time you go in there, instead of just simply changing the HTML to have a new button that says sign in instead of log in,
you've got to go into this configuration system and double check that it's not in the JSON for the config file and it's not, you know, whatever,
right?
Check that,
Scott: JSON.
Brad: not product that.
Scott: No, no, no. This config file is going to be in a list.
Brad: Yeah, the config.
To think about it is, I love it.
Scott: So I want to go back to the previous example, though,
where as engineers, we do have requirement for two different pages.
We put them in one with the configuration so we create complexity.
I don't consider that complexity tech debt.
Brad: That is, Not
Scott: so not all complexity is tech debt is what I would say.
I
Brad: it's
Scott: would say a
Brad: serving
Scott: lot of tech debt is
Brad: a
Scott: purpose. excess complexity.
Brad: Yeah, but if it's again,
and that's why I'd go this is a distinction between tech debt and product that that
Scott: Okay,
Brad: complexity
Scott: so,
Brad: was
Scott: yeah,
Brad: required by product.
Scott: yeah.
Okay,
so let me...
expand this a little bit this originally came up because we were having a conversation about the proverbial problem a system that has a lot of debt in it whether it's product or tech it just has a lot of debt in it and the proverbial
Do we rewrite it from scratch or do we refactor it, right?
Brad: Modernize it somehow
Scott: Modernize it, yeah, modernize it somehow.
And you had made this comment.
This is when you made, in that conversation is when you made the product data is real comment.
And so why in that conversation,
how does it relate to that conversation?
Brad: Okay, because one, okay, great.
I'm so glad you asked this.
So one of the things that I consistently see in my, I've seen this over and over and over again in my career is when the team starts to do the modernization effort.
And maybe they're going to rewrite it from scratch. Maybe they're going to like take it piece by piece and just kind of componentize it, whatever it is. But this is going to happen with this modernization effort,
right?
Inevitably, there are requirements. I'll call them features. There's features that imply requirements that nobody remembers.
and aren't written down anywhere accessible and are effectively they're required like if you fail to do them correctly in your modernization effort someone is going to notice them but
Scott: Mm-hmm.
Brad: nobody in the modernization project or even any of the immediate stakeholders of the modernization project remember
That requirement and remember to say,
hey,
while you're doing the modernization,
make sure you don't forget about buried old feature X,
Y, Z that no one remembers because we wrote it five years ago,
but turns out is being used on the regular.
by real customers, but everyone has forgot about it.
Scott: Mm hmm.
Brad: That's a category of product debt.
Scott: Interesting.
Brad: And in my experience,
it is the number one worst landmine that is sitting there waiting for you to accidentally step on it when you do your modernization effort.
Scott: Well,
that's interesting.
To me, that landmine is more of a rewrite landmine than a modernization landmine because the rewrite landmine is.
we'll just go back to the landing page example hey i've got these landing pages they're riddled with debt product debt or tech
Brad: They're
Scott: debt whatever
Brad: in a that we're using a what is it we're using like PHP for it
Scott: doesn't matter they're just they're they're just scrambled and uh and um they're bankrupt right or their or their debt is so high that they're consuming all their whatever it doesn't matter so uh
So you got to rewrite it and
Brad: And no one remembers
Scott: you got,
Brad: the VIP landing page.
Scott: right,
because you just don't even know, or more to the case more,
and I would say is there are so many requirements in there that it's actually just, I don't want to say impossible,
it's approaching impossible,
but it's closer to impractical to
capture them all so that you can put them in the spec for the new thing you're writing like
Brad: Yep.
Scott: oh it's they're just too small like the vip thing that could be pretty big but it could just be like one little one
Brad: Yep.
Scott: little wrinkle that's in there right and it might not be a special case it might just might be like um
Well, an example that came up today and something I was doing was just like we were talking about,
well,
it's hard to explain the example without going into a huge story, so I'm going to skip it. But to me, those landmines are more on the rewrite side because you just forget about them.
versus the modern the refactor side it's like it's a different kind of landmine that landmine is like well this is here but does anybody know why it's here and then you get into the chesterson's fence problem you know chesterson's fence if
Brad: No.
Scott: you come across a fence and you don't think you need to have that fence there before you take down that fence find out why somebody put it up because they put it up for a reason you
And so you run into the Chesterton's fence problem,
which is very expensive in terms of time to kind of run around your company trying to say, does anybody know why?
This VIP thing is here and nobody knows nobody knows nobody knows maybe some engineers go and look at some logs and nobody can figure it out and then you finally delete it and well either you re-implement it and you didn't need it so it was cost or you delete it and you broke something that was important and somebody's like whoa our VIP thing stopped working yesterday so but at least you know about it.
Brad: Yeah, but this is where I'll give you. So you started to ask the question,
hey Brad,
is this like
It's like unknown feature product thing.
Okay,
you're basically like, yeah, Brad,
I agree with you. There's these features that have long since been forgotten about and those are sitting around waiting as landmines. So I hear you saying,
yes, you agree that exists in almost every code
Scott: 100%.
Brad: base.
And you're saying like,
hey,
but if we don't fall for the trap of rewriting it,
can we safely avoid those landmines? And my response to you is.
not likely and
Scott: Oh,
Brad: the
Scott: really?
Brad: reason and the reason is is and we'll use your two uh landing pages your two login pages as an example right so in this case like that vip landing page we've all forgotten about that one it's still being used but no one remembers that it's being used you know and um
you know it's in some dashboard somewhere but it's like you know blips once a week or something like that so no one ever notices it because it's like its scale is so small right um and you're not going to rewrite everything but you're refactoring and the thing that you're refactoring is the auth service and while refactoring the auth service somebody notices that there's this like refer header in the in the um you know in the in the html metadata
or in the in the http metadata and people are like why wait a second why are we plumbing this refer header all the way through like six layers of our microservices like we don't use that we only have one this is dumb why do and so then in the refactor we get rid of the refer you
Scott: Yes.
Brad: know http metadata
And that's when that's when the VIP page breaks and no one and everyone's like, what?
And and worse,
it's a low enough, rare enough use feature that the time delay between when we made the refactor to have the breaking change that we didn't know about.
And the time and the time and the time that we trip over the breaking change is enough time and enough releases went by between those two events that now we're like, what?
We didn't change anything about that.
Scott: Yeah, I guess I disagree with you weekly.
Brad: Okay.
Scott: And what I mean by that is in the case of the refer header or whatever it was that's there,
at least an engineer saw it and thought about it, and maybe they made the wrong decision,
right?
Versus the case of the, that's on the refactor side.
On the rewrite side,
you just, you just, you don't even know, you're oblivious. You didn't even know.
that that header existed so you didn't even know to put it back in and I just feel like the problem of making the wrong decision because you didn't have all the information is at least like if I think about a retrospective it's something I can manage I can we can say oh
what could we do to avoid this in the future oh when you come across a header that you don't know what it does maybe let's go look at the i don't know edge load balancer logs or something and see if it's coming through there to see if it's meaningful or something i don't know there's whereas the case where it's like we went about building a whole new landing page thing and nobody knew about this and
Brad: I just think that like,
yeah,
I agree with you. Like it's a slightly easier to catch it.
it but it's not easy to catch it No. it's not because remember here's the here's the here's the thing we have to remember a stepwise refactoring is actually just a bunch of small rewrites so you're still rewriting it
And the thing you're rewriting has a bunch of requirements that may not be obvious to you.
Scott: Okay,
I know why I have a visceral reaction about this, not a strong one, a weak one, like I said.
Here's what I think it is.
Let's say that you and I were engineers with hubris.
And we say, oh,
we can go rewrite this landing page.
It'll take us very little time and it'll be so much better than the last one.
And we probably do a cursory review.
of what features and functionalities are in the landing page before we go about building our new one and we we likely don't go through the code every bit of the code and look at every little detail that's in there we probably click through the landing pages a bunch we might even not do that at all we might even have the designer say hey we're going to build new landing pages just make us a new landing page right um and we might not even look at the old stuff whereas
With the code situation,
I'm sorry, with the refactor situation,
at least the thing, the code,
the header,
it's right there in front of your eyes.
I'm not saying it's easy to make the right call,
but at least you've got to.
Brad: chance?
Whereas the hubris of starting from scratch is you're actually putting yourself in a position of, unless you're super diligent about going and reviewing every line of the existing system,
you're just setting yourself up to make the mistake.
Scott: OK, well,
so I agree with that.
I'm not you're not going to get an argument with from me on that point.
I agree with that point that you're making.
I'm saying.
I'm going to say one I'm going to take one more swipe at this this this point that I'm trying to make is that ultimately when we refactor the opacity of undocumented requirements.
ancient old undocumented requirements they are opaque to us and we can look at the code to try to understand those requirements but
Brad: Yes.
Scott: if we don't actually have the enumeration of the requirements the code is cryptic and we don't know why the code was written that way
Brad: 100% agree.
I can't tell you how many times in my career I've sat and looked at some code and I have said to myself,
I can read this, understand what this is doing,
but I don't understand why.
Scott: Yeah.
Brad: Why
Scott: Why was
Brad: did someone
Scott: it written this way?
Brad: put this here?
Scott: Yeah.
Brad: Why are we checking to see if the customer is in West Virginia?
I don't get it.
Scott: Right.
Brad: And I find out, oh,
well,
it turns out there's a law in West Virginia that says blah,
Scott: You can't sell llamas.
Brad: blah, blah, blah, blah.
Scott: Can't sell
Brad: Seven
Scott: llamas.
Brad: years ago, the lawyers,
yeah,
seven years ago, the lawyers said you can't sell llamas in West Virginia, right, whatever.
But, you know, and hopefully the person did it clearly and it makes sense, but often they don't.
Okay.
You mentioned the author example.
Scott: Hmm.
Brad: I've lived through that before.
Scott: Yeah.
Yeah,
Brad: Let's
Scott: all of
Brad: see here.
Scott: us have.
Brad: Winter of 2022,
matter of fact.
We're replacing homegrown off system,
hooray, with off zero,
a reputable vendor.
And, you know, like all engineers who have hubris, we thought this will just take us two weeks.
and we only had to roll that thing back about seven times back I remember a document I got from one of our I don't know if it's title but it was like a principal type of engineer and the title of the document there was an app let's just call it Apex and he said the title of the document was how the F does Apex even work
And you crack this thing open,
we've been rolling this thing out and rolling it back with this thing because we've been missing use cases or whatever.
And this is this exploration of how authentication works for this one application,
this one like, you know, admin tool that's on the side.
And he's just like, I don't get it. I don't understand how I'm
Scott: I would have to rebuild it all.
It's like.
Brad: How does authentication work for this system?
period i don't i'm like looking at this code i'm looking at like this is where it's looking up its users this is the stuff blah blah well it turns out i mean this is a gem of some bad design uh this was like a separate application and instead of like either
And using something to like authenticate against like the main system or making its own little authentication thing,
what it did is what kind of made its own little authentication thing.
But then there wasn't I'm not making this up. I swear to God, I don't know if I should say this out loud,
actually.
It's so it's so bad, but I didn't do it. I just found it.
There was an ETL job that copied the usernames and passwords from one database to another.
And so this guy's like,
I don't get it.
get it how how does this work like i changed my like i don't he didn't know about the etl job right and
Scott: How frequently
Brad: and probably
Scott: is this ETL job running?
Like on a minute?
Brad: I don't know no this was like an admin tool so probably only ran like once a night or something like that but the point was like we was trying to make this thing work with this third party thing off zero and like the way we thought it should work just wasn't working and it turns out whatever you get the story so that was
Scott: So
Brad: a that
Scott: there you go.
Brad: was a
Scott: That's
Brad: fun one
Scott: you.
You just proved my point.
That was a refactor that had some weird product debt in it that you later
Brad: Oh,
Scott: like
Brad: no,
no, no.
That was I do not put that one on product.
Scott: Okay
Brad: In fact, I don't even know if we can call that tech debt.
I mean, we can call it tech debt, but it's got to have a special name of tech debt.
There's there's.
A type
Scott: Munchausen
Brad: of tech debt.
Scott: by proxy tech debt.
Brad: I don't know what that means.
What does that mean?
Scott: Oh, that's a mental
Brad: Is that the thing?
Scott: disorder where you make your child sick so that you somehow feel better as the savior or something.
Brad: Here's what I'm getting at.
There's tech debt that comes from we've introduced it of years of adding product complexity.
There's tech, you know, essentially the needs of the business have changed, but the product hasn't evolved enough.
There's tech debt,
which is systems are outdated.
We're using old versions of stuff,
things like that.
And there's probably other types of tech debt. I'm sure there's a million of them.
But here's a special one. And I think it deserves a better name than tech debt.
And maybe we can come up with that name.
Well, there's tech debt when somebody makes a poor design decision and in retrospect,
you look back and you say, that's not very flexible or scalable. We could have done that better.
And then there's tech debt and this deserves a special name.
When somebody makes a design decision that is so bad,
like I'm going to set up and I don't have the time to actually figure out how to share the authentication system. So I'm going to set up an ETL job to copy usernames and passwords. Such a.
a egregiously what's
Scott: Design.
Brad: you know the word delinquent is coming to my mind but it's worse than delinquent negligent negligent technical design what what is the word for that kind of tech that we need a better word
Because sometimes we mix those up together and it's unfair when the product has just changed and the system is rigid because the requirements have changed. It's unfair to put that in the same bucket as someone made such a terrible decision here.
I
Scott: OK,
Brad: feel like
Scott: well,
Brad: we fair have to come up with new names.
Scott: enough.
I'm going to pivot us back to this question of product debt for a second. And
Brad: Do it.
Scott: I want to pivot to this question that you basically are saying is like,
hey,
rewriting the system is is.
is never the right answer because you'll get you'll definitely like get bit by this product debt higher
Brad: I'm not going to say never the right answer.
It's just higher risk.
Scott: risk okay let me look at let's look at the other side of that coin
Brad: Yeah.
Scott: Okay, the other side of the let's rewrite it coin.
One of the things that you can do what you certainly would need to do if you're going to rewrite it is you would need to say, what do we want this thing to do?
What are the requirements of the rewritten thing?
That's an opportunity to eliminate product features you no longer need.
Brad: Yes.
Let me tell you my two just instinct,
like very quick, the things that came right to my mind
Scott: Your
Brad: in response
Scott: first reaction
Brad: to that.
Scott: to that.
Brad: My blink reactions.
The first was,
yeah, but will the requirement writers remember important requirements that are hidden,
like the VIP landing page?
The other thing that came to my mind is a category of existing feature.
a requirement that is on the bubble like let's just use this via i'll actually give you a real one from task rabbit we had one of those things a lot of websites have them you know refer a friend and get a credit or something like that right and recently it needed some update
hey i don't know why there's a bug or something and there wasn't a bug there was some update and someone asked a product manager do we need this thing like it's sitting here in a corner does anybody really use this and that person went around and spent some time and it probably took a month of time not full time but like the whole duration of like well i'll go check and i got to ask all these people and yes it gets used but let's do some analysis to see if it gets used whether it's worth it
worth it to fix it and actually in something very positive that came back and the answer was yeah we're going to get rid of this we don't think it's worth updating we can just scrap it that took time but a lot of those so not only do all those take time less times they don't come back clear they're fuzzy it's like well i mean you know a fair amount of customers use this every month and
It might not be worth rewriting it, but it'd be really unfortunate if those customers lost out on that whatever capability that they had.
And so then that's an expensive process, going through all that rationalization.
So those are the two things that came to those are the two things to my mind
Scott: Yeah, I think those are both valid things.
And this is where you kind of got to challenge the question.
This is, by the way, this is the reason that like upstarts have an advantage over incumbents.
They're not saddled by that.
So, you know, one.
One strategy that if you have the environment and the wherewithal to do this, one strategy is be your own disruptor.
Brad: Yeah, I've thought of that a lot.
And it's very alluring.
But for these reasons we've talked about,
it's also risky.
Yeah, I mean, actually, the words that were coming to my mind were intimidating and scary.
Um,
especially if you, if you have an, it's fundamentally the innovator's dilemma,
which is,
Hey, we've got a good thing going and we want it to go better.
That's why we want to improve the platform.
And this actually could potentially make it go a lot worse.
Scott: isn't that didn't kevin goldsmith give us that one of those stories from his time at spotify where basically they did the big
Brad: Yes.
Scott: launch and it was like they didn't follow their normal practices of kind of testing small and stuff like that and then basically did this big launch and the thing that was supposed to increase usage and traffic actually like tanked usage and traffic and they were just like wow
Brad: Yeah.
And so as an engineering leader.
I mean, I guess I'll just be honest.
I guess I don't have the cojones to recommend that because I'm afraid of cratering the business.
Scott: And I would say this is never a call that would be made just by an engineering team. You've got to have the product team,
the business team has got to be like,
yes, this is something that we recognize,
understand and agree,
you know.
And I there's plenty of times I've worked with product teams where the product team themselves identified the product that they were just like, you know, and it could be a little bit of like, you know, throwing the old product team under the bus, you know, when a new regime has come in or something like that. And so it's like we're the new product team and we're going to like we don't care about the features from the old product team. Right.
Brad: Yeah, I've found myself in this situation more than once where the business side of the house really wants me to start over from scratch.
And I've been the one who said, no,
to use your language of product that which I didn't quite have before.
Now, you guys don't understand the product that like it's.
That's why I would call it a fool's errand.
And I think it's because I would have haven't had the words before. It's like you're not really thinking through the level of the volume of requirements that are in here and the cost.
Scott: Revitalizing.
Brad: of thinking of either rebuilding them or rationalizing them it sounds it sounds really easy to sit in the conference room and say we're going to start from scratch and in a year we're going to rebuild the whole thing but this thing has gotten here organically over many many years of experimentation and evolution and um and some of it's good and some of it's bad but it
It is truly the innovator's dilemma.
Scott: Well, there you go.
Brad: There
Scott: So you
Brad: you go.
Scott: and I were talking about rebuild versus refactor, and
Brad: Yeah.
Scott: I threw product debt at you.
And now after 30 minutes of talking about this,
do you feel empowered to use the term product debt in an upcoming conversation?
Brad: I absolutely do because we're having some conversations.
is at our company about investing more in improving our platform and we have things on the list of things where we might invest is like
modernize the front-end framework to Next.js and improve we have we have two mobile apps but they're different architectures and different everything in them is different and the product features are different too but like hey let's consolidate those so maybe there's still two apps but at least let's get some more sharing going on in there right we're having talking about decomposing our back-end monolith into some pieces and this gives me some language to say hey you know what we need to put on that list
Let's see if there's any product debt we can get rid of.
Scott: Yeah, I love it.
That's a great, great way to use that term.
I love
Brad: Thank
Scott: it.
Brad: you. Thank you. This has been a fun conversation today.
Scott: Awesome.
It's good chatting with you, Scott.
Brad: All right, everybody.
If you're listening,
don't forget to smash that subscribe button to leave us a five-star review.
Scott: Yeah.
Brad: and to tell all your friends about it.
We have just crossed the 1 million listener mark, and the only thing between us and being the biggest podcast in the world is Joe Rogan, and the only thing that's going to get us there is more of your support.
So
Scott: This,
Brad: thank you very this much.
Scott: facts may or may not be fake news.
Brad: All right. Thanks, everybody.
Scott: Thanks, everybody.
Brad: Bye.
Scott: This episode of How Many CTOs Does It Take Podcast was edited by Safran Hepagel.
Our theme song was AI Generated by Brad.
Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon,
or at our website at HowManyCTOsPod.com.
And remember to rate, review,
and subscribe on the podcast platform of your choice.
Thanks for listening.