Episode 10 Fantastic Product Managers And Where To Find Them In GOJEK

welcome to go figure my name is Nadine McCarran CEO and Founder go-jek Southeast Asia's first super app go Jack does ride-hailing food delivery payments even on-demand massages you name it you do it go figure is a podcast dedicated to expose the inner workings of ambitious tech companies in the emerging world we like to talk about things we like and talk about things together there are a lot of myths out there that we want to dispel so keeping it real is kind of a mantra hope you enjoy [Music] hey guys welcome to go figure thanks for making it today we have a Kevin our co-founder as always yeah your regular notice and we have DN and DN is our SVP of product management and Yin had a lot of experiences in both Silicon Valley as well as in Africa all related to product management and product managers so today we're going to talk about the topic of today's discussion is is product management the title of our podcast is great product managers and how to find them all right fantastic sorry fantastic product managers and how to find them correct correct and on that point you know I think I wanted to start first of all by kind of demystifying what product management is I feel like there are a lot of misconceptions about what it is and that in fact it is one of the say six crafts in you know technology companies software technology companies that are most kind of predominant and those six crafts are software engineering research design data scientists product management of course and what am I missing here well there's a there's a subset that or a subset of data scientist sometimes that are just specifically for analysis work and race analyst that's right the analyst craft and so we're talking one none of these six crafts which is product management and so let's go a little bit deeper about what it is and what it is not first of all you guys want a kickstart sure okay well we call product managers PMS for short a lot of the time that often gets misconstrued as project management and people use that interchangeably and I think well there's quite a bit of overlap in skillsets between project managers and product managers they're inherently two different roles a lot of product managers are excellent project managers right and I think there needs to be good project management skills to be an effective product manager but they are not the same roles okay can you explain that like what is the fundamental difference between a project manager and a product in my mind and in our frameworks here at GU eject when we describe the difference between the two is I think with program and project managers you know you're the product that you're building is you know for the customers within the company right like you were managing delivery timelines you're figuring out problems internally and you're delivering projects for products right for product managers you're doing this for the end customers it could be the merchants that we're building for our writers write our drivers but inherently you're building products for in customers and you were also you know responsible for delivering those products on time sometimes with the help of a dedicated project manager does that make sense so your primary stakeholder your North Star you're you know Mecca is the customer right is this is someone that is outside of your organization where as a program manager and project manager it may not be the case okay and specifically we're talking about in this case software products right all right that's that's when we say product management within tech it's good in that scope okay what are some of the the things that may be a misconception in the market about what product might one is that they are a project manager so they're doing something the timeline but they're not in charge and they're not actually paying homage to their final stakeholder which is the end user you've ready stated out are there any other kind of misconceptions about when people say product manager management I think it's worth spending time to talk about that specific I think a common misconception because it's actually a fairly common one and you see you see it happen in in certain companies where the product manager is essentially just in charge of a Gantt chart or like just a set of delivery timelines and say okay by this date you have to deliver X by that day you have to deliver Y and it's just this constant like rolling schedule of just things that you have to deliver and essentially they're being evaluated on their ability to deliver those things on time right that what is generally called to be a feature Factory because that way you just described well some companies you know run their product organization it's like feature factories and it is it's probably of the symptoms right of you know feature factory type products or companies but there are companies that don't necessarily run like a feature factories that still have product managers essentially act like project managers right so the folks who can kind of estimate and and in deliver on time are considered the ones who are doing well in their job and if they don't then they aren't considered doing well and then and into earlier point there is a part of the skill set that is about delivering stuff on time right there needs to be a certain level of accountability for the predictability of when things are gonna ship to the customer but I think the the pointer on the North Star is really that customer right like like I think that's the the common misconception around project management I mean the product management that ends up being boiled down to project management is that there isn't the focus on delivering something to the customer that solves the customer problem right so even if you deliver a bunch of stuff on time if you don't solve a customer problem then you're not you shouldn't be considered doing your job well as a product manager because at the end of the day it's all about solving the customer problem and so the way that you one should kind of evaluate a product manager is really around like how well are they solving that customer problem and there's many ways we can define solving a customer problem well but I think that's a that's a really critical misconception right that's a really interesting point because you know I feel like the differentiator there is the level of autonomy that the product manager has so am i correct to say that if that product manager or the so called product manager is basically getting assigned features that is given by let's say the CEO or the founder right say do this this this this this and I want you to make it on time then that person is actually not performing a product management role it's not correct that that's that's correct that's correct because also there's also no accountability because if the things don't work or they're not solving the problem the customer problem then whose fault is it really made anything said another way which I like to like to do is that you as a product manager you're not just in charge of you know finding in building solutions you're also prioritizing like the problems to solve right because you're not just delivering the solutions on time right you are making sure that you are delivering the best possible solutions for the customer and actually delivering and value but I think when you abstract away even more I think a good product manager doesn't jump straight to the solution you're thinking about okay what are the most important problems to solve for the customer right instead of saying here's a bunch of ideas you're thinking okay what am I actually trying to solve and then you draw or derive the ideas and solutions from there yes does that make sense yes so so a product manager is the scope of a product manager a good product manager should not simply be the solution to the problem it is the definition of the problem itself mm-hmm the one step before that that is even more critical and that's really what separates the average to the good product manager is like let's not even talk about good to great yet because that's that's that's another topic I think we should we should move on after this but the baseline what makes you a really good product manager is being able to identify and constantly question the the problem itself and whether or not you're actually solving the most important problem for the customer in the business right now because and I think another question I like to ask is you know it's not it's very easy to say yes this is an important problem to solve but it's harder to justify like why solve this problem now versus everything else right that you could be solving why is this important to do right now mm-hmm relative to everything else I think that is also another way to look at whether or not a product manager has reach a certain level of maturity that seems like a really huge amount of responsibility yet I for product manager pressure I mean so then what is the relationship of that product manager who does a product manager report to right if you if you are supposed to be in charge of that entire problem set whatever scope you define it cuz you can have multiple problems right multiple products and the organization you can split it but who should be the product managers boss that's a very hard question to answer anything and one we have not you know completely figured out a cut under answer two even here at gojek ring it really I've seen this vary across different types of companies and different sizes of companies I've seen product managers a very small startups report directly to the CEO I myself as a product is director have report directly to the CEO who's also overseeing not just product management but IT and data right we're an engineering with chief information information is not innovation okay yeah incorrect information um I have seen in other models you know if a product is in charge of a suite or portfolio or group of products that also have a business counterpart them actually reporting to the business em rule right or you have a chief product officer overseeing all the all the different product portfolios and I've also seen that model is there such a thing as a kind of a limit to how big a product should be and should have a product manager like is there like a minimum size or a maximum size how do you start deciding how many product managers you should have in your organization I'd say it's a massive problem that we face in gochang as well I mean we don't have the exact answer but how should we start thinking about this about should you have groups of what we have been some some of our organizations as group PMS right where it's kind of like a higher level p.m. that under them are a few PMS yeah but where does that unit stop should we just continue to split products again and split products again and then you have junior PMS underneath PM's right and then maybe junior junior PM's anything where does that stop where it is that unit series they know we should stop this is the level that we want to have a product manager at and not break it down anymore and also vice versa how much can we group together product manager so I'm talking about the org now yep hmm this is a really good one I think there's a few ways of laying it and Kevin you'll fit it in chimed in I feel like I've been talking a lot one measuring stick I have is the number of developers or engineers that you have I think there is a healthy ratio that is manageable for a product manager for delivering software products and how many engineers are on that team or stream I find in my experience that one product manager two four to six to eight max engineers I think is a reasonable ratio depending on how experienced you are as a p.m. write anything I think under four or five developers per PM you actually you know don't have enough developers I think to support the stream where I was like anything beyond eight or nine engineers per p.m. it starts getting very difficult for the p.m. to keep up with the pace and velocity of the engineering team hmm so that's one measuring stick that I have what what Kevin used to tell me in the being of the day there was this theory about the team of five meaning no teams this was specifically in engineering right okay we should have no bigger teams than five you want to talk a little bit about that and how that relates to that product management unit and why there's this magic number five yeah you shouldn't go beyond I think it's more of a principle and a guideline than a hard and fast rule but as the invention I think we when you when you get enough when when you have a too large of a team doing something it ends up becoming the the management overhead starts becoming significant enough that you spend less time thinking about the problem and more time managing and so that boy do we know it yes yeah we definitely do right and and there's nothing necessarily wrong with spending more time managing than executing but when you're trying to ship products out to the customer that thinking time is something that is necessary to have obviously to prioritize the right problems to solve it and have the right solutions to those problems so I think just having those smaller teams allow you to kind of have that ratio of like managing to actually thinking about problems and executing on that problem in a productive in a productive way and I think the other but the other that the other thing that I kind of think about when structuring product teams is that one is yes there's a function of like was a talent that you have available right like you how many people do you have how long will it take to onboarding people and also you know given where we are in the world right now the availability of experienced engineers and product managers so there's a lot of things that kind of go into what the ideal team size is that you know isn't just about a ideal theory but but also about availability but if one can be just like ideal ideal I mean for me ideally and and I have I it's not Universal there's some disagreements I have with with people on this but for me I would actually like to boil down this the smallest unit of user experience ideally to a small team so in an ideal world and in an ideal world where there are a lot there's a lot of availability of talent right what would be an example in go J okay so for example when you order food or when you order a ride there's an animation of a driver that kind of animates towards the pickup yeah and the live tracking yes the life yes what we call live tracking in my view like if we had enough people I would love to have just one pod of pm's engineers and designers just working on that right 1:00 p.m. right yes a pod means a 1:00 p.m. in a few engineers and a designer yeah that's a unit yeah maybe a data scientist right so and and they're there to solve one specific customer problem which is actually to give the customer a sense of assurance and reduce the anxiety of you know when is this driver going to show up at the pickup or the drop-off right and so you define that customer problem which is you know around information information availability around transparency and predictability and then you say okay you know have a crack at how to communicate this information of where somebody is in relation to what the customer wants to do right so that ideally that's what you know what should happen but in our because we have a lack of enough PMS and engineers then we kind of abstracted even higher and say oh we have a PM and a set of engineers and a designer and data scientists to solve the pickup experience mm-hmm right so the pickup experience is even broader right it's not just about communicating information to the customer on you know where this driver is it's also about the physical like how does a driver and a customer meet how how do we provide a predictability around you know when they're gonna show up how do we create easier ways for a user to select where exactly they want to pick up right so that the problem becomes bigger okay I like that you so it's it's again whenever in doubt about how to scope something always go back to the consumer experience right what is that kind of chunk of user experience that is similar enough that you can count as a single unit right so for example that waiting to the driver gets to you that's a distinct experience once the driver has picked you up you're on a different stage that's right of that user expanse and therefore the objective is different they're different balls that's where you can put a new pod with a new PM it is really interesting just before I want to ask you a question but before that I just wanted to make a note that that kind of magic number of five six people as a team as an organized pod you know by the way this is not a ratio or a number that is only reflected in technology or in companies you know there's been lots and lots of articles and books discussing about how Special Operations military teams are the it may be seals for example acceptor aware where these are the optimal breakup points that you can execute something in the most effective way so there's there's many examples of doing these pots optimal pod sizes just really interesting now we just described me that the pod it seems like the focal point of the pod is that product manager that product manager is the one responsible for defining refining the problem statement prioritizing the key feature sets and somewhat project managing the execution set delivery so why isn't the product manager the boss of that team is the product manager the boss of that team which means are those engineers should be reporting to that product manager or no no are you sure because a bunch of product managers think that their engineers are theirs and they're there one down so let me get into the next common misconception okay I think a lot of people feel that the job is a glamorous one where everybody reports to them right and you have full authority over what happens within that team to me that has never been the case and the mark of a good product manager is being able to lead by influence and being able to persuade people on their team who don't necessarily report to them that in fact this is the drumbeat that they should be marching to because they do believe that it's a right customer problem to solve right that's another I think hard to measure characteristic of an excellent product manager and in all my previous companies none of these other functions report up to the product manager you literally do unless you have product managers as your one down so for example a more senior product manager having a couple of associate product managers directly reporting to them there is no company I've worked for where the model is the other functions of that pod reporting up to the p.m. like we all lead by influence not Authority why is that it seems like such an impractical thing you've got you know you've got a pod that has to deliver from the company you're in a very competitive space yeah you have crazy deadlines and timelines why not just give full authority and power to the product manager and have all those engineers or scientists or analysts report to them what's what's wrong with it well because I think ultimately that actually goes against I think it doesn't incentivize versus well the product manager to think about you know whether or not this is actually the right problem to solve it makes it too easy to say hey you know what what I say is ultimately what's going to happen so I think it doesn't incentivize the right behavior secondly I think because the role is multidisciplinary right and like the other roles within that pod are more specialized in technical you know the PM doesn't necessarily know like what the technical constraints are for exam well they don't necessarily know what the correct methodology is they're not even an engineer no and like have never been an engineer and even if you spend a ton of time with customers you don't necessarily know what the correct research methodology is to like conduct you know a type of research to answer a specific type of question or what stage of the product development or you know if you're not an analyst right you don't always know if you're like actually analyzing something correctly and like getting statistical significance I would expect actually a good PM to do you know some bits of that but you know all these other specialized functions are there to inform the product manager to make the best decision so they the PM should not have authority to tell them how to do their jobs right but influence them to like want to build the same thing together how important is it to have on the engineering side right this relationship between the product manager and the engineers seem to be tantamount this is the most important relationship right now how important is it to have one person or one engineer there what we would normally call the tech lead to be the counterpart of the PM on the engineering site that will then and usually that tech lead will then the engineers will report in to that tech lead but he's also an engineer so engineers should always reports engineers not to product managers so what do you what do you think about that you think that's the right way of doing it always having a tech lead I think engineer lead it's very helpful to have a counterpart like that within a pod and and the most successful I think pods or teams that work for AI have a counterpart which is the tech lead okay and what's that relationship like what isn't what is a good relationship between the tech lead and the product manager is it kind of the same relationship that a CPA would have to a CTO if you take it to the company level was it different it's a good analog I think I see them as peers I think the best relationships I've had with tiel's are ones where we respect each other as peers and there's enough psychological safety to be completely transparent to each other and also call each other out right same with like my design leads right some of best work I've done is when I'm actually trying to pursue one path for example like I'm trying to optimize a certain metric right so I'm like you know I think this is the best solution and I did a bunch of estimates I think we're gonna be able to move this metric by this much right we should go for this and prioritize this in our next iteration and the designer or the tech lien will challenge me saying yes you know those are pretty solid estimates but at what cost have you considered you know this engineering constraint or are you actually doing right by the customer have you considered these other solutions that might actually be about our customer experience right so I think having those partners to challenge your assumptions and having a safe enough environment to have those conversations is pretty critical what do you think is the number-one topic of conflict between the technique and the PM experience what is the number one okay 80% of the fights what are they about I think it's usually when you have teams of smart people you don't always agree you know you know in a culture where like ours where we encourage people to speak up we encourage people have having access to research and data the same research India that everyone has access to people built their own opinions right so I think one one particular kind of type of conflict that you see is that in a way an engineer might see the customer problem you're totally differently based on the same set of information or different you know adjacent like sets of information and think that you know the product manager is not actually solving the problem or prioritizing the right problem and then you end up with a situation where there is a bit of a deadlock right where engineers says hey this is the right customer problem to solve we should work on this and here's why I think that and think something else and you end up in a fairly difficult situation because at the end of the day it's the engineer and the engineering team that needs to build the thing right and because it's a craft right it requires buy-in to build the thing right you at the end of the day you know engineers are actually building this thing and if they don't believe in what they're building yeah you know how much of their heart and soul are they gonna put into building it how much will they you know spend extra time thinking about how to even improve it as they're building it and as a result you know when you kind of end up in these situations and you kind of just push through sometimes things aren't built you know the right way I think that's one common issue that that happens another one another one that happens I see is we is usually when the product manager still has somewhat of a project management type mindset where they think like okay you know we want to build X and engineer says okay cool I agree let's build it it's gonna take this much time and then the product manager then sees his or her job as like oh you said it takes six weeks do it in three right and it kind of like and so you end up in this like a situation where it's more of a negotiation right it becomes a negotiation of like oh that's the timeline so then my job is to shorten the timeline and so you end up with also these uncomfortable situations where the engineer feels like you know the problem and it doesn't realize what exactly he or she is asking right and so these point I think when she was alluding earlier to that you kind of have to have a little bit of understanding okay every little of every discipline that you work with because oftentimes in that situation engineer will say that makes no sense like there's no possible way we could do it there and that in that time period and then you kind of end up again in a deadlock where the engineer feels like you don't know what you're talking about like and then the product manager just feels like oh you just want to free up more time for you to do work right and so sometimes there is this that comes in a kind of a low trust type of environment and so I've also seen that a decent amount of time yeah when we got started right if you remember correctly we used to do that to our product managers all the time Brad miters come in and say like okay after lots of discussion we think we can pull this off in like one month no you have one week yes yeah I gotta go now yeah I'm glad you don't do that anymore we don't we don't do that anymore but you know I think that point emphasizes the importance of the confidence of the product manager the product Matt a good product manager will not only be able to get alignment in the team but a good product manager because they are generally the ones that will interact with a business leadership of the organization whether it's the group PM or the GM or the CEO or the founders wherever right they will interact a lot with with the senior management team I believe and if you don't have someone with the courage to say no and the courage to defend both the tech leave engineering interests are even the designers interest in their team then you're gonna have a really big problem so like you said a good product manager has this intrinsic should have this intrinsic or learn capability to collaborate but they also need this fortitude and courage to say no and to be able to rationalize and somewhat play a protective role to their team right and that's why you really need high integrity in product managers I think if I had to pick one craft out of all of those that would need the highest level of integrity in my opinion it would be the the product managers like the threshold of our integrities is much much higher I would say than even any of the other crafts so because of the vagueness of their job right and the complexity and they Dependencies you had a point before but I cut you off was that related to this I have lost the point I will come back if it's important because I want to have a quick discussion around that relationship like we mentioned the relationship with engineering and the tech lead an attention I'd like to shift gears a little bit and talked with the designer okay this is a really interesting dynamic right it's also timely you know what's happening right now we have we have some interesting tension yeah it's interesting conflicts let's just call it what it is okay it's not sugar coat yeah you know in you know there is this interesting I'm just going taking one step back the the whole paradigm of the product manager function versus the engineering function you know there is some people who say that you know they're both both of them have to look to the customer right they're solving a customer problem right but if you have to kind of segment the element that they are accountable for some people say that product managers are most responsible for the user experience of that feature or app or whatever it is and the tech lead is responsible for the scalability and reliability of that oh that's slightly imperfect yeah you know but it kind of gives some kind of a guidance sure to what each of them kind of are in charge of because there needs to be some separation but some level of separation of accountability right right now what about designer and p.m. first of all what are the main fights about what is the split of responsibilities between them why isn't the PM the chief designer of that product you know like there's a technical element but I'm sure there's other there's more to it and what is that what is a healthy working relationship between a PMI designer and what is an unhealthy working relationship well I think one of the things that we've observed is that some some PMS are more design sensitive than others and usually the the tensions and conflict arise when PMS might be less designed cetera and what that means is that some often times when you kind of design what designers want to build a helped build a product you'll be well as designers to try and create great designs delightful designs things that you know might be less directly kind of utilitarian like it's not just about oh that's how you want to search box it's just you know a box and you can put text in it right but designers will want to say like hey you know should what should the drop-down for the search box look like you know should the search box just be like a box or should have rounded corners because that's how it fits with the rest of the aesthetic of yeah and what happens when somebody in puts a search that doesn't work right should there be something that kind of communicates a bad search query and somebody who's kind of product management that's utilitarian which is kind of like oh do a pop-up and says you're you know your search failed so the and when you have a finite amount of time and bandwidth from your engineering team their product managers that might not have more design sensitivity might just say hey you know I have this much bandwidth why should I spend more effort on making that search effort delightful if you know it works when I have a massive back exactly your features that I'm already behind on exactly right I want to I want to do ok search is done cool let's go move on to the menu selector well what we did in go-jek was a pretty aggressive move what me and you decided was we gave the lead designer of every product 10% of engineering capacity by force yeah you remember this okay we just means controversial ok it's a very good rehearsal so why do you think we did that and was that was it aggressive does it make sense or and is that a failure on the product managers of go-jek is the reason why we implemented that just to be clear what we did was we basically said that every designer a very that's attached to a product or the lead designer it's actually the product gets 10% say on what gets prioritized from an engineering perspective in order to create user delight right yeah that may have nothing to do with the okrs you know right or you could just be hygiene or a doesn't even out and be delightful it's like a product dead yes similar to tech death yes there is a tiny thing you want to improve that might not necessarily move a needle but overall contributes to like a cohesiveness of the product for example that's right for aligning things that should look the same that are not the same right yeah I can't argue that's gonna help my ok ours yeah but it looks weird right it looks weird and these kind of things don't get factored out in little cares I can't put on the ok are make everything look nice because it's really hard to track but a designer knows what nice looks like and can defend that has that created conflict in the organization I mean you tell me what how what what what what have people in the in the design team and in the product management team in the engineering team think about that 10% rule honestly if it's if it's a problem it's the least of my worries right now there are other fires that I think people have elevated to me more than that so I think it might actually be working I don't know maybe I'm missing a point but I think it seems fine for my end ok and if it's not people should have talked to me about it right some some product managers you know kind of grumble a little bit yeah I mean haven't they they're prioritizing their problems to me yes that's a good product manager should do yes I mean any from me it's more like absent like hey things are that are bothering me right yeah and some some PMS have have have mentioned to me that some PMS have mentioned that it might be a little bit too prescriptive right I think a pony in that word wasn't used yet but but but prescriptive in the sense that you know it shows some to some extent like like you said a lack of trust yeah right it's like hey like we're in charge of many areas why we did it right I mean and it is because like historically I think we've we've over indexed on kind of launching things and and and the function and the utility rather than you know making things delightful for the user however that's measure if even if possible right so yeah can you talk a little bit about that about the tyranny of MVP talk a little bit about there's like a counter-wave yeah yeah yeah internally like before it's all MVP MVP and now there's a counter wave against the tyranny of MVP thing when I explained that yeah I think you know from I think we you know just because everything just scaled so quickly and we expanded into so many different types of products and businesses so quickly that kind of the culture that was formed was just like hey I just I think we need to clarify for the people that don't know what MVP means it's the Minimum Viable Product that's right it is the concept of launching something that's good enough yeah in order to test and then build on top of that right it's kind of this agile mindset of you know it doesn't have to be perfect yeah but now we have a bit of a mini revolt a healthy revolt it's not like a native revolt it's a it's a it's a healthy kind of dissenting to the MVP concept so yeah please continue and and so because you know we we are in so many different things and the more you kind of increase the surface area of things that we do that longer exponentially longer the backlog then becomes so every it's almost like you know the PM's just like okay there's this problem we were trying to solve this problem we launched something it seems him move metrics okay cool what's next right and so there's always like this is a constant like going from like a product or feature to feature even though they are thinking about what's best for the user there's this quick kind of like impetus to just kind of move on to the next thing once we feel like we've kind of moved the needle significantly enough and and I think the problem that's kind of come up and why a lot of the designers were upset about about that was that they felt like product managers didn't really take into account going the next step and making sure that the user actually feels that sense of delight or as you know the unmentioned there's a certain cohesiveness to kind of how everything is put together and looks and feels and and that you know revolt the way you put it it's been harsh but is is I think yeah I think it's something that you know we we did welcome right I thought we wouldn't have kind of pushed through the idea that they have to spend you know 10 percent of their time but I think again the grumbling does come from yeah just like hey I have a limited amount of bandwidth and you're you're permanently shaving that bit of bandwidth yeah I think it also like depends on what stage of the company here and right if you're if you're already a really really big company then the damage caused by MVP consistent MVP development especially when it's not even a good MVP that in itself the threshold of what is good enough to release can be very wide right and that's dangerous as well but there is a certain level of size of a company in which you you can't do that and we're like we're not a tiny startup anymore right there are customers demand a certain level of quality from us every time we release let's let's kind of turn a little bit into now the human into the actual product manager itself yeah how many product manager interviews have you had in your lifetime I've lost count roughly hundreds probably like him though like hundred ish that's a lot with us for 10 years that's way more than me so tell me what are you looking for Oh first of all let's do this what are your red flags when you're interviewing a product manager what are your red flags um I think if communication in the interview is a problem right if this person can't articulate clearly ideas or concepts that he's trying to get through to me that's a red flag because I think being able to communicate your ideas and customer problems and other kinds of problem statements and then how are you going to solve them that's that's something you need to do even if it's like at a feature of level right so if you're having trouble answering my questions in an interview because you can't articulate ideas that's a pretty big red flag and for me like when you're communicating articulations kind of like a big thing like what is it about community communication part that matters most is it is it clarity of concepts is it structured communication bottom you know like pyramid principle communication like what what are you looking for in that communication piece um a few parts I think the structure of their answers right being able to like break their answer down into a structure way that I can follow that's one active listening is another one right if I'm asking you know a couple of specific questions and they kind of go off on a completely different tangent and aren't checking themselves and I have to really pull them back that's sort of a red flag for me because that means you're not necessarily listening to what I'm saying right you're just kind of talking over me and that's a red flag for me in any role really because I look for communication as a kind of a core value for me I've rarely found people who communicate very concisely and structurally that aren't actually good active listeners it's weird sometimes there's a lot of good talkers good talkers there's a lot of good talkers who are really crap at listening there's a difference between someone who's good at talking and polish to being a structured communicator right this is a big difference you can have the most introverted person be the most incredible in fact I think in go-jek there are many more introverts who are excellent and concise communicators as opposed to the extroverts who are very salesy or polish but actually are not as good at structured communication but I like your point about active listening that's also one of my things that I look for in general but those seem to be generic you know like I feel like those two are super important for every role what's specifically in product matter because I asked what your red flags alright so are there any other red flags yeah specific to product managers I think when even after coaching in the interview for example I'm like okay I'm nudging you towards a certain type of answer they're still not getting it specifically around when they're just always jumping to solutions right and I'm like what's the problem you're trying to solve can you and I'm nudging them in that direction without explicitly asking them like hey what is the problem right because then it's easy right that means they're not thinking about the problem right they're trying to solve what's a business problem you're trying to solve what's the customer problem you're trying to solve and if all you're doing is just like giving me a bunch of features and ideas and solutions without clearly articulating to me what problem you are actually trying to solve and how you're going to measure it that's a pretty red flag for me if it's an interview for I think not an entry-level position right because I think it is a very common thing to just like hey product I'm designing products and features you know early in my career that was how I treated products as well because I was working on individual features people explained the problem I was trying to solve and then I would figure out the best solutions right so that's fine at certain level so it really depends on what level I'm interviewing for - that's really interesting there's this you know really popular book by Daniel Kahneman called think fast things slow and I feel like for for product managers the ability to think slow mm-hmm is one of the biggest advantages product managers that do not have the patience to actually pause their thinking right like you said instead of jumping to the solution figure out first when redefining the problem first and not and restraining the the natural inclination to want to jump to the solution every every human it's human nature to want to jump to the solution you want to be that smart person who figures it out right whether you're in a conversation etc you know I've fallen prey to this too many times myself but great the good to great now right the great product managers that I've interacted with will very rarely jump to conclusions in a discussion but continue to ask more and more questions and then when they're comfortable will then have a hypothesis right they withhold their hypothesis until much later have enough information to even put together hypotheses yes yes the opposite is also very bad where they they are like analysis paralysis which is another thing you may want to elaborate about but even in a in a non let's say we're not discussing numbers or data in a specific conversation but we're talking about conceptual things about a consumer even then that the speed by which that person comes to the conclusion matters a lot to me it matters a lot to me yeah so I thought I would add that part any other red flags you have any red flags yeah I one one question I often ask interview product managers to talk as I usually ask to talk about products they like and this could be you it could be an app yeah it could be hardware I mean it could be like a phone somebody talked to me about their car and I think one thing is you want to look for people who genuinely love products yeah they need to love products that solve problems and it doesn't have to be a tech product it doesn't know be any product it doesn't I had one person talk about his cars mirrors Wow his cars side mirrors side mer his side mirrors and like how how it was placed an angle next to the door that max that minimized the blind spot why did you love that oh I like was that great for you well because it you know it combined a lot of different things right like one is that there's an attention to detail right most people I mean if you kind of look at your mirrors you can look behind you and it prevents you from getting into accidents most of the time then you're good right is just a mirror yeah but then you know for somebody to kind of look at it I think most people won't even see it as a product no right now exactly we see it as a unit of product No yeah they'll see the car as a product but right that mirror exactly exactly and so most people wouldn't even think about it as a product most people wouldn't even think about like what is that mirror there to do right they just kind of seem like yeah cars and mirrors my car is a mirror cool right but this person actually mentioned that his cars mirrors were especially good at catching blind spots considering the design of the car right and so I thought that was great I think a lot of people that are asked this question sometimes just go to whatever is the sexy product at the time right like a few years ago a lot of people said oh I love snapchat okay but I think it's the ones who can can really explain like and I think saying you love snapchat it's totally valid but you know what exactly did snapchat bring to the table that was new that you know solved a specific problem yeah so you know if somebody would say snapchat I think the minimum level of of explanation that I would expect this oh you know talking about how you know the world today in social media everything is recorded and there's not this concept of like things that are being ephemeral and how it prevents people from living in the moment and now with this new interface now you can actually kind of capture those informal moments which I should represent a majority of human life that type of stuff right like it's the minimum the minimum is you expect something to really understand like what problem is it solving not you kind of like some new sexy feature yeah right the why yeah and and I think that's actually I actually find that missing actually a lot of times it because I think right now there is a certain level of glamour or sexiness to like the product manager because you're building cool products that could use my millions of people but then you you miss out all right now it's really hard to find as like people who really love the craft yes hey that's and that's I think what's instead of the glamour exactly right so it is very glamorous it is you get to tell your friend no no the work is not glamorous but to the external world it's like that's my product it's true right yes they get to say it's my product it is becoming the dream job for most MBAs now yeah consulting thank you so people that don't know what they want to do but want to be intact they're like I could be a product manager right yeah that was me oh my god I just happened to be the founder as I got lucky I got the step out of that before anyone noticed how bad I was at it I think that the you know what you said about that attention to detail right if you asked someone who said or you're trying to assess someone's writing capability and you ask them what you know how often do you read a book and the person says like I read one book every like three months like that in itself and and make me do a very cursory overview of that book like you're gonna have a question mark right people you have to love the products that you use for you to to show some potential and how good you would be at building product mm-hmm right you don't necessarily have to demonstrate that you've built one but you need to demonstrate that you've thought deeply about the products that you do use you understand why you love it that's right so that self reflection is a critical skill it also means that you pay attention to quality that's right yeah not just detail what what is the next what what is the business performance rationale - attention to detail because quality is all in the details that's right reality is all in the details it is in the massaging every little part of that experience in a thoughtful way that adds to the grid to this amazing experience overall yeah and that's hard it is hard it is hard to not not that many people care but you can also overshoot that quality by being too detail that's your said and there are some product managers that never want to release the product like no no it's not ready yeah it's not ready and I'll get it out yeah I'm usually on that side after yeah the equation cuz it's good enough it's good enough now I'm pulling back I'm going to the other side of the equation and saying Lee no no no this has to be much better when it gets out like yeah like no joking around now and so those are the things you're looking at for me I have a few things that because I've done some not as many as you but I think both of you have done probably more product manager interviews than I have but what I am looking for in product managers especially when it's a more senior level you know what I'm looking for is actually ability to think two or three steps ahead okay this is one thing that you know for me is extremely important because one of the most constant things constant truths about product management is the unpredictability of your work it is massively unpredictable okay and so first of all if you get shaken by unpredictability very easily emotionally don't pick product management right unless you've read it yeah it was brutal right I mean you know you you you do something you think you're brilliant and then nobody uses it yes so you gotta have a touch again what do you do when do you kill a product oh my god it's one of the hardest things by the way to kill a product but I think that that that mental first of all the mental resilience is very very important but because of the unpredictability people who are very good at contingency planning if this then that if that then this doesn't is that creates a calm in the team that creates the ability to know that if things go wrong we have a plan B we have a plan C plan D and there are many people that just intuitively don't do this right they shoot first from the hip and they don't have this planning capability so it's this weird combination of comfort with uncertainty but with the structured planning of different scenarios all right this is the great the good to greet p.m. from my perspective and finally I would say what I'm looking for when I'm interviewing a great product person is a sense of disgust this is also very important a sense of disgust at products or services that are just like this is not up to par with what I expect from a service like this there is a so it's not just the oh I love great products there's this should be also complemented by a sense of god this is unacceptable right this is this level of quality is unacceptable and without that frustration I feel like the the motivation to fix things that are you know may not exactly may not be delightful to the ordinary not at sit directly though care will be very low the quality level people who have a very high bar of quality will always get frustrated by by low quality products even if you don't necessarily do something about it immediately but you know that feeling is there and I can tell when it's there and a person like you just have to tell them like describe a product that you hate right and then just see how emotionally involved they are about it that's usually a good sign frustrated people with low quality good thing final point that I wanted to just touch upon where do you find these great product managers what's their background because you know product management is really interesting we don't hire entry-level product managers at least now kojic doesn't we we would never accept someone fresh out of university with no job experience whatsoever into a product manager role and we don't have the luxury of hiring people only people with product management experience all right so this is a very interesting thing so where do you find them what are the professions that are high potential that you've realized mmm what are you looking you know when you mentioned those six crafts right that go into building a product those are good places to start I think is one like in 10 years engineers researchers too designers right analysts because usually they have actually already worked with a product manager before so they're familiar with that role already so that's a big plus right they know what goes into building a product they just don't know maybe the day-to-day skills needed to be a good product manager but at least they have that context already hmm so I think that's a really good place to start especially if you're looking internally and then they also have the company context which is a big big plus I can you really think an engineer can become a good product manager absolutely yeah yeah is it what about a consultant what about the non-technical crafts got like a management consultant or where would you look first if you had you know topic where do we look honestly I would cast the net very wide some I just presented on this Ashley attack in Asia I like put the slide on with like six to eight like profiles of like some of the best product managers I know in real life they worked for you know Google Facebook ooh BRR Kea and change org here in Kojak right and we look at those backgrounds wildly different from electrical engineering right to software engineering something interdisciplinary like um like symbolic systems that stand for and look it up also my major also Marissa Mayer's major by the way and so someone was a translator a professional translator a translator yep before they turned to product management and she's one of the best I know right so there's like no hard and fast formula here I think you look for those skills right that you think would make a good product manager and then you you prioritize I think areas or you think you're more likely to like be able to find them so like start with the crafts that are adjacent to product management start internally you know in your company and then start expanding outwards and management consultants yes absolutely they know I understand business some of them have worked with product managers right so there is no one right answer I would say and I mean you've been in charge of this hiring process and the overall kind of health or the functional organization what are you thinking in terms of home growing product managers from within the organization itself I think it needs to be a priority we just have not had I think the structure to support it because what you don't want to do right is have people transfer in who are not PMS or people who are entry-level right whose join us from outside and there's no support structure to like mentor and grow them so either they're really struggling right to like move move up in the organda skills that they need or they just fail right either they're like succeeding but like at a great cost right on their own or they're not succeeding at all when they really potentially could so I absolutely think that we should be doing that some of the best companies that we know in Silicon Valley in the Bay Area do this right like Google's associate product manager program is pretty world famous really growing some of the best PMS Facebook has a similar program now uber has built by actually I think one of the PM's who basically grew up within the Google system right so I think we absolutely need to start investing in that right I think the internal of the internal one is the internal hire or internal transfer route is one that's interesting and I think we have a few interesting ones that I know and one person he used to be an operations manager actually so his job I believe at one point was to just basically manage the office and make sure that we could onboard enough drivers and now he's actually a product manager and our transportation product group and he's actually doing really well and is one of the rising stars within the organization and so you can find them anywhere I think I think that the the definitely I think that the probability of conversion and success is probably highest and those kind of adjacent those adjacent crafts but it seems like the variability is high enough that basically anyone can kind of can kind of do it if they have the right mentality thought process mindset and also importantly like attitude rather than humility for example I think I think one of the there's always and also it also depends on what exactly is a type of product right like the some products with more consumer facing some problems are more technical and it also kind of depends and that's why you know I think this whole field is very interesting because it's a pretty new feel for especially I think the concept of product manager may not be a new one but the concept of like a software product manager has kind of dramatically changed over the last couple of years as even the the you know the the form factor has changed primarily to you know like smartphones from from from you know desktop the emergence of ml machine learning techniques also means that now that's another component to product managers potential toolkit and so there's like all these like basically as a the the discipline seems to always evolve as technology evolves right because you're building products that are technology products so that also means that you know because the role is always evolving the types of people who are good fits the types of people that we should be thinking about pushing into the discipline also kind of evolve so it's always it's it's it's in very inclusive in one sense but it's also very demanding on the other so I think the the field is is kind of very excitingly vague right for that purpose yeah I haven't seen too many books on it right there's a bunch of engineering books and materials and stuff like that I mean product management is a little bit more niche right it's cuz it's a little newer especially because it's mobile now it's pretty much all mobile like at least with with the big big unicorns I think I want to end this session you know with one thought that you know you know how I know that we have great product managers or you know when I am I'm using me and in general saying like when a CEO or a founder knows that you have great product managers if you have great product managers you should feel stupid from time to time as a founder and CEO right now that's that's how you know you've got great product managers when you throw out a an idea that you're so confident about or you throw out or you or it's a rant about something that you think you know it's so easy to do it and then your product manager calmly and politely explains how you're wrong and then you feel okay alright I should have thought that one there a little bit more or I should know more about my product those are the little indications that your product management organization is doing a great job when they are able to correct the course of beliefs held by more powerful people in the organization right and that's where me personally my greatest learning with working with great product managers is to always prioritize evidence over belief and to know the difference between the two thanks so much guys until next time [Music] hey guys hope you enjoy the podcast if you liked it please hit like subscribe and follow us on social media thanks so much for tuning in [Music]

Loading