AA101 - Accountability, Prioritizing Technical Debt, & Product Cannibalization

If you do a podcast, especially, the Agile podcast, aka. Arguing agile for so long, you end up with a whole bunch of topics that you cannot cover in a normal podcast. Cause they don't they don't really lend themselves to discussion, a long form discussion, but they're still worthy of being discussed. So that's today. we had a, a topic come up recently at a, networking event that we were both at, and the topic was, and I quote, Agileists never take account. What a statement to make. There's, there are a couple of strong words in that statement. Never is one. And accountability agileists never take 'em. Accountability. I don't know. I think the person who said that had something else on their mind that they weren't able to relay, I guess in the time allowed at that, , social event. But fundamentally, if you look at this at face value, agileists never take accountability. I mean, if you're an angelist, you know who we are. If you're an agile list, how would you feel about this? Uh, please, please let us know in the comments down below. Personally, my, my own opinion on this is it is a bunch of baloney. Because Agileists typically work with teams and. Team members take accountability for collectively the team's, effectiveness and outcomes. Actually, I know exactly what the counterpoint, like this is what happens when you work for psychopaths for too long. The counterpoint here is when, when accountability is not one, one individual, it's on nobody. That's the counterpoint that I hear very clearly ringing in my head. Oh. Usually coming from a psychopath, trying to pin down or blame absolutely. Couldn't agree more. Um, so yeah, I have seen that. I'm not supposed to agree, but but on this point, I, I've seen this myself, right? These psychopaths that, that of which you speak. Mm-hmm., I've seen them, they say, mm-hmm., well, where's that? One neck to choke. What a horrible phrase. What a horrible phrase. so yes, people looking to pin the blame on someone, they're very keen to make sure they have a name on a spreadsheet usually, and they're very keen and intent on making it go from green to red. so these are the people that say we need accountability. In other words, I need to blame somebody That's right. A person. That's right. Right, that's right. Um, and and they, they don't buy into this concept of the team operating as, a team of N number of individuals. So, the dictionary.com definition of accountability is the state of being accountable, liable, or answerable. Okay. Accountable - subject to the obligation to report, explain, or justify something. So, Responsible, answerable, capable of being explained, explicable, explainable. Subject to the obligation to report, explain, or justify something. Agilists never take accountability. Agilists never report, explain, or justify what they're working on. When you read the definition and then you go back. It kind of sounds ridiculous so I wanted to read the definition to know how better to dispute from the. Side to say Agileists never take accountability. I'm assuming that when they say Agileists, they're not talking about developers and product owners. I assume they're talking about Scrum Masters. Let's, let's, let's get through the assumptions. Let's assume that, let's assume that for a minute and go with it. Okay.. Okay. All right, good. Let's say we're talking about agile coaches and we're talking about Scrum masters. Never take accountability. The person exclaiming this statement, Agilists, never take accountability in this type of organization. Now, is this CTO, director of development, somebody like that, who says, well, I don't see a reason to hire scrum messages cuz they, they never take accountability. Meaning they, they can't report, explain, or justify when commitments that I make on their behalf are missed. Yeah, I can see you. Charlie, the CTO's point of view here, right? Uh, if you are a scrum master worth your salt, you're gonna say, here's what's going on in, in all honesty, in full transparency, the good, the bad, and the ugly. Mm-hmm., and that is not quite what he wants to hear because he's gonna sanitize your message anyway before it filters upwards or, or laterally from him. He doesn't wanna show the team quote unquote failed because failure is quite honestly frowned upon. Right? Right. Yeah, right there. I can see the point of view of a person like that saying, Agileists never take accountability because I don't have one person who I can say, Hey, you failed. Right? Yeah. Even if they don't report that up the chain, right? They want to be able to blame a person, whereas here's the team coming at them saying, the team did this, the team did that. So I can see that, that perspective, if you work for somebody like that, I'd say keep that resume updated. The interesting part about accountability, that little dance that I just did doesn't really work on product that much. I mean, I guess it works, but it only goes so far , especially if you're responsible for the P&L of the product, if you have actual dollar figures tied behind what you're doing you could say like, Hey, we spent 20% of the last two, three sprints on learning. you know, th these are the things we learned. Oh, well you failed, Brian, your team failed. Well, actually, yeah. I mean, yeah, we failed, but through the things that we did not deliver the, this is what we learned, we tried to make this database change because you wanted this feature. And we learned once we did it that we blew up some other thing because everyone that I have on my development team were not the in individuals that created the system in the first place. So we learned that something that only the people who created the system in the first place that have been gone 10 years or whatever, would've known. And now we understand that, that that deep, deep part of the code, I, I think when you have leadership that take that position and say, but Brian, you failed. Even though you learned stuff that was extremely valuable. I find it, I find it useful to term that into terms that they understand we didn't fail, we saved this amount of money because had we not learned this, we would've put out bad code, et cetera, et cetera. Right. So, un you know, then they can understand, oh yeah, glad you didn't do that. so I think you need to kind of do a reciprocal dance, if you will. I also since like since we did the podcast on Carol Dweck's mindset with Ed, shout, fantastic podcast. Shout out to Ed. It's like a quick, an hour and 15 minute podcast here. Real quick, so we did the podcast on mindset. This is, this is what I was talking about. And in the podcast on mindset. The book makes it a point to say , you don't fail until you start blaming. That's a quote from, from somebody in the book. I don't remember who it was. that's a great quote. Yeah, I'll remember it in the editing and I'll throw, it'll try to throw it on the screen unless I'm too lazy and then I'll just cut this out. Cuz that's the idea here is like, oh, agiles never take accountability. Well, well, what do you mean here? Do you mean, do you mean we we're not gonna blame. People, is that, is that what you mean? Agile pushed back against the blame culture. Because if so, I'll agree with that. And also like I'll immediately turn that file around and be like, so what do you actually do here at Initech? Like I'll, like the Bobs are in the room and is like, oh, you're the one guy blaming, let's do a little introspection. Look at what you do during the day. Other than blaming people, looks like you basically professionally deflect off to other people and blame people. And, you know, we've talked a million times on podcasts. This is, this is not really a reason to go super in depth here, just get rid of that person and see what happens in your organization. Yeah, it's like throwing out the bad apple, you know, in a bushel of apples. Right. It, it can only get better cuz you're getting rid of the rock basically.. Uh, maybe some will say I'm big, a bit extreme on this, but I don't think so. I mean, other people will say, look, you know, Agilists never take accountability. I don't know what your developers are doing all day, right? I don't know. Well stop micromanaging them. Then. Of course, they're not gonna be forthcoming with what they're doing if they know that you're gonna nitpick away at them. I just don't see a problem with going to your team like if you're a leader in the organization, going to your team show, showing up at one of your team events, let's say for example, and say, Hey, I, I'm not seeing x, y, Z outta this team. I need more X. Oh, that, that is okay. That's within their ative to, to do that, right? But it's when they come in and say, you. Fred, you, Mary. Right? That is where I have an issue. Sure. Because now you're putting one person on the spot. Sure. Then the team's trying to do their best to deliver as a team. Sure. But if, but like, just taking the, trying to run with the spirit. I'm trying to defend this. Mm-hmm., try trying to run with the spirit of this bullet point. Never take accountability. if I'm a leader in the organization and I constantly have a scrum master from the team saying, well, you, you know, you have to talk to the team. You have to talk to the team. Well, I, you know, maybe I, I know one person on the team is not delivering as fast as other people or people in the organization are complaining about one specific person on the team, and the team is not dealing with it. Then I'll be like, well, you guys are just not, you know, you're not, you're not, you're not taking accountability for, you know, if you want to self-manage, you wanna self-organized, self-manage, whatever iteration of the scrum guide we're on and you want to deal with that person internally, like you have to do it. Like, don't, don't leave it. Uh, on my mana, my random management plate of. Random things that I have to take care of. Cause I'm gonna delegate it to you, and then I want to know that it's been done. I feel like if we're gonna go into that category, like, hey, the team should be identifying the people that are in need of training, the people that are maybe not working as, as, as fast as other people or not catching on or whatever. And then get them up to speed if the team would like that to be something that is continued to be delegated to the team rather than to some other lead or to a manager or something like that, the team needs to show that they can deal with those situations. I don't know if like, the team proving they can deal with those situations. I dunno if that's different than accountability. I kind of see it as the same as accountability. It is the same. It is the same. Okay. I, I think some of these. Symptoms that you describe, you know, somebody's not up to speed with something or whatever. These are self-limiting if you're truly acting as a team because you talk about 'em as a team and then you chart the course of action mm-hmm. to redress that deficiency. so I think those things, if you trust the team and leave them alone to figure these things out. Yeah. I think they're self-limiting. If management is hearing things in the organization, or if management's feeling things in the organization or management just like susses things out how would they communicate? But would they go through the scrum master, through a team, lead, through a senior member of the team? Through like who will they go through to communicate? Like, Hey, I need something more from this team, or I need, you know I hear that developer, whatever is combative, or I hear that you know, you guys are always miss your deadlines, I've been in an organization where managers have like 30 teams. Yeah, just a, just a completely unreasonable amount of teams. I'm gonna try to empathize with the overworked manager who just simply doesn't have time to come sit with your team to see what the real problems are and is just gonna delegate to somebody to say, Hey, look, you're on the team. You're a smart person. You are somebody, I dunno what, senior Scrum master, whatever product, I don't know what it is, hey, bring it up to your team. Make a decision. Let let me know what the plan is so that I have confidence it's being handled. So if I'm ever asked, and usually I'm not ever asked, but if I'm ever asked, I can say, Hey, the team's got it. This is what they did, this is what they took, this is the evidence they're built. You know, and that kind of stuff. Like who does that? Yeah. So that's a great point. I wanna just double click on what you said. The team's job collectively, you can break it down into individual roles if you like it, it ultimately boils down to. You need to make your boss look good. That that's what it boil down to. Yeah. So if they're asked in your example, and they don't have a, a decent answer to that question, then that's not a good thing. Right? as far as who that person is, more often than not, it is the scrum master, so that's pulled aside and being asked these things, right? Yeah. Um, I mean, sometimes it depends, I suppose, right? Sometimes maybe it's the product owner to , what are we doing? Why are we always missing the goal? Are you setting realistic goals? Those sorts of things. But typically it's the scrum master, right? Your team, the team you're on, right? I could see it being the product owner from a business perspective. Like, hey, like, Hey, how come your product isn't making more money? Heck, basically, if someone's approaching you with a business metric, I could see them funneling through the product owner. But if, if the scrum master truly is a , a, a decentralized member of leadership a delegated piece of leadership down to the team, and the scrum master represents that piece, , then I could see it being the Scrum master. I mean, more often than not, the Scrum master is a non delegated piece of management rather than leadership. so I'm choosing those words because that's typically what happens there. Report centric as an organization. Yeah. And the scrum master is basically being interrogated, frankly, you know? Um, yeah, but what, what should they be though? Well, so when you say what sh I ideal the ideal, the i, the ideal should be that they should be a trusted member of the organization, right? Mm-hmm.. So leadership should basically set the goals and leave the scrum master to attain those goals. Now, of course, there could be you know, there could be precedents there where the scrum master needs to escalate for risks, et cetera. But sure, in the normal, quote unquote, right, in the normal working environment, the scrum master should not be the whipping person, basically. Uh, and you do see that quite often in these organizations where, , they roll up through technology, it, it management. Mm-hmm. as opposed to leadership who understand hopefully you know, what motivates people. Mm-hmm., right. Um, yeah. So that's what it should be. It should be, you know, empower your scrum master and let them go ahead and deliver, and then just ask them what they need. That's what it should be. It sounds simple, but you know, I, I don't see that all too often. When I do see it, it's remarkably effective. Yeah. I want to pivot hard pivot, hard pivot into the PO's input on technical implementation. I was on a team one time where the, team members were a couple. It was a mobile development team, a couple mobile developers, I think two mobile developers, one for Android, one for iOS, and a tester.. And the tester would basically do some manual tests and walk through their stuff. And I was a manager in this uh, organization. I was also a product owner, but I didn't, my, my, my product was not the mobile products. And I remember making a case to say, Hey, you, the, product person for mobile, you should really go with automated testing. You should stand up automated testing so that you don't have to, like all these manual tests and all these manual regression tests and everything that you run through, you won't run through them anymore. The automation will run and I was like, you, you basically won't pay the cost of manual regression anymore and you can repurpose your one tester that you have to, to do whatever, get 'em closer to the business, bring 'em with you to business calls. Do what you know, have 'em, write documentation, have 'em write release notes, whatever, whatever you want, but get 'em out of this nonsense regression stuff that they're doing. And as the test manager at the time, I had automation people that I could have assigned if they wanted to pay that cost., but there was a, there was a cost to be paid the idea is the entire application was manually tested. So in order to get it to a point where it's automated as far as testing goes, they would've had to overcome a certain amount of what I think of as technical debt is the, the, there's no automation in place now for the application. And then once there is full again, for the listeners, I'm doing super air quotes. Once your critical paths through the application are automated and you have automated reports going to your email every morning or whatever, you know, or if you have a page that gives you, you know, green, amber, whatever. Yeah. The rags. Yeah, then you don't have to, you don't have to think about it. Like there's a certain level of quality built into your application that you no longer have to think about, and it doesn't cost you anything more other than the, the tiny, tiny, tiny little cost of whatever the automation costs to run. Right. And to maintain nothing practically, which is practically nothing compared to the cost of change so I bring up that story because I was in a similar discussion about uh, the PO's input on what is like technical, like hey like you're the po but also like we don't need your input on technical. implementation. He's doing air quotes for people. Yeah. Without audio. Technical video rather. Cause, it's not like business value. The customer's not gonna see anything. I think the same thing as adding automated tests as I think of in like rolling out your application through development pipelines through release pipelines, for example, like the, the pipeline for that sends your stuff out to test and then once it clears test and, and then it goes to stage and once it clears stage, it clears production. And then if your automated test run in each different environment, then it, it triggers the next deployment to happen to the next environment all the way through to production. If you trust your deployment process and automated testing all the way through that cycle, it's like the development team would say like, , this is not. A customer facing feature. So use the product person, like, your input's not really necessary about this. Yeah. A lot of times yeah, I see where you're going with that. A lot of times developers say, well, you know, this is, you've given us the, the what, hopefully the why as well. Mm-hmm. and, and this is the house, so leave us alone. Right. Um, customer doesn't see that, okay, but you delivered or you, you finished that feature at a certain point in time and you are, because of your manual test strategy, there's a, there's a certain time it takes before we can clear all of that and put the thing into production. And for, if I was a product person, I would say, wait, that time, that time that you are, you're spending in running manual tests, that is tech debt right there because you're sitting on value, technically in the lean way of thinking. That's waste. Yeah. So you're, you're sitting there with something that's finished, ready to go. Yeah. but you're not able to get it out there fast cuz you're not using, you know, release pipelines and things like that. Sure. So often when teams say, well the customer doesn't see that, that's a bit of a curve ball because they don't really mean that, or if they do, they, they're not seeing the truth. Right. Yeah. The customer doesn't see value early enough. Uh, you've done the work you know, doing things like manual testing, it's an opportunity cost. There is where I'm going with this. Right. So pay down that up upfront, get that automated testing implemented in, and e reap the benefits. Timing again, it automatically runs thousands of tests in a minute. Yeah, right. Which you can't do the computers so fast. You can't do that manually. What's the value of that? Well, it's gonna catch something out of those thousand tests that you're not gonna catch until your manual tester goes through his 20, 30, 50 tests. They're not gonna do a thousand. Otherwise, you never release anything to production. So there's a, there's an argument right there. the product owner coming back to the, the point here mm-hmm., they're not necessarily saying how to do this. They're just saying to do this. Right. So they're saying, well, maybe you should use automated testing because it will allow us to X, Y, Z. Well, the team in the, like, I remember the team in this point had a, had a go like they had a pretty serious back and forth. Again, I was not part of the team. Yeah. I was just a manager. And the team had a pretty serious back and forth with that product owner at, in that organization because the team were, was basically saying like, we don't want to do the manual testing anymore. So, so basically the, the whole team minus the product owner approached me to help them convince the product owner that this was worthwhile to bring in and prioritize. Another way they could have gone about it is just to tell the product owner, like, Hey, we don't wanna make any changes anymore until you adopt X, Y, Z. And they could have pitched that case, just like any other stakeholder says, like, I don't, I don't want to adopt your application unless you add this, whatever PDF functionality or this other functionality, the ability to scan a document or something. Like, whatever the intake forum is, where a, where the prioritization happens. I bring this up because the way it's been asked to me now that I'm strictly a product owner and not a manager anymore, was, I don't understand why the product owner thinks that they even have input into, should I work on this or not to which my suggestion was, if the product owner wants to have a manually deployed and manually tested application and continue with that level of technical debt forever, there may be reasons you, you need to talk about those reasons. Yeah. Their pushback to this was it's an engineering decision, not a product decision. Ah, to, to knock down that technical debt to, and then, , we were done. Cuz I was like, I'm not discussing this anymore because I, first of all, it's not, it's not appropriate cuz it wasn't my product. I certainly have opinions, but also I'm not, I'm not working on any of these teams., where's, where's, where's the camera? I'm not working on any of these teams. I'm not the manager for any of these teams. And I only have influence over these teams, not controller management over any of these teams. The German three. There it is. here's my suggestion. Now it's up to you, the team members to push it forward with your product person and that, and that's about it. Like who, who's right, who's wrong in that? How hard can the team members push? Should, is it actually the product manager's job, product owner's job to say like, I disagree with, we need to knock down this technical debt now. And I'm good with this technical debt for X number of time or, you know what I mean? I think it is. Oh, okay. No, I tell you why. I think it is because the, it's the product owner who is responsible for delivering things sprint over sprint. So they may look at the, the team suggestion, yes, there's this tech debt. To your point, yeah. Put it in the backlog. And as a product owner, I might. You make a point. Mm-hmm., but we're, you know, we really need to get dysfunctionality out. So maybe I'll just, I'll just weather that for a little while. Two or three sprints or whatever it is. Oh boy. And then we'll bring it in as a tech debt remediation item. don't you only have a certain amount of time until like your development team just grabs pitchforks and gets tired of like, middle, like pajama party deployments and Oh boy. Yeah, you do. Unless you have access to these you know, these minions that basically live offshore and you can say, oh, you don't like it. No, no, I know. It's as horrible. yeah, you're right. I mean, you really, as a product need to think hard about this, right? Yeah. Because it's gonna impact you. Not in the long term. I would say probably in the medium term, right? Yeah. I mean, in the short term, you might be under the gun that deliver a feature or two that the team's working on right now. Maybe the next one or two sprints, but pretty quickly you need to grapple with, you know, these two things that we talked about, automation testing and using release pipelines. Otherwise you are going to stumble over your own feet. I mean the big takeaway from that conversation was the perspective of the developers. Working on that product was why should we go to the product owner for anything that doesn't have customer visibility, that was their perspective. I understand it, but I don't agree with it. you know, I, I, I think, I think they need to work together as a team, right. The product owner and the developers and, and each make their case rather than say the customer doesn't see this and that's why we shouldn't do this. Yeah. I mean, you could extend the argument. It's a bit, a bit ridiculous, but you could say, why should we clean up our feature toggles once they've been turned on in production? Now they're live. Yeah. We introduced them three months ago. They're still in the code. Who cares? They don't see 'em. Yeah. Well that's that, that you're accumulating in that production code, right? Yeah. You really should be cleaning up after yourself. Yeah. so they could argue that. Yeah. And then, and, and., some product owners could argue the other way, and they, they, they could say, well, why is you bother going in there and doing all that stuff? Work on this new stuff for me? Yeah. Right. Yeah. And that's again, short term thinking, but it prevails. oh boy, I don't think this is discussed enough, this topic. Like, well, maybe we might put a pin in this one and come back to it in there. Yeah, I'd like to, yeah, I'd like to come back to it. Yeah. I don't think this one's talked about in like, this is this this like borderline was I'm doing the sandpaper, motion. It's like that borderline, this, this rubs directly up against like, er, craftmanship and uh, like that kind of movement of you know, why would we , why would we make it pretty, it works. Like, why don't, don't touch things if it wor if they work. I could go super in depth on this topic about like, hey, if you look at like, you should be able to read a function quickly and understand what it means. And if you don't, if you can't quickly understand what the function does, like, like, let's, let's, let's take that one off line. But, but, but, but Brian, I have a thousand lines of comments in my function. If you read 'em, you'll love this. I it's a three line function like German three. Sorry. Oh yeah. We only read German three on this podcast. I'm with you on reducing. To a point I I, I had a, a director of development one time who was like, if the code is written, well, you shouldn't, you shouldn't need comment. I don't agree with that. I don't, I don't necessarily agree with that, but I understand what he was saying. But some code is very complex. Um, agree. So I, like, I, I don't a hundred percent agree, but also my, my technical competence level is nowhere near where his was. So if I try to have the technical competence level of everybody on my team at a very high level, and I spend a lot of time and energy into basically internal training and stuff like that, to, to make sure that every developer I hire gets to that same, you know, minimum technical competence level, then I will be in line with what he was talking about. I still don't agree because there are some things that you need to., you need to make clear to those that read the code behind you. Mm-hmm.. Um, I, I think this idea of self-documenting code is nonsense., I see people documenting code for the sake of documenting code. Like they'll just say, you know, I equals I plus one, or I plus plus, whatever it is, whatever language you use. And then, and the comment next to it just says, increment I, well, duh, . Right. So why? Yes, I know. So that this is where minimal but useful commenting is an art. And not every like, key point. Yeah. I mean, we need to invest in developers to make sure they reach that level. Uh, this is where some level of coding standards are warranted, I feel so that when somebody new comes in, somebody else who's been through that can take 'em under their wing pair programming is an ideal way to do it. Sure, sure. You know, if that's what's afforded at your In your shop. I mean, sometimes though it's difficult, I grant you that, like, let's say you, you are not just pair programming, but you're swarming and people are just busy, busy, busy. Okay. Just have somebody going after you and add in the comment. They're part of the mob. Yeah. They understand what's going on. They're, they're swarming, but that's no excuse to not put any comments in. long time ago, I was in a, at a hospital, I was actually coding then in my boss, who was very technical could read the code, but he would still say, if you're not here, how would somebody know what this does? Right. And he insisted on the comments being plain English language, nothing technical. Yeah. Pass this into this array means nothing to somebody new. It's like, why? You know, just say, validate postal codes from the post office database or whatever. I mean, that, that's meaningful, at least, right. We could do a whole podcast on and get a guest in specifically to talk about software craftsmanship and all these little in like, in-depth topics. Cuz I, I have, I have my own kind of beliefs crafted on my own experience in this topic. I would say like six months passed when I originally wrote a a a a script.. I have no memory of writing the script at all. So basically I'm reading somebody else's code at that point, when you end up swearing up a piece of code and go, who wrote this crap? And then you realize it was you? It was me. It's even worse for me cuz I had junior people in the department at that point, and I'd bring them over in and I would say like, Hey, step through this code with me. They'd be like, whose code is it? Oh, it's. And I have no idea what it does. All. I know is it does the, this is the outcome I'm trying to get outta this coat and it does it, I just can't, I don't understand how I got there, but I wrote this like six months ago yeah. Yeah. So I, I'm a big fan of bringing, so if you're on a shop where you're developers develop something and, and another group is basically gonna support it, like operations or production support group, I'm a big fan of bringing those guys in during development so they understand how the code is written. Sure. And they would be very quick to point out, , when something is not obvious. Right. Yeah. Um, I, I think it just always contextual as well. It depends on the language you're using. Yeah. Again, , I could talk the whole podcast on this topic we should have a podcast particularly on, we should, we should. Let's make a note of that. I can think of somebody to bring in for that too. Okay. Okay, good. another hard pivot since staying in line with our potpourri uh, theme of the podcast is I recently was asked, how do you work with multiple products that operate under one suite of products without cannibalizing any one of the products? I feel like this is a. Particularly fragrant piece of the potpourri. They're all fragrant. But this, this one has a nice nice aroma. How to work on multiple products. Products under one suite. Under a suite, single suite. You have multiple products. They have synergy with one another. Maybe they use similar data, or maybe they use the same data from the database or whatever, but they don't cannibalize each other. Yeah, I mean, what, what immediately springs to mind immediately is you know, product suites like Microsoft Office. Yeah. Right. And you have Word and Excel, et cetera. Different part of it. Actually, actually, Microsoft Office is a great example because in all the office tools, you can make things bold, italicized, change the font, do whatever, delete, copy, paste. Like you have some functions that are available, so that, that's a great example. from, from that perspective, how to do this. That's the, that's the topic here. How to do this, right. How to do it. Yeah. I, I, I think one is to really recognize, first of all, the boundaries of each of the two products. Let's just take two for now. Sure. It can get complex. Sure. Uh, A and B, let's call 'em A and B. Yeah. And to recognize the boundaries of intersection, right. On this venn diagram of A and B, like, , how close are they? And, and then the degree of overlap between those two. Right? Yeah. So I, I don't mean in just in, in that plane, like in a Venn diagram. Yeah. I mean, how much truly is shared for the customer when, when they look at something, will they even see B when they look at product A? And, and, and then what is your strategy? Do you want to give each product characteristics where they, they look like they're standalone, but they're part of a suite? Yeah. Or do you want commonality across them? Like in, like in office, right? Yeah. Uh, Microsoft office. Yeah. Every ribbon looks the same when it comes to simple functions, right? Mm-hmm. like, like you said, you know, bold, italicized, underlying, et cetera, and all the shortcuts are the same. Do you want that or do you want uniqueness, but the products are part of a suite? I'm trying to think of a, a suite like that, but I can't come up with it. No. Microsoft office is a great example to stick with, like the stick with word and Excel. One is basically for replicating books and the other is replicating tables for some reason, like tabular data, basically working with data. If I'm gonna attack this subject that we're talking about now, not multiple products, not cannibalizing each other, I would say first of all, segment your users for each application. And if the users for the applications truly are the same, Om & Brian's software development company, the infamous that we might sell tomorrow. So you better keep your resume polished. if, if we develop two applications, both for people working on word processing documents and they're separate applications, what the hell are we doing with our lives? This is why we need to sell the company. No, seriously though. What, what I agree with you. This is what I was trying to say with the overlap, right? I, I'll give you another example. There's a stick with word in Excel. Both of these products need the ability for the user to print. Yeah. Right? Right. You wouldn't develop that twice. You would develop. A module that prints, you know. Sure. And then just bolt it into each of those. It's the same module. Right? Right. so how does that answer this point? Well, you're not cannibalizing one product doing it differently here and here because that's a sour UX for the person to have to remember that they have to, you know, hit control function, alt p in one product and just control P in another one. Right. It should be a consistent UI experience for them where you ask for them. Sure. That is one way, but cannibalizing the other here, here's where my head is going with this question. Right? Yeah. I'm trying to stay with, with Word and Excel, but any two products when you have a piece of functionality that's not core to that product and a piece of functionality that is not core to product B as well. A and B. And you're developing those. Yeah, just for those two. that is when you're cannibalizing because, you're basically taking away the need for a user to even get to product B. If they can do some, or even if it's awkwardly some things in product A, they won't buy you product B. Right. That's the cannibalization to me more than anything else. And limiting your opportunities there. If I was a product manager for Word and I was like, I want word to be able to open any Excel document and show it in the Word document the same way you would show an, an Excel, I would expect my director or product or whatever, or you know, product officer or whatever you have in the organization to be like, why, why would you wanna do that? Well, it sounds like a waste of time. Why? Why don't they just use Excel to opening Excel files? Or, or for word to process all of the formulas that Excel can process, which it does very poorly, by the way, . Um, yeah, and, and this is where I think you had that middle, that kind of gray area where they came up with what did they call them plugins and stuff like that to be able to do something. Yeah. If you're gonna support plugins and you're not charging for them anyway. You know, what, what are you doing? I, yeah, yeah. It's, it's a, it's a gray area. I don't think we've got clean cut examples with word and Excel with cannibalizing products. I think you were, you were onto something when you said, identify who is your, you know, who is your user persona for each one. What I want to get from this topic before we get out of this topic, before we pivot to something else, is all, all of your products have to connect all the way back up to your corporate strategy. Amen. Or multiple strategies. Sure. It could be more than one. Yeah. And then your strategy or strategies, your strategy. empowers and informs the product vision. Your product vision leads to goals and your goals create the roadmap for your product. Hopefully all of your product goals are not the same for all your. Yeah. And hopefully your vision is not all the same for all your products. So if, if your product vision for ev, for Microsoft Word, Microsoft, Excel Vizio, whatever anyone use Vizio anymore If, if all of those visions corporate, you know, strategies and product visions are all boiler plate exactly the same, you have a problem. Absolutely. You should seek to solve that problem first before we're dealing with this question. Yeah. You have product fuzziness. Yeah. You have a, you have a real problem. And, and then, and then I would, I would take this to the next step, which is hey, let's look at metrics. Look, users that use word., are they looking to deal with tabular data? Are they looking to deal with tables and formulas and whatever? Probably not. Users that use Word are looking to write books. They're looking to write write reports. They're looking to write documents. They're looking to long form text with paragraphs like they were read in a book. Is that the vision because of the vision for Word Over Time becomes Well through the data? Oh boy. I don't normally introduce new ideas into the podcast, but when I do, it's nearly an hour in. I love that meme. Hey you, through our data we see that most people that use Word are embedding tables in the application. So we need a new application that specifically deals with tables., we're gonna call it Excel. Here we are. Welcome to 1993, right? Yeah. So I think you've just gone somewhere where my head was going in terms of cannibalization, we're all familiar with products that have a freebie version, and then they put the carrot in front of you and go, sure. You could do this, do this, do this. Oh, upgrade to pro. Sure. Right? That's one way of making sure you have product segmentation. You don't, you don't cannibalize the one product Sure. By having, you know, segments, right. For the free one, yes. You give them some things that actually work great, but more importantly, you put the lolly in front of him, as we say in England, um Right. Dangle look at it to say, you can do this too. Isn't this fantastic? You can do this. It's just $2 a month or whatever it is. Yeah. and then if you wanna do a little more, then it's only $10 a month. Right. Yeah. But yeah. But that, that decision. to go with a different product order to, to, to split out this piece to a different offering that is a data-driven decision. Let's say that like, oh, well 45% of people use Excel, use it to make grids, which are just gonna copy paste into a. and publish or whatever. Like, okay, well that's that's data that we didn't have before. Maybe we, maybe we wanna make the import from one product to another. Uh, a big thing. Or, or maybe we gonna wanna give this some kind of automatic wizard functionality or what?. I'm a wizard.. You need a hat? oh man. Oh, speaking of Wizard. If you like our podcast on Wizards and Lizards, you should subscribe to our new game. Oh, nevermind., your point is extremely valid. No, no, I mean, the point is like, if you ha if you like, if you're even gonna create a separate product, like there should be data leading you to, how did that product get created in the first place? I know, I know. We start, we started with Word and Excel, which is probably terrible examples. Cause those, those pro like, there, there probably are people listening to this pod. Actually, statistically, most people that listened to this podcast were born after Word and Excel. Both were products live in the, in the ecosystem. Them. Yeah. Yeah. And, and I'm one of them. Yeah. I absolutely agree. So I think the point you make , no, we're not . I'm very young. What am I talking? No the point you make about these part decisions being data driven is extremely valid. Sure. Right. The only time you might wanna venture a product out in the field is just to gather data. Sure. Right. In in that case. Yeah. I mean, that's like the initial state where you're looking to see what will stick you know, do all of the, use all of the tools that you disposal to gather data and then use that data to formulate a strategic direction for the product. Sure. Um, but you know, when, when it comes to, to cannibalization., I don't see how you get away from trying to figure out who your core personas are for users of each of the products, and then looking at those in two different ways. One is, can we make sure that we can still sell both products to two different personas? That's one question. And the other question I think is the opposite of that, which is, you know, if I make this product, the, the, the Swiss Army knife of everything, then now who's my customer? Right? Yeah. That, that's tricky sometimes to, to pull off. Well, if you, if you make your product the Swiss Army knife, now the problem is not like, Hey, well, I, I could like, the pushback against what you just said is everybody who wants both will want your product. Well, that's not true because now your product is gonna be crappy at both. Like, it might not be crappy. It might be good at. one thing for feature A and two things for feature B, whereas another competitive product is like eight things for feature B, right? Because you're contact switching your development team now between feature A and B cuz you like, like if we go back to Microsoft Word slash Excel. Okay, I'm gonna have a great word processing. Application and I'm gonna have a great spreadsheet processing application, or I'm gonna have one crappy half a Word document application and, and you know, a tabular whatever record application, which is not really super great either. Or like, that's probably the cleanest way to get this point across this is say, Hey, do you wanna have one application that kind of crappily does both, or do you have, you wanna have two applications that, oh one is fantastic for formatting, whatever, and it's like just bad at tabular, whatever. Like you add the tabs to your Word document, you can never get the columns right. You, you know, it's difficult to select the entire column cause it, it, it messes up and selects the entire thing and it's time. That's right. I've used Excel and Word in my life,, or do you want to optimize for one audience? And, and maybe you can do two or three things, but there were a bunch of applications over the past that kind of partially did both, and they're all gone Now. They're in the product graveyard resting permanently. Yes. Yes. That's the quickest way to obscurity, right? Because to your point, your competitors will definitely eat your lunch because you're not doing anything, you're not excelling at anything. You're kind of doing okay on this and not so good on this, right? Yeah. And, and that, that brings us back to where you started, which is know your audience. Brings us back to what I call user segmentation, which is who are the users that wanna write Word documents? who are the users that need their data shown in a tabular format in, in, in tables and and are those users the same? Oh, no, they're not. Oh, these people over here that need tables, they're mainly fi finance people, accountants data scientists data analysts, whatever. And the people over here need word documents are people that write books and technical documents and whatever else. They're completely different. Okay. Well, if they're completely different, why do we even try to. Create the same application for both of them. Let's just make it easy on our development teams and just split our development team and say, okay, you developers go over here and make yourselves experts in this type of user. And, you few members of the development team move over here and split off and you make yourself extras on this. So, so what we end up with is we end up with a development team dividing and team A becomes expert at people trying to write full length documents. And Team B becomes experts at people trying to work inside of tabular data. Yeah, yeah. So the before, the two people who are about to type in kind of nasty things. Oh, I thought you could say the two people watching the video. No, no. There's at least eight. Um, no, before those two chime in. Let me just say what is, what you're not proposing is you're, you're developing two distinctly different products. You're, you're developing. Two products each aimed at a specific purpose. However certain modules are shared, like printing. Sure. spell check, whatever. Those kinds of things. Um, save as PDF is another example. I'm, I'm, wait, let me stop you cuz I'm not clear. Uh, you're saying I am proposing No, I'm saying you're not. I I, I am proposing different applications, but I think what you just said is, There will be shared functions between both applications. Now I'm saying both the applications, but I really, what I really mean back in the spirit of this bullet point was in our suite of products, we're saying everything in our suite of products should have these text functions, these print functions, these whatever functions, everything in our, our whole suite of applications. But the, each suite of applications is for a specific user, right? Exa. Exactly. Okay. So these common functions, they are enablers that allow you to put these different. Products and call it a suite. Mm-hmm., because people can easily use one having used another one. Sure. Yeah. Right. So their, you know, barrier to entry is much, much, much, much lower their learning curve, all of that. That's how you end up with a suite that sells well. So those people that are writing lots of pros and the authors Right. Using the word application. Sure. Should they need to do some occasional spreadsheet type work? Yeah. They, you know, they can, they can buy that other module called Excel and they'll be familiar with basic functions, how to open a document, you know, how to print things like that. How to save, yeah., yeah, that makes a lot of sense to me. The last thing we have was, estimates and burn down in hours, but we can, we can turn into a separate podcast. Agile podcast questions at Gmail. We have we have not said that in a long time. We have not, oh boy. Beyond estimation. If , you live in the area, Tampa Bay area, let us know if you'd like to come on the show and argue agile with us. And we sincerely hope you enjoyed this episode of agile potpourri