Discerning and defining a project manager role. (Podcast Transcription)

Wait What Really Ok. Ok. With your host, Loren Weisman. This is a fully licensed theme song for the show about stuff that makes you say, Wait What Really Ok. Ok.. This is. Wait What Really Ok. Ok. I'm still Loren Weisman and I'm here with Derrick Boudwin. Now, many people have many definitions when it comes to titles. You see, it used to be the coo, the cfo, the co, whatever, oo, and then we got into strategy officers, and then we got into motivational officers, and then we get into that management level of interesting management terms that make no sense whatsoever. One of those that sometimes makes no sense whatsoever to me, but is crucial as a product manager. And Derrick is known for being a quality director of product engineering. He's been a product manager, he's been a product line manager, he's been a principal technical program manager. And unlike many other people, these aren't made up terms or titles as a whole. The way that I see what a product manager is, and we're going to get into it with Derrick about his definition, his responsibilities and more. So the communication point, which ties to the messaging and why we have Derrick on here today, I see a product manager being responsible for a given product throughout its entire life cycle, identifying the customer needs and identifying the businesses that are selling it, as well as a lot of the midpoints, the creation, the execution, the distribution. Now, in that in different managerial positions, people take on partial roles, total roles in between roles. Before I go any further than that. Is that a pretty good overarching umbrella, Derrick? Yeah, it covers probably 80, 90% of the hats that you get to wear in product management. Now, for me and my experiences with different company, the product managers that I found to be the most productive, effective, or for that matter, successful, usually had a cornerstone that came to a better level of communication. And not necessarily your super teched out guys drowning themselves on Mountain Dew or some of the cats that I used to know that would spend all sorts of time in programming, avoiding management. And as soon as they were done working on a program, then they would go play online and do one of those, you know, crazy games all night. A lot of time in front of the computer. You actually have a family, you got four kids, you have a wife and a life. Yeah, people ask me all the time, you know, oh, what are your hobbies? I'm like, hobbies. I have four kids. They are my hobbies. Now, if we were to, before we jump into the work part, how would you approach a product manager job description for your life with four children? Pretty wide Array of ages there and a pretty wide array of personalities. And in a sense the product being the family and the operations of it. I was wondering if. And he has not been prepped with this question. Prior, I was wondering how you would approach a job description for someone to be the product manager over your household, which you're already executing. That's interesting. So you always begin with the end in mind. Anytime you're talking about a product, you know, what, what do we end up wanting this to be? So our end result is we want four responsible, compassionate, empathetic adults who are able to navigate the world and be able to provide for themselves and their future families. So that's the goal. So the manager position would be providing training opportunities, one on one coaching, regular mentorship, providing for the necessities of life, listening a lot, learning how to do bedtime over and over and over again. So beginning with the end in mind there. Yeah, if we, if the goal is to have four successful adults and a family that is still a unit after all, that, that would be what I would put in the job description. Beautiful. And it's. I think it brings a greater clarity when you put it into a family model where a lot more people may be maybe able to understand that now staying in the same way and then the same theme around family. How would you be a product manager for a given home? Let's say from the standpoint that you were building a house and some people, they call them construction, they change the terms there. But from a true, more technical, creative product manager, how would you run product management when it comes to construction, when it comes to the architectural creation, building, execution and move in of a home. A home as opposed to a house. Exactly. So when we're creating new things, there's this concept that I can't remember who coined it, of mvp. Minimum viable product. Where we want to get the, the minimum amount of features that provide value to the customer out into the wild first before we start developing all these things that we may or may not know what we need. And so for a home it would be, you know, what is the bare minimum that we need to be able to create or be on our way to achieve the goal of this family that we want. And first and foremost for us, there needs to be unity between the husband and the wife. It doesn't mean you have to agree on everything or like all the same things, but it means that you need to be united in your vision of what you want the family to look like. If you and your partner are not united There will not be harmony in the home. And there's lots of things you can do without. You know, there's lots of activities that we like to do as a family that bring us together but aren't strictly necessary. So if we're, if we're starting, we're going to start with, you know, our vision, our mission statement, you know, what is it that we want this family to be? What are the hard lines that we're not willing to cross? And then what can we do from there? And then we experiment with little things like, hey, let's case in point, my two youngest, let's see, seven and nine. And all summer they've been at each other's throats. Just, I mean, I've seen them play nice. I know it is possible, but they've just, they've been bored and they nitpick at each other. And Cammy had the idea, let's move them both into the same room. Just, you know, just try it to see what it is. And we did. We put the bunk beds together and moved them in there and they kicked and screamed the whole entire way. The very next day, they played for like four hours together in their room without fighting. So it was just a little experiment, just like a little feature. Just try it, see if it works. If it doesn't work, move on to the next thing. But keep in mind what your original goal is. The original goal isn't to have them stay together in the same room or to even to not fight. The goal is to have them be responsible, loving, empathetic adults. And so we just, we try little things along the way. We're not afraid to experiment. We're not afraid to say that didn't work or to acknowledge when the other person has a better idea. But that's where I would start. And in a sense, parting. Parting or adding a bullet point to the job descriptions of the things that you do. Alpha and beta testing, as your youngest is definitely alpha beta, and test them out by putting them together and they represent, you know, a customer set. You know, they're all different. They're all very different. What worked on child number one doesn't necessarily work on child number four. There are some things that do, fortunately, but there's a lot of times where that last kid makes you feel like you're a brand new parent all over again. Like, how did I ever think I was ever good at this? I think there's an aspect inside the humility of product management. You have some people that have moved from one singular linear job they were put into a position and they could have been developing the roadmaps, the MVP elements, the testing, the strategic differentiations. However, in their coupling and safe place, with an operation that ran very smoothly before they got there and perhaps very smoothly after they left, they might not necessarily have the communication, the problem solving, the preventative maintenance tools to be a solid or qualified product manager anywhere else. Yeah, the thing that I always have to remind myself is that I really don't know anything as much as I think I know, as much as I. As I try and I learn, especially when you're coming up on a new product, you just. You really have to assume I really don't know anything about this. I really don't know what the stakeholders want. I really don't know what the customers want, because every time I've gone in with a set of assumptions of what I think they want, they're always wrong every single time. And I don't get any better at it. And I think it's just because everybody's different. And like you said, like one project that could have gone completely well with one specific set of ideas, the next just doesn't work. I think in the humility of that, or, you know, some people use a whiteboard. I know you have a blackboard in your office, but in that, to be able to say, I'm going to throw out a whole bunch of ideas. And it's. I think it's in a humility where you find, and other product managers like you find that authority and authenticity. It's being able to say, okay, I'm throwing out ideas not necessarily to be right, not necessarily to be wrong, but to at least begin to gauge a benchmark of what is right, what is wrong for you. And from there, then the development can happen, the strategy can happen. The beginning of a roadmap where many of these people, they've never built a roadmap before. So for you to even lay out a plan of, we're going due east, and here's how we go due east, and here's the steps and here's the budget and here's the team, and they're saying, no, we're going to go southwest. But they can look at that and say, oh, well, you brought this element, you considered that element. Okay, we need to do that. We just need to completely shift it the other way. I think in product management or the quality of a product manager, I think there's a chameleon element. It's not making it up. It's not some kind of False fake business coach, but more so someone that can throw something out on the table not to see whether they're right or wrong, but to see where the motion is going to be or how people interpret where their intention is and where their perception is of direction so that you can help them create an actual, and I won't say actual roadmap. And my next question follows that. Product managers, to me and the experiences that I've had, you're not sitting there making a roadmap in pen. It's always in pencil or quality one. Because in that. Would you comment on that? So you can't steer a stopped car is the biggest thing. So does it really matter which direction you start in if you can steer it? No, it really doesn't. And like you said before, we're not out there. You have to check your ego at the door because it's not about who's right, it's about what's right. And it may come from anybody, it may come from a customer, it may come from a stakeholder, it may come from one of the developers, it may come from some random place, it doesn't matter. And we need to be able to accept those ideas and acknowledge, hey, this wasn't my idea, but check this out, this could work. You know, let's steer that direction and see what happens. And it's in the process of, like you said, the motion getting in motion as fast as you can. Even if you're going 180 degrees from where you should be going, if you begin the motion, you can start making those corrective turns to eventually get you in the right direction and then you can work on Velocity later. So inside of product management, or sometimes I almost feel like coming from the messaging standpoint that it should be more of a title of product and process manager because in a sense many of the things that you do with the roadmap, how you create, how you connect, what you draw, ends up going into the SOP's ends up being part of whatever is going to be for a very long time. What is your thought though? For many of the companies, especially inside of lower echelon, lower invested seed funded organizations where they state, oh, we don't need a product manager yet, and yet they're assigning someone inside of a team to state, oh no, you're just going to run, you're going to run the show, but also do this job, what would you say? Maybe three points of while you're allocating funds, especially in this foundational period, and it's not an upsell. But to me, without that product and process manager, as I like to term it, you become a greater risk for that next series of funding, and you become a greater risk for the processes that are in place, the roadmap, and at the time, how much longer this will end up taking to get to that next point. See, building software isn't like building anything else. It's, you know, when, when you've got home builders that come in and build, they, they build from a set of blueprints. Now, everybody that's worked construction knows that on the job site, things do come up, you know, the, they deviate from the original blueprints. But by and large, if you come up with a model that works, a set of blueprints that work, you can redo it over and over and over again. It saves you a lot of time. Especially with these seed companies, you know, they see what worked for somebody else, or there's a little bit of survivorship bias from, you know, some unicorn that made it and like, oh, let's do it like how they did it. Creating a new product is like the worst game of telephone anybody ever played. And it is always so surprising to me to find out, you know, the executive says, oh, this is, this is what we want. And the developers come back and say, okay, we built what you want. And that's not anything like what I want. No, well, you, you said you wanted this, this and this. And look, it's got this, this and this and, and. Well, no, that's, no, that's come. That's completely wrong. And the product manager is the one who gets in between. And that's where communication skills are absolutely key because you just, you have to clarify and clarify and clarify. I did a stint out at Three Mile island nuclear station during a refueling outage. And we had this thing called three way communication where a supervisor would come say, Derrick, I want you to move this chest from the trailer into the office in the owner controlled area. And I would say, I understand you want me to move this chest from that trailer into the owner controlled area into the, this office. And then he would say, correct. So there was that back and forth three times. And you know, it felt, it felt like it was too much at the time, but I was always so surprised, you know, how things, how many problems that avoided by just having that exchange back and forth. And product management's even more so. It's, you know, we hear from the stakeholders, we want this. So before we start building a ton of infrastructure, we come back with real Basic wireframes, like maybe even like literal back of the napkin. Hey, this is what it could look like. And then here. Oh no, that's not at all it. Well, good. Oh good, we caught it. Now before we invested 160 hours worth of time in here. Let's redraw the napkin. Sorry, I can't remember your original question. No, that's the idea. And I mean it leads into the next question which you've kind of answered. I made a joke with a company I was doing messaging straight strategy strategy with. We called the product manager, we nicknamed him mct and we said he was mediation. He was a conduit and he was a translator. And it was between the C suite to the tech team and every so often the C suite guys where we asked them, don't go talk to tech, it's only going to upset you and you're only going to upset them. And what you think you're doing to motivate or share is not helping them at all, not how they work. It's going to create an adversarial relationship every time. And having that mediation point of someone that has the ability to, you know, as, as yourself, you can pop on a tie, you've got a, so you've got the social skills with your, your voice, your posture and whatnot to sit at a board and handle criticism questions while at the same time go in with the tech guys and, and again, we're not trying to make fun of them, but it is a very careful way of communicating to get across your point. I've noticed in projects I've been involved with going, I, I feel like I shared this with the intention and yet this guy stormed out the room. Yeah, it's the, you have to be able to, to balance those relationships. Everybody has to know that you're on their side and it's a difficult place to be. How can you, you know, serve two masters, so to speak? But, but you can. If, if you're, if your personal goal as a product manager is to make a successful product, then you're going to want to have a good relationship with the development team. You're going to want to have a good relationship with all the other stakeholders and be able to appreciate their needs and communicate the needs and the trade offs. Because most of, you know, once things are moving, most of what a product manager does is just continually communicates, updates everybody on the status of everything and then negotiates trade offs because there's always, oh, well, we need this feature, like, okay, we can do that feature. But if you want it now, it means we have to stop work on this other feature. And context switching is expensive so it's going to have to come at the expense of, of this other thing. And so you give them the information, you let them make the decision. They're the, they're paid to be the decision makers there. Your job is to arm them with the information such that they can make informed decisions. You know what that I, I do think it's worth that trade off. So yes, let's do that. And would you apologize to the development team? Because I know it's frustrating to have to stop work on something, you know, and that kind of transparency I feel like is so helpful to be able to getting work further along. Send down a case of Mountain Dew. It's funny the way you mentioned that it leads into the next question or you've answered it again is the idea of the product is done, it's live, it's distributed, it's out there, it's being purchased and downloaded. I don't need a product manager anymore. Yet you've reiterated clearly that it is a persevering position to keep the calm. Whether something were to go wrong, whether there was some kind of add on or something else that a responsible, well organized organization may want to hang on to that product manager for a very long time. Maybe the role has slightly changed but it comes to more of, and I know you've referenced it in the past, the people centric strategies of handling the moment for what is today, tomorrow, next week, next month, next year. Because things will inevitably go wrong. Competition will come into play, advancements will come into play and having. While a tech team may change, while an upper management or C suite team may change. I've noticed inside of some of the tech arenas and when I used to drive, you know, Eastern Massachusetts on that, on that 128 border we had all that tech stuff and you see the updates. Product managers that came in, a lot of those, I mean they are larger scale companies but they seem to be there a lot longer than anyone else. The job's never done. So when does a product manager's job end? It ends when the product is end of life. It ends when the product is dead, when it is no longer under development. Now you may not need to devote nearly as much time. You might go fractional on that project. Hopefully once things are going and moving and it's been released and you've got a regular cadence and your customers are happy, your stakeholders are happy and you're not delivering Maybe as frequently, then that product manager's time can be freed up to take on some other projects. Very rarely does a product manager only get to work on one thing, but the job's never done because you need to continually be searching for and getting qualitative and quantitative customer feedback, reincorporating that into the roadmap and the development cycle and then to be able to look ahead. Because landscapes change all the time, nothing ever stays the same. And if you're not constantly aware of what the changes are, you're not going to be competitive, you're not going to be able to turn on a dime the way you need to, you're not going to be able to keep up with your competition, you're not going to stay current. What would you say to a company that's in a place of hiring, they're looking for a product manager? What would you say? Three, let's call them red flag, red flag attributes. To put up the flag, end the call, end the interview. This is someone where regardless of what they have on paper, how they are connecting, how they're communicating could be setting up for a greater level of failure in the immediate. So red flags for the company to look for in the product manager they're interviewing. Yes, anybody that says, oh, I know exactly what you need to do. If somebody after getting a five minute explanation is so confident that oh yeah, we know exactly this is exactly what you need to do, that should be a red flag immediately because there's no five minute conversation that is ever going to be enough to cover everything. For somebody to have that kind of confidence, you know, having the kind of confidence that like I know we can get there, that's different people that come in with predispositions about that. If you are bringing a new product to market, if the product manager you're working with has never brought a product to market, then that's kind of a non starter because there's elements to inheriting an existing product and keeping it going versus Greenfield and bringing it all the way into market. So if you're, if you're a small seed company, you want to make sure that you're hiring somebody that has absolutely done that whole process before and understands how to do it. And the other, I would say is really, really the most valuable part of that interview is going to be the soft skills, is just less concerned about like the technical acumen tools that are used. Oh, do you know how to use Jira or can you, you know, have you done Kanban? Have you done Capital A Agile have you done scrum? How, how are they talking? You know, are they coming at you with some empathy, with some curiosity? Because communication is probably the most important skill. The rest of the skills can be learned. But if you can't communicate, teaching communication, I don't know how to do it. It's outside my wheelhouse. What would you say? And those are three great points and I love the reference about communication where you've got someone coming in and they have the most beautiful resume or they've run it through one of those AI resume generators and they've taken secondary positions that now look just absolutely amazing. But I mean you bring up three key points or key flags to watch out for in the sense of looking into someone's background as far as that resume and the validity of it. Where do you see the versatility? Your background has a great deal of versatility from you know, startup projects, brand new projects to existing, to working with an array of different sized teams. I like that you mentioned at one point that you apply people centric strategies to development. I was like in messaging, I love that one. But where would you take it when? Not necessarily a follow up or a call, but does it come to a budgetary idea? Like would you want someone that has worked along the same lines from a budgetary thing? Would you want to work from somewhere along the same lines of you have this big of a, of a development team. What would you say are some key points to look for for an individual paralleling the concept of the given product or the company to what this person has or hasn't done in the past. So a lot of it I think would depend on scope. There are some products that are, well, not necessarily simple from a technical standpoint that may not be that complex. You're going to build a new to do app. You know, there, there, there are hard problems to solve there, but it's very different than say a product that is going to be using machine learning. Machine learning is a very specific skill set and I've been fortunate to come up through the ranks from the very beginning. You know, I started out at the help desk, moved into systems administration, did some development work and automation, really learned how to program, did some security and security audits before I moved into program and then product management. So having been able to sit with each of those teams, I'm able to understand mostly, you know, not making too broad of assumptions here but you know, what, what day to day life is like for them, what things make their life easier, what things make their life harder. So if if you're going to be working with a cross functional team that has QA developers in one country and front end developers in another and back end in another, and you've got internal stakeholders and then you've got external stakeholders, that's going to require a different skill set. Then if you've only got internal stakeholders, you don't have a QA team and everybody meets in person. So it's going to be different. So you're going to want to match your candidate with the scope of what you're trying to do or as near to as you can. There's just no substitute for experience. There is no substitute for experience and there's no substitute for the experience you've had. Derrick's had 15 years plus experience leading international cross functioning teams. The term I like. He uses people centric strategies to develop software and I think also in a sense to develop the teams that he works with. If you are in the process of hiring inside of product management, you can reach out to Derrick as that mct. It's something that he does inside of his strategy and consulting. If you're a little bit unsure if you're hiring the right person, maybe you know the scope or the job description, but that is a service that Derrick provides in the sense of being that conduit, that mediator, that translator, you can reach out to Derrick regarding that. His information will be left in the content below the podcast. And when you look to a product manager or the product manager or product and process manager, consider some of these attributes. Perhaps send this podcast along to the person that's in the middle of hiring because having that, for lack of a better word, the conduit glue, that management style, that is as much tech as it is communication, as it is understanding as it is humility and communication, that person in between is going to be a great representation of everywhere you can go or might not be able to go. So this was Derrick Bowdoin. I'm Loren Weisman. This was. Wait What Really Ok. Ok. Episode. Whatever. Not tracking these days. Have a good one. Thank you, Loren.