AA132 - Who Should Product Management Report Through?

Recently I threw out post on LinkedIn because I was looking for stats on how many CPOs, VPs of product had actual backgrounds in product management, I was having difficulty finding any information about where they came from in their career before they became Chief product officer or VP of product so I ran across this post, from Jason Knight. He's a product consultant. He says, PMs, which of these would you least like the product function to report through? Report through. So he lists four positions. He lists the CEO, the COO. The CTO and the CMO are from for everyone who can't see the screen right now. This basically is a poll of which C level position as product you do not want to report to coming in number one at 44. 4 percent was the CMO, the chief marketing officer coming in at a second at 27. 4 percent was the COO, the chief operating officer. Followed up by the CTO at 18. 1 percent and the CEO at 10. 1%. Yeah, and that poll had, 1, 370, or so responses. So, pretty extensive, I would say. That's not bad at all. So where should product be organized in your hierarchy or the organizational structure? That's really what we're trying to delve into today. If you're a product person, I am sure you're interested. If you're not, I'm sure you're still interested because... You love arguing at you. That's right. That's right. So let's see. Let's see if we can argue about any of these things. That's that's the poll. I thought it was interesting and it's the closest thing I've found directly to my answer Because I still didn't I still never found an answer like I searched around no answer we're gonna save that topic for a little later in the podcast. And we're gonna start with there was a whole article attached to this poll. And, it, it was actually pretty interesting. As he walks through, he gives his opinion on each individual position and, he doesn't really go pros and cons. So I think that's, I think we're going to talk about pros and cons. Why don't we walk through his article until we get to the first con and then we'll, we'll pivot to talking about pros and cons. That sounds like a plan. Yeah. Cause we are Arguing Agile as we're going to talk about pros and cons. So you get double the value. so we'll come back to the article. After he shows a poll, he says, it's fair to say that most people's judgment is going to be clouded. Clouded by, quote, that one executive. That's right. By your one bad experience. I want to start arguing, but I also want to get through the article so we can get to the actual meat. We can maybe do both the meat and the potatoes. Well, I want to argue because like how many, how many quote What one executives do you have to work for that are bad before, you know what I mean? Is it all anecdotal evidence? If every single, workplace? Whenever you give out the advice, like you should keep your resume updated, like that advice gets given out a lot, especially by yours truly, because I believe it. So there's a lot of, a lot of variables there. Alright, let's, let's push on. Okay. He says, who product manager reports through is a statement. Which I, I'm, I'm kind of with him on this one. I kind of feel it is a statement. He says, they have an outsized impact on product management and how it's run through the organization and they have a, and they have a big impact on what success looks like. I agree with him on all those points. I'm going to say the other side of it, which is it depends, right? Because if you are. A, if you're a new company that's just formed, right, you got maybe some VC money, you don't really have product in place, right? What you have is a very enthusiastic, leader. They may well be the CEO. And when that company matures... Over, let's say, 2, 3, 4, 5 years maybe, and they grow. Now you have a proper product function. We might talk about that at that point. So where products should fall in the organizational hierarchy. But if you've just started, you bet if they bring you in, you're going to be working for the person who founded the company and got the VC money. we're going to go into the pros and cons of working for the CMO, I'm gonna read his section and then we'll kind of respond to it and we'll talk through it. Okay. So he says, because the CMO has a traditional marketing background. All about brands, brand and events. They really don't get product marketing, let alone product management. And they're just really desperate to have something to give to the content marketer for the next LinkedIn posts. They push to get flashy, but ultimately useless features onto the roadmap with a hard deadline of some conference or other. They refuse to talk about tech debt because they can't market it. The first half of the paragraph I'm on the fence about, the second half of the paragraph, I, I will push all my chips onto the table, because I'm all in on that one. Pushing to get flashy and useless features onto the roadmap with a hard deadline because they're going to a conference and they're bringing all their gear and they're going to be there in person. I've seen that a thousand million times over and over and over again. Always happens. Also, the second part can't talk about technical debt. I was at a company once where the product was built on a mountain of technical debt. And, the marketing staff, I remember the CMO of sales, marketing, , whenever the conversation would take a technical turn, because it was required to talk about some customers and why certain features couldn't go out in front of some other features or, or why we had to go and refactor some process or whatever in order to get critical feature out by these arbitrary dateline. Well, we can't hit that conference because you know, this table was built with no indices and we have to write the proper indexes because when you load this many users, blah, blah, blah, blah, blah, blah, blah. And they're like, what are you talking about? Right. I am laughing here because I've actually lived this. scenario. Yes, exactly this. We are a conference in New Orleans, Louisiana, and during the conference, we're doing some dry runs at seven a. m. As one does, because you know, your first prospects are coming in at eight. So you gotta make sure everything's lined up. And sure enough, Things aren't working as they should. What do you do in this scenario? You have a few choices. You can cancel the appointment that the prospect has with you. Heaven forbid sales isn't gonna let you do that. Your CEO, CMO, whoever, no one's going to let you do that. Plus there's this thing about. Pride, right? You got to make sure it works. So what do you do? You have somebody who comes in, logs in from the back end and does things. Essentially, folks, this is classic ignore the man behind the curtain. It doesn't have to be a man, but you get my point, right? Long story short, we landed a, a major account overseas, and by the time everything was done and the contract was written, all of this stuff that didn't work at the conference was figured out, right? It just happened to be that tech debt scenario. Now, knowing that we were going to win this large contract, we focused on it and we delivered a successful, project in that case, it was a project. I would say this is actually quite legit, right? It's, it's just what they know. But, marketing folks, if they don't know technology, What happens now? What happens? Like, do they, do they owe it to themselves to learn about it? Or does the team, the technical team, owe it to themselves to educate them? Or is it a bit of both? Well, let me, let me step in now to be the arguing agile person. Of course. To say, what about all those people on the internet that are saying you don't need to know about technology to be good in product management? B because... I already know you're about to, you're about to hit me with the baseball bat of these people don't know product management and they don't know technology. So like how many, how many things can you not know and still be like I was going to say useful. That's not a great word. Useless, still not be effective at product management in any way, shape or form because you still have to do. Product management at some, in some way, shape or form, you still have to do the core of product management. Yeah, absolutely right. And this is, this is, I feel that the CMO, if you work for a CMO, like that's what this category is talking about. If you work directly for the CMO, you basically are signing up to be the feature factory. And there's, you will never, never break out of being in a feature factory. Because you, you're taking your marching orders directly from sales, potentially from marketing. I don't know if one is worse than the other. I really don't know. I could go either way. But I'm also the guy who's lobbied on different podcasts to say, if you're a product manager and you've not built a bridge to your sales organization, Like you're partially to blame in that, in that situation, your, your responsibility is to get with the sales people who are most likely, especially if you're in a place where you don't have founders anymore, they've moved on or whatever, your salespeople probably. Represent the people that understand the customer's problems. The problems that the customer is trying to solve, their business problems, the deepest. So if you haven't built that bridge, folks, guess what's going to happen? You're going to have power dynamics at play, right? And you're going to have whoever is, quote unquote, wields more power is going to run, run right over the others, right? ultimately, here's my take on this, I'm going to cut to the chase. The product people, the product marketing, especially marketing people, okay, they can have all the bases, everything lined up, etc. But guess what? Who's selling it to the paying customers? Who's paying your wages ultimately, right? It's the salespeople. So you are a team of Marketing sales and I'll say technologists if the three of these teams cannot work together, nothing good can come out of it. Right? The other thing I want to tell you is this. I've worked for companies that have had no marketing. function, right? There's been nothing in the organization. There's nobody with the title, the word marketing in it. Nothing. We had sales, we had development, and we had support and that's it. So that's where listening to support right, especially from salespeople is absolutely critical because guess who listens to the customer's issues every single day? It's your salespeople. Our top three customers would call us between the hours of 7 a. m. Eastern and 7. 30 a. m. Eastern. Without fail two to three times a week, and it wasn't until we formed a good relationship through the support, the support department with these folks, they told us we got you on speed dial. Yeah, we have to call you this many times for you to even listen to us. That spoke volumes about our responsiveness or the lack of it, right? So I just reason I go into that anecdote is to just point out it isn't one or the other isn't. Six of one, half a dozen of the other. It is the entire organization has to put up a front that is real. It's not a facade. It is real. Right. And, and make sure you listen, truly listen to your customer. You don't just hear them. Listen to them. I feel, if you really, I mean, empathy gets around a lot of this problem. Right. I guess my final word on this too, right? Yeah, I will say my final word on this too is. 44 percent , of people say they don't want to be here. If you're in this position, and there's really, not a lot you can do, and you're trying to make the best of the situation, Build a bridge with marketing. You know what I mean? Go, go to all their, try to try to join all their calls, try to, learn what they do in marketing. I mean, you're going to have to try to inject some product management at some point to get them okay with ambiguity and to get them a little bit dialed away from. The whole date mentality of, I must have this by this date, that kind of stuff. Yeah, I think you can have a really fruitful dialogue with people about the dates too, right? You can make any date you want, right? It's just what you're getting for it. So, together, yeah, I agree with you. Form an alliance. And don't forget salespeople get a lot of flack, but they are the ones that are bringing in the moolah, right? Getting those signatures on the contracts where we all get paid. So they're part of a team, work with them. If you ignore them, then you're going to have this division, right? Us and them isms, whatever. You don't want that. The other thing I was going to say about this topic was if you've not provided your sales team with a roadmap off of which to sell things, that that's an issue. Like, of course they're going to be lost if you've, if you've not. Clearly started defining, these are the big bets we're going to make in this order. You know what I mean? This is how we're going to deliver on the strategy of the business. So CMO, right? Why is it good to report through the CMO if you're a product person? Oh, I can get, I'll give you the pro of this one. Sure. You know, you want a good, a good, good hot take on this one? Sure. If they are open to you doing your product management thing, and if they are open to you... Bringing them the roadmap and talking to having your own relations with customers and having your own people to go to and you riding along if they are cool with that. Knowing that you're the one that kind of makes things happen and you empathize with them and you. Figured out how to, how to work with sales. You've now aligned again, assuming the type of organization where you're aligned under a CMO is also the type of organization that sees the sales department as a revenue generating department and all the developers as the, the sink of money that doesn't bring any money into the organization. That's, you know what I mean? They're just a cost center. The old IT cost center. Like, I know, we know that model is ridiculous. But if you, now sit with the team that makes all the revenue. Life is golden. You're probably cashing checks and buying yachts. But you're also living on cloud nine. I agree with you on a couple of things. First of all, if you're aligned with the CMO in terms of your reporting hierarchy, and the CMO is enabling you, that's a good sign, right? In other words, you're not dictated dates and told, make this happen, bye. this date or else, right? That, that's one good sign. The other thing I want to tell you is this, if, is the CMO dictating certain other things about, product or are you saying every product is unique, which it is, every product is unique, right? And you take that to the CMO and they actually back you. They say, yes, you're right. Have you done this and this and this, how can we help you? If you're seeing that kind of support. Rock on, my friends. You are in the right place, okay? On the other side, because we are Arguing Agile For the other 63. 6 percent of you. Yeah, exactly. 60 plus, percent of you, if you're in those scenarios, please rethink your work your purpose for being and yeah, well we always say on the podcast keep that resume up there resume updated Oh Like learn where you can win the battles you can You know, lose the ones you can't, try to learn from them and keep their resume updated. And not in that order, by the way. Oh boy. So that's the CMO. How about we, we move to another way that product is, kind of structured within your work structure. We, so we talked about the CMO. So what he says, reporting to the C O O. So here we go reporting operations because everything is about processes, processes, everything's about processes and trying to make things efficient. They want a dozen dashboards approved that the engineering team are all quote on track and to quote and want to measure engineering utilization per Jira Epic. Oh, and by the way, only approved people can change JIRA. They dislike experimentation because everything has to be a sure thing. Otherwise, we're wasting time and effort. And they're very keen on customer special projects because they're chargeable. So in everything you've just read, what I'm seeing is just dollar signs, which is So let's just kind of unpack that a little bit in terms of the cons, and then we'll get into the pros, right? So in terms of the cons. Everything needs to be on track because optics is everything, right? If you say you're on track to deliver something, you will get no more trouble from anybody. Nobody's going to call you into their office and say, Why aren't you going to deliver by that date? So this is what I call watermelon reports. They look great because they're green on the outside. But hey, got one open. They're red. So if you're doing project management, You know who you are? Rag reports, right? Red, amber, green. Everything's green. And maybe we have this one thing amber, but I got it. Right? Great. Except, sooner or later it's gonna catch up with you. And then something's gonna turn red. You may not even turn it red. Someone's going to turn it red for you. So, that is one of the things I see here reporting through the , C O O chain of command is everything has to be operationalized on a date. Right. Like, date, date, date, date, date. Yeah. And, one date slips. It's like a it's like a house of cards, right? You move one card and the whole thing comes falling down. So If you're late by one date, that's c o o Organization is going to be on you, get on the brakes. Right, yeah. This is every culture I've ever worked in where it's like some, when something slips or something, it slips. Like, all the dates by the time they're handed to the team are already in the past. And then when you miss a date, invariably, and when you miss a date, now someone's got to get yelled at. Yeah. Like that, that's this, that's what we're talking, that's the culture here that we're talking about. Like, this stinks. This, I've been in this culture, it sucks. It absolutely sucks. It truly does. The COO probably has a project manager or two that are their right hand person. They're quote, eyes and ears. And, they make you fill out a bunch of reports that are all nonsense. And that's his culture. Every C. O. O. That I've ever seen. They have their own system that is completely disconnected from the system of record. That all the employees use, and that's where they keep a status in, and if the status in their system disagrees with the status in the real day to day system, then there's a big blow up, a big problem. You know, some people might be listening to this and say, there's not a problem, whatever they have on their record. is right. And whatever you have in your system is wrong. And that's fine. And that would be, that is also, I've seen project managers that report to CEOs like this, walk up to the team and say, when will this sprint be done? When will this feature be done? When will this feature be done? The feature will be done when the sprint closes. Well, when will the sprint close? Well, the sprint closes in a week and one day, because our sprints are two weeks and we're only a couple days into it. Well, that's not good enough. I have the date as this. So you're going to hit that date. Make it happen. Make it happen. Yeah, yeah. And like, now, who are we going to question? Because now we all work for the COO. So basically, there's no one to question. That was a real place I worked. I certainly agree, I've worked at a place or two like that too. COOs are always living and dying by two things. Right? Dates, schedule, and budget. Dollars, right? As long as... If you do slip a date, first of all, let's just take those in sequence. If you slip a date, it's not necessarily going to please them, unless you tell them, hey we slipped a date, but... It wasn't our fault. Right? It was someone's fault. The customer said they wanted this other thing and, they wanted this line over here on the screen in pink instead of fuchsia. So, guess what? We missed the date, right? The comeback almost immediately from that org is great, raises change request. How much are they paying for that? That's right. How much do you think it's going to take to change the pink color to a fuchsia color? Two minutes? Okay, charge them a day. Because everything works in an increment of a day. I a hundred percent agree with everything you're saying, but also, since this is Arguing Agile, I'm going to pivot immediately into the pros of working for a COO. Absolutely, please do. The pros of working for a COO, I will tell you, the advantage here, if you can think of it as an advantage is you get to sharpen your project management skills. Cause like, again, if you're not fighting, if you're fighting with a dull blade, you're going to get cut up. So you better have a sharp blade too. So you get, you get a lot of sword fighting practice. That's what I'm saying in this category. And also you get a lot of practice, like you were saying, like the numbers, the money wins at every single argument. So you get a lot of practice translating into financials. Your argument points. So it it, those two things, and again, that's what I got from the culture where we were like this, I got those two things. I know how to capitalize a software development project, the easy way and the most conservative way, both for internal use and external use software. And I can do that stuff out of the system. I can set it up to do, with no overhead. So it doesn't impact anything. Like, nobody has to do anything on time sheets or whatever. I can do that stuff in my sleep. I've done it at a couple different companies and I learned how to do that because I was in this situation. So there are pros here. The pros are... You start thinking like operations thinks everything has a finite date. Everything has a , deliverable, and every change has somebody waiting. You know, and, and I work with some really great project managers who, will, they will never let you out of the room without pinning you down for a date. I want you to commit. You, you will go on a line item on the Gantt chart. And I will put a date next to your name because you've committed on this date and they will write down the whole exchange. I, yeah, absolutely. Look, I agree. I also want to add a little to that, right? Yes. And if you're watching Julie, so, yeah, yes. And Brian, COOs, we're just, we're just suspending the whole working agreement. This, I know we did. We'll come back to it. It'll be like a piñata. We'll keep hitting it till it blows up. That's right. Listen, listen. It's like a piñata. It speaks Spanish and we don't understand it. Exactly. So COOs aren't just talking about dates for the purpose of hitting dates. They are actually delivering, right? Your customers are paying you, your company, ergo you, your paycheck, right? Based on meeting or not meeting SLAs and SLCs. Work with your COO to see if you can meet those. Because if you can't meet them, it's akin to not getting paid. I worked for a very... Small startup company that lasted for about nine months and then they blew up like exponentially, right? But those nine months we were holding our breath because we didn't know if we're gonna get paid at the end of the two weeks And that's because we were going about things by the book But also we had you know, the ops guys saying we talk to customers every day Here's what they need and here's why and this would have to do with regulatory stuff in Europe So, you know this had to do with Governments getting together, blah, blah, blah, blah, but long, long story short, if you're not aligned with those dates that matter to your customers that translate to dollars coming in Good luck. I like this category because the COO is the direct path to money like that. That's what's at the end of their rainbow. And if you can find a way to. Live in this environment and you can follow them, you'll get good at, at the direct path to money. That's, that's what I like about this category. Although, it is a dystopian hellscape. Listen, I want to talk about the COO role as the last thing, and that is the effectiveness it has of connecting your organization with your customer, right? If you don't do that, why would they trust you, right? You miss the date. Okay, everybody gives you the benefit of the doubt. You miss the date. Especially if you can talk smart and go, this is why. You gave us new requirements, right? Okay, that's only going to get you so far, right? And so when the customer says, Well, we didn't know what our requirements were nine months ago when you asked us to sign those off in blood, right? They changed. So, guess what? It's either you or this competitor of yours or this other one that's going to play with us, right? So, listen to those signs. All I'm trying to say here is working through the C O O, keep your ears open, right? Listen to your customers, listen to those cues, listen to those signals, and Either react accordingly or feed them up to whoever needs to react accordingly. The other pro that we also didn't talk about is you are connected, I mean the operations is connected to every, every, everything, everybody is connected, they come internal, external, whatever, vendors, whatever is connected to operations, so you do have an advantage there with potentially a, potentially that some of these other ones do not. Let's move on to the CTO. So, he says, Because they only care about, what can be built, not why or whether it should be built, they have no real understanding of the business value of the product management team, or even of talking directly to customers. The product management team, We'll spend all of its time talking to developers and having arguments over technical debt and shadow roadmaps. Wow. Okay. So first of all, this sentiment is somewhat recent, but it doesn't reflect. The latest thinking in, in and among CTOs. If you're a CTO, are you only concerned about what can be built? What is only possible? Or are you thinking about the why? Right? Not the how. I'm not going to worry about the how. In this, in this discussion. Lately, CTOs have been going through this, this kind of modality of thinking where they say yes, we know what can be built, right? Technology is what it is, but why should we build it? So I don't fully agree with this. This might have been true maybe like five, seven, maybe even, older, seven plus years ago. Nowadays, you got CTOs that understand the language of business. They're not just simply there saying, Well, we're the, we're the pointy heads, right? We're going to tell you what needs to be done. This is how you do it. And to heck with the rest of it. No. That, that used to be the case by, by far. But not anymore, right? So product management team will spend all this time telling developers If a CTO lets that happen without having them, in the loop, they're not really a CTO. You think so? Because, this, this is in line, although my experience working for a CTO was, ago. It wasn't quite five years ago, but it was a couple of years ago. I did have this issue with the, the CTO they were more fixated on solving, architectural runway, technical enablement type of, tasks than they were talking to customers If you ask them their three year plan, their three year plan probably would be something along the lines of, of where the, it probably would be, let me think about how to say this without throwing people under the bus. I don't know why I'm trying to defend them so much because the CTO's that I work with they were the most petty C level executives I've ever worked with like they played the most games like games with shadow roadmaps and games with quote resources when they didn't like certain features, they would move people off of teams because they owned all the developers and they could do that to just to undermine, different things that were, started by different people. But, but what I'm trying to say is. rather than looking at the entire business as a system, they would look at it from the perspective of, the, the technical debt that we had to overcome in order to be more free to move around in the future, which is sort of looking at it from a, I don't know, it's sort of looking at it from the bigger picture, but also it's looking at it from the bigger picture from the lens of what you control, not, not trying to take the perspective of the whole business, so I sort of agree with what he's saying that they were kind of, limited in their vision. The CTOs that I've interfaced with. Yeah, I couldn't agree more. I think we both align on that because they are really looking at what I can only describe as turf management, right? So they're looking at their own turf and saying, this is what I can control, this is what I'm going to do. And that's really the extent of it. Now, unfortunately, I say unfortunately because in a lot of technology led products, they have a pivotal role to play, right? They can be the good corporate citizens and educate their clients and potential clients in the nuances of For example, cybersecurity, for instance, right, what can happen if you did this or didn't do this, right? As a CTO, you should be thinking about this. If you do that, if you're holding, these breakfast sessions where you have CTO CEOs, all the CXOs coming in and discussing these things without an agenda of getting something out of them. If you're not doing that, I don't know. As far as tech debt goes, I only have two things to say here. One is, CTOs always want to paper over the cracks, right? Because guess whose organization it was that led to the tech net. It's theirs. The devs, the testers, even right sometimes that they all report into the CTO, so they don't want to admit to the fact that we delivered a subpar product. So they're going to say, it's fine, but the requirements changed or whatever, right? The other thing I want to talk about tech debt is they do not want to go backwards and say, Hey, listen, last three sprints, we had all this stuff that we accumulate. Let's go fix that. Let's spend a sprint fixing that. Nobody does that. The only time they do that is when they have the highest paying customer or customers scream blue murder and go fix this and then they go, Oh, the customer's screaming. We better fix at least 10 percent of that. So we can like, put them at bay for little while. That's how it goes. Unfortunately. Yeah. I, I agree with some of that, but, not all of it, but also, it's like, there was so much of it. I can't remember. I can't, I can't, I can't, I can't go back and red pen. No, I, again, I, like the CTOs that I work with are, are. Are very different from the person you're describing. So like they're, I've just not had that experience. You're lucky, man. I've just not had that experience. Oh, no. Lucky in the other way. Like it's, it's, they're the ones that have had the shadow roadmap of like, we have the roadmap and we've gone through this big exercise and making everything transparent. And they've, they participated and they, they sure not up. They showed up there and they nodded up and down they said. And there's a product organization. And at all the meetings, they say the right thing and they throw out the old Bill Clinton thumb. But then when it comes to actually doing stuff like They're, they're going to the developer Hey, buddy, just do this one thing right quick. It's a little tiny change. So they have a shadow roadmap they're getting what they want into the product. And then now we're up against the annoying product management of like, Well, you just gotta do your job through influence and be the best person you can be and build bridges and burn bridges and blow up bridges So here's, here's what I say about that, that oftentimes when you look at Your road map and you look at the items that your CTO has inflicted upon your road map. I can't think of a better word. You'll never see him in the road. No, you'll see him because because the developers are working on it. So hopefully it's in your. No. Negative. Negative. It's not in the backlog at all. Can you, can you look at PRs? Because that's where they are. They don't appear. PRs without work items. That's what they are. Explicit approval to just go ahead in any way, right? So Two things I want to say about that because we're talking about this from a product perspective If you even get a wind of this stuff that's going on like, oh, yeah, this might be happening Just question one thing Question the opportunity cost. Your devs are working on this, Mr. CTO. Ms. CTO. What are they not doing? To deliver customer value, right? And, when, when you have that discussion, and you see that person Get a little warm under the collar. Just ask, how much, how much time, is being spent on this activity exactly? Because I can tell you what I would rather get done in that time. It's uncomfortable to have that conversation that you got to have it. Again, it's, it's uncomfortable to have that conversation unless the person realizes, unless the person... Who worked their way up the development ladder to CTO realizes that they're in the position of CTO and you are not because again, I've also had this discussion where they say, listen, all you have, you have all the developers in my department dedicated to your project. All two of them. And they're, they're all, no, you have, you have a certain number of developers, whatever. And they all have. 85 percent utilization, of course, the other 15 percent I can give them whatever I want them to do because I'm their boss. Yeah, yeah, ultimately that's true. And that, and also in environments like that also, the leads, like the technical leads, solution architects, stuff like that, they're not assigned to individual teams. So they 100 percent float between teams. So they're like 0 percent of their utilization is guaranteed to your team. So they, they also can be agents of random chaos. Yeah, yeah, yeah. Full time, 100 percent of their time checking in stuff into your product, and you don't know where it came from. Still in the mechanical craft. Agents of chaos, so, again, we're beating this up because this is my trademark, that one Exec in my career. so 18 percent of the poll said they don't want to be placed under a CTO. Yeah. This is why I think, right, CTO is a relatively young role, relatively, I mean, it's been only around for, I don't know, 10 years, maybe, really, like not just a title, but I'm talking about. A role as such. Right. So what happens here is we need to look at the progression. What happened in the last 15, 18 years? Some of the CTOs that you see now acting as CTOs are actually people that have gone through, training, education as MBAs, whatever, whatever it is. But they think about the business. Primarily and then technology secondarily that is very rare and it's in its infancy I will grant you that okay. I know you're not talking about people like, you know Zuckerberg or people like that. I'm talking about people that come up Through the ranks, Brian, through the ranks. The more that we talk about this, the, the harder stance I take on the opposite side to say, all the CTOs that I've been coupled with, have this real obtuse, objection to product management. Actually, you know what they end efforts to build a roadmap and to talk to customers and to figure out the path forward through experimentation because, quote, I know what to do. I mean the pros in this category are you can keep that resume updated. That's my pro right there. I agree. I agree. Keep it updated, folks. Let's finish out the pros and cons because the CEO is the last one. Because they're still the de facto head of product and won't allow the product management team to do their job, they're desperate to still be seen as the visionary and every single idea that they have will immediately fall directly onto the product management team. Who have very limited ability to push back. They will constantly complain that the teams aren't delivering as fast as they used to while generally stymieing any effort to help the teams do that. Well, I, I almost want to cut out that last, that after the comma, cause that, that really doesn't even fit. They will constantly complain that the teams aren't delivering as fast as they used to, or as fast as they should. I would, I would alternately, I'd throw that in there as fast as they should. I've been in organizations where they have offshore development and then the CEO is like, Whoa, they should be delivering faster. These features are easy. Or whatever. I've seen that too. Although, I will tell you I'm immediately on the side of products should be working directly for the CEO. And I'm immediately, Yes, some of these things are true. Especially with the visionary who wants to be the Steve Jobs and, they want to pretend they got the greatest ideas, I'll take all those problems, if I'm working directly for the head of the organization. Because again, they're setting culture for the rest of the organization. If the, if the organizational culture they're setting sucks. Of course working for them as product is going to suck. Working for them anywhere is going to suck. Yeah, going to say that. Working for them anywhere is going to suck. Because they want to be seen as the visionary. Okay, we can yield them that. Right? But if you are part of product, here's what you bring to them. You bring them a cold reality of what is the market Fit what is the market need? What is what we know? How much people are prepared to pay for this stuff, right? So it doesn't matter what they think sitting in their ivory tower. They have to understand. Here's what we're spending Here's what we hope to gain from that be conservative. Of course, right in the early days But, if they're not willing to listen to you, I'm sorry we go back to the previous point, which is keep that resume updated. And I mean, the other thing in here that I sort of want to, I don't know if I really want to push back on it. Like, he says He says every single idea the CEO has immediately falls on a product and product has kind of a limited ability to push back. I mean, you have some leeway, armed with statistics. You can push back and say, this is your idea. However, our market potential market share is only. 12 percent right and if each customer can only contribute let's just assume the best case scenario here X amount Therefore project out and go this is what it is now. We're looking to spend so much more Maybe it's a multiple of that to try and get that does that make sense? Mr. CEO miss CEO, right? Does it make sense if it doesn't make sense then? The question can be asked. Why are we doing that? And the second question, I always forget this. What is the opportunity cost? What are we not doing in the space and time that it takes us to, pursue this, right? Somewhere else. Very few people make that visible, to be honest. They say, this is what we're passing up in order to do. It's a safety thing, though. When you're working for the CEO, it's a safety thing, right? You want to keep your job. I get that, right? Yeah. But if you've been listening to our podcast of late, you got to keep that resume up. You also know that speaking up armed with evidence is the best thing you can do. All right. Keeping quiet and being subservient is the worst thing you can do. I mean oh, oh, I know what I was gonna say. You have very limited pushback. That's what I want to say. You have very limited pushback. Listen, I agree because you you're afraid of whatever, losing your job or whatever. I, I get that, but also if you've done your job well and you've fostered a culture of testing ideas. Mm-hmm. and saying Orientation. How are we gonna prove like, okay, Mr. C e o, Mrs. C e o, whatever, you have this idea that if we do x. Then y result will happen. What can we do to prove that in the market? What can we do to explore that in the market? And we're going to try that first to explore the idea. And it shouldn't be anything special that you're doing with them to handhold them. You should just do that with all your ideas. Unless, unless. There is pre existing evidence that this is already the way to go. And, and if it's, if, if, if, the other thing that's not detailed in this article is, if your CEO is the expert, the domain expert, and you are not, product manager is not, CEO is the domain expert, maybe the whole company, I've seen several companies started because a CEO had a relationship with somebody that they ended up selling to. And the CEO starts company sells to the person they had a relationship with because maybe they used to work there as the expert that their software is tailored for now. Yep. So at a certain point like you would test ideas and everything, but also Unless you have those deep contacts and that deep expertise, your ability to challenge here could be limited. So that's, that is very realistic in this category, which is a trade off. So, the, the, the, there are pros here. The pros is, the pros is, the pros are... Yeah. The pros are, the, if the CEO is the one with the domain expertise, you need to ride along for a while before you really can start challenging, exerting your influence, stuff like that. Maybe help them do some basic product management stuff, and help them understand you're, you're, so you're extending their. Skill and knowledge while also they're doing the same for you at the same time. The buck stops with the CEO. So you really, if you work for the CEO, you have a huge advantage. You don't have to go through different layers of the bureaucracy to get things done. You go straight to the top and you're done. You just switched over to the pro side. I agree, absolutely. Listen, if your CEO is already vested in this way that you just described, yeah, absolutely. Listen, you don't have to try hard to convince them that this is a viable, go to market strategy, right? But it behooves you to say Yes, sir, ma'am, this is what we're gonna do, but beware of these things, right? Because when, the proverbial, poo poo hits the fan, you are actually going to be in a better place because you, you warned them ahead of time. You told them, even if they don't listen, you still get fired. Hey, give that resume update. But yeah, you're gonna, you're gonna be able to say, listen, I did my level best to tell you what's going on in the market. The other pro I want to say is your CEO is probably quite well known in the domain, right? So you can, ride on their coattails. So right by by simply saying, look. Our CEO is, James Bond III or whatever, Sean Connery, yeah, he, he's, he was last seen fishing in the river. It's a real term, fishing in the river. Last seen on a rock, yeah. Yeah, so just, just, use their street cred, if you will, but also put in your nuances that are evidence based. Right. On top of that, not only because you want to protect your own credibility, but his as well. If you can do that, and you can survive through the first round of. Getting this into the market, whatever this is. Right. I think you're really off to a good start. I want to skip straight to the end because he, he concludes by. By asking, well, he includes the final thoughts, but we're going to skip final thoughts because we're running out of time here. Our CPOs, the answer to all this. So he says, I'm a strong believer in product management teams, having direct C level representation, right?, it'd be nice to have a rep from the product team on the C suite. So that's, that's what he says in the article. However, he says some business leaders prefer industry experts or quote business people to take the CPO role. These people need to know what they don't know and defer to the product management practitioners, at least some of the time. Or, the other scenario, he says, is senior product managers get the chance at the top table and fumble it because they struggle to connect with the C suite. These people need coaching, training, and support to thrive. Yeah, let's, let's kind of decompose this a little bit. So he gives you two alternatives, A or B, right? Right. Don't know if I agree with that. And here's why. So A says, Businesses prefer industry experts or business people to take the CPO role. Okay, fine. What if you have a really hot CPO that comes from outside of your business domain, but they know the business of CPO. They know how to handle product. It doesn't matter if they were You know, over Mars bars in the past or I don't know, Tesla, whatever, whatever it is. It doesn't matter. They know the craft, right? They just don't know your domain. Give them the help they need to come in and help you. I don't think that's a, I don't think that's a scenario that he outlines as a possibility in here. I'm saying alternately, alternately too. And also Because he only like outlines too. I'm saying this is my third. I'm going to back him up on this one because I don't think I've ever seen a CPO, a chief product officer. Who came from a strong product management, background who had a strong track record of leading product at different organizations. So, so maybe like a director of product someplace or maybe a group product manager someplace. And then they moved up into CPO roles and now they landed at my business. Basically, that and unicorns, I've seen the exact same number of in my life. I can't disagree, right? However, however, this is what I'd say, the art of product management is an art more than it is a science, right? So if somebody has proven their craft, practicing product management in a domain that is not quite yours. That doesn't disqualify them from being a candidate in trying to do what you're trying to do. It doesn't, right? It doesn't disqualify them. They know the core essential skills. Give them the domain knowledge and all the support they need. Let them write as far as they can. And see what they can do. Because you never know. I don't, I'm not from your planet. No, you're not, but that's okay. You're in my galaxy. I don't, I don't, I'm not quite sure if I am anymore in this galaxy. Normally what I see is I see sales people come in who have a large amount, a, a, a very diverse amount of contacts throughout the industry and get tapped for chief product roles in the same way that marketing CMOs work basically, or actually, the other, the, the equivalent is chief revenue officers. I've seen that too. It basically, they hire them with the CPO role, but they really expect them to do the cRO role that that's, that's what I've seen. I've seen salespeople or former operations people get hired and get thrown into this product. I don't think I've, I've, again, I've never been at a company that has a experienced product management person with domain expertise together, who has a successful track record of, product management, I don't think we're saying anything too different. So what I'm saying is somebody has the experience and they come in, at least give them the rope to either succeed or fail. But to your point, yeah, absolutely. I've seen that too. Somebody comes in from outside and they just ordained this role, right? I've seen that. Yeah, definitely. I've seen the cousin of the ceo come in here, right? This guy, 27 year old, fresh out of, Stanford marketing MBA. Yeah, yeah, yeah. So I've seen that for sure. Right. But he's outlining two different alternatives here. A and B. And I'm saying, well, there's probably a C and a D. This product person needs to be informed about product management practices. They need to understand that like, well show me what we've tried. Show me, what the trends look like. Show me some, some, I don't know, show me some, some, some product metrics. I, they need to, they need to be able to speak the language and not speak the language like. You know, hey buddy buy this used car for me speak the language. I mean actually know what the language means exactly Yeah, completely devoid of anything that is very subjective. It needs to be yeah, you know numbers objective I agree with you there. It also means that that product person should not be doing. Yes Well again, the problem with this is I see you know, the the the MBA Processing line sending people from MBAs into large businesses like that, they're teaching These people to speak the language. But then, again, they're made out of paper. And the first time it rains, they completely disintegrate and go back to Gantt charts and whatever. That's my concern with this one. So, I don't know. I don't know if we're I know we've gotten way off topic because this should have been this talking about CPOs specifically, I had to get through this whole podcast to bring up the topic because I've never seen a CPO that I've worked with that came through product management. They've all just been salespeople or operations people or executives, lifers basically who've been tapped to just sit in this chair, which is wild to me because I've, I've never seen that with any other position. I've never seen somebody who, who has never sold a thing in their life get tapped to lead sales. I've never seen somebody who's never used a computer get tapped to be the CTO. that's wild to me. It is, absolutely. So yeah, first of all, look, I concur with that. Ah, CPOs, by the way, that term. Isn't all that prevalent unless you're in the, Scrum at Scale type of, discussions. More tech space, maybe. Yeah, exactly. Yeah, I mean, so if you're following these rigid scaling structures like SAFE, for example, or LESS, for example, right? Where they devolve everything to a... singular product owner that's across gazillion teams. But just, I just want to put it out there because that's a term that you won't necessarily see unless you're in one of these big, heavy scaling framework. I think I learned the trick today. I think my, my new strategy is going to be to know somebody who knows somebody. And, that's how I'll move into CPO. I think that's, that's my new career move. Know somebody who knows somebody. Know somebody who knows somebody. I did a lot of work in, in Middle East knowing somebody, knowing somebody. Oh, man. Well, listen, folks, if you've enjoyed this, And especially if you, especially if you've not enjoyed the podcast. Yeah, give us a like anyway, but let us know what you'd like us to talk about. And, yeah, and subscribe that, button down below. That's right. And if you're Jason Knight, double like, definitely, definitely double like.