In this episode, I am focusing on just two aspects – what is (and what isn’t) a good product manager and interviewing product managers.
Also, I highly recommend watching this episode on YouTube as well or watch it in the same YouTube glory as an embed below.
You can listen to this podcast on any of your favorite podcasting platforms:
This episode transcript:
Please note that the transcription below was generated automatically and may contain misspellings and errors. If you want to help with cleaning the transcript – please get in touch!
Vlad G 0:07
This is real world product management.
Vlad G 0:16
This is Vlad again, and you’re listening again to the real world product management, I apologize for missing. At that time. I know I promised to release more episodes, and I’m releasing less episodes, then, once a week, I was sick. Sorry, got better, you can still hear me speaking a little bit in those but should be sounding pretty normal right now. So we’re back to our regular scheduled programming. And today, I decided to narrow down everything, and only talk about two things. Number one, what is and what isn’t a good product manager and number two, interviewing and hiring a product manager. Why those two? Well, because I figured it would be a good idea to narrow things down and dive deeper into things. And to if you define what a good product manager is, it will allow you to interview and hire better. At least that’s my understanding of things. And that’s why I the way I’m thinking about this. So what is and what isn’t the product good product manager. We’re not going to cover everything today. Obviously, it would be insane. If we could just talk for an hour, define what the hell a good product manager is. And that’s it with that there’s nothing else to talk about. But I am going to talk about a little bit about things that i’ve i’ve seen, I believe I’m somewhere in the middle of the road between product manager who hasn’t done much. And the product manager who’s done a goal. So I’m I think I’m somewhere in the middle. So let’s talk about what what does it mean to be a good product manager? One of the things that I consistently see on in the field, let’s let’s put it this way. One of the things that I’m consistently seeing in the field is that everybody knows what a product manager does. There are executives, there are project managers they are there are delivery managers that are sales executives, salespeople, they all know what the product manager does. Surprisingly, they also think that they can absolutely do a product manager’s job. It’s just that they’re so busy being delivery managers, sales, people, janitors, whatever else. Thing is, it’s clearly then in Kruger effect. For those who are too lazy to dive into the Wikipedia, a Dunning Kruger effect is a hypothetical cognitive bias stating that people with low ability at a task overestimate their ability. In other words, the less you know about specific field or area or specific tasks, the more you think of yourself as being able to do that task. So if you don’t really know what, what’s included in chopping wood, you’d think that hey, I can do it, as you know, down physical work. Guess what, if you don’t know how to do it properly, you probably they’re probably either shut your muscles, you’re damaged, you chop your fingers off or something, something something, it takes practice to good be good at something. So there’s a lot of people out there who can think that, Hey, I know what product manager does. It’s just this really simple. They just need to come in, do this, do this, this and that’s it without they don’t need them anymore. Or, you know, I could do it. And that’s how you see sales executives or account managers or project managers or or some such people coming into the meeting with a client and they’re like, okay, so from the product perspective, how do we do this or from the product perspective? I think we should do this. And and here’s here’s, here’s the trick. When they say, as a from a product perspective, how do we do this? That’s not a bad idea. That’s not about choice of words that we worse is when they say silver from Rado, effective, this is what we’re going to do.
Vlad G 4:40
And the reason why I’m making this distinction is because when they say from a product perspective, here’s the solution is a it’s the person who’s not qualified to be a product manager be they jumping straight to the solution and see they think they know what product management is or how to do a job overall. Manager. And they like fast forwarding the whole thing. The Fast forwarding, like the whole movie, basically, right? And they come come straight to the conclusion. And then you see resource plans, you then you see timelines, you see project plans, like, hey, we’ve figured it all out, we know what we’re doing, we just need two teams. For six months, we’re good, we’re just gonna write, we’re gonna have a product manager, write all the user stories upfront, and we’re gonna execute. Well, you’re in, you’re about to enter, big, scary world of pain. But that’s not my problem. It’s their problem. So what is and what isn’t the good product manager? A good product manager is the one who is a who’s present these conversations, and be a good product manager is the one who doesn’t jump into the conclusions. And he is aware of his own, then Kruger effect, that maybe he’s the main knowledge is limited, maybe his or her industry knowledge is limited, maybe her understanding of this particular approach to building a product is limited. And instead of jumping into solutioning, or instead of jumping into how we’re going to solve this problem, they stick to what is the problem? Can we define the problem? To the best of our abilities today? Can we define the path of building this product moving forward? We didn’t know how we’re going to build it. Okay, wait, let’s let’s all agree on that the product manager should not be saying how we’re going to build it. They can say we’re going to use this methodology, they can say we’re going to use this approach. We’re going to use this. I don’t know ways of working. But they should not tell you how we’re going to build a product that’s for a solution architecture. That’s for engineers. That’s for developers, for technical technology, folks, for legal for sales, there will be a way to build it, we’re not going to talk about it at the at the beginning, we’re going to talk about what is it that we’re building? What is the end result? What are the okrs? What are the KPIs? How are we going to measure success? All That Jazz? Now, in other words, we want to define the ideal state, we don’t want to say, oh, is we going to, you know, use Java and we’re going to use react GS and we’re going to use I don’t know, I bought cheap stock on the back end, and all is gonna be peachy, I don’t know, is a product manager, I don’t know. So a good product manager sticks to defining the what and making making the was so clear that the engineers and solution architects and deck leaves, MBAs are able to make their own decisions about how they should be able to make their own decisions based on the ideal state defined by a product manager. So that’s, that’s kind of where the sexualize we as product managers should not be going into the solution. That’s somebody else’s task, we need to define what requires solutioning? Which is why we’re simply talking about Product Manager defines the what? And then engineering defies the how the business defines why the whole thing exists, right? What’s the business reason for certain things, another? Another trait, okay, so let’s understand that there’s gonna be a ton of stuff that nobody’s like strictly good product manager, or strictly bad product manager that we’re all somewhere in the spectrum. Another thing, another trade that we want to talk about is the obsession with certainty versus embracing the unknown. Let me talk about that a little bit. When you are a product manager, you are intentionally putting yourself in a very uncomfortable position of not knowing basically anything, you don’t know the how you are in a constant state of discovery, you’ve constantly thinking, what if you got slow thinking, I’m gonna, I’m gonna assume that’s gonna be my decision. But I also understand it could be wrong. I
Vlad G 9:26
want to build two different ways I want to build through different approaches. I want to do a B testing, I want to interview my potential users or existing users. And I want to understand what’s going to work best for them. I’m only based on that. I’m going to go to experience designers or graphic designers, or UX or developers, engineers, or solution architects and I got to tell them, hey, our users want to do this or our users expected this to see this or our users will only be able to use our app or our solution if we provide them with X, Y and Z features. It’s its constant state of uncertainty. It’s a constant state of I don’t know. And the best part of it is, the more you though know, the more you’re willing to experiment, the more you’re willing to think it through, the more you’re willing to ask questions from the users from the engineers from the US from the legal from the sales from support. And the more questions you ask, the more information you have to make the right decision, this is how you get this is that you collect data for those data driven decisions, right. However, the rest of the organization does not like that. The rest of the organization wants to be certain of things. They want to know when they will be able to release, especially first release or major release or something like that. They want to know, when are you able to deliver whatever it is you promised to deliver? They want to know how many people you need. They want to know the budget, they want to know the timelines, they want to know the scope of the release, are you okay, you’re going to release on? I don’t know, January 30. But what’s in the release? Are you able to deliver these features? Are you able to deliver these features in full? Or what’s the scope? How much time do you need? How many? How many people do you need, which results in how much money do you need, and on and on and on you go and it results in really funny. It comes out to a an absolutely weirdest things are weirdest constructs you could ever see. One of the things and I talked about this last time. One of the things is the PRD, which is an abomination of the product management world. I keep saying it. Someone just recently asked the question on Quora. So how do you use the PRD? I use this template? And I’m not sure if that’s the right template? How do you 40? What do you use? How do you use purities? What other teams are doing? And my view means some quite as an answer was other teams don’t use purities period, you don’t use purities purities are via elimination for one specific reason, as a compromise a bad compromise that that it’s a compromise between the need for certainty and need to for clarity, from the regular you’re off off the shelf of the shelf. For off the shelf enterprise, and new ways of working, that are well, they’re not so new anymore. But for some enterprise, they are for some of the prizes, they are the product management approach, the product mindset approach, this uncertainty and discovery by delivery. What happens is, you’re right Brd is like the same way you used to write functional specification or business requirements document, or, and in many cases, br DS both the I think the question that I mentioned was, how do you you define functional and non functional requirements in yo PRD? And it’s like, No, you just don’t define New Zealand very PRD. And that’s, that’s, that solves your problem. You just don’t realize that but not having to write PRD solves your problem. And then the person got confused, somebody else has started digging deeper. And they went exactly the same way that I would have one, which is there’s a reason why you write user stories. And there’s a reason why user stories have a specific format. The user stories are the bread and butter of software development. And the reason for that is each user story, it’s it’s it has this like minimal consumable minimum deliverable. It still delivers business value, if you if you if you go in, and then Google
Vlad G 14:04
what the what the criteria for a good user story is, it delivers business value, but it delivers them in tiny little chunks. And it’s kind of that age old question. How do you how do you eat an elephant you eat it in small chunks, you can just swallow an elephant in the hole. And PRD is effectively trying to define that elephant. Not not just just what that looks like, not just the size and you know the weight and the volume of the elephant but also how he walks or how he eats and his his his behavioral patterns. And after you define all of that, and you try to kind of like make that elephant that the real elephant that we tried to find has the diarrhea and that’s it and you’ve done in Europe er D is no more it doesn’t make any sense anymore because now it’s completely different elephant. So what do you do is You break down your product into the structure, whichever structure you use, I don’t I don’t, I’m okay with using any structure. In our product mindset we use product is divided into capabilities that are defined into features. And then their features are defined by epics and user stories, you don’t have to do that you can do epics, features, user stories, you can do themes you can, whatever works for you prop point here is you keep chunking, smaller and smaller and smaller, smaller pieces until you get to the point of the user story, which is the minimal business value delivered in a sprint within a sprint. And the goal here is to have that delivery. That if you deliver in these small chunks, that one of the reasons why initially, people want one of the reasons why people initially loved the idea of a sprint, and aside from many other things, was that if you need to change the direction, if something happens in the market, the product, you discover something, you only lost this small, tiny chunk of work, you haven’t lost the whole project, which is the predefined project by the predefined documentation, which is what the purity ultimately is, the only lose this much of work. You’re saving yourself from you know, drama, a huge drama, huge losses, you’re minimizing the losses, and you continuously deliver and develop and deliver product, you continuously giving something to the business, every sprint business gets some business value. So if you think about it this way, you’ll need to define everything upfront you what you need to define is is the product strategy, the product vision that the product roadmap, product roadmap is not a sequence of user stories, or epics and features, its capabilities and maybe breakdown of capabilities into something smaller, and then you can you may or may not call it a feature. The trick here, as you may think about does a product, then there is a capability underneath the product. So let’s say I don’t know, a phone, a smartphone, one of the capabilities is actually making phone calls right now that could be abilities making video, which is what I’m doing right now. So then you have the video. And then you can say, Oh, I want to record video in different formats. Is that a feature? I don’t know. I don’t know. But within the capability, I have this idea, idea space, whatever theme that I want to record videos in different format. Maybe it’s a gr maybe a 16 by nine, maybe it’s four by three, maybe it’s 30 FPS versus 60 FPS, whatever the hell that is. But when I’m thinking in terms of the roadmap in terms of product strategy, that’s the level of staying at. And that’s what I need to have. Once I get to that point, I can start working with individual themes, I can start working with individual delivery teams solution architecture, I can talk to Solution Architect saying, Hey, this is my roadmap, I intend to have this different formats of recording the video, the friend form factors 16 by nine four by 360, FPS 30 fps? Do you think it can be done within the single feature? Do you think it’s still different things? From technology perspective, from a user from experience perspective? Is that same thing? Or is that a different thing? How do we approach that. And then, based on conversations where you wax based in the conversation with technology, as a product manager, I make a decision
Vlad G 18:58
to say Oh, is going to there’s going to be a feature, selecting frames per second. And then there’s going to be another feature, selecting screen ratio 16 by nine or by three, whenever. then based on that, I can structure my more detailed roadmap into the actual capabilities features, and then break it down by epics and user stories. That’s kind of how the process should work. However, that pushed for certainty. And you’ll see this in, in a lot of enterprises. They they buy they I mean, PMO, upper management, whatever it will tell you. So here’s what we want to do. This is what the product should be doing in the future. We want to see all the user stories written up front. They don’t have to have all the details but we want to see all the user stories estimated. So we would know what the budget should be. Write me all the user stories and estimate them in story points. And I’ll ball we’ll see how long it will take for you guys to build it. And that’s what it’s going to. That’s what our project plan is going to me. And if that’s not a two barrel shot into both feet, I don’t know what is because you should be writing user stories all the way at the end after discussion where about product roadmap product, vision, product strategy, coming from the business coming from the product management office or innovation office or whatnot. Then you have product managers defining the roadmap or a feature of feature roadmaps or product roadmaps. Then they start working with the teams on the second that into smaller into smaller chunks down to the point where they get to the point of either again, their features, or epics, and then individual teams with their feature teams or which however your teams are position, they take over and they start writing epics and user stories while in my world is capability feature epic user story. So capabilities and features are developed by product managers with social Arctic’s dev dev leads or teams or whatever. And then from the epics down to the user stories and down to tasks and execution. It’s more teams that would hate agile is enabling teams to be self sufficient. That’s where you hand it over, not handed over, it’s probably not a good choice awards, they had over means I gave it to you, you own it, they own it. But I’m still here, I’m still participating in discussions of some participating, participating grooming sessions. But the team is responsible for delivering it, I don’t get a say in how they’re going to do it. All I’m saying is, I need this one, when you’re done. This is what needs to be happening. This is how the product should behave. How you guys get there. As long as all teams are on the same page, we’re using same programming language, same frameworks, same solution architecture, we’re good. We’re good. I don’t need to tell you. And that’s why writing purity is probably a sign of a bad product manager. And then not resisting having impurities is, well, maybe not bad product manager, but more of a inexperienced product manager or not. The Product Manager is not mature enough, unfortunately. But yeah, don’t don’t resist, resist writing parodies, as it’s bad, is best for business. But I think I already I already talked about that. Now, we’ve talked about what’s good and not good product manager. We’ve mentioned the Dunning Kruger effect, we talked about what versus how, and we talked about obsession with certainty versus embracing the Unknown. Unknown is a friend or a product manager unknown is good, because it allows you to experiment and get the let me let me let me see if I can say this, right. It allows the unknown allows you to choose the right solution, versus choosing the best solution. The trick here is, you know, you can you can spend all your budget,
Vlad G 23:41
because spend all your time and money and waste all the resources on building the best solution out there. By the time you get to be done, your products going to be probably going to be obsolete. But picking the right solution, it may not be the best, but it’s the right solution. For the moment, it solves the problem. It allows the user to do what they want to do. Ultimately, it keeps the user using your product. And that’s what matters. That’s why you want to pick the right solution, not the best solution. And the unknown leads you to the right to begin the right solution, not the best solution. So there’s that. Alright, next big topic. We wanted to talk about was interviewing and hiring Product Manager. And this is this is the part that I promised to leverage right it and I kept reading the Reddit in the last few weeks, especially when I was sick what else but also what I do right. You should sit there and read and there’s a lot of there’s a lot of pain going around. Interviewing in Malta Pull rounds. I agree, I tend to agree with the fact that too many rounds is bad. I don’t agree with the video, just one or two rounds is good enough? No, my personal opinion. And it’s just my personal opinion, and I don’t think we’re doing this, what the company that I’m currently working for, I need to check. But what, what I think is, you need to have about four interviews total. One should be HR, they should do a good job pre screening the candidates. And they should do a good job, figuring out the fit the company fit the culture fit, whatever else is their job. If they can’t do that job, fire your job. Or in more realistic terms, don’t let them do the whole interview. Let them do 15 minutes per screening, give them a couple of questions, pretend they’re doing it, and then do the actual interview yourself or with the peers or with other departments. But you do need, you do need the cultural fit, interview, but somebody needs to do it from the the people who are doing it for the person who’s doing it. He or she needs to know what what that means what that cultural fit is, if if one of the departments doesn’t do that job, then somebody else has to do it. But it has to be done. Now, another two interviews should be the the meat knowledge, the knowledge, the main authority. So if you’re interviewing for a product manager position, it should either be two hours with two different product managers or two different interviews with different product managers. A reason for that is each product manager has their own has their own quirks. I have my quirks. I know, a bunch of other people that I’ve been on the interview with who are interviewing the person have their own quirks. Sometimes they’re compatible, sometimes they’re not. It’s not fair to the candidate, that we did not resolve our quirks internally. And the reason why we didn’t have that result down was because with a no, because we didn’t have time, because I don’t want to give up my quirks, because they allow me to make good informed decision about the candidate. So what this means is, I don’t need to be on the interview with that other person. It’s not fair to the candidate. And it’s fair for the candidate to see at least two different people to have at least two different opinions. The more the merrier. But again, I don’t think there should be more than four interviews total. So one generic cultural fit to the main role specific, and one with upper management, or upper management, culture fit or expectations or somebody with a lot more experience a lot higher position, see how that person would fit the team. And I think that’s it, that’s that’s the most,
Vlad G 28:30
you need to go through four is the top again, you may be able to combine some of these, you may be able to do away with three. But at least from my opinion, these are necessary steps. If you can’t make a decision after these four interviews, you’re just wasting everybody’s time you’re not hiring, you just got to know proving to somebody in HR or in the management team, that you’re doing everything you can to find the right fit the exact person that specifically knows the ins and outs, well, you’re not going to find them. By the time you get to find them. It’s going to be two years and your competition is going to be way ahead of you. So four steps, one cultural fit, one, upper management, sort of kind of thing, make them feel better. And then the two different people from your peers, specifically from product management. here’s here’s an example. So I think I brought this up earlier. But just in case I’m going to repeat that again real quickly. The way I interview people, I tried to understand their experience and then move on to case analysis. I know other people hate case analysis and they try to avoid it. Okay. So the drill into the experience. I, personally, I’m on the fence with that. I don’t think just drilling into the experience is fair to the interviewer. The reason for that is I may not know the specifics of that particular role. So I mean, not ask. I mean, that’d be asking questions that help the candidate open up and tell. Tell me more about them and more about their experience. And on top of that, they may well, we will think just just to be clear, rolfing candidates are honest people who are trying to get into the role because they understand what it is they want to work with us. And they are good, honest, people who are looking to fill a specific need the company has. Without said, I’ve seen my share of people who pretend to have done something they have not. Again, I go into each interview with good faith in the candidate. And I literally again, they think I’ve, I’ve made that example before, I’ve literally seen a project manager resume where the word project management was replaced in the word Ctrl, r Ctrl, F Ctrl. R into the words of product management. So all the responsibilities are proof of project management, all the words on time and by Ponyo writing things on time on bhajan the scope, but he’s a product manager. And my grievance here is that I don’t want to resort to idiotic questions like how many, you know how many x fifth in the in the y when Z’s is alpha. I don’t want to talk about you know how many baseball’s fit into the bus? I don’t want to talk about how it’s annoying. It’s annoying. It doesn’t tell me anything about the candidate. It tells me that either candidate study these questions, and they can pretend really well that they are answering these questions on the spot. Or they didn’t. And they also just like me, they think it’s idiotic, these questions are useless, and they didn’t prepare for them. It doesn’t tell me anything else about doesn’t tell me anything at all about their abilities as Product Manager. All it tells me is either they’ve studied this idiocy or they haven’t. That’s it. That’s all. That’s all it tells me. Why would I waste time on that? So instead, I give because there’s use cases, hey, I want to build a product that does this, how you approach it? What do you think you will need? What do you think your MVP would look like? How do you approach building an MVP? How would you use your previous experience? And I think
Vlad G 33:16
that’s a legitimate question. I’m not asking them to write up. Actually, that’s something that happened to me, I had a way way back. I had an interview with a company with a startup they just received their round a or OMB something like that. They create the open the office, huge office, beautiful view on Hudson River, I think was awesome River. So it’s amazing, like millions of dollars in rent one of the prime downtown locations in the financial district in Manhattan. Absolutely gorgeous office, absolutely gorgeous view a ton of money. These guys are asking me Well, here’s here’s our product. This is what we think why don’t you take this home? If you have any questions, ask us. Today’s I don’t remember the first probably Thursday. So let’s buy Monday. Let’s have let’s have a PowerPoint that you’re going to come in about to the office and you’re going to present it and we want to see you present a roadmap of this product. How do you see it? And it got me thinking, Hey, guys, you have a ton of money. It’s not it doesn’t look like you’re, you know, starting in mom’s garage. You’re asking candidates to create a roadmap of your product for real, which means you want them to ask you questions that you want them to call you discuss things effectively you want them to work for week on strategy on road mapping of your product, present the results for free? The answer is no. And there’s there’s a ton of ton of red flags right there. If you want me to do consulting gig per week, that’s fine. Let’s write up a contract. I’ll spend the week I don’t have a problem with that. I’ll take time off of my other work or whatever. And I’ll consult with you. And he, you take these results, and then you can either hire me to continue as you would with a consulting company, guess what? have come. Other companies do this with the lawyer. Other companies do this with McKesson, other companies do this with whoever else be the VCG. It’s normal thing to do you hire someone for a week, two week three week consulting, engagement, the write up the strategy, they ask all the right questions, they do everything you just asked me to do. They produce a tangible result, which is actually a PowerPoint deck. You pay them for their time, or you pay them for the result. And then you if you want to use that result, you hire them. And they help you with the execution. If you don’t want to use their their result, you hire somebody else. That’s the way it works in a normal, real world. How much do you think a week of my time would cost? Whatever it is, I’m sure you guys have the money, given the office that they give you this cheers square footage, and the view, you can definitely afford someone like me for a week. So I’m going to break a budget. Why do you Why Why are you Why are you doing this by trying to get this freebie from from people? I’m sure I’m not that wasn’t the one the one. I’m sure there’s like a ton of other people who were doing same or not doing doing or not doing this for free. So bad way to interview people, by the way to interview product managers.
Vlad G 37:11
for interviews, give them an abstract case, my personal opinion, give them a abstract and abstract case, I say this five, probably at least five times every interview. This is a hypothetical case, you I don’t expect you to build anything really real I want I expect you to build realistic, which means I get it if I’m asking you to build, I don’t know a chat application or messenger or something like that. I don’t expect you to actually come up with I don’t know, user interface or something. But at the very least, I expect you to tell me what your view would look like, Well, you know, it’s 2020 or 2021, or 2025, whichever the case dictates. And a lot of people are moving away from typing. A lot of people are doing voice messages. But not everybody can listen to voice messages. So I would my MVP would have typing, voice messaging and transcription service. There’s a ton of capabilities on ashore on AWS on Google Cloud, where you can transcribe the voice. That’s it. That’s my MVP. perfect answer. Even if you if you didn’t include the transcription, I feel good with that. As long as you justify, as long as you tell me this is how I would approach the MVP. This is what I know, this is what the questions I would ask. This is how I get there. And this is what the impact should be. This is what how I’m going to solve the problem that you gave me in the case. And again, simplifying them, not not giving out the real case here. Just tried to get the point across that. Why am I giving cases? Even though I do know, not everybody’s on board with cases during the interview because they take a lot of time. And yes, sometimes people get drowned in the case. Yes, sometimes people get scared. I had a kind of candidate who got scared by the case. And they failed the interview because of that. My rationale is if you’re going into a product management role, and in the consulting company in technically speaking, we are a consulting company. If you’re going to into the product manager position at the consulting company, and you can’t deal with the case on the interview. You’re a bad fit. Sorry. That’s that’s that’s the way I think and feel free to disagree. The happy to hear your thoughts view through comments. I don’t know, Reddit comments you can find me whatever. Tell me why you disagree. Because for me, k use cases specifically business cases or or generically calling them cases on the interview is your freakin bread and butter. He kids get away from that. And actually, as a matter of fact, if I remember correctly, there’s, there was a ton of ton of times when I’d be with the client and client would approach me in the informal fashion in an informal fashion, either over teams or over slack or, you know, in the room, hey,
Unknown Speaker 40:46
I think
Vlad G 40:48
this, what do you think about, you know, this, this and this, what do you think about, you know, what the product would be here? Believe me, it’s 100%. The same case is just wrapped in a slightly less details. And it’s a little more convoluted, and it assumes you know, everything about this particular client and their environment. But it’s the same case I’m giving you on the interview, or it’s the same type of a case, I’m giving you the assessment. And that’s, that’s exactly the reason why I keep pushing for it. I know there are people who disagree with me, I, I’m okay with that. But I’d love to know your reasons, please let me know. I absolutely hate just going through the resume and leave it at that. Which is another reason why I’m saying this should be two different product managers with two different approaches to the interview. A then there is the candidate, believe it or not, people who interview for product management positions are really smart people. I absolutely love talking to them, even to those who fail. I still love talking to them. They’re smart, they don’t fail, because they’re stupid, they fail because whatever, they fail, they weren’t ready. They couldn’t solve the problem. They forgot something. They took specific approach and decided that, you know, sticking to that approach was more important than being flexible, whatever it is. They fail, because whatever. There was somebody better. I don’t know. It doesn’t mean they’re stupid, doesn’t mean they’re bad candidates. It just there was there is reasons why they didn’t pass the battery vote the interviews. But they’re absolutely smart people. And I absolutely love talking to them. love hearing those stories, those things. And one of the things smart people do, guess what? They’re smart people, right? One of the things that smart people do, they prepare the stories. And I think I said that at least couple of times on this podcast, sparks evil prepare their stories about each and every job they held each and every product they built each and every engagement they were in. So whenever you ask them, they come up with this story. I know because I do the same thing. I know because I’ve seen people do the same things. I’ve seen my bosses do that. I’ve seen my colleagues do that. My peers, I’ve seen people on the interviews on the assessments. That’s the whole point of being prepared for the interview, you have to have a story behind anything you say on the interview has to have a story behind it. I then recently I did a pre assessment, which is kind of like a mock interview. person comes in you pretend you have this like pretend interview. It’s not really an interview. Because you don’t you don’t really ask tough questions, you ask questions to assess if the person is ready for the actual interview. Because again, you can do a mock interview and then let the person go into the interview. And that’s called the same questions. Right? That’s that would be cheating. So you kind of try to assess how ready are they? And when we were talking and I was asking questions about around the resume around the jobs and around the engagements. The person sounded very off the cuff, the person sounded like, Oh, yeah, here’s what happened or in they were trying to come up with a store in a spot. And I realized that after conducting hundreds of interviews and houses of assessments, I can actually tell I can actually tell when the person prepared is prepared. And they have a good story or person is not prepared and they don’t have a good story and they try to come up with a good story on the spot. Find wise, it takes them longer to get to the point. And story wise, it takes them longer to get to the point. And story’s not that interesting. Because again, your story has to be engaging. If you tried to tell a story, during the interview, specifically you’re in the interview has to be engaging, it has to be engaging story. And it felt like, you know, I wouldn’t I wouldn’t go into the interview, I wouldn’t go into the assessment, I wouldn’t go with this type of level of preparation. Just because you did something. Doesn’t mean you know how to tell other people, what you did and how you that isn’t, and what was it, I think is one of the biggest ones. And that’s I think that’s why a lot of companies are thinking cases are not fair to candidates and the subsidy cases with eight rounds of interviews with a bunch of other people. Don’t Don’t do that. That’s, I mean,
Vlad G 45:48
I, if you’re hiring an executive, I can’t imagine eight rounds of interviews, you probably want to give them time to talk to all the other executives or you know, all the big big shots at your company. But a product manager is not that is not that type of a role where you need a interviews was everybody including the janitor? Why? What are you trying to accomplish? What are you trying to extract? If it’s free work, if you’re, if you’re trying to ask questions about your, your own company’s roadmap and your own company’s stuff, and have them do free work for you. While while we’re like I said, pretty much if you’re if you’re if you’re going to the product management, especially if you have experience if you’re not fresh graduates that are trying to become, you know, a product managers, whatever, they can pick a spot, and they can call you out. So don’t do that. I mean, I know there are some desperate people who would go for it. And they get taken advantage of I, I think you have to have some kind of BS meter. And don’t fall for that. But I totally, I’ve been through some desperate times. So I completely understand why people would fall for that, or why people would still go for it. I don’t blame anybody in this. In this case, I don’t blame candidates, I would blame the company. But who does that but like I said, I understand they’re desperate people, there are some companies. This is kind of a good, good place to wrap up, why companies are doing that they come they think the answer. And I, I want to give the credit to the credit is due. I read this as one of the comments and read it. And I felt like it’s it’s too buried down there. And I wanted to bring it up. companies don’t need visionaries, they need cogs in the machine. And product managers are no different. It’s really rare when the company is looking for a visionary and I don’t mean vision or like Steve Jobs, right? We’re talking about person who can have a vision about the product. Because that’s what the executives are doing, right? That’s what sales execs together with a CEO CEO are, that’s that’s what they do, they really don’t buy, okay. Problem with us is everything is is getting commoditized and that’s probably a conversation for another time. But product management is no different is getting commoditized that’s why you have all these MBAs or people who, oh, I just graduated from school or from college, I want to go get an MBA, and then I’m going to go into the product management, they will and they won’t, because companies are indiscriminately hiring everybody who is you know, who gets to be who gets to have MBA and want to be a product manager and they did an internship, build this, you know, software, whatever. And maybe that’s good, maybe it’s, it’s good that we’re gonna have we’ll have same level of this same levels of seniority, you have fresh graduates going and writing code and then you have solution architects who build really truly complex systems, you rarely see fresh college graduate getting into solution architecture, but getting into coding is not that big of a deal for a lot of college. So maybe the product management will have similar
Vlad G 49:51
will have similar growth and similar distinction. That would be beginning or junior product management where Have you end up doing basic things, small things, small product, small features, writing user stories, getting acquainted with what the product management really is. And then you’ll have system architects or business architects, or people who understand the full scope of responsibilities and do all those things that are on on the diagram from legal support to go to market to sales through support to everything else. So maybe that’s the way it is. But as of right now, Product Management is no longer a vision or a job, it’s a cookie cutter approach to, hey, we need someone who’s going to be doing the roadmap, and who’s going to be doing this who’s going to be doing maybe user stories, maybe, you know, breaking down features into epics, or epics and features depending on your framework of choice and your voisey new things. And that’s, that’s why you get these humongous interviews, because if you don’t need a visionary, which is really easy to spot, that that type of a person is really easy to spot, if you need just need a cog in machine, you’re really trying to get that cog to fit the existing structure, you’re really looking for somebody who’s going to solve your problems, you’re looking for someone who is going to fit into the structure. And that’s the difference. That’s why you’re going to have all these growing pains. And there’s a lot of companies that are going digital or after during COVID or after COVID they change their ways of working the moving fully digital, they need that product mindset they need that the front approach, they’ve never done it before they were always putting on the back burner. Now they’re trying to get into it. And they just need someone who fit the structure of fit they fit the bill fit the bill, the space with the card needs to be so that machine keeps keeps going forward. And maybe that’s the best that’s a different topic for this topic for another day. That’s a different discussion altogether. But that’s why you get that interviewing my massive massive hiring massive interviews of product managers but your interview them like you would any other lower level, lower lower lower level worker, again, not because I want to talk somebody down or disrespects how long just because they understand worth talking about cogs in the machine, just another brick in the wall sort of thing. So that that was it. We talked about what’s a good product manager wasn’t versus was a bad product manager talked about the everybody’s in the experts and Dunning Kruger effect talked about what versus how obsession versus with certainty versus embracing the unknown. Then we talked about the interviews, multiple raw rounds of interviews, dive a little dive a little deeper into cases why I prefer cases versus not being ready for the interview, doing free work for companies as a part of the assessment or as a part of the initial interview. And we ended up on the prowl, little bit sad note. But it’s a you know, real world product management. So the real deal is, companies don’t need visionaries. They need cogs in the machine. With that. Thank you very much. Appreciate it. Give let me know what you think comments, emails, anything works. You’ve been listening to the real world product management and I’ll be your host Vlad Grubman. Until next time.
Transcribed by https://otter.ai