In product management, it’s easy to find oneself donning the cape of a hero. But what if the true path to success and impact goes beyond the allure of being the team’s go-to savior?
In this episode, Hannah Clark is joined by Clement Kao—Founder of Product Teacher—to delve into the intricacies of heroism in product management and explore strategies for empowering product teams more sustainably.
In product management, it’s easy to find oneself donning the cape of a hero. But what if the true path to success and impact goes beyond the allure of being the team’s go-to savior?
In this episode, Hannah Clark is joined by Clement Kao—Founder of Product Teacher—to delve into the intricacies of heroism in product management and explore strategies for empowering product teams more sustainably.
Before we dive in, I just want to clarify exactly what I mean by heroes in product management. I'm not talking about thought leaders like Marty Cagan or Lenny Rachitski, I'm talking about YOU. I'm talking about the person your product team leans on to save the day when something catches fire. I'm talking about the hero who wears many hats, but never a cape. I'm talking about the reason you can't seem to work less than 50 hours per week and you still feel like you're no further ahead than you were the week before. And if that sounds like you, good news—today's guest is Clement Kao, founder of Product Teacher. Having coached product managers in all environments from early stage startups to Fortune 500, he's seen a lot of product team dynamics, including plenty that needed some serious rescuing. We're about to discuss why being the hero of a product team is a danger all of its own. And if that resonates, stick around to the end to find out how to get the superhuman strength to finally turn things around. Let's jump in. Welcome back to the Product Manager Podcast. Today, I am sitting with Clement Kao. He is the founder of Product Teacher. Clement, thanks so much for joining us today.
Clement Kao:Yeah. Thanks so much for having me.
Hannah Clark:So we'll start how we always start. If you could tell us a little bit about your background and what led you to found Product Teacher.
Clement Kao:Yeah, fantastic question. So I originally actually started not in product management right when I graduated from college. I actually started as a management console. Then as a management console, I accidentally became a UX researcher. Then from there, I accidentally became a data analyst. And then from there, I accidentally became a product manager. So I have a very non-traditional background. So yeah, so as I was continuing to progress in my career as a product manager, so starting as an associate product manager at the bottom of the ladder, then going up to product manager, senior PM, group product manager, principal product manager. One of the things that I noticed is that there were just a lot of other people who were struggling the same way that I did. Basically, not necessarily having the right resources on hand. How do you tackle this particular problem? How do you actually work through this particular mistake? What are all of these different terms and why do these things matter? And so for me, one of the things that I started to ask myself as I was getting more and more senior in my individual contributor PM career, is how do I make the most impact possible? And I started to realize that, hey, you know, me making the biggest impact isn't necessarily continuing to do product management within a company. But actually helping hundreds, if not thousands of other product managers, being able to succeed when they first become product managers, right? Because that can be a very confusing transition and then helping them to rise the ranks. So that's why I decided to found Product Teacher. Product Teacher has helped more than 7,000 product managers really succeed on the job, whether it's breaking into product for the first time, whether it's getting promoted, whether it's, as a head of product, setting that product strategy, making sure that we've got really clear processes for all of our, teammates, et cetera. So yeah, it's been an incredibly gratifying journey to be on.
Hannah Clark:Nice. And it sounds like the most intentional part of your career journey and not the...
Clement Kao:Yeah. It was the one thing I didn't do on accident. Yeah. Yeah.
Hannah Clark:Today we're going to be exploring the idea of heroism in product management, which you've kind of taken a bit of a stance against. Just to be clear though, what does that mean in this context and how do you see it manifesting within organizations that you've worked with?
Clement Kao:Yeah, fantastic question. So something to clarify, right? I'm not saying that heroism is a bad thing entirely, right? So one of the core things about being a product manager, the buck stops with you. It's your responsibility to make sure that the product succeeds and, you know, you're willing to get your hands dirty for whatever it is that's necessary. Whether it is, hey, we don't have a QA person and we suddenly need to make sure that things are well tested before they go into production. Whether it's, hey, you know, our designer is sick and we really need to get the ball moving to unlock our engineers. Whether it's, hey, our customers are struggling to understand this part of the product and you need to take that product operations role in terms of getting it rolled out, making sure that people succeed. Whatever it is, the product manager needs to be able to jump in. But the core problem that I see a lot of times with kind of heroism in product management, if it's being used as a thing that you're supposed to do all of the time, instead of something that you're only supposed to do when it becomes very, very, what's it called? When there's suddenly an exception that pops up, right? And so to be clear, a product manager, yes, should be able to step in and make things happen when necessary, but they shouldn't be the person who does everything all of the time, right? And so I see a lot of times, you know, when people think about, Oh, this product manager is such a hero, right? What they're doing is they're actually taking a lot of the job functions away from other colleagues to make the product work. And what that causes is it causes the rest of the organization to atrophy. You have folks who are not necessarily doing what is necessary from, let's say, a product marketing perspective, or from a product analytics perspective, or from a customer success perspective, or from a customer sales perspective. There are all these different things that start to become a lot less strong and a lot less repeatable when you're just relying on the one person to do everything. And I've actually seen this, yeah, around me. When that product manager winds up falling sick or goes on vacation or leaves the organization, then everyone is in a really bad spot, right? And so the thing that I want to clarify, right, is of course, product managers should very much be willing to step up to the plate when the need arises. But if the need is arising on a daily basis or on a weekly basis, there's probably something deeper that needs to be addressed.
Hannah Clark:Yeah, and I think we can imagine some of the logical consequences of a PM being in a position like that all the time. But why do you think then there's still so many product managers in this position?
Clement Kao:Yeah, fantastic question. So I think many times product managers just continue to be in this position because the way that work has changed over time is everyone is kind of cross matrix to being able to handle lots of different things all of the time. And so in the past, you might say, Oh, well, you have one UX designer and they're just focusing on one initiative. And now you see that, oh, well, that person might actually be supporting five to a product. You might have someone who is supposed to be, let's say, like a business analyst and they only need to focus on one core set of initiatives. And now they're focusing on, you know, supporting seven different teams, right? And so you see that because of all of this cross matrixing, it's a lot less clear who's supposed to be holding the ball. And so when things go wrong, it's not really clear who should step in. And because it's not clear, by default the product manager needs to step in. And so if there's more clarity on, Hey, when these kinds of things happen, this is the person who should be doing it, then that product manager doesn't need to step in. But given the rise of the tech startups, given the rise of much smaller teams that are a lot more autonomous, sometimes what happens is that there's not really clear guidelines around who should be doing what. And so anytime we're like, Hey, we're not sure who should be doing it, it's the product manager's job to do it. And as soon as they do it the one time, then it becomes almost this, you know, self reinforcing loop of, Oh, well, the product manager did it before and they did it really well. It's a lot better than I could have done it. Then why don't we just have them do it again next time? So I've seen a ton of product managers suddenly basically take on the job of, I'm going to be doing all the analytics all the time, forever. I've seen product managers become like, yo, I'm going to be the one doing all the market research and all of the customer discussions forever. I've seen product managers do, you know, Hey, I'm going to be the one who now has to do all of the sales conversations and be the one who closes the sale forever, right? Because, oh, well, they did so much better than we did. Why don't we just have them do it? Because I've got all of these other initiatives that I got to go do where maybe, you know, other folks aren't going to be able to outperform me. And so let's just have this product manager do that. And so that's kind of why I see this situation happening more and more over the last decade or so.
Hannah Clark:Would you say that there's any tells kind of early signs that an organization hasn't really put in the work to adequately protect their product managers from being in the position of having to be the hero or just hasn't really prepared from a process standpoint?
Clement Kao:Yeah, fantastic question. So one of the ways that I think about it is it's kind of like a, when you see it, which is if you need to jump into one time, that's totally okay. That's totally expected. But if you're noticing that you're jumping in pretty frequently, like, Hey, I'm jumping in almost on a monthly basis. I'm jumping in every time we're supposed to launch something. I'm jumping in every time there's a bug, right? Like there's something that seems to be a pattern. If it happens twice, right? Like if the same kind of thing happens twice in a row, you probably need to have that deeper discussion, right? And I think if you're in an organization that values retrospectives, or if you're in a place that doesn't have retrospectives, you should bring retrospectives into that board by talking about, hey, why did this problem go wrong, et cetera. If you're doing that on the first time around, ideally it should stop it happening the second time around. If it happens the second time around, right? That retrospective should include, why is there a pattern? And so then that should hopefully help in terms of being able to catch, hey, we've got product people doing things beyond the scope of what they should be doing on a regular basis, which is not what we want to happen.
Hannah Clark:So when it comes to running these retrospectives, I can see that this is kind of sounds like the unsexy remedy for something like this.
Clement Kao:It's very unsexy. Yeah.
Hannah Clark:Unfortunately. What kind of process should a product manager be using to run a really adequate retrospective that's going to get everybody on board with making the necessary changes to remediate a situation like this?
Clement Kao:So one of the things that's really important is that when running a retrospective, we want to make sure that the retrospective is blameless and that we're talking about the system and not the people. And so what I mean by that is what we don't want to happen in the retrospective is we're kind of talking through all of these things. And, you know, let's put an example. There is some enterprise customer that is very frustrated about the way that the product experience is currently working. We happen to have a product manager who knows how to code and, you know, all of the other software engineers. Either due to like really hard deadlines or due to whatever else, they're not able to make a particular copy change, right? So the product manager writes their own code, like merges that and like gets that deployed, et cetera. In that case, we should probably have that retrospective. The retrospective should not begin with, Hey, this engineer was so busy that like they weren't able to do it. And so that's why I had it, right? It's almost finger. Instead, it should be something more like, Hey, why was it that this particular customer, when they raised this issue six months ago, why don't we pay closer attention? Why did we wait until, you know, they got very frustrated and was about to cancel the contract? And that's when the product manager intervened. So kind of taking that step out and asking about the system's perspective, right? It's not, Hey, you know, this particular person failed to raise it at this particular time. It's, okay, well, if this situation happened again, what are some of the things that we could have done better next time as a system, as a process to make that happen? One of the things that I actually was reading recently was about, you know, air traffic control. And I know that this sounds like completely like a tangent. But as an air traffic controller, right, what you're supposed to do is you're supposed to make sure that, you know, planes take off, planes landed that there are no crash. And when a crash happens, yes, that air traffic controller was there when it happened. But no, it is not 100% their fault. There are all of these other cascading things that make it really hard where that becomes a single point of failure. And so what we want is not to further be one point of failure. We want there to be lots of different places where we can help to prevent that failure earlier on. So it's not just on the one person who's holding that like title of product manager, right? And so that's really the way that the retrospective should be run. Like, you know, there are all of these, you know, best practice guides, you know, there are all of these, like, hey, like, you should ask these questions, etc. Those are all great. But the most critical mindset that really is the foundation of any retrospective is, Hey, we're going through this together. We're not pointing fingers. We're not saying a specific person is to blame and that career is online. No, no, no, no, no. It's, let's go audit the system, right? What wrong with the system? And how can we make that system a little bit better for all of us the next time this happens? Right? So that can be incredibly powerful in terms of making sure that we've got the right sets of supporting players and supporting processes and that, you know, it's not just on the product manager every time to like merge code, right? Or jump in and prevent a customer from churning. But again, if you have a customer who's about to turn and the one time the product manager jumps in, says the conversation great. But if every single customer, you know, conversation, you need a product manager in the room and it's like that one person every single time, we should probably reframe how that actually happens.
Hannah Clark:That makes sense. Having to reverse engineer sort of the issue and then find the solution from that starting point. In your role working with product teams, have you personally seen any kind of organizations successfully remediate an issue like this? And if so, without naming names, of course, kind of tell us a little bit what happened.
Clement Kao:Sure. Yeah. I'm going to first tell a story about myself. At some point in time, I wound up being kind of, you know, the person doing all the product ops stuff when I shouldn't have been. So basically for one of the products that I was owning in B2B SaaS, we were launching basically this totally new product, Vertical. That was adjacent to our existing product Vertical. And so, because I was the one who had already done all the customer research, I understood the customer pain points. I was the one who was, you know, making sure we had like the right release notes, making sure that we have all like the recordings, just really making sure that our customers are going to succeed in terms of how do I actually set up the product and use it for success. And that was okay back when we only had three customers using it. But when we got to our 70th, one of the things that I had actually done a poor job of, right, so this is actually me, is I did not raise my hand much earlier on. I like maybe like the 10th customer, the 15th customer and say, Hey, my job is not to actually go and like run every single demo and run every single training for all of my customers. That's something that someone else should be owning. And the way that I thought about it at the time was, well, it's my job, right? Like I'm a product manager and I need to make sure the product succeeds. Hell or high water, I'm doing it. I had not framed it in a way of, look, you're taking away an opportunity for folks within the customer success or for folks within the product marketing work, et cetera, to actually have a holistic view of what is it that our customers are seeing, right? Kind of how do we make that experience much better for them? How do we actually have instrumentation and metrics and things that actually help us grow as an org, right? Basically, I had jumped in and done all of this stuff thinking that it's just the one more time, it's going to be okay. And I was actually, as well as my intentions were, I was actually undermining my teammates, right? Like, I wasn't really giving them the opportunity to own a thing from end to end. I was just kind of always jumping in when necessary. And so that kind of cause people to say, Oh, Clement, I'm bringing on a new customer to this product that you own. I don't know how to configure this thing. Right? Like what are the options available? And I would like walk each person through one by one. It's well, probably someone should own, you know, broader documentation on like, you know, how do all these different configurations work and which customers should use which ones and kind of videos and like screens of how does all of this stuff work. Or like qualifying questions and sort of like intake for, Hey, when we're onboarding a customer, here are the things that you should ask and set up. And so because I had not done that, I was very lucky to be working with an incredible manager, right? So incredible director of product and he said, Hey, Clement, I'm noticing that you're a little underwater these days. And it seems like you're doing all this stuff that's not technically yours. I'm like, yeah, but the buck stops with me. I said, that's great. But what you're doing is you're causing us to not be able to have a robust system around supporting our customers for the long run, right? Like, sure, you were able to support us from 1 to 10 customers, but like, you're at the stretching point, right? Like at 70 and like, we want to double next year. We want to have 140 next year. How are you going to do that? Oh, okay. Fair point. And so at that point, right, then it's, Hey, let's bring together all these other parties and talk through who should be owning what. Right? And where the places where that ownership is not like a burden, it is an unlock, right? Like we're giving people new identities. We're giving them new superpowers because now they get to own these pieces that I was taking away from them before. And so I think one of the couple of things that really succeeded in this particular instance is, one, having buy in from leaders within product management of this is stuff that you're not supposed to be doing. So that is incredibly important, right? Because if your product leadership team just says, well, you should just go do it. Right? It's very hard to be able to say, no, we should push this to other folks where it better belongs. That's part one. Part two is in terms of framing, who should be owning these responsibilities? It's not, we're giving you more work and this work is not fun, right? It's, we want to give you more ownership. We want you to actually be able to control from end to end this entire thing. And we were unfairly taking that away from you, right? Like we want a position in a way where it's, Hey, you are actually getting a stronger identity. You are the one who now gets to own all of these things. And that is incredible, right? Like then customers actually get to see the full value and you get to have a much bigger say in what is it that customers should experience from us. And so kind of framing that differently is also really important. And then from there, right? It's just like making sure that we regularly check in. And so after we set up these responsibilities, delegated them out, made sure that folks understand just, you know, at the start, maybe, you know, sync up every week, every two weeks, Hey, how's it going? Where are the places where I need to transfer that information? What are the things that I did in the past that you're going to be doing for? And just make sure that like, we smoothly ramp that off. Right? Like what we don't want to have is you just throw it over the wall and then people are just like, whoa, whoa, I own it. But what were we doing before? I was like, oh, well, you can't talk to Clement anymore because Clement's not the person who owns it anymore. Right? It's, we're all teammates, right? Like we were transitioning through. Let's have a couple of touch points. Make sure that we fully understand what was happening before. How do we want to incorporate that moving forward? And not feel like, oh, well, just because Clement did it this way in the past, it has to be done this way in the future, right? Because yeah, they're the owners now and they get to see kind of end to end what's a better way to do it. So yeah, so that was like the very personal case study that I can name names. I was the one, right? And I had actually made that mistake. And so I like very much lived it and felt it, but yeah, more than happy to also talk about, you know, other instances from like other organizations or...
Hannah Clark:Yeah. Well, if you have another instance, maybe that's more recent to that, that kind of frames the situation, but I really like the way that you frame this also is kind of giving back agency to the team and kind of sharing the workload. Because I have seen that in orgs that I've been part of as well, where someone unfairly takes responsibility for something that really isn't, and then it really impedes their ability to grow and impedes other people's ability to contribute. So that really makes a lot of sense. Do you have any other examples that you have that might kind of illustrate some other points around this concept?
Clement Kao:Yeah, I do. I'm actually a very recent one. Like let's call it a live case actually. It is right now, I'm actually working with this large organization where the product team is relatively new, right? So kind of all of them had originally been serving more as almost, let's say solution architect of hate. This particular organization, the way that they were operating in the past is, Hey, we have an IT, right? And so we're going to custom build each of these things for a particular costumers, and so it wasn't really like a scalable product. And one of the leadership decisions that they made is, Hey, we want to actually have a product team because it's very clear that each of these custom solutions that we're building have a lot of commonalities for the kinds of customer use cases that we want to support. We should be building robust, scalable product. We shouldn't be building all these one off solution. And so, all of the folks who were in the solution architecture team, right, kind of, they took a couple of them who were kind of ahead of the curve and said, Hey, you're now actually going to be on the product side of the house and you're going to be looking through what are the ways in which we can retool everything so that way we're building scalable technology problems and not just these one off solutions. But kind of because of that background and because of how new this product is, one of the things that they had fallen into is hey, as I'm coming up with this particular product solution, right? I have solution architects who are my end customer who are working with the customer to figure out what do we build? A lot of times this product team kept doing solution architecture work because they were the solution architects before, right? Like, Hey, now that you're using this part of our product, then you should be building these processes and using these systems to do duh, duh, duh, customers, et cetera, et cetera. And the actual staff solution architect for these initiatives were like, well, what am I doing? And so that created a little bit of stepping on toes, right, of, oh, well, you know, because the thing about it from like the solution architect's perspective, it's, oh, well, there's this newly minted team that has direct visibility from the CEO. And like, they're the ones who are supposed to change the way that things work. I guess I shouldn't be solution architecting anymore because they're ex solution architects and they get it. And this must be part of the product process, like, even though it's not. And for that product team, it's, Hey, we want to make sure that this product is really well adopted. And so we shouldn't just figure out how to build a product, but then we should figure out every other system in ecosystem and figure out like, how does everyone ingest all of these things? That's well, no, right? Like the solution architect is the one who should be exploring what are the other things that the customer's using today? Kind of how we wire all that, right? So in that way, the product team can actually work at scale, right? Basically, they were going into each of these deployments and doing both solution architecture and product management. And to know that you should focus on the core is we're building this robust platform. So then that way the social architects don't need to rely on, you know, this engineering team that has to build all this custom stuff. We've got stuff that's out of the box and now the social architect can go wire up the specific things that that customer has. So basically shifting us away from like a one to one relationship of like one PM to one customer, because that doesn't scale, but shifting it more to be one to many, right? One product manager owns the core and like each solution architect can then be one to one to us. And so, that was something that definitely took multiple touch points across the entire team to kind of talk through of, Hey, like, I totally get where you're coming from, like, you want to do a really good job as a product manager, and, you know, I really admire that in seeing that from my clients, right? But we got to remember that if we're taking away the ability of solution architects to actually go and solution for customers, in the future what that means is that we're not going to be able to actually build this technology core, right? Like you're now going to be like joint PM and solution architect. And then that means you don't have enough time to figure out what is the next building block to help all of these other solution architects move even faster. And so, let's not trade kind of the long term or the short term. Let's make sure that we are clearly saying no and why, right? And kind of give back that ownership to the solution architect, so they don't feel like they're out in the cold. And so that was just something that took some reframing. That particular team is just absolutely incredible, right? Like they're very open to feedback, very thoughtful folks. And so they took the message very quickly and was able to kind of rewire that. And the good thing is that we caught the soap, like kind of this product team has been around for less than a year. And so it's really great that they redefine this relationship now, instead of like waiting for it to crystallize in the next three years and then saying, Oh, wait a second, we did this wrong. We need to go like rebalance. It was just really good that we caught it early as a group and we're able to rewire that in a way where it's like the product manager is not the hero for every customer deployment of like, and now I got to do all this other stuff, right? It's hey, the product manager owns product and the solution architects own the solution. And so that was also like a really interesting experience. Because this entire product team were X solution architects, right? So you could kind of see why they were thinking that way. I mean, you can kind of see why the solution architects who were not shifted to product were like, Oh, well, maybe I shouldn't be engaged, right? Kind of, they're not the right intentions. It's a lot more about making sure that we're bringing in the right mindset, but we want to scale for the longer term. And so we want to make sure that each or owns a thing from end to end that they ought to be owning instead of owning like something and then a piecemeal other thing. And so having that just made it a lot easier for that entire team to succeed.
Hannah Clark:So I kind of want to talk a little bit more on that kind of idea of mindsets, but also the maturity of an organization and how that impacts how things work. So something that I've definitely observed in myself, and I think it's kind of a common thing throughout is that as an organization gets to be more mature and people who have also grown their rules and processes get more complicated and overwhelm kind of takes over, you get kind of stuck in this slog where you feel like this is not sustainable, but also feels like the only possible way. Because it's really difficult to get yourself, I think even most difficult to get yourself out of a situation where you are overwhelmed, where you are really underwater in terms of the perceived amount of work that you should be taking on. And that kind of atrophying has already started to set in. So I kind of see that as a few different things that have to happen. And one of them is the motivation to change your circumstances. And then another is actioning it, the process, the advocacy to kind of get yourself out of that hole. So in terms of, you know, someone who's been in this kind of a situation where they've already sort of inadvertently caused maybe some organizational atrophying, already kind of been in the situation where they feel they're overwhelmed with this amount of responsibility that they don't technically own, what kind of light at the end of the tunnel can they look forward to if they really put in the work to make themselves, to free themselves from those kinds of shackles? And how do you advocate for yourself in an organization that's in that sort of stage?
Clement Kao:Totally. Yeah, fantastic question. So in terms of tackling that, right, kind of, I want to go almost like bottoms up, right? So kind of the first part is just recognizing that you are underwater in a way that was not something that you had signed up. And like many times that realization just doesn't even happen because you're so underwater, right? Like you're working like an 80 hour week or 70 hour week. Like you don't have the time to think about, wait a second, this doesn't seem like product management. And so something that's really valuable is, you know, at the start of a week or end of a week, just like taking like 10 minutes to reflect on, Hey, how do I feel about the work I'm currently doing? Is the stuff that I'm doing actually product? Am I actually moving the metrics that I ought to be? Is there stuff that I'm doing that just doesn't feel like the highest value, but for some reason, I'm just the person has to do it. And so really taking the time to just reflect on your own, many times can help you to recognize those circumstances. Just like, Hey, wait a second. I thought my job was to understand the customer problem, work with design and engineering to figure out how to build it, and then work with the business to figure out how to roll it out, right? And now I'm doing all these things that don't feel like that core product responsibility, what's going on? And so, part of it is being able to self realize that, because if you don't, you can't advocate for yourself. Then the second part is making sure that you've got buy in from your manager, right? I think most of the time, right, managers don't know that you're doing all of this stuff, not through their own fault, right? Like they've got their own metrics that they need to go hit. They're managing lots of other people, right? And so a lot of times when they hear from you, Oh, like I'm spending something like 10 hours a week doing this stuff. You're like, Why? I wish you told me earlier that you were spending 10 hours a week because that doesn't belong to you. And so a lot of time, you hitting your metric matters to your manager because your metrics are partially their metrics, right? And so most of the time, right, like not even thinking about it from like a selfish like, Oh, I'm gonna like create all of this like pain for my manager. But no, you're making your manager more effective by showing them, I have all of this time that I'm doing stuff that doesn't align to my metrics or your metrics. And so like, let's figure out what's going on, right? So they want to hear that from you, right? So don't feel like, oh, look, I'm now going to bother my manager. It's no, no, no, no. Let's help your manager hit their metrics by making sure that you can hit yours, right? So here are the things that I'm doing that are not core product. Here's how much time I'm spending per week. And ideally come to it with some thoughtfulness. So here's why I think I'm doing these things, right? Because then the next question you manage to ask, right? It's, oh, well, why are we in this situation? And what are the things that we've tried so far? And so once kind of the two of you are aligned from there, then you can start to actually work with other folks to start thinking through like, hey, like, what are the things that make more sense to belong with others? Whether it is, Hey, I'm doing all of this, like UX designs and wireframes and we have a designer, right? Like, why are they not doing it? Or like, Hey, like I'm doing all of these like ad hoc SQL queries and really we have an analytics team. They should be the ones who own it, right? Because again, if you were the one doing all of these, like ad hoc SQL queries, you might not realize that like the analytics team could figure out a way to wire up the dashboard that just like automates that away forever, all time, right? And like, then your entire customer success team can benefit from that, right? And so you sticking yourself in there to like serve as the hero is no bueno, because you're not helping your organization scale. So it's like, hey, here are the things that I'm doing that I think actually belongs to another team. Here's why I think it belongs to another team. So really going through and saying, here's where I think it belongs. Here's why I think it belongs there. Then we can start to have these conversations of like, Hey, let's start to reach out to each of these teams and say, Hey, I was originally doing this stuff, right? I'm starting to realize that it might actually belong better in your wheelhouse and here's why. You can drive that more scalability. You can drive kind of that deeper visibility. You can make sure that it wires into the rest of your processes and that like, you know, you don't have a blind spot where like, I'm kind of holding it together here, right? And kind of working together with them to get that rebalance. Once you've got all of that stuff going, right, then like making sure that you're checking in first frequently, and then wrapping that down to like not checking in again like in the future because you've transferred that. Making sure that they feel comfortable with, hey, here's the things that I'm doing now, and understanding the context in which you were doing it before, making sure that they're set up for success. And once all of that is done, going back to the original question, what's at the end of the tunnel is, now you have so much more time, the time that you should have had in the first place, to do core product, right? Like to really understand our customers, to really get creative with design engineering and figure out how do we actually build things that are delightful and scalable and create profits over the long run. And to really be able to partner deeply with the business to understand what is our go to market positioning strategy, right? Kind of how do we want to stand out? How do we want to make sure that customers are succeeding? Which new segments are going to penetrate, et cetera. And so you'll just feel a lot cleaner brain, I think. I shall be able to really focus on like core product. And so that's what you'll be able to get from it by committing to this hard work. Right? And I know it's hard because like, again, I went through it myself and it took forever. Right? But it was really valuable at the end. I was able to make products that so much more impact and really understand my customers in a much deeper way than I could before. Because now I had the time to actually engage. I think the other thing too, just like the adjacent tip that I want to give. A lot of times, and this is just reflecting on my own experiences, but also what I see in a lot of clients that I coach, a lot of times product managers really want other people to succeed, and so they deprioritize themselves a lot. And so what that means is that every time I was like, I really should be spending 10 minutes to think about how my week went and where can I delegate things away. It's like, well, no, I could spend those 10 minutes coming up with like, what is the rollout plan for this thing? Or like, well, I can spend these 10 minutes cleaning up the documentation for engineer. I could spend these 10 minutes making sure that, you know, these particular tickets are like cleaner in the backlog or whatever, right? Kind of a lot of times you don't spend that 10 minutes on yourself. And so the thing that I found to be incredibly valuable is to split myself in two. Where basically, yes, like, I've got this, like, execution persona. Like, Clement the product manager, Clement the person who's, like, doing this stuff. But then, there's this separate other persona, which is not, like, me. But it's, hey, there is this product leader. And this product leader demands that in the next week, you come up with a plan for how are you going to work sustainably, right? Like, that is blocked off on your calendar. And it's like, if it helps, right? Like don't name that person yourself, right? So for me, like my middle name is Richard. And so I said, Richard, the product executive expects that in the next week, you will have a plan to work more scalably. And so Richard demands this from you. You don't get to depart. And that was incredibly helpful, right? Because now I actually made time to say, okay, I have a meeting with Richard to review the plan to drive scalability. And if I don't make progress, Richard's going to be real disappointed, right? So helpful just being able to break yourself out of like, oh, I'm always the one executing. So like, no, I also own the strategy. And if I need to pretend that I am somebody else owning the strategy, fine. So be it. But I am a stakeholder too, right? I think one of the things that product managers forget a lot is that they themselves are really critical stakeholder and they cannot neglect this product manager stakeholder while they're executing the product manager. And so that is something that I found to be incredibly helpful, not just for being able to rewire and redistribute responsibilities, but also just for so many other product management, you know, leveling up type things that you can't possibly get unless you dedicate this time for yourself.
Hannah Clark:I love an unconventional tactic and especially something like that, where you can really externalize your own value and what you are contributing to the team. That's really cool. It's just amazing how the most heroic thing that you can really do in your organization is to empower other people and by proxy yourself. So Clement, thank you so much for joining us. This has been really fantastic. I always appreciate your insights. I think you just have so much to give in this field. Where can people catch up with you online?
Clement Kao:Yeah, great question. So you can always find me on LinkedIn, right? So I'm probably the only Clement Kao, I think. So that's Clement Kao. Otherwise, you can find me at productteacher.com. No spaces, no dashes. So yeah, so that is mostly where I hang out and help other product people succeed.
Hannah Clark:Awesome. We'll see you there.
Clement Kao:Awesome. Thanks for having me.
Hannah Clark:Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager, wherever you get your podcasts.