Juli 15, 2019

Episode 10: Fantastic Product Managers And Where To Find Them At GOJEK

Episode 10: Fantastic Product Managers And Where To Find Them At GOJEK

Intro: Welcome to GO FIGURE. My name is Nadiem Makarim, CEO and founder of GOJEK Southeast Asia's first Super App. GOJEK does ride hailing, food delivery, payments, even on demand massage. You name it. We 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 we don't like. There's a lot of myths out there that we want to dispel. So keeping it real is kind of our mantra. Hope you enjoy.

Nadiem: Hey guys, welcome to GO FIGURE. Thanks for making it today. We have, Kevin, our Co Founder as always.

Kevin: My third time here.

Nadiem: Yeah, you're regular now.

Kevin: Yes.

Nadiem: And we have Dian is our SVP of Product Management and Dian had a lot of experiences in both Silicon Valley as well as in Africa.

Dian: Correct.

Nadiem: All related to product management and product managers. So today we're going to talk about the topic of today's discussion is product management. The title of our podcast is great product managers and how to find them. All right.

Kevin: Fantastic.

Nadiem: Sorry. Fantastic product managers and how to find them. Correct. Correct. Um, 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, uh, you know, technology companies, software technology companies that are most kind of predominant in this. Those six crafts are, uh, software engineering, uh, research design, a data scientist, um, product management of course. And what am I missing here?

Kevin: Well, I think there's a, there's a subset that of, or a subset of data scientist sometimes that aren't just specifically for analysis work. So, and right.

Nadiem: Analyst.

Kevin: That's right,

Nadiem: The analyst, uh, craft. And so we're talking one out 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 to kickstart.

Kevin: Sure, why don't you start Di.

Dian: Okay. Well, um, we call product managers PMs for short a lot of the time, right? And that often gets misconstrued misconstrued as project management. And people use that interchangeably. And I think while there's quite a bit of overlap in skill sets 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, um, good project management skills to be, uh, an effective product manager, but they are not the same roles.

Nadiem: Okay. Can you explain that? Like, what is the fundamental difference between a project manager and a product?

Dian: In my mind and in our frameworks here at GOJEK when we describe the difference between the two is I think, uh, with program and project managers, you know, the product that you're building is, you know, for the customers within the company, right? Like you're 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 can be the merchants that we're building for our riders, our drivers. But inherently you're building products for end customers and you're also, you know, responsible for delivering those, um, products on time sometimes with the help of a dedicated project manager. Does that make sense?

Nadiem: So your primary stakeholder, your North Star, your, you know, Mecca is the customer is someone that is outside of your organization. Where as it program manager and project manager, it may not be the case.

Dian: Yeah, exactly.

Nadiem: Okay. And specifically we're talking about in this case, software products, right?

Dian: Correct.

Nadiem: That's when we see a product management within tech. It's given that scope. Okay. What are some of the, the things that may be a misconception in the market about what product means? One is that they are a project manager.

Dian: Yep.

Nadiem: So they're doing something with a timeline but they're not in charge and they're not actually paying homage to their final stakeholder, which is the end user. Right. You've already stated that. Are there any other kind of misconceptions about when people say product manager or product management?

Kevin: I think it's worth spending time to talk about that specific. I think common misconception.

Nadiem: Okay.

Kevin: Because it's actually a fairly common one. Um, and then you see a, you see it happen in, in certain companies, uh, where the product managers essentially just in charge of a Gantt chart or like just to set up delivery timelines and say, okay, by this date you have to deliver x by that day you have to do delivery. 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.

Nadiem: Is that what is generally called to be a feature factory? Is that what you just described?

Kevin: Well, some companies you know, run their product organizations like feature factories and it is, it's probably one of the symptoms, right of, you know, feature factory type, uh, products or companies. But, um, 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 deliver on time are considered the ones who are doing well in their job. Um, and if they don't, then they aren't considered doing well. And to these 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 going to ship to the customer. But, um, I think the point around the north star is really that customer, right? Like I think that's 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 product manager because at the end of the day, uh, it's all about solving the customer problem. And so the way that one should kind of evaluate a product managers 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, uh, but I think that's a, that's a really critical misconception, right?

Nadiem: 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. Is that correct?

Kevin: That correct.

Nadiem: That's correct.

Kevin: 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? Right.

Dian: And I think said another way, which I like to, um, like to do is that you as a product manager, you're not just in charge of, you know, finding and building solutions. You're also prioritizing like the problems to solve. Right? Because you touched on this a little bit. It's like you as a PM, right? You have to,

Nadiem: Sorry,

Dian: is that better? Can you hear me better now?

Nadiem: Much better.

Dian: Okay. So yeah, 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 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 derive the ideas and solutions from there. Does that make sense?

Nadiem: Yes. So a product manager is, should 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. The one step before that that is even more critical. And that's really what separates the average to the good product managers. Like let's not even talk about good to great yet. Cause that's another topic I think we should, we shouldn't move on after this, but the baseline, what makes you a really good product manager is being able to identify and constantly question the problem itself.

Dian: 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 relative to everything else? I think that is also another way to look at whether or not a product manager has reached a certain level of maturity.

Nadiem: Oh, that seems like a really huge amount of responsibility yet, right? For product manager, um,

Dian: No pressure, right?

Nadiem: I mean, so then what is the relationship of that product manager who, 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, cause you can have multiple problems, right? Multiple products in the organization, you can split it. But who should be the product manager's boss?

Dian: That's a very hard question to answer. I think. And one we have not completely figured out a cut and dry answer to even here at GOJEK. Right. Um, it really, I've seen this vary across different types of companies and different sizes of companies. Um, I've seen product managers at very small startups report directly to the CEO. I may solve as a product, I guess director have report directly to the CIO who is also overseeing not just product management but IT and data. Right.

Nadiem: What's CIO?

Dian: Chief Information Officer

Nadiem: Information not Innovation. Okay.

Dian: Yeah, correct. 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, um, that also have a business counterpart, them actually reporting to the business kind of GM role. Right? Or, uh, you have a Chief Product Officer overseeing all the, all the different, um, product portfolios. I've also seen that model.

Nadiem: 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? Right. I'd say say it's a massive problem that we face in GOJEK as well. We don't have the exact answer, but how should we start thinking about this? About should you have groups of what we have in some of our organizations is group PMS, right? Where it's kind of like a higher level PM that under them are a few PMs. 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 PMs underneath. Where does that stop? Where does that unit say we say, no, we should stop. This is the level that we want to have a product manager at and then not break it down anymore. And also vice versa, how much can we group together product managers? So I'm talking about the org now.

Dian: Yep. This is a really good one. I think there's a few ways of looking it. And Kevin, feel free to chime in. I feel like I've been talking a lot. A one measuring stick I have is, um, 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 to four to six to eight max engineers I think is a reasonable ratio depending on how experienced you are as a PM, right. Anything I think under a four or five developers per PM you actually, you know, don't have enough developers I think to support the stream. Whereas like anything beyond eight or nine engineers per PM, it starts getting very difficult for the PM to keep up with the pace and velocity of the engineering team. So that's one measuring stick that would have.

Nadiem: What Kevin used to tell me in the beginning of the day, there was this theory about the team of five, meaning no teams. This was specifically in engineering. 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 of five. Oh, you shouldn't, you shouldn't go beyond.

Kevin: I think it's more of a principle and a guideline than a hard and fast rule. But, uh, as Dian mentioned, I think when you get enough, when, um, when you have too large of a team, uh, doing something, it ends up becoming the management overhead, uh, starts becoming a significant enough that you spend less time thinking about the problem and more time managing. Um, and so that

Nadiem: Boy, do we know?

Kevin: Yes. Yeah, we do, definitely do. Right? And there, there's nothing necessarily wrong with spending more time managing than executing. But when you're trying to ship products out to the customer, um, that thinking time is something that is necessary to have, obviously to prioritize the right problems to solve 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 way. And I think the other, but the other, the other thing that I kinda think about when structuring product teams is that one is yes, there is a function of like what is the talent that you have available, right? Like you, how many people do you have? How long will it take to onboard people? Um, and also, you know, given where we are in the world right now, uh, the availability of experienced engineers and product managers. So I think there's a lot of things that kind of go into what the ideal team sizes that you know, isn't just about an ideal theory, but also about availability. Um, but if one can be just like ideal ideal, I mean for me, ideally and I have, it's not universal, there's some disagreements I have with people on this. But, uh, for me, I would actually like to boil down 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?

Nadiem: What would be an example in GOJEK.

Kevin: Okay. Um, so for example, um, when you order food or when you order a ride, uh, there is an animation of a driver that kind of animates towards the pickup, right?

Nadiem: Yep. And the live tracking, yes.

Kevin: The live, yes. What we call live tracking. Um, 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?

Nadiem: 1 PM right? A pod means 1 PM, few engineers and a designer.

Kevin: Yeah.

Nadiem: That's a unit.

Kevin: Yeah. Maybe a data scientist. Right? Uh, 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. Uh, and so you define that customer problem, which is, you know, around information availability, uh, around transparency and predictability. Um, and then you say, okay, you 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 should happen. But in our, because we have a lack of, uh, enough PMs and engineers, then we kind of abstract it even higher and say, Oh, we have a PM and a set of engineers and designer and data scientists to solve the pickup experience. 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 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 the problem becomes bigger.

Nadiem: I like that you've, so, 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 until the driver gets to you, that's a distinct experience. Once the driver has picked you up, you're on a different stage of that user experience and therefore the objective is different.

Kevin: yerp, their different problems.

Nadiem: And that's where you can put a new pod with a new PM. So it is really interesting. Just before I want to ask you a question, but before that I just wanted to make a note that kind of magic number of five, six people as a team, as a, 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. Um, you know, there's been lots and lots of articles and books discussing about how special operations military teams are. In navy seals for example, etc, where at these are the optimal breakup points that you can execute something in the most effective way. So there's many examples of these pots, optimal pod sizes. Just really interesting. Now, would you just described me that the pod, it seems like the focal point of the pot 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 to delivery. Yeah. So why isn't the product manager, the boss of that team? Is the product manager or the boss of that team, which means are those engineers should be reporting to that product manager or no?

Dian: No.

Nadiem: Are you sure? Because a bunch of product managers think that their engineers are there. And they are their one downs.

Dian: Let me get into the next common misconception.

Nadiem: Okay.

Dian: 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 is never been the case. And the mark of a good product manager is being able to lead by influence, um, and being able to persuade people on their team who don't necessarily report to them that in fact this is the drum beat that they should be marching to because they do believe that it's the 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 unless you have, um, 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 or the model is the other functions of that pod reporting up to the PM. Like we all lead by influence, not authority.

Nadiem: Why is that? It seems like such an impractical thing. You've got, you know, you've got a pod that has to deliver for the company. You're in a very competitive space. 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 that?

Dian: Well, because I think ultimately that actually goes, um, I think it does into incentivizes first of all, 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 multi-disciplinary, 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 example, they don't necessarily know what the correct methodology is.

Nadiem: Most of the time they're not even an engineer, right? Like they've never been an engineer.

Dian: No, yea. 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 special ed functions are there to inform the product manager to make the best decisions. So the PM should not have authority to tell them how to do their jobs right. But influence them to like want to build the, the same thing together.

Nadiem: How important is it to have a, 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 side. That will then end, usually that tech lead will then the engineers will report into that tech lead, but he's also an engineer. So engineers should always report to engineers, not to product managers. So what do you, what do you think about that? Do you think that's the right way of doing it? Always having a tech lead, an engineer lead?

Dian: I think it's very helpful to have a counterpart like that within a pod. And the most successful I think pods or teams I've worked for, I have a counterpart, um, which is the tech lead.

Nadiem: Okay. And what's that relationship like? What is a good relationship between the tech lead and the product manager? Is, is it kind of the same relationship that a CPO would have to a CTO if you take it to the company level? How is it different?

Dian: That's a good analog, I think. Um, I see them as peers. Um, I think the best relationships I've had with TLs 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 the 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 going to 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 lead will challenge me saying, yes, you know, those are pretty solid estimates, but at what costs 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 a better 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.

Nadiem: What do you think is the number one topic of conflict between the tech lead and a PM?

Dian: Do you want to talk about this a bit before I jump into it?

Nadiem: You have deep experience in this Kev. 80% of the fights, what are they about?

Kevin: I think it's usually when you have teams of smart people, you don't always agree, right? And in a culture where like ours where we encourage people to speak up and we courage, um, people having access to research and data at the same research and data that everyone has access to. People built their own opinions. Right? So I think one particular kind of type of conflict that you see is that in a way an engineer, might see the customer problem, you know, 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 engineer's says, Hey, this is the right customer problem to solve. We should work on this. And here's why I think that and the product manager will 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 a buy in to build the thing, right? 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. You know, how much of their heart and soul are they going to 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. Um, and as a result, you know, when you kind of end up in these situations and you kinda just push through, um, sometimes things aren't built, you know, the right way. Um, I think that's kind of, you know, one common issue that, that happens. I think another one, uh, another one that happens I see is usually when, um, 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 going to take this much time. Um, and then the product manager then sees his or her job as like, oh, you said it takes six weeks, uh, do it in three. Right? And it kind of like, and so you end up in this like situation where, uh, 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, um, the engineer feels like, you know, the product manager doesn't realize what exactly he or she is asking. Right. And so did these point, I think what she was alluding earlier to that you kind of have to have a little bit of understanding of every discipline that you work with because often times in that situation, the engineer will say, that makes no sense. Like there's no possible way we could do it in that at 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, uh, and then the product manager just feels like, oh, you just want to free up more time, uh, for you to work. Right. And so sometimes there is this, that comes in a kind of a low trust type of environment. Um, and so I, I've also seen that, uh, a decent amount of time.

Nadiem: Kev when we got started, right. If you remember correctly, like we used to do that to our product managers

Kevin: All the time.

Nadiem: Crazy, right? Yeah. Product managers come in and say like, okay, after lots of discussion, we think we can pull this off and like one month, no, you have one week.

Kevin: Yes. Yeah.

Nadiem: I gotta go now.

Kevin: Yeah. Yeah.

Dian: I'm glad you don't do that anymore.

Nadiem: We don't, we don't do that anymore. But um, you know, I think that point emphasizes the importance of the confidence of the product manager. A good product manager will not only be able to get alignment in the team, um, but a good product manager because they are generally the ones that will interact with the business leadership of the organization, whether it's the group PM or the GM or the CEO or the founders, wherever. Right. Um, 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 lead engineer interest or even the designer's interest in their team, um, then you're going to have a really big problem. So like, 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 a high integrity and product managers 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, the product managers like the threshold of their integrity 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 the interdependencies. Um, you had a point before but I cut you off. Was that related to this?

Dian: I have lost the point. I'll come back if it's important.

Nadiem: Because I want to have a quick discussion around that relationship. Like we mentioned the relationship with engineering and the tech lead and the tension. I'd like to shift gears a little bit and talk with the designer. Okay. Oh, this is a really interesting dynamic, right?

Kevin: It's also timely what's happening right now. We have, we have some, uh, interesting, uh, tensions.

Nadiem: Yeah. Interesting conflicts, let's just call it what it is.

Dian: Okay.

Nadiem: Let's not sugarcoat.

Kevin: Yeah.

Nadiem: Conflicts are conflicts. You know, and you know, there is this interesting just going, taking one step back. 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. Uh, but if you had to kind of segment the element that they are accountable for, some people say that product managers are most responsible for the user experience, um, of that feature or app or whatever it is. And the tech lead is responsible for the scalability and reliability of that. That's slightly imperfect.

Kevin: Yeah.

Nadiem: But it kind of gives some kind of a guidance to what each of them kind of are in charge of, because there needs to be some separation. Right. Some level of separation of accountability. Right. Now, what about designer and PM? First of all, what are the main fights about what is the split of responsibility between them? Why isn't the PM, the chief designer of that product? You know, like there's the technical element, but I'm sure there's other, there's more to it. And what is that, what does a healthy working relationship between a PM and designer and what is an unhealthy working relationship?

Kevin: Well I think one of the things that we've observed is that uh, some, some pms are more design sensitive than, than others. Um, and usually the tensions and conflict arise when PM's might be less designed centric. And what that means is that, um, some often times when you kind of design with designers want to build, uh, help build a product, um, you know, well as designers, they 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, um, let's say you want a search box. It's just, you know, a box and you can put text in it, right? Uh, 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 it have rounded corners because that's how it fits with the rest of the aesthetic of the app. And, uh, what happens when somebody puts a search that doesn't work right? Should there be something that kind of communicates a bad search query? Um, and somebody who's kind of a product manager that's utilitarian, which is kind of like, oh, let's do a pop up and says you know, your search failed. So when you have a finite amount of time and bandwidth from your engineering team, uh, 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.

Nadiem: When I have a massive back log or features that I'm already behind on.

Kevin: Exactly right. I want to, I want to do. Okay. Search is done. Cool. Let's go move on to the menu selector.

Nadiem: Well, what we did in GOJEK 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. You remember this?

Kevin: Yeah, very controversial.

Nadiem: It's very controversial. Um, 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 GOJEK is the reason why we implemented that? Just to be clear, what we did was we basically said that every designer that's attached to a product, or the lead designer attached to the product gets 10% say on what gets prioritized from an engineering perspective in order to create user delight. Right? That may have nothing to do with the OKRs. Right.

Dian: Or it could just be hygiene, right. It doesn't even have to be delightful. It's like product debt. Similar to the tech debt. 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.

Nadiem: That's right. Or aligning things that should look the same that are not the same. Right. I can't argue that that's gonna help my OKRs but it looks weird, right? It looks weird and these kinds of things don't get factored onto the OKRs. I can't put on the OKR make everything look nice cause it's really hard to track. But a designer knows what nice looks like and can defend that. Um, has that created conflict in the organization? I mean, you tell me what are people in the design team and in the product management team and the engineering team, think about that 10% rule?

Dian: Honestly, if it's a problem, it's the least of my worry is 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 from my end. And if it's not people should talk to me about it.

Kevin: Well, some product managers, you know, kind of grumble a little bit. Maybe they haven't, they,

Dian: They're prioritizing their problems to me as a good product manager. Should do.

Kevin: Yes. I think for me it's more like absent, like, hey, things that are bothering me. Right? And some, some PMs have mentioned to me that it's, it might be a little bit too, uh, prescriptive, right.

Nadiem: Draconian?

Kevin: Uh, that word wasn't used yet, but prescriptive in the sense that, you know, it shows some to some extent, like you said, a lack of trust. Right. It's like, Hey, like we're in charge of making sure...

Nadiem: I mean it is. That's why we did it.

Kevin: And it is because like, historically I think we've, we've over indexed on kind of launching things and the function and the utility, uh, rather than, you know, making things delightful for the user, however that's measured, if even if possible. Right. Um, so yeah.

Nadiem: Can you talk a little bit about that? About the tyranny of MVP? Can you talk a little bit about how there's like a counter wave. Internally, like before it's all MVP, MVP, and now there's a counter wave against the tyranny of MVP thing, you wanna explain that?

Kevin: Yeah. I think, you know, for, I think we just because everything just scaled so quickly and we expanded into so many different types of products and businesses so quickly that, uh, kind of the culture that was formed was just like, Hey,

Nadiem: Sorry. I just, I think we need to clarify for the people that don't know what MVP means, it's a Minimum Viable Product. It is the concept of launching something that's good enough. In order to test and then build on top of that. It's kind of this agile mindset of, you know, it doesn't have to be perfect. But now we have a bit of a mini revolt, a healthy revolt. It's not like a negative revolt. It's a, it's a, it's a healthy kind of dissenting to the MVP concept. Please continue.

Kevin: And so because yeah, we are in so many different things and the more you kind of increase the surface area of things that we do, the longer, exponentially longer the back log then becomes. So every, it's almost like, you know, the PM's just like, okay, there's this problem and we were trying to solve this problem. We'd launched something, it seemed to 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 I think the problem that's kind of come up and why a lot of the designers were upset about that was that, um, they felt like product managers didn't really take into account, uh, going the next step and making sure that the user actually feels that sense of delight. Uh, or as you know, Dian mentioned there's a certain cohesiveness to kind of how everything is put together and looks and feels, and that, you know, revolt. Uh, the way you put it, it's like I said, it's a bit harsh, but uh, is I think, I think it's something that, you know, we did welcome, right. Have not, we wouldn't have kind of push through the idea that we have to spend your 10% of their time. But I think the, again, the grumbling does come from, um, yeah, just like, Hey, like I have a limited amount of bandwidth and you're permanently shaving that bit of a bandwidth.

Nadiem: I think it also like depends on what stage of the company you're in, right? If you're, if you're ready a really, really big company, then the damage caused by MVP, consistent MVP development, especially when it's not even 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? Our customers demand a certain level of quality from us every time we release something. Let's, let's kind of turn a little bit into now the human into the actual, uh, product manager itself. Dian, how many product manager interviews have you had in your lifetime?

Dian: I have lost count.

Nadiem: Roughly hundreds?

Dian: Probably like in the like hundred ish.

Nadiem: Hundred ish? Okay. That's a lot.

Dian: Yup. I've been doing this more than 10 years.

Nadiem: 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?

Dian: 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 something you need to do, even if it's like at a feature 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.

Nadiem: And like when you say communicating articulation is kind of like a big thing. Like what is it about the communication part that matters most? 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?

Dian: 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. Um, 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. Cause 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. Cause I look for communication as a kind of a core value for me.

Nadiem: 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 polished 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 GOJEK there are many more introverts who are excellent and concise communicators as opposed to the extroverts who are very salesy or polished 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 specifically in product management, because I ask what your red flags are. Right. So are there any other red flags?

Dian: Yeah, specific to product managers. I think when even after coaching, um, in the interview for example, and like, okay, I'm nudging you towards a certain type of answer and they're still not getting it. Um, 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. That they're trying to solve. What's a business problem we'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 cause I working on individual features, people explain the problem, the problem I was trying to solve and then I would figure out the best solutions, right? So that's fine at certain levels. So it really depends on what level of intervening for too.

Nadiem: That's really interesting. There's this really popular book by Daniel Kahneman called 'Think Fast Think Slow'. And I feel like for product managers, the ability to think slow, is one of the biggest advantages, um, 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 and redefining the problem first and not, and restraining 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, et cetera. 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, we'll then have a hypothesis. Right? They withhold their hypothesis until much later.

Dian: Until they have enough information to even put together a hypothesis.

Nadiem: Yes, yes. The opposite is also very bad where they are like analysis paralysis, which is another thing that you may want to elaborate about. But even in a non, let's say we're not discussing, uh, numbers or data in that 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 and matters a lot to me. Um, yeah. So I thought I would add that part. Any other red flags? Do you have any red flags?

Kevin: Yeah. One question I often ask when I'm interviewing product managers is, I usually ask them to talk about products they like. Right? And this could be you, it could be an app. It could be a hardware. Uh, 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, right? They need to love products that solve problems.

Nadiem: It doesn't have to be a tech product. It could be any product that they use.

Kevin: It doesn't. I had one person, uh, talk about his cars, mirrors. His car's side mirrors, and like how, uh, how it was placed and angled next to the door that minimized the blind spot.

Nadiem: Wow, why did you love that? Why was that great for you?

Kevin: Well, because it, you know it combined a lot of different things, right? Like one is that there's an attention to detail, right? Um, most people, I mean if you kind of look at your mirrors, you can look behind you. Uh, it prevents you from getting into accidents most of the time. Then you're good. Right? It's just the mirror. Yeah. Right. But then, you know, for somebody to kind of look right,

Nadiem: I think most people won't even see it as a product. Right. They wouldn't see it as a unit of product. Yeah. They'll see the car as a product, but not that mirror.

Kevin: No. Exactly. And, and so, uh, most people wouldn't even think about it, uh, as a, as a product, most people wouldn't even think about like, what does that mirror there to do? Right? They just kind of seem like, yeah, cars have mirrors. My car has a mirror. Cool. Right. Uh, but this person actually mentioned that his car's mirrors were especially good at catching blind spots considering the design of the car. Right. And so I thought that was great. Uh, I think a lot of people that are asked this question sometimes just go to whatever is the sexy product of the time. Right? Like few years ago, a lot of people said, oh, I love Snapchat. Right. Uh, uh, but I think it's the ones who can, can really explain like, uh, and I think seeing you love Snapchat, it's totally valid. Uh, but you know, what exactly did Snapchat bring to the table, uh, that was new, that, you know, solve that specific problem. Um, so, you know, if somebody would say Snapchat, I think the minimum, a level of kind of a explanation that I would expect is, oh, you know, you're 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 actually represented majority of human life, that type of stuff. Right? Like it's the minimum, the minimum is you expect somebody to really understand like what problem is it solving? Not just kind of like some new sexy feature. Yeah.

Nadiem: Right. The why.

Kevin: Yeah. And I think that's actually, I actually find that missing actually a lot of times because I think right now there is a certain level of glamour or sexiness to like product management because you're building cool products that get used by millions of people. Um, but then you'd miss out. All right. Now it's really hard to find is like people who really loved the craft. Yes. And that's I think, what's that

Nadiem: Instead of the glamour.

Kevin: Exactly. Right.

Nadiem: It is very glamorous.

Kevin: It is.

Nadiem: You get to tell all your friend. No, no, no. The work is not glamorous. But to the external world is like, that's my product.

Dian: It's true.

Nadiem: Right? They get to say it's my product.

Dian: It is becoming the dream job for most MBAs now instead of consulting or banking.

Nadiem: 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? That was me. Oh my God. I just happen to be the founder. So I got lucky. I got to step out of that before anyone noticed how bad I was at it. So 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 they do a very cursory overview of that book. Like you're going to have a question mark, right? People, you have to love the products that you use for you to show some potential and how good you would be at building a product, 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, but yet understand why you love it. So that self reflection is a critical skill. It also means that you pay attention to quality. Not just detail. What is the next, what is the business performance rationale to attention to detail because quality is all in the details. That's right. All in the details. It is in the massaging, every little part of that experience in a thoughtful way that adds to the great, to this amazing experience overall.

Kevin: Yeah, and that's hard.

Nadiem: It is hard. It is hard. Not that many people care, but you can also overshoot that quality by being too detailed. And there are some product managers that never want to release the product. They're like, no, no, it's not ready. It's not ready. And I'm like, get it out. I'm usually on that side of the equation cause it's good enough. It's good enough. Now I'm pulling back and going to the other side of the equation and saying like, no, no, no. This has to be much better when it gets out. I'm 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, I've 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 the 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 thing, 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?

Kevin: The world is brutal, right? I mean, you do something, you think you're brilliant and then nobody uses it.

Nadiem: Yes. So you've got to have a tough skin.

Dian: Well, what do you do? When do you kill a product?

Nadiem: Oh Man. Forget about that.

Dian: It's a whole other podcasts.

Nadiem: Kill a product. Oh my God. It's one of the hardest things by the way to kill a product, but I think 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, if that, then this, 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. Right? This is the great, the good to great, uh, PM, uh, 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, there 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, may not add to directly to the OKR will be very low. The quality level people who have a very high bar of quality will always get frustrated by low quality products.

Dian: 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 in a person.

Nadiem: 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. And that's usually a good sign, frustrated people with low qualities. 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 GOJEK doesn't, 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. Right. So there's a very interesting thing. So where do you find them? What are the professions that are high potential that you've realized? Where are you looking?

Dian: You know, when you mentioned those six crafts, right. Um, that go into building a product, those are good places to start I think because one,

Nadiem: Like engineers?

Dian: Engineers, uh, researchers, designers, right? Analysts, um, 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. 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.

Nadiem: Can you really think an engineer can become a good product manager?

Dian: Absolutely. Yeah.

Nadiem: And is it, what about a consultant? What about the non technical crafts? Like a management consultant or where, where would you look first if you had, you know, top pick, where do we look?

Dian: Honestly, I would cast the net very wide. Some of, I just presented on this actually at Tech 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. Um, they've worked for, you know, Google, Facebook, Uber, Kiva and Change.org here and GOJEK. Right. And when you look at those backgrounds, wildly different from electrical engineering, right? To software engineering, something interdisciplinary like um, like symbolic systems at Stanford. Look it up. Also my major awesome. Awesome major by the way. Um, and someone was a translator, a professional translator.

Nadiem: A translator?

Dian: Yup. Before they turned to product management and she's the one that 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 prioritize, I think areas where 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. Um, and then start expanding outwards and management consultants. Yes, absolutely. They know, they understand business. Some of them have worked with product managers. Right. So there is no one right answer. I would say.

Nadiem: And I mean you've been in charge of this hiring process and the overall kind of health, the functional organization. What are you thinking in terms of home growing product managers from within the organization itself?

Dian: 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? Who's a 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 a move up in the org and learn new skills that they need, um, 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, uh, Google's associate product manager program is pretty world famous for like growing some of the best PMs. Uh, Facebook has a similar program. Uh, now Uber has built by actually I think, uh, 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.

Nadiem: Great.

Kevin: Yeah, I think, I think the internal, the internal one is the internal hire, uh, or internal transfer route is one that's interesting. And I think we have a few interesting ones. I know one person, um, he used to be an operations manager actually. Um, so his job I believe at one point was to just, uh, uh, basically manage the office and make sure that we could onboard enough drivers. Um, and now, um, he's actually a product manager in our transportation product group and he's actually doing really well and he's one of the rising stars within the organization. And so you can find them anywhere. I think. I think that definitely, I think that the probability of conversion and success is probably highest in those kinds of adjacent, um, those adjacent, uh, 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 and thought process mindset. Uh, and also importantly like attitude, right? Like then the humility for example. I think, um, I think one of the, there's always, and also it also depends on what exactly is the type of product, right? Like the, some products were more consumer facing, some products are more technical. Um, and then also kind of depends. And that's why I think this whole field is very interesting because it's a pretty new field for especially, I think the concept of product manager may not be a new one, but the concept of like a software product manager, uh, has kind of dramatically changed over the last couple of years as even the, you know, the, the form factor has changed primarily to, you know, like smartphones from desktop, uh, the emergence of, um, ML machine learning, uh, techniques, uh, also means that now that's another component to a product managers potential toolkit. And so there's like all these, like basically as 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 in very inclusive in one sense, but it's also very demanding on, uh, on the other. So I think the, you know, the field is, is kind of very, uh, excitingly vague, right? For, for that purpose.

Nadiem: 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 think product management is a little bit more niche, right? It's because 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 how I know that we have great product managers or you know, when I, and 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.

Kevin: Agreed.

Nadiem: Right? That's, that's how, you know, you've got great product managers. Uh, when you throw out an idea that you're so confident about or you throw out or it's a rant about something, uh, that you think, you know, it's so easy to do that. And then your product manager calmly and politely explains how you're wrong and then you feel, okay, all right, I should've thought that one through 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.

Kevin: Thanks man.

Dian: Thank you.

Nadiem: Thanks for coming on board. Until next time.

Outro: Hey guys, hope you enjoyed the podcast. If you liked it, please hit like, subscribe and follow us on social media. Thanks so much for tuning in.

See Full Video