 Hello, everyone, and welcome to this week's Product School webinar. Thanks for joining us today. Just in case you didn't know, Product School teaches product management, coding, data analytics, digital marketing, UX design, and product leadership courses online and our 16 campuses worldwide. On top of that, every week we offer some amazing local product management events and host online webinars, live streams, and ask me anything sessions. Head over to productschool.com after this webinar to check them out. Hi there. My name's Eric, and I think this is now recording. I'm a product manager currently at the Volkswagen Group. In the past, I've worked at Capital One, Google, a handful of startups, co-founded my own thing for a little bit, not necessarily in that order. But in that time, I've picked up on a few items which you could call soft topics. But I really am looking forward to sharing with those with you today. So this is not going to be heavy on metrics or industry data, statistics. Like I said, it's more soft. It's really more the human side of things, which is exactly what it's called. So you go ahead and share this screen with you and we'll get going. All right. So being a human product leader. And when I say human, obviously we're all human beings. What I really think about with this stuff is that this industry hasn't been around for that long. And even industries that have been around for much, much, much longer in the big scheme of things, manufacturing, even before that, things like farming or ways of running government. There's been lots and lots of time for humanity really to iterate on those things, to keep correcting those things, to see what works and what doesn't work. My point here is that all of this is really new, even if it seems like it's been around forever for us because we're still fairly early in our careers. And so these are things that maybe seem obvious to you in retrospect or outside of the world where you might be working. But it's always important to call them out and to keep them in mind. So the first thing that I think about when it comes to this topic is the fact that product management, you're in a product school, you are learning things, you are learning very specific principles on how to do product right, how not to do product. And there's a lot of truisms or maxims that we hear. There's everything on the left. And I would say to a one, as crazy as it sounds, not a single one of these is true all of the time. Is the customer always right? Ask Steve Jobs. Should we always build strictly for the customer? Really same question. Design thinking. This is one of the things that in various points in my career have been more or less emphasized. I think it's a great way of thinking about how to solve problems and how to frame problems, but it's not to be all at all. You know, we talk about how the product manager is the mini CEO of the product. I think that's very often true. It's definitely not always the case. There's a lot of different stripes of product management, as you probably know. Your job doesn't always require building things. Your job also does not always require strategizing about building things about really being the person doing those decks, making those presentations, the business leadership. The two things that I think are unimpeachably true all the time, though, on the right side here, everyone involved in the product development process. We think of the most as different species, right? You know, engineering and legal. Those two don't talk to each other, but they're all human beings and everyone involved in it should be treated like a human. Again, I know this sounds like really basic stuff, but it's so easy to lose sight of it. I know I have and I don't want to anymore. And I hope you are able to keep these things in mind. So this is a three-way Venn diagram that I think a lot of us have seen before or seen variations on it, right? You know, product management is all about marrying the human or the user needs with the business requirements and the business goals with the technology feasibility and sometimes their goals as well. But ultimately, like I was saying before, humans are running all three parts of this when it comes to the components of a business and when it comes to thinking about those problems, it's always being framed by and addressed by and analyzed by humans. So that's really a better way of looking at it. To build a product is to build a human solution for a human user. That's not always true, but when it comes to software products where most of us are these days, it definitely is. So one really, really key point that I think about all the time when it comes to this is terminology. Terminology is this very simple thing that we learn words and labels when we get to a new workplace or enter a new professional discipline and we take it for granted. We just start using it without really thinking about what it means. My very first job, I was, it was brought to my attention. I don't know how I didn't know this before that there was a group called Human Resources. I thought, well, that's a strange name. I mean, we are humans, yes, but resource implies something else. If you've seen this picture before or something like it, it's from a little game called Warcraft 3 and it's a peasant hauling lumber in a forest presumably back to his lumber camp or the base. Now, there's a few different ways of looking at this here, but what is the resource in this picture? Is it the person doing the work? Is it the actual material that he's hauling or is it what's around him, the source of the material? You could say all of those things are true. You could say nothing of them is true. Now, if you apply this to building and shipping, the technical product development process, we talk about developers, we talk about designers, we talk about sometimes architects or sales folks as resources, we say, okay, let's secure a resource for that. I think I can put four resources on that project for you over the next month. It's again, one of those labels that we just sort of take for granted. And if you're at high enough level, yeah, of course this makes sense. You have to be thinking about teams more numerical terms. If you've got hundreds of people reporting to you or that you're responsible for, you have to think at a much more, I guess, I don't say dehumanized, but mathematical level about how you apportion things, how you split out work, how you prioritize and allocate. At your individual level, it's so much more subjective, especially if you're a product manager that's got maybe one or two development teams or sprint or agile teams. That's maybe low double digits of people. All those people are individuals and they all have specific needs, they all have specific skill sets. And so it is not necessarily to your advantage to think of them as sort of interchangeable parts. Like parts of a car, I would call those resources. Those are things that are taken, they're used up. They kind of don't really think for themselves. They do a very specific purpose and then they're done. So that last question, are you a resource? Would you like to be thought of as one? I know there have been times in my career where I have thought of myself as really more of a resource and sometimes I think of myself as more of a thought leader or somebody who is coordinating all of this. So yeah, it's up to you. I would just advise, think next time you think about using that term. Now, let's drill that in a little bit further. As a product manager, not all of you, but many of you, maybe even most of you are working with technical folks for much of the day. Sure, there's times when you're working more with the stakeholders presenting to the business side, but generally when you're building out whatever feature or software product that you're working on, you're working with this team. And I've been at places where there's this sense that the product manager kind of sits at a higher level. They're not really in the day to day, they're not really talking with the team. Sometimes that's because your schedule is just way too busy for it, understandable. In most cases, not so much. It's not really that difficult to make a little bit of time to engage with and spend time with the developers who are working on the things that you are passing them to do. I have also been in a lot of organizations where generally product has more budget than engineering and that gives some good opportunities to help morale, help team building, help really coalesce the team around the purpose that you are there for, which is, hey, we're gonna solve this customer problem. Take them out to lunch or dinner or happy hour or take them to play laser tag, go have a fun event. Again, things that I think people talk about a lot, but it's very easy to lose sight, especially when you get busy. And before you know it, you say, well, we haven't had a team event of any sort in six months, we've been working our butts off on this project. So that's something that you can really bring to the forefront because in a lot of cases, for leadership may not, for various other reasons. The goals are not aligned with yours. The budget's not the same. They have different sort of priorities when it comes to what they want out of their team. Second piece here is establish those team responsibilities early because truly every team is a little bit different. Even if organizations where it is so clear cut and so set in stone how teams should be working and operating, they still have minor differences because it's different people working on it. And sometimes those minor differences, if you don't address them early and often in some cases will spiral, will grow into something that's a little less tenable. The last thing is, another thing that I have been told sometimes, I've heard sometimes, I've also heard refutations of. So take it with a grain of salt. A lot of times you see that the product manager feels like they're the most important person in the room and indeed they are the one who everyone else is paying attention to. They're saying, okay, well, what do you want us to do? Why are we doing it? How do we get there? When do we need to do it by? And any and all other guidance points. That's not really anything you can do much about but be human about it. Don't act imperiously because we're all in this together. Now there's one specific member of that development team who you need to have a particularly strong relationship with and that's your tech lead. Again, this is making certain assumptions about what you're working on the software products but I think in most cases it generally holds. And your tech lead is usually, if they're not directly managing the other developers working on your piece of software or your product, they are a little more horizontally leading them and they are the ones who are really deciding how this work gets chunked out, how it gets done, maybe, which approaches you take in certain cases. And when it comes to working with them, you just gotta do it. You gotta connect with them. You have to understand, well, where are they coming from? I mean, they are more your partner in this than, I would say just about anyone. And as product managers, we have a lot of partners and partnerships that we have to maintain and foster. So really I wanna focus on this second bullet here or third bullet. Don't try to do everything yourself, especially if you think you can. A lot of product managers come from technical backgrounds and they say they know better. Say they've been there before, they've done this exact thing. So what are you talking about tech lead? That's such a bad way of doing it. Your head's stuck in the past. What's wrong with you? I've heard all these things before. You might actually truly know better, but you know what, you're not the tech lead. You are in a product management role. And so it's your responsibility to collaborate, to maybe help push ideas. As always, if you need to bring it to a head, if you need to escalate, that's an option always available to you. But it shouldn't have to get to that. And in most cases, it doesn't. So you wanna agree on everything and that's completely okay. You are often evaluated on different things. You have different career goals. You think about the team in different ways. But there's common ground to be found always. Another aspect of working with teams as a product manager is this horizontal leadership piece. It goes back to that mini CEO of the product, except for the fact that none of those stakeholders and none of the people working on that initiative with you are generally actually reporting to you. And yet you are leading them. You are leading meetings. You are leading initiatives. You are the one framing the work and saying, this is what we're doing. This is why we're doing it. This is what we need to do it about. Not directly managing someone does not mean that you cannot play a strong, prominent role in their career development and even their morale at the company you happen to be at. I think some of these are pretty obvious, giving feedback when you can, not about the quality of their code in most cases obviously, but in the way they handle themselves in meetings or their communication style. You can also speak about this with other people on their team or people that they report to, other leadership and engineering organizations. But it's also good to just have a good one-on-one relationship with them too. It might be a lot to manage the juggle if you have 10 plus developers, but again, they're all 10 people and they're people who have specific wants, dreams, egos, flaws, strengths, things that they would be benefited by hearing from you about and if they gave you feedback as well, great. The second one I think is pretty important because visibility opportunities are often something that sort of fall by the wayside when you think about technical organizations especially in a big company. Your work is in a specific place you stay in your lane and it's on the product manager to handle the demos or show off a prototype and say, hey, this is the vision we're really trying to go for. Now, did they build those prototypes or those MVPs? Well, almost certainly not. That's why we work with developers as product managers. So let them showcase their work. Obviously you're there to handle that bridge of communication but when people build stuff, they wanna be proud of it and in a lot of cases we have a setup where we don't really assume that they want that and a lot of people might not but sometimes going out of your comfort zone is a good thing. And then when it comes to their side projects, innovation, 20% time, 10% time, it goes by many different names but always be supporting that because even if it might be distracting from your core work that you want them working on, clearly they have buy-in from their own organization that this is something to focus on. This is something that will help in their career that likelihood will probably help the company's bottom line at some point too if they really are able to keep at it and if they have a well-formed hypothesis about it and it's going to make them, again, better, stronger, better informed in their career. So I broke down communicating into two categories. One, we'll keep talking about the tech organization because I'm sure many of you have or will be in meetings where you feel like there are just way too many cooks in the kitchen. You might invite your tech lead and then you are also told by someone else, hey, you should bring in this architect and that architect and how about a couple of these developers from your team? Oh, and also the testing leads should be there too. Don't forget about design, so on and so forth. Other people from your product team, sometimes even people from legal or parts of the business that really shouldn't have much to do with that initial build phase. Sometimes you need all of them. Sometimes you do find yourself in a, you know, let's call it a fire drill situation or a war room situation where everybody's input is needed because you really need to coordinate something effectively and quickly. Most of the time though, you don't. So again, I would say start with the tech lead. It goes back to that relationship with that person because I think they are such a key member in your ability to be successful in your product management role. And your tech lead in most cases, at least from the engineering point of view, will have a good sense of who else you should be looping in and whoever else is not looped in, your tech lead can be relied upon to kind of pass that information on. Judicious but kind is kind of the way I frame it. And BCC for various reasons, blind carbon copy as you know, is your friend in these cases in order to kind of control that message and the sort of meta message of, well who's seeing this, who's getting this. Team norms is something that you generally go over with an agile team, often between sprints or program increments and establishing those norms early and everybody being on the right page about them and revisiting them when it seems like maybe that's not the best approach to take will help you set the right dynamic here. When it comes to communicating on the business side of things, I always, always, always recommend asking yourself this question, do you need a deck? In so many businesses, startups, legacy companies, it all comes down to the deck. That's what I'm reading from right now, of course. So I'm not in too much of a position to push back on it, but it is an effective way to tell a story. At the same time, when you use it as a catch-all solution for anything you want to convey, think about the language that you're speaking and the story you're trying to sell. If it's a story that really lends itself to that slide format, great. Sometimes it might not be. Sometimes it might not be very heavy on data like this story is. Sometimes it might be so data heavy that you actually just want a series of tables to show. Other times, visuals might not be all that important because you are maybe couching what you're talking about in a personal anecdote or kind of showing by demonstrating rather than having a series of slides around it. And people can litigate on these things for such a long time. I went through something like that myself recently. So who are you communicating this stuff out to? Well, a stakeholder and who are stakeholders? I would say in many cases, they are executives. They are business leadership, sometimes engineering leadership or leadership from other parts of the org. And oftentimes they are above you in the pecking order. In many cases, more than a few levels up. They might not even know your name, but you know that and your leadership knows that you have to sell the story to them. You have to convey this to them in order to make sure that everyone who matters in your organization is on the right page and you can keep going with it. But there's even harder for some to really come to peace with than the engineers because these people often sit in their office. They're in meetings all the time. They're traveling constantly. It's hard to get on their calendar. You have to work with their admin and sometimes spend weeks hoping to get 15, 30 minutes with them, but if you can do that, it's so worth it. Every time that I have taken the trouble and tried to have the patience to get on someone's calendar and just met with them one-on-one, not necessarily with a deck, just a conversation. Hey, we haven't really spoken much, but this is what I'm working on. I'm looking forward to pitching it in a more structured setting at some point, but I wanna run past you what we're thinking about and get your early thoughts on this. I found that to be very effective, not in every case, but in many of them. Just make sure you know the story you're trying to tell and it'll flow into a conversation hopefully. And if not, then you know that you may need to revisit some of what you're talking about. So, we've gone through the different stakeholders and how to work with the different folks who you have to work with to ship products. Now, when something goes wrong in any phase of this process, and it always does, it always, always, always does, because as I said at the top, most of these concepts are still pretty new. Manufacturing has been around in one form or another, at least industrial revolution for almost, or over 200 years now. And even that, they're constantly improving operational processes and new concepts on how to do things. Now, building software products has been around less than half that time. And the way that we do it currently, largely internet-based products, has been around 2025, 30 years at most. No one's perfect and no technology is perfect. And it's all very complicated. And there are always so many different sort of threads that a given business task or a user action goes through to get to that perfect ideal and state. So, again, things will go wrong. When they do, just remember, everybody is going for the same outcome. They all want the user to have a great experience. Nobody wants crashes. Nobody wants bad reviews on the app store. Everybody wants that happy path to be realized as many times as possible. And finger pointing is almost always the first thing that happens. It's an instinctive thing, because I kept saying over and over again, probably sound like a broken record at this point, but everyone's human. It's a very human thing to want to blame, to want to deflect. And it might very clearly be someone else's fault, but you're not focused on that right now. You're focused on, well, how do we resolve this and how do we move on? Empathy is tough. And there's a Thomas Jefferson quote, I believe around, you know, if you are angry about something, count to 10 or take 10 breaths before speaking. If you're really angry, do the same thing, but with a hundred. Again, not easy to do, but something that's going to make the process of resolving whatever your issue is much, much smoother and generally much faster. And keep in mind that communicating across different teams, that is largely what a product manager should probably be better, best equipped for and best suited for relative to anyone else that they work with. So making sure the business understands, hey, these are the challenges, these are the risks that we sort of signed up for when we took this approach is part of your job. And the same thing, vice versa, talking to engineering and saying, you know, from a business perspective, we wanted to vet that, you know, this business model was going to work. We wanted to make sure that this wasn't going to impact our operations significantly. Again, it's your job, not always, but often enough that it's definitely something to focus on as a core competency here. Now it's good to find a point on it here, but problems are bad. How you handle them is usually, I would say almost always more important at the end of the day, because especially if you're in a larger organization, there are processes, there are frameworks, there are bridges to jump on when you need to do a hot fix, when you have a fire drill, when you have a mass crash event, no one really knows how it happened. The actual fix for the problem is different from how you approach it, which is all the way from the beginning of someone gives you a call or sends you an email, says, hey, there's this outage happening to you, who do you contact? Who do you inform about it? Who do you keep in the loop? You know, what is the tone you take? And then once it's all said and done, what is your retrospective like? How are you going to feel about the way that you handle this? And how are you gonna approach things differently next time? Comes back to humanity, vulnerability, understanding that no one's perfect and no technology's perfect either. And when things do go well, and they do sometimes, hopefully, you gotta celebrate. Go back to that lunch, that dinner, that happy hour with the team, say, hey, we did this together and it wasn't the easiest thing in the world, but we got there. And now we have customers using it and you know as well as I do, what a fantastic feeling that is. So I'll close up with this. Be human because you don't have a choice. Unless I'm addressing any humans and robots here, but I don't think I am. No one's perfect. There will be challenges. There will be shortfalls. There will be interpersonal issues either between you and someone else or between others on your team that you are often in a very strong position to help resolve. So the way you react is always gonna be important. And be human and be patient and be kind. And again, again, again, these are super obvious things. They're just things that are so easy to lose sight of. So please try to remember it because when you share that glory, it's just so much more pleasant for everyone involved. And remember, at the end of the day, your goal here is to build a great experience and provide a great experience to the user. And they're also human and they're also imperfect. And they're also going to make mistakes and run into error scenarios and maybe open your feature in a way that it wasn't meant to be opened or try to use it in a way that it wasn't meant to be used in and cause issues. And that's what we try to account for when we're mapping out what those experiences are before we even start the product development process. But it's difficult to always account for every single scenario because humans are complicated, we're innovative. We can innovate solutions as well as we can innovate problems. And when we remember our humanity, we make better experiences. So that's all I've got. Thanks for your time and have a good day.