Transcript: Product Debt: The Hidden Drag on Innovation
0:00 Brad Ultimately, when we refactor the opacity of undocumented requirements,
0:06 Brad they are opaque to us and we can look at the code to try to understand those requirements.
0:12 Brad But if we don't actually have the enumeration of the requirements,
0:16 Brad the code is cryptic and we don't know why the code was written that way.
0:37 Scott everybody to this week's friendly happy episode of how many CTOs does it take?
0:43 Scott I am your host or co-host Scott Porad and my trustee host and or co-host is and
0:51 Brad Brad Hefta-Gaub.
0:53 Scott this week we have got an interesting topic.
0:56 Scott Well we always have interesting topics to us because we're nerds about this stuff.
1:00 Brad That's true.
1:01 Scott But the topic that has come up,
1:03 Scott Brad said something to me recently, and I didn't quite know what he meant.
1:08 Scott And I said, Brad, I want to talk about that on the pod.
1:11 Scott He said, and I might be paraphrasing you wrong, so I'm just going to say the sentence,
1:15 Scott then you just run with it.
1:17 Scott Scott,
1:18 Scott you have to acknowledge product debt.
1:19 Scott Product debt is real.
1:21 Scott And I was like, we got to talk about that,
1:24 Scott Brad.
1:25 Scott What is product debt?
1:26 Brad Cool. Well,
1:27 Brad 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.
1:52 Brad features and requirements that exist in your product that also slow you down in maintaining and innovating. So I think of technical debt as
2:12 Brad You know, the the code itself is written in such a way that it is hard to maintain.
2:19 Brad 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,
2:32 Brad like two features that basically are at odds with each other and they exist in your product and they're in there.
2:39 Brad And you've built around those features,
2:41 Brad you know, you've kind of added all the different special cases.
2:44 Brad 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,
2:57 Brad not the code, but the features. And that's what I mean by product debt.
3:02 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
3:10 Brad Yeah, and we had that great early episode where we talked to John Helm about,
3:16 Brad like, is it debt or is it calls of, you know,
3:19 Scott yeah
3:19 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...
3:28 Scott I think it comes conceptually.
3:29 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.
3:46 Brad 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
4:02 Brad product requirements that the customers or the business have,
4:08 Brad the expectations around those product requirements,
4:10 Brad 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,
4:23 Brad innovate,
4:24 Brad whatever.
4:25 Scott Yeah, like let me give you an example.
4:28 Scott Um,
4:28 Scott we have a partner,
4:31 Scott TaskRabbit, I work at a company called TaskRabbit, we have a partner that's a special partner,
4:35 Scott and we have made a custom landing page and workflow for them.
4:41 Brad Yep.
4:42 Scott And so if we want to update something about our booking experience on TaskRabbit, we have to update it in two places.
4:52 Brad Yep.
4:53 Scott And eliminating that second flow is not technically possible,
5:00 Scott but from a business product perspective,
5:02 Scott it's not possible because we have an arrangement with this partner to,
5:06 Scott as part of doing business with them,
5:09 Scott we have to offer them something tailored for them.
5:11 Brad That is a great example of product debt.
5:14 Brad And product debt like that can also come along with it can kind of drag in technical debt.
5:22 Brad Right.
5:22 Brad So, for example, in this particular case, you're like.
5:27 Brad Yeah,
5:27 Brad the way we implemented it is we have two slightly different onboarding flows,
5:30 Brad one for the one for the product ask and one for the kind of the normal front door.
5:35 Scott Right.
5:35 Brad And the way we manage that is we have two different flows that we have to keep updating whenever we make changes. Right.
5:42 Brad And so that's that's a piece of product debt that also kind of resulted in technical debt.
5:50 Scott Well, let's explore that for a second.
5:54 Scott If it is, let's just imagine that both of these flows have a date picker on them.
5:59 Brad Mm-hmm.
6:00 Scott And if they share a component for the date picker, then,
6:04 Scott well,
6:05 Scott phrase it the other way around.
6:06 Scott If they each have their own date picker components,
6:09 Scott now we've sort of got some tech debt.
6:11 Scott If they've got one date picker between the two,
6:14 Scott then...
6:16 Scott You know, you want to update the date picker because of, you know, whatever reason you get it in both places.
6:21 Brad Yeah, and that's a great example where a technical choice to implement this piece of product requirement could be done in a.
6:31 Brad a less technical debt way or a more technical debt way,
6:34 Brad but regardless of the implementation, you still have this product debt where you have to always think about those two front doors.
6:43 Scott Yeah, that's right.
6:45 Scott And then there's another piece of this, right? Sometimes what we say is
6:50 Scott Okay, we've already got a landing page and we got this one special customer,
6:54 Scott they're writing us big checks and they want a custom landing page.
6:57 Scott So sometimes we say, okay,
6:59 Scott we're going to make them a custom landing page and we have product dev.
7:02 Scott And sometimes we say,
7:03 Scott okay, we're going to make our one landing page kind of do double duty,
7:06 Scott right?
7:08 Scott Somehow, something
7:09 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
7:20 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.
7:28 Scott You've maybe minimized some of your tech debt because it makes it easier to share.
7:36 Scott 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
7:55 Brad Yeah,
7:56 Brad and I think this is a good example where it's like.
7:59 Brad Where did the complexity come from? Did it come from engineering decisions that were orthogonal to product requirements?
8:11 Brad Or did the challenge first get introduced at the moment of the product requirements,
8:16 Brad right?
8:18 Brad And this dual landing page is a great example where...
8:24 Brad If there hadn't been, let's do a slightly different variation of this. Let's just say, oh,
8:29 Brad we're going to have a landing page.
8:32 Brad And product has not come and said, hey, you've got to have two landing pages.
8:36 Brad We've got VIP customers.
8:37 Brad They're going to want customized landing pages and everyone else is going to get the standard one.
8:41 Brad Like nobody in product ever asked for that feature.
8:43 Scott Mm
8:43 Brad But
8:44 Scott -hmm.
8:44 Brad the engineering team was like,
8:45 Brad oh,
8:46 Brad I can imagine a day when they might ask us to have special VIP landing pages. So when I first do my design statement,
8:54 Brad I'm describing it in these with this this.
8:57 Brad 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
9:16 Brad 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,
9:25 Brad 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,
9:34 Brad right?
9:35 Brad Check that,
9:35 Scott JSON.
9:35 Brad not product that.
9:37 Scott No, no, no. This config file is going to be in a list.
9:40 Brad Yeah, the config.
9:40 Brad To think about it is, I love it.
9:43 Scott So I want to go back to the previous example, though,
9:45 Scott where as engineers, we do have requirement for two different pages.
9:51 Scott We put them in one with the configuration so we create complexity.
9:55 Scott I don't consider that complexity tech debt.
9:58 Brad That is, Not
9:59 Scott so not all complexity is tech debt is what I would say.
10:03 Scott I
10:03 Brad it's
10:04 Scott would say a
10:04 Brad serving
10:04 Scott lot of tech debt is
10:05 Brad a
10:05 Scott purpose. excess complexity.
10:06 Brad Yeah, but if it's again,
10:08 Brad and that's why I'd go this is a distinction between tech debt and product that that
10:13 Scott Okay,
10:13 Brad complexity
10:13 Scott so,
10:14 Brad was
10:14 Scott yeah,
10:14 Brad required by product.
10:17 Scott yeah.
10:18 Scott Okay,
10:18 Scott so let me...
10:19 Scott 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
10:36 Scott Do we rewrite it from scratch or do we refactor it, right?
10:39 Brad Modernize it somehow
10:41 Scott Modernize it, yeah, modernize it somehow.
10:43 Scott And you had made this comment.
10:46 Scott This is when you made, in that conversation is when you made the product data is real comment.
10:50 Scott And so why in that conversation,
10:53 Scott how does it relate to that conversation?
10:56 Brad Okay, because one, okay, great.
10:57 Brad I'm so glad you asked this.
10:59 Brad 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.
11:13 Brad 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,
11:23 Brad right?
11:25 Brad Inevitably, there are requirements. I'll call them features. There's features that imply requirements that nobody remembers.
11:37 Brad 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
11:50 Scott Mm-hmm.
11:51 Brad nobody in the modernization project or even any of the immediate stakeholders of the modernization project remember
12:01 Brad That requirement and remember to say,
12:03 Brad hey,
12:04 Brad while you're doing the modernization,
12:06 Brad make sure you don't forget about buried old feature X,
12:12 Brad Y, Z that no one remembers because we wrote it five years ago,
12:16 Brad but turns out is being used on the regular.
12:21 Brad by real customers, but everyone has forgot about it.
12:24 Scott Mm hmm.
12:25 Brad That's a category of product debt.
12:27 Scott Interesting.
12:27 Brad And in my experience,
12:29 Brad 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.
12:38 Scott Well,
12:38 Scott that's interesting.
12:40 Scott To me, that landmine is more of a rewrite landmine than a modernization landmine because the rewrite landmine is.
12:48 Scott 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
12:54 Brad They're
12:54 Scott debt whatever
12:54 Brad in a that we're using a what is it we're using like PHP for it
13:00 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
13:13 Scott So you got to rewrite it and
13:15 Brad And no one remembers
13:16 Scott you got,
13:16 Brad the VIP landing page.
13:18 Scott right,
13:19 Scott because you just don't even know, or more to the case more,
13:23 Scott and I would say is there are so many requirements in there that it's actually just, I don't want to say impossible,
13:32 Scott it's approaching impossible,
13:34 Scott but it's closer to impractical to
13:38 Scott capture them all so that you can put them in the spec for the new thing you're writing like
13:43 Brad Yep.
13:44 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
13:51 Brad Yep.
13:52 Scott little wrinkle that's in there right and it might not be a special case it might just might be like um
13:58 Scott Well, an example that came up today and something I was doing was just like we were talking about,
14:03 Scott well,
14:04 Scott 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.
14:14 Scott 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
14:27 Brad No.
14:28 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
14:39 Scott And so you run into the Chesterton's fence problem,
14:41 Scott which is very expensive in terms of time to kind of run around your company trying to say, does anybody know why?
14:48 Scott 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.
15:10 Brad Yeah, but this is where I'll give you. So you started to ask the question,
15:13 Brad hey Brad,
15:14 Brad is this like
15:14 Brad It's like unknown feature product thing.
15:16 Brad Okay,
15:17 Brad you're basically like, yeah, Brad,
15:18 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,
15:26 Brad yes, you agree that exists in almost every code
15:28 Scott 100%.
15:28 Brad base.
15:29 Brad And you're saying like,
15:30 Brad hey,
15:31 Brad but if we don't fall for the trap of rewriting it,
15:34 Brad can we safely avoid those landmines? And my response to you is.
15:40 Brad not likely and
15:41 Scott Oh,
15:41 Brad the
15:42 Scott really?
15:42 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
16:00 Brad 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
16:26 Brad 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
16:46 Scott Yes.
16:46 Brad know http metadata
16:49 Brad And that's when that's when the VIP page breaks and no one and everyone's like, what?
16:54 Brad And and worse,
16:55 Brad 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.
17:06 Brad 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?
17:15 Brad We didn't change anything about that.
17:19 Scott Yeah, I guess I disagree with you weekly.
17:24 Brad Okay.
17:24 Scott And what I mean by that is in the case of the refer header or whatever it was that's there,
17:32 Scott at least an engineer saw it and thought about it, and maybe they made the wrong decision,
17:37 Scott right?
17:38 Scott Versus the case of the, that's on the refactor side.
17:42 Scott On the rewrite side,
17:44 Scott you just, you just, you don't even know, you're oblivious. You didn't even know.
17:49 Scott 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
18:07 Scott 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
18:26 Brad I just think that like,
18:28 Brad yeah,
18:29 Brad I agree with you. Like it's a slightly easier to catch it.
18:32 Brad 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
18:47 Brad And the thing you're rewriting has a bunch of requirements that may not be obvious to you.
18:53 Scott Okay,
18:53 Scott I know why I have a visceral reaction about this, not a strong one, a weak one, like I said.
19:00 Scott Here's what I think it is.
19:02 Scott Let's say that you and I were engineers with hubris.
19:05 Scott And we say, oh,
19:06 Scott we can go rewrite this landing page.
19:09 Scott It'll take us very little time and it'll be so much better than the last one.
19:15 Scott And we probably do a cursory review.
19:19 Scott 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
19:44 Scott With the code situation,
19:46 Scott I'm sorry, with the refactor situation,
19:48 Scott at least the thing, the code,
19:51 Scott the header,
19:52 Scott it's right there in front of your eyes.
19:54 Scott I'm not saying it's easy to make the right call,
19:58 Scott but at least you've got to.
19:59 Brad chance?
20:00 Brad 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,
20:12 Brad you're just setting yourself up to make the mistake.
20:15 Scott OK, well,
20:16 Scott so I agree with that.
20:18 Scott I'm not you're not going to get an argument with from me on that point.
20:21 Scott I agree with that point that you're making.
20:23 Scott I'm saying.
20:25 Scott 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.
20:38 Scott ancient old undocumented requirements they are opaque to us and we can look at the code to try to understand those requirements but
20:47 Brad Yes.
20:47 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
20:56 Brad 100% agree.
20:57 Brad 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,
21:03 Brad I can read this, understand what this is doing,
21:07 Brad but I don't understand why.
21:09 Scott Yeah.
21:10 Brad Why
21:10 Scott Why was
21:11 Brad did someone
21:11 Scott it written this way?
21:12 Brad put this here?
21:14 Scott Yeah.
21:15 Brad Why are we checking to see if the customer is in West Virginia?
21:19 Brad I don't get it.
21:20 Scott Right.
21:21 Brad And I find out, oh,
21:23 Brad well,
21:23 Brad it turns out there's a law in West Virginia that says blah,
21:27 Scott You can't sell llamas.
21:27 Brad blah, blah, blah, blah.
21:28 Scott Can't sell
21:28 Brad Seven
21:28 Scott llamas.
21:28 Brad years ago, the lawyers,
21:30 Brad yeah,
21:30 Brad seven years ago, the lawyers said you can't sell llamas in West Virginia, right, whatever.
21:34 Brad But, you know, and hopefully the person did it clearly and it makes sense, but often they don't.
21:41 Brad Okay.
21:41 Brad You mentioned the author example.
21:44 Scott Hmm.
21:44 Brad I've lived through that before.
21:46 Scott Yeah.
21:47 Scott Yeah,
21:47 Brad Let's
21:47 Scott all of
21:48 Brad see here.
21:48 Scott us have.
21:50 Brad Winter of 2022,
21:51 Brad matter of fact.
21:54 Brad We're replacing homegrown off system,
21:56 Brad hooray, with off zero,
21:59 Brad a reputable vendor.
22:02 Brad And, you know, like all engineers who have hubris, we thought this will just take us two weeks.
22:07 Brad 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
22:32 Brad And you crack this thing open,
22:34 Brad we've been rolling this thing out and rolling it back with this thing because we've been missing use cases or whatever.
22:39 Brad And this is this exploration of how authentication works for this one application,
22:46 Brad this one like, you know, admin tool that's on the side.
22:49 Brad And he's just like, I don't get it. I don't understand how I'm
22:53 Scott I would have to rebuild it all.
22:55 Scott It's like.
22:55 Brad How does authentication work for this system?
22:59 Brad 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
23:16 Brad And using something to like authenticate against like the main system or making its own little authentication thing,
23:22 Brad what it did is what kind of made its own little authentication thing.
23:25 Brad 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,
23:29 Brad actually.
23:29 Brad It's so it's so bad, but I didn't do it. I just found it.
23:32 Brad There was an ETL job that copied the usernames and passwords from one database to another.
23:39 Brad And so this guy's like,
23:42 Brad I don't get it.
23:42 Brad 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
23:51 Scott How frequently
23:51 Brad and probably
23:51 Scott is this ETL job running?
23:53 Scott Like on a minute?
23:53 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
24:12 Scott So
24:12 Brad a that
24:12 Scott there you go.
24:13 Brad was a
24:13 Scott That's
24:13 Brad fun one
24:13 Scott you.
24:13 Scott You just proved my point.
24:16 Scott That was a refactor that had some weird product debt in it that you later
24:21 Brad Oh,
24:21 Scott like
24:21 Brad no,
24:21 Brad no, no.
24:22 Brad That was I do not put that one on product.
24:24 Scott Okay
24:26 Brad In fact, I don't even know if we can call that tech debt.
24:29 Brad I mean, we can call it tech debt, but it's got to have a special name of tech debt.
24:33 Brad There's there's.
24:35 Brad A type
24:36 Scott Munchausen
24:36 Brad of tech debt.
24:36 Scott by proxy tech debt.
24:38 Brad I don't know what that means.
24:39 Brad What does that mean?
24:40 Scott Oh, that's a mental
24:41 Brad Is that the thing?
24:42 Scott disorder where you make your child sick so that you somehow feel better as the savior or something.
24:49 Brad Here's what I'm getting at.
24:51 Brad There's tech debt that comes from we've introduced it of years of adding product complexity.
24:56 Brad There's tech, you know, essentially the needs of the business have changed, but the product hasn't evolved enough.
25:02 Brad There's tech debt,
25:03 Brad which is systems are outdated.
25:05 Brad We're using old versions of stuff,
25:07 Brad things like that.
25:08 Brad And there's probably other types of tech debt. I'm sure there's a million of them.
25:11 Brad But here's a special one. And I think it deserves a better name than tech debt.
25:14 Brad And maybe we can come up with that name.
25:16 Brad Well, there's tech debt when somebody makes a poor design decision and in retrospect,
25:20 Brad you look back and you say, that's not very flexible or scalable. We could have done that better.
25:23 Brad And then there's tech debt and this deserves a special name.
25:26 Brad When somebody makes a design decision that is so bad,
25:30 Brad 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.
25:41 Brad a egregiously what's
25:43 Scott Design.
25:43 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
26:00 Brad 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.
26:13 Brad I
26:13 Scott OK,
26:14 Brad feel like
26:14 Scott well,
26:14 Brad we fair have to come up with new names.
26:15 Scott enough.
26:16 Scott I'm going to pivot us back to this question of product debt for a second. And
26:20 Brad Do it.
26:20 Scott I want to pivot to this question that you basically are saying is like,
26:24 Scott hey,
26:24 Scott rewriting the system is is.
26:28 Scott is never the right answer because you'll get you'll definitely like get bit by this product debt higher
26:35 Brad I'm not going to say never the right answer.
26:37 Brad It's just higher risk.
26:38 Scott risk okay let me look at let's look at the other side of that coin
26:42 Brad Yeah.
26:42 Scott Okay, the other side of the let's rewrite it coin.
26:45 Scott 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?
26:54 Scott What are the requirements of the rewritten thing?
26:58 Scott That's an opportunity to eliminate product features you no longer need.
27:05 Brad Yes.
27:07 Brad Let me tell you my two just instinct,
27:10 Brad like very quick, the things that came right to my mind
27:12 Scott Your
27:12 Brad in response
27:12 Scott first reaction
27:12 Brad to that.
27:13 Scott to that.
27:13 Brad My blink reactions.
27:15 Brad The first was,
27:16 Brad yeah, but will the requirement writers remember important requirements that are hidden,
27:25 Brad like the VIP landing page?
27:27 Brad The other thing that came to my mind is a category of existing feature.
27:34 Brad 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
27:53 Brad 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
28:18 Brad 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
28:43 Brad 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.
28:51 Brad And so then that's an expensive process, going through all that rationalization.
28:59 Brad So those are the two things that came to those are the two things to my mind
29:02 Scott Yeah, I think those are both valid things.
29:04 Scott And this is where you kind of got to challenge the question.
29:07 Scott This is, by the way, this is the reason that like upstarts have an advantage over incumbents.
29:17 Scott They're not saddled by that.
29:19 Scott So, you know, one.
29:23 Scott One strategy that if you have the environment and the wherewithal to do this, one strategy is be your own disruptor.
29:32 Brad Yeah, I've thought of that a lot.
29:35 Brad And it's very alluring.
29:38 Brad But for these reasons we've talked about,
29:40 Brad it's also risky.
29:43 Brad Yeah, I mean, actually, the words that were coming to my mind were intimidating and scary.
29:48 Brad Um,
29:49 Brad especially if you, if you have an, it's fundamentally the innovator's dilemma,
29:53 Brad which is,
29:54 Brad Hey, we've got a good thing going and we want it to go better.
29:57 Brad That's why we want to improve the platform.
29:59 Brad And this actually could potentially make it go a lot worse.
30:04 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
30:09 Brad Yes.
30:09 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
30:24 Brad Yeah.
30:25 Brad And so as an engineering leader.
30:29 Brad I mean, I guess I'll just be honest.
30:30 Brad I guess I don't have the cojones to recommend that because I'm afraid of cratering the business.
30:41 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,
30:48 Scott the business team has got to be like,
30:50 Scott yes, this is something that we recognize,
30:52 Scott understand and agree,
30:54 Scott you know.
30:55 Scott 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.
31:18 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.
31:27 Brad And I've been the one who said, no,
31:30 Brad to use your language of product that which I didn't quite have before.
31:33 Brad Now, you guys don't understand the product that like it's.
31:38 Brad That's why I would call it a fool's errand.
31:40 Brad 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.
31:53 Scott Revitalizing.
31:53 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
32:16 Brad It is truly the innovator's dilemma.
32:20 Scott Well, there you go.
32:21 Brad There
32:21 Scott So you
32:21 Brad you go.
32:21 Scott and I were talking about rebuild versus refactor, and
32:26 Brad Yeah.
32:27 Scott I threw product debt at you.
32:29 Scott And now after 30 minutes of talking about this,
32:32 Scott do you feel empowered to use the term product debt in an upcoming conversation?
32:38 Brad I absolutely do because we're having some conversations.
32:43 Brad 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
32:53 Brad 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
33:18 Brad Let's see if there's any product debt we can get rid of.
33:21 Scott Yeah, I love it.
33:23 Scott That's a great, great way to use that term.
33:26 Scott I love
33:26 Brad Thank
33:26 Scott it.
33:26 Brad you. Thank you. This has been a fun conversation today.
33:29 Scott Awesome.
33:30 Scott It's good chatting with you, Scott.
33:31 Brad All right, everybody.
33:32 Brad If you're listening,
33:33 Brad don't forget to smash that subscribe button to leave us a five-star review.
33:40 Scott Yeah.
33:40 Brad and to tell all your friends about it.
33:42 Brad 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.
33:57 Brad So
33:57 Scott This,
33:57 Brad thank you very this much.
33:58 Scott facts may or may not be fake news.
34:03 Brad All right. Thanks, everybody.
34:04 Scott Thanks, everybody.
34:05 Brad Bye.
34:07 Scott This episode of How Many CTOs Does It Take Podcast was edited by Safran Hepagel.
34:12 Scott Our theme song was AI Generated by Brad.
34:15 Scott Please follow us on all the social media platforms at at HowManyCTOsPod.
34:20 Scott You can find us on YouTube,
34:22 Scott LinkedIn,
34:23 Scott Instagram,
34:23 Scott Facebook,
34:24 Scott Threads, X,
34:25 Scott TikTok,
34:25 Scott and Patreon,
34:26 Scott or at our website at HowManyCTOsPod.com.
34:31 Scott And remember to rate, review,
34:33 Scott and subscribe on the podcast platform of your choice.
34:36 Scott Thanks for listening.