How to be a Great Product Manager | 4Ps PM Operating System (Saturday School #1)

You guys probably see we have a little bit of a janky setup here, but um as I was talking to some of you guys earlier today, we have a philosophy of belly flopping, just kind of getting started and then optimizing over time. So, we're going to do that, but uh I'm really excited. This is the first Saturday school, so welcome all of you guys here today. So happy for you guys to be here. We really want to start this initiative here in Bangalore, and what India really, but but here in Bangalore especially to start having these like educational sessions so that we can all like learn from each other to share best practices. And the focus of today's talk is something that I call the four P's PM

operating system. And what that means is and what it is really about is how do you create like a structured approach, or how do you have a framework for how do you develop competency over your career as a product manager? And really what this is intended to do is that in my experience I've found that there are too many PMs who are more organizers or analyzers instead of people who actually have influence or make an impact. And so, the objective of this is to is to provide kind of a framework. A lot of it in involving my own personal kind of philosophies, my own personal take. But, the point is like how do you build a framework for yourself? Now, not So, you should actually use this as more as as more conceptual so that it's it's kind of an illustrative framework where you can tailor this to yourself based upon your own philosophies, based upon your own discipline, even if it's not

product management. And so, the the agenda for today is really going to go over these three areas. First is just a brief intro to the PM role. Like how do we define what a product manager does? And again, this is kind of from the perspective of Lila Games, and it might be different for you, but um we'll describe it in a way that is again more conceptual, and then you can tailor it for your own situation. Secondly, this presentation of this high-level framework. It's what I call an operating system because it's really intended to be like this sort of this map. So, how do you become instead of a coordinator to contributor? That person that makes has influence that makes an impact. And so, it's sort of like a map that helps you orient your skills in a way so that you can be more impactful, so that you can have more influence. And so, that's what I'm going to be going over. And then, what I'll do uh in the third section is really just

go over every operating system layer, which I will describe soon. All right. So, I wanted to start with a audience question. What does a product manager do? Anyone in the audience here want to take a crack at defining what a product manager does? Dream, define, deploy, and launch. Dream? Dream. Define. Define. Deploy. Deploy. And launch. I like that definition. Any other definitions of what a product manager does? I like the dream part especially. That's uh it's very optimistic. Okay. So, the definition that we have, and again, like I'm not saying that we have the definitive sort of definition, and it's it's going to be situational dependent on your organization, but the way that we define it here is that a PM determines how to deliver a successful product. And by

successful product, we define that to mean a profitable and growing business. And the how it has a lot of nuance to it because the the how actually it is is is constrained by a lot of variables, right? And so, for example, it it applies depending on your organization, depending on how the product manager role is defined, de- depen- depending upon your company's culture. All of these things may impact exactly how do you deliver a successful product, right? So, are you a bull in a china shop, or do you have to be very political? But, it's the job of the product manager given the bounds, given the constraints of the organization, the role, all that kind of thing, how do you actually deliver upon this objective? Right. And then, I want to now talk about from my perspective,

what are some of the major differences between product managers at different organizations? And the way that I define this is really or the way that I view it is really around three primary areas. And the first has to do with the level of specialization, meaning, you know, how broad is your scope? Do you do a lot of things, or do you do kind of just one narrow specific thing, right? And so, it's more it's about what I'll go into in the next slide. Do you have compact is is your is your team generally compact and cross-functional versus highly specialized and focused? And again, I'll go into a little more depth on that. Second is planning versus execution, or in some cases like here at Lila, we do both, right? And so, and usually the way that execution manifests itself in an organization is really around how much does the product manager interface directly with development, right? And so, here our product managers do. We've got someone

from Zynga. Zynga usually there's a producer that sits in between um you know, uh the PMs and uh development. And so, you know, and there's not again, we're not professing to have one right answer. There's but what I want you guys to to know as product managers is to understand the nuances and the differences that you will see in the in the games industry. And the final area of differentiation is the business case. And what that means is that at different companies product managers are going to have a different level of ownership and visibility into the actual economics of the business itself, the product that you're working on. In some companies you will you may not have any ownership or any visibility. In another companies you might have visibility into some parts like revenue or unit shipped or things like that. And in some cases you may actually own the P&L and have full visibility into all the all of the numbers, right? So, these are the three areas, and I'll actually go into more depth on the first

two uh right now. Okay. So, when it comes to specialization, I think the best way to understand the difference in specialization is to take two archetypes in the games industry that's pretty famous. And so, on the one side we have very compact and cross-functional teams. Uh Supercell is famously known for having very small teams, like the teams that have worked on some of the biggest games like Clash of Clans, Clash Royale. These are teams that started with like less than 10 people. And I know Ilkka wrote a post about a a post recently or within the last year about how that's kind of changing where now they have big teams of 25 to 30, right? But, even that's not a really big team. And so, in this situation what you're going to see are generally speaking, the roles that people have are going to be very broad in scope. And um on the other side of the spectrum, you have companies like EA or Zynga or companies like that where you actually

have more narrow scope. You have bigger teams that are more focused in nature. And from a product manager perspective, you might have various types of product managers. At our company, we're trying to be closer to to this side as as much as we can, but like, you know, so we only have one you know, at one at a company like EA or Zynga, you might have a growth PM, a features PM, a revenue PM, a fortuity PM, someone really narrowly focused. And uh generally what you will see is that where you sit in the spectrum often, not always, but often has to do with these three characteristics that I list on the slide. The first is production value. Generally, the higher the production value, the closer to triple-A quality, realistic graphics, you know, like the the extreme level of production value, you'll have more you'll have the bigger teams, and you'll have higher specialization. The second is the content requirements. The more

content cadence, do you have a massive battle pass where you're trying to, you know, just release tons of content and things of that nature. But, the more content you have, usually the more specialized you are. And finally, the higher scale, meaning, if you have a huge game, like if you're King and you you're working on Candy Crush, one small tiny improvement is worth a lot, right? And so, from that perspective, you might have PMs that really specialize and focus on those small improvements because the scale at which they are operating. All right. The next The other thing that I talked about was planning versus execution. So, what does that mean? So, from a product management perspective, you will see differences in terms of whether you have product managers that are more focused on things like road map, forecasting, budgeting, P&L analysis, things of that nature, you know, um you know, in in live ops you you might

do like feature prioritization using either expected outcomes or ice rice type of framework. And so you're more here on the planning function. And you also have and especially in like a Silicon Valley startup, you have you have product managers that may also be involved in execution meaning you're involved in engineering. You're working with engineering directly. You might be involved in a scrum, in dev follow-up, following up with the feature, seeing if it was implemented properly, things of that nature. And so this is the second area where in some cases you'll have PMs that just do the planning or just be involved in the execution and usually if it's just execution they may be called a producer for example. Okay. And I want to also present to you two additional ways of viewing the differences between PMs. So this is hard to read so I apologize for that but this is like different functions or areas of

work that are involved in whatever project that you're working on. So for a game project these are all the different things that you can actually do. And so the other way of defining the differences or the role of a PM would be what does the PM actually do? And so you can then scope out here are all the things we need to do. A PM would own this piece or that piece and a producer would own that piece or a project manager might own another piece or you know, designers would take this part. But the other way to look at the role of a PM is again from a functional perspective. And finally the other way to look at it and again I apologize for the small text would be around skills. So in this organization or on this team, what are the skills that are necessary for a PM to be successful or not? And so some companies have a notion of a skills development matrix, right? And so in those cases you would then specifically codify for this role what

skills do you need to be successful or you know, to deliver a successful product? Okay. So now I want to get into this notion of the four P's PM operating system and why do I call it an operating system? And again this is you know, in intended to act as like this framework for you to build skills over a career. And so I just wanted to like first start by giving you the dictionary definition of an operating system. So based on a Google search on for for operating system, the Merriam-Webster dictionary defines an operating system as software that controls the operation of a computer and directs the processing of programs. And so for me when I thought about this four P's operating system, the way that I would interpret that definition would be as a framework that controls the actions of a worker meaning what should

I do as a PM and directs the future skill development for a role. What should I learn? So this is intended to be again a map to some degree. If you want to become an effective PM, you know, what is the framework? How should I think about building skills to get from here wherever you are today to becoming a really effective impactful product manager. And so with that I want to actually go over the framework. And it looks a little bit complicated but it's called the four P's because there are four layers to this operating system. And I'll go ahead and start with the bottom layer and work up because the bottom layer is the most foundational part but in my opinion the most important thing to have as a PM is a set of philosophies that help you with decision making. And in philosophy there's this concept of a razor, right? Which is basically kind of a heuristic or kind of principles that you believe in that help

you make decisions faster. And so the bottom layer are that set of principles. You know, do you focus or not? Do you give someone direct feedback or not? Like how should you be making decisions? That set of philosophies is what I is is how I categorize this layer under philosophy. Now the next layer up has to do with personality and I call this layer the effectiveness driver. Because in my experience I believe that it really is personality that is the hardest to sort of learn or to develop, right? A lot of people can learn skills. It's harder to have the personality to make an impact. And so I'll go into I'll go into more depth but I believe that having the right personality and again it depends on your situational context, the type of organization you're at. But in fact the personality can be 10x more impactful in terms of how you make

a difference at an organization versus things like well, you know, I really know how to use Jira really well. One layer up has to do with process meaning how do you view operational efficiency at your company? The workflows, the specific process, how do you how do you operate or manage a scrum? How do you all the different things that you do? Are you doing them to best practice? Are you doing them the in the right way for your situation for your team? And so having this understanding of of knowing how to implement best practice and how to how to make things run as efficiently as possible is the process layer in this operating system framework. And the final layer at the top is what I call practice which is basically just the work. The tools you use, the things that you do and how do you learn and understand those things? And by the way, if there if you have if

anyone out there has any questions, feel free to stop me. Happy to kind of explain in more depth or to answer any questions. All right. So that was a high level framework and so what I want to do now is actually go through each of these layers and talk to you about what I mean by each of the layers. And again all of this stems from my own personal experience and so it's meant just I really want to underscore it's meant to be illustrative, right? I I think it's most most important for you guys to understand the concepts rather than to just blindly adopt, okay, well here's JK's framework, we're just going to adopt it. I I think you have to you have you have to tailor it and customize it for your own specific use case or for for yourself, right? Your situation. So the practice. So I want to start again at the top layer and there are four things I'm going to talk about from my perspective that I think are important to understand when it comes to the actual work that you do as a PM.

Which is the actual scope of work. How you view the tools that you use. How to think about analysis and optimization. And finally understanding the product and customer. Okay. So starting with scope of work. So one of the things I think it's really important for PMs to understand and if you join a new company, I think it's important to do at the very start is to understand what is your scope of responsibility meaning what functions or areas do you own? What responsibility do you own? What decisions can you make? And really what you're trying to do is you're trying to establish the bounds. What are your bounds, right? What are the rules of the game in which you're operating in? And in the real world we know that none of this stuff is fixed. But you want to at least know what is your starting point? Where are you starting from? And then you can optimize from there. And then you also want to understand how our roles defined. So if you're a

product manager, the first thing you want to do is understand all of the adjacent roles. So if you're working with a producer or if you're working with a designer or an engineer, what are they what are what role like how have their roles been been defined and their interface with you? What should that look like and what are the expectations there, right? And so so I think that the first thing you should really need to understand again is your scope of work. What are your expectations? What are your responsibilities? How do you interface with other people? And at your specific organization which may be different from others most likely what does a PM need to be good at to be effective? Okay. Now tools. And this kind of I get triggered a lot of times at many when I visit many different studios when it comes to tools because I think that as a product manager it's not good enough to just know your tools kind of okay.

So you know, maybe you're at Zynga and you kind of know Jira. Not good enough. And so a lot of times I will ask a product manager to different game studios, okay why are you using Jira? Why? Why and what's the difference between Asana, Jira, Trello, ClickUp, Monday? And 99% of the time they don't know. They're like, well I use this on the last project so we're going to use it on this project. But I think that if you are a product manager you have to know your tools. Not just the tool that you're that you're using. And by the way, if you're whatever tool you're using, you should know to complete mastery but also the other tools. You should understand the usage metaphors. Why would you use a Kanban system in one context ver- versus another? You know, what are the different kinds of um advantages to the different tools that you could potentially use, right? And then And so to the second point here

is, do you understand the situational context with the tools? There are good reasons for using Jira. There are good reasons for using Asana or other tools. Why? You need to develop a mental framework for why these tools are better in different situations or uh other situations, right? And finally, you also need to be actively experimenting. Meaning, a new tool comes up, you should try it out. You should understand. You should fit that new tool into your mental framework of when do you use different tools at different times. And so I just kind of concluding the section on tools, you know, I would submit to you that if you are not looking at all these tools, if you don't understand these tools to massive depth, then you're not doing your job as a PM. Okay. Um the third box, if you remember from the practice layer, has to do with analysis and optimization. And really what this means is that as a

PM, you really want to start to develop kind of like a a Batman utility belt of tools, of analysis, of when something goes wrong, revenue's dropping over three straight weeks, what do you do? You need to start developing like a playbook of different analysis tools, methodologies for understanding when problems occur, how do you determine root cause, how do you determine what the problem is. Different types of hypotheses, different types of ways in which you can understand why you have a problem in your product or not. And um secondly, not just understanding the symptoms and how to treat the symptoms, but root cause. And so um I definitely recommend that you really understand different methodologies for root cause analysis. You know, whether it's five whys or decision trees or there's various methodologies, but understanding these ways of analyzing the product is very critical for a PM.

And so over time, what you're going to be doing as you develop in your career as a product manager is, you know, you're going to have your Batman utility belt and you're going to add like a little bat wing thing and then you're going to add like a grapple hook. And so all these different tools, you want to add over your career as a PM so that when you are confronted with a new problem, you know exactly what to do. Okay. And finally, the the last box in this practice layer has to do with a product and customer. And so one of the other things that triggers me a lot is especially when And and so you know, I have a bias. I have a MBA, but I have a bias against MBAs and usually it's for this reason. Because when you hire an MBA into a gaming company, more often times than not, if you ask them about different games, they don't know. They're like, "Well, I I can do the analysis. You know, I can analyze this game really well or I can look at the KPIs or I can do all this other kind of quantitative

um modeling or analysis, but what often happens is that they lose sight of the actual product itself. And so playing the games, if you're working on a game, you should play the game and all the other games in the genre. You should know it very very well. You should also have some idea of who is the audience and why will customers use your product, your game versus other games in in the market. And also um uh having an understanding of market potential. How do you determine the market potential for your product, right? And so especially when we went even going back to that um to the slide about differences between PMs, the more you own the business case as well, the more that this specific function is very very critical for you. All right. Moving one layer down to process. And again, process is really about how do you develop as much operational

efficiency into your team, your organization, your company as possible. The first thing I want to talk about is basically it like how you approach something, right? And so if I were to ask you some of these questions, I would hope that you would know the answers depending on, you know, your role as a product manager, but for example, if I asked you if if you are responsible to interface with engineering directly and you're working with engineering, what is Agile development how does it differ from a waterfall model, right? If you're working in that scope, you should know this answer. Like what is Scrum? Uh what development process does your team employ? How effective is your development process? Like all of these questions, you should understand at a very fundamental level. And so this kind of goes back to this uh concept I was talking about earlier of just, you know, using a tool and using a tool because you used it last time. Doing a

process because you did the process last time. But as a product manager, if you want to not be the coordinator, if you want to be somebody who contributes, who has influence and makes an impact, you have to understand all of these things at a fundamental level, right? This is kind of very similar to kind of like first principle thinking. You have to understand the very foundations of why like how are we doing a thing? What are other ways to do that thing? And is how we are doing this thing as effective as possible given your situational context? And so um you know, there was a there was a research project uh published by Gamasutra many years ago called the Games Outcome Project. And what they did is they studied the outcomes of many game projects. And one of the things that they um that they concluded is that it seems that in spite of all the attention paid to the subject, the particular type of

production methodology a team uses is not terribly important. And it is not a significant driver of outcomes. Even the much aligned waterfall approach can apparently be made to work well. Now, the common wisdom is of course we use Agile. Of course. Why? Because everyone else does it. Of course. But why, right? Why would waterfall work in some cases versus Agile? Like really having a deep understanding of these things and having, you know, a hypothesis of why various methodologies work in some cases not, is very important for you as a product manager. I think the other part to think about when it comes to process is sitch- situational awareness. And I've talked about this before, but off- more often times than not, a lot of PMs, a lot of people in a company will will just want to do something because that's what was done before. And so if you don't want to understand

um the work, the process at a fundamental level, you can't improve it. And so that's why it's very critical to not only understand these things at fundamental level, but then for your situation, for your specific situation, what should you be doing? And as an example, I'll give you um I'll give you a very specific example. What kind of code review process should an engineering team use? Does anyone have any thoughts on this? No, no. Not no one from Lila. No one from Lila. Please. If the company is in the early stage which is trying to figure out how the basic game is being observed in the market, you might not have a code review process at all. But once it reaches the very stable stage, then you would want to have stable code base so that it doesn't affect Yeah. Well, I think you're thinking along the right lines, right? Which is basically what situations would um would determine

the type of code review process that we should be using. So for example, I'll give you just a couple examples, right? Well, what what about a junior team versus a senior team? If you have a senior team from Blizzard who's written the book on how to do programming, are you going to code review all of the masters in that team? Probably not. But if you have a junior team that that needs to improve and that's not fully like they have a long ways to go, right? Would you code review that team? Yes. Would you code review everything? Does UI code need to be code reviewed or do you just need to code review like the most critical parts of your game, for example? But my point is is that you have to understand where are we? Your team, your people, your situation. So whether it's code review, whether it's a tool you use, whatever process that you're looking at, you have to determine how do I apply

just because we did um you know, pair programming, full code reviews on everything in the last project with a bunch of junior engineers on a new team, and now you're put in charge of the, you know, super expert Blizzard team, do you apply that same process to that team? The point is you have to think about it. You have to again not have that hammer and use that hammer on everything. The next thing I want to talk about is cultural awareness. And the thing that I I actually find surprising is how few people really understand how big of an impact culture has on your ability to do your job as a product manager. And so the question I ask here is, does culture impact work? And if so, how and why? Actually, maybe I'll just throw it out to you guys. Does culture impact work? And how and why? Please.

Right. Is there a culture of trust or not? That That's a good good point. Anyone else? Okay. Okay. Right. Right. You It seems like you're actually talking about like it Do you have an environment of safety where these new people come in? Can they make mistakes or not, right? Something like that.

Okay. Like Right. Having an open environment or not. Yeah, that's that's another good one. So, let me actually walk you guys through a few different situations, okay? And this is kind of taken from real life, but I'll just I'll just read a few things out to you, okay? So, one. Situation one, executive readouts, okay? GOD DAMN IT. WE NEED A PRESENTATION FOR THE exact team explaining the launch of the game and why it did not hit the numbers. How are we going to spin this? I need you guys to drop everything and focus on a presentation for Bill and Sandy. Don't show all the numbers. Just show the iOS and Western market numbers and make sure the numbers back us out by Q3. You need to do this right now. So, as a product manager, if you are in an environment where, let's say, a a game launch fails

and you're being told you have to not fix the problem. You have to create You have to spend the next 3 days creating a presentation that explains to upper management a cover-your-ass presentation on why it failed and blaming other people for why it failed. That's a cultural impact, right? The kind of culture that you're in will impact your ability to do your job or not. Second situation, relationships, politics, and sacred cows. I heard you spoke to Fred about our data infrastructure. While I appreciate your concerns, you guys need to figure out a way to work together. I've worked with Fred for 12 years. Don't push this. Meaning, there's a problem in the company, you're trying to raise an issue, but somebody above you tells you don't do it. Leave it alone. Don't address the problem. Can you do

root cause analysis? Can you fix a problem if you're not allowed to raise issues or concerns? Again, another cultural impact on your ability to do your job as a product manager. Uh one more situation. CYA, meaning cover your ass. Sarah, I know she's bullshitting about our UA. She's totally it up. It's her fault we're not hitting our ROAS goals. Oh, really? What was your response to her when you talked to her about this problem? Oh, uh it's it's her fault. Blaming someone else for a problem, not talking to them directly and trying to work on a solution. Again, another cultural situation that will impact your job to be effective as a product manager or not. And so, you know, you talked about an open environment. That's what I'm talking about. So, you have to understand the cultural context in which

you're operating. There are some companies that are going to have open cultures where, you know, in terms of the communication style, you have direct communication with honesty. You can have uncomfortable conversations, or you're going to have a closed culture where people don't say what they really think. Right? Where you have to be careful how you say something, what you say. You're going to be evaluated and judged upon. And where you have to kind of focus on building a narrative, a story to tell upper management at all times. There's also this notion of accountability and ownership. Are you accountable for what you're doing or is accountability and responsibility purposely vaguely defined so that when something goes wrong, somebody can be scapegoated. And finally, safety, which is some somewhat of what we were talking about, right? Which is like, can employees feel safe to express their opinions or not? Or are employees punished for changing their mind or expressing something

wrong, right? And so, this kind of, you know, this spectrum for whatever company you're working in, where you operate, will impact your ability to be effective as a product manager. The most important thing, and the reason I highlight this is because you need to be aware of Again, this is the the rules of the game that you're operating in, the bounds that you have. How you're operating in your specific company. You need to be aware of those differences. All right. And the final part I want to talk about when it comes to this prac this process layer is basically about best practice. And oftentimes, I'm I really encourage product managers to always be on the attack. Offense, offense, offense. Offense is defense, meaning PMs should always be focused on best practices. Always attack every process. Is it effective? Why is it effective? Can it be improved? You know,

and then how can we improve it? And in order to be on the attack, it also requires depth, right? If you don't understand things at a very fundamental level, you can't attack the problem. You can say, "Well, this is this thing is messed up." Why? Right? You have to know things from a very fundamental level to understand why. The situational context we talked about, right? Like um the just because a practice may be considered a best practice for a certain company in a certain situation, you have to understand whether it's the best for you and your situation. And then again, the experimentation mindset. That having at least some small percentage of your time where you're always actively trying out new tools, new ways of doing things, and you you've already established in your mind this will not be, you know, most of the time when we experiment, it'll likely fail, but the few times

when something works, then you implement it. And again, you then put that into your into your tool belt. That becomes uh something that you then understand can work. All right. And as an example, I I I just wanted to kind of give you guys an example of, you know, a very specific example. And usually a easy one is meetings, right? And so, for a lot of people and in a lot of companies, the way meetings are set, you get a calendar invite, okay? Oh, uh this meeting. No no description. The you know, the the game meeting. Okay, I guess I've got a game meeting. Do I need to be there? What do I need to prepare? No, it's just the game meeting. And you know, you've invited a bunch of different people. So, like a few things I would highly recommend that you guys consider. So, even something as basic, fundamental, and simple as meetings, you know,

think about this this notion of operational efficiency. Why an hour? Everything's always set to an hour. Why? Why not 45 minutes? Why not 30 minutes? Why not an hour and 20 minutes, right? So, under like just because things are set as a default, to think about what how much time do you actually need, right? And because and especially when you multiply it out, it's not just you at the meeting, it's you times whatever, five people, 10 people, however many people come up come to that meeting, right? So, you're when you set the meeting, you're impacting a lot of other people at your organization. And then setting an agenda. Maybe maybe, you know, Yash is a PM here at Lyla. Maybe Yash thinks that I should be at a meeting, but if he sets the agenda and the context, then I I might just say, "Well, I don't need to be there." Or "Here my thoughts, you know, good luck." But not But if you don't set the agenda, then people can't know whether they

actually belong in that meeting or not. You can have a discussion, but that could save somebody an hour or however long you set the meeting. The third point is like, own and control your meeting, right? So, like I'm sure many of you have seen in meetings sometimes things really start to go off the rails and, you know, people talk about, "Oh, yeah, you know, um politics or this or that." Or, you know, there's a lot of different ways in which meetings can go off the rails. And so, whoever sets the meeting should own the meeting, meaning they control um what happens during that meeting and like when things start to go off track, getting people back on track. Tracking all relevant issues. So, like, you know, after a meeting, I think especially for important meetings, you should say, "Okay, we had this meeting. Bill does this, Sally does this, whatever." and track and have basically an owner and due date behind all of the things that were discussed or decided on that meeting. So, long story short, meetings should be clear, efficient, and effective, and I

believe that most companies, and even our company, you know, we're not the best at it. We're I think we're better, but we we can be better at meetings as well. And so, um this notion of how do you do things more? Um I don't know if um if you guys are familiar with uh um manager versus maker schedule, but this was something from a Paul Graham blog post many years ago. But the other thing you should understand about meetings is that meetings to different people in a company are different. The cost is different. The impact is different. And so, I just want to quote from Paul Graham's uh blog post. One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more. There are two types of schedule, which I'll call the manager schedule and the maker schedule. The manager schedule is for bosses. It's embodied in the traditional appointment book with each day cut into 1-hour intervals. You can block off several hours for a single task if you need to,

but by default you change what you're doing every hour. When you're operating on the maker's schedule, meetings are a disaster. And so, also important for you, and again, I'm just trying to be very illustrative about a single concept, a single situation, right? Meetings. What are the things you need to know? How do you need to actually understand how to be as operationally efficient with meetings as possible? You have to understand that meetings have a different impact on different kinds of people. And I I won't go through this, but this is um this was a blog post of some kind um that talked about opinions on meetings, and you can see that what you'll see through reading through the quotes is that engineers, developers, makers are at to Paul Graham's point much more impacted or affected by meetings than managers are. Managers are used to just like, "Fill up my schedule, you know? And then uh just take meetings all day and go home. Oh, I had such a productive

day. I had, you know, 15 meetings." Anyway. So, um and and the other thing to to consider is this notion of deep work, right? And so, when you're even for yourself as a PM or as somebody who's scheduling a lot of meetings, you know, I would also recommend that you also consider deep work in your calendar, where you try to minimize meetings so that you can actually spend time on deep work. And just say, quote from Cal Newport, the author of the book called Deep Work, "To produce at your peak level, you need to work for extended periods with full concentration on a single task free from distraction. The type of work that optimizes your performance is deep work." So, in summary, my recommendation here is that good PMs should consider fewer meetings and deep work instead, forcing meetings to be operated efficiently as per some of the guidelines that I had uh that I had written about, and

considering the cost of meetings for managers versus makers. Um so, final thought on the process layer is that you know, in order to be as operationally efficient as possible, it requires an open mindset, an experimental nature, it requires experience and exposure to lots of teams, research, and original ideas. And finally, I think there's too many people are lazy about good enough. This is good enough. Yeah, it works. Good enough. Instead of how can this be the best? How do we make this the best? Because what you'll find is that if you look across the workflows, the processes in your team, if you can get 10% improvements across the gamut of workflows that you have, you will be dramatically better. If your team is dramatically better than a competing team, how can they compete with you? How will they be able to compete with you when you're

you know, 100% more efficient? Yeah, it's just it's going to be very very difficult. Okay. The personality layer. So, now we are on the third layer, and yeah, let's talk about personality. And some of the concepts that I'm going to talk about is this concept I call the bulldog and the cockroach, rebuking your neighbor, which is part of our values, uh communications, and finally follow through. All right. So, I consider product managers to have two spirit animals. The bulldog because a bulldog is relentless, not afraid, will bark at anything. And so, as a product manager, it's so important that when you're in a meeting and or when you're discussing a specific issue, and if you see a problem that you raise it. Too many product managers will see an issue, talk to someone, and

just basically you know, well, I I don't want to engage in this. Right? And so, the bulldog. The bulldog as a product manager is very very important that you voice concerns, that you are not afraid. The second is the cockroach because a cockroach in a nuclear holocaust, the cockroach will survive. I don't think human beings will survive. The cockroach will survive. It's about persistence and not giving up, right? And so, uh product managers should always be detail-oriented. They should watch the small details and keep pushing on those small details over and over and over again, right? And so, it's a job of the product manager to help set the standard for teams, right? And so, keep pushing on things. Well, you know, I asked Bill to do this. He didn't do it. Okay, well, let me follow up with him. Okay, now let me sit down with him. Now, okay, let me schedule a meeting where we're going to talk about it. Just over and over and over again. It's important to be

persistent. And now I want to talk about this concept of rebuking your neighbor. And I I got this from the Bible, even though I'm not a Christian, but um the question I have for you is how many of you have directly talked with a coworker about their faults in their performance or work? Now, this could be related to this concept of culture, but often times most PMs don't have that ability. So, I see a problem in a coworker, and it's hard for me to say, "Hey, you know what? I think you're doing this wrong, and here's how I think you could do it better." Right? It's very very difficult. Um and how many of you just let things slide and make excuses about why you should just let it go. I should talk to Sally about this issue, but uh maybe next week. And then next week, well, maybe it's just not that important. And so, this notion of rebuking your

neighbor, I would submit to you that over 90% of PMs or just people generally cannot have this conversation, cannot rebuke their neighbor. And so, I want to read um a couple of biblical verses for you. And again, I'm I'm not Christian, but uh I believe there's a lot of wisdom, whether it's from uh the Bible or Hinduism or Stoicism. I study all of it, but I thought these two verses in particular were very very uh wise. First is from Leviticus 19:17, "Rebuke your neighbor frankly, so you will not share in their guilt." So, what does that mean? That means here at Lila, if you see a fault in somebody, and you don't you don't talk to them about it, you are 50% at fault because you have not talked to them about that problem. You see the problem, you know there's a problem, you haven't done anything about it. It is your fault, too. You share in

their guilt. And the next verse is Proverbs 27:6, "Better are the wounds of a friend than the deceitful kisses of an enemy." Now, I've known so many people um whether it's uh because of layoffs or in um within the last, I would say, year and a half, I can't tell you how many people said, "You know, I was working at company X." Some of you are working at some of those companies, and I got fired. I had no idea. No idea I was in trouble. No idea that my manager thought I was doing a really bad job. I just got fired." So, the the point I want to make here is who really is your friend? Is your friend the person that works at that says, "Hey, you know what? You're doing a great job. Yeah, good for you." And then at lunchtime like, "Fucking Fred, that guy is such an idiot, right?

That guy can't do anything right." But to your face says, "Good job, Fred. Good work." Or is your friend the person that actually talks to you and says, "I think you can do this better for these reasons." Right? The wounds of a friend or the deceitful kisses of an enemy. Okay. So, the next part about personality that I want to talk about is communications. And some high-level thoughts here on communication. First is that it's always better to over-communicate, right? Like um too many people think, "Oh, yeah. Uh, you know, uh, Raj probably knows this. I think it should be okay." But, it's better to over-communicate versus under-communicating. The second thing is written versus verbal. There's a dramatic over-reliance in just generally all companies today besides maybe Amazon on verbal communication. "Oh, I talked to him. Oh, I talked to her."

If that doesn't work as a PM, you should think about, "Well, I wrote it down for him or her." Right? Because different people understand communication in different ways. And some people may be good verbally, you talk and then it's it's forgotten. Or if you send something in written text, this is actually the conversation we talked about. Here are the specific points I'm talking about. Then, the written communication can actually, depending on the person, be dramatically more effective than just the verbal communication. And finally, communication flows. So, I think that PMs need to think deeply about how does information flow? What is the communication flow between the different teams? And I think, um, as an exercise, I would even recommend that you actually try to draw it out. On a Miro board, on a piece of paper, draw how does information flow? And then it'll become natural to you. You don't need to do that, you know, just the first time maybe. Then, as you get to understand how it flows,

um, you'll you'll get a better sense for it. But, it's important that you understand how the information is flowing and where you think there are information gaps and based upon the information gaps, how you can actually create better communication, whether it's between people or teams or anything of that nature. Okay, the second thing I want to talk about here under communications is radical truth. And for any of you who have not read Principles by Ray Dalio, I highly recommend it. It's one of my top PM books of all time. But, uh, Ray Dalio in Principles states, "By radical truth, I mean not filtering one's thoughts and one's questions, especially the critical ones. If we don't talk openly about our issues and have paths for working through them, we won't have partners who collectively own our outcomes." So, this kind of goes back to some of the other concepts as well. But, radical truth in communications is very, very

important. If you don't have that truth, you can't, again, work through the problems that you have in your company. Uh, the third concept I want to talk about with, um, about communications is open communications versus chain of command. And this was, uh, highlighted and popularized by Elon Musk, um, through this leaked email at Tesla. And I just want to read to you about this concept of open communication. So, subject, communication within Tesla. There are two schools of thought about how information should flow within companies. By far the most common way is chain of command, which means that you always flow communication through your manager. The problem with this approach is that while it serves to enhance the power of the manager, it fails to serve the company. Instead of a problem getting solved quickly, where a person in one department talks to a person in another

department and makes the right thing happen, people are forced to talk to their manager, who talks to their manager, who talks to the manager in the other department, who talks to someone on his team, then the info has to flow back on the other way again. This is incredibly dumb. Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company, no kidding. Right? So, um, again, open communication, do you have to go up the chain of command, over, down, or again, in a truly open company, and this goes back to culture and some of the things we talked about, it's certainly much more efficient and better just to talk directly. Now, you might want to plus CC a manager just to let them be aware that you're talking to someone, but it's always better to go directly. And finally, there's also a kind of a related principle, but what I found at a lot of companies, especially like the

the bigger companies, is this notion of, um, what I call an information hoarder, which is basically kind of like a power grab. And usually, information hoarders are people who don't have a lot of skills. And so, if you're in a company without a lot of skills, how do you maintain power in a company? Well, between department A and B or between person A and B, you insert yourself in between them and say, "Hey, no, no, no. You guys don't talk to each other directly. You talk to me. B, what do you want to say to A? Okay." Now, I will talk to A. A, what do you want to say to B? And you insert yourselves in between them, and it just creates so much inefficiency because this person is trying to justify their job, is trying to gain power in the organization. They're trying to serve themselves rather than serve the company. It's very wasteful. It's very inefficient. But, I will tell you at almost every large company, this thing exists.

All right. And finally, um, I wanted to talk about this notion of pre-meetings, okay? And so, the problem with pre-meetings, and by pre-meeting I mean, "Oh, there's this big meeting coming up to discuss a decision." Okay, Bill, Fred, Sally, Bob, let's all meet together before that meeting to discuss what should we try to push? Right? And the problem with these pre-meetings are one, they're inherently political. So, a select group of people want to try to agree on their agenda and then meet with others and gang up on those others with a unified front to influence them. This happens so often at big dysfunctional companies. The objective of meetings, if you again, if we take this again to fundamentals, first principles, the objective of meetings should be to have open and honest debate considering

all points of view, even contrarian views. Pre-meetings violate the very nature of objective discussion. You're trying to turn an objective discussion into a biased debate. That's not good. And I would also submit that pre-meetings are by nature, just again, inefficient. Why are you meeting twice on the same freaking issue? And again, presumably the first time to agree on what the pre-meeters want and then the second to just influence. Not to discuss, to push and influence. And the final box I want to talk about in this layer of personality has to do with, um, process design, okay? So, or implementation actually, which or follow through. And the point I want to make here is like, it is so easy to design a process, right? "Oh, we're doing this thing. Oh, this process is so screwed up. We should do it this way instead.

This way is better." Okay? Great. And then you send out the email. "Hey everybody, here's the new process." Boo-boo. And then, you know, it's like few weeks later, ah, freaking Abinash, he's not following our process. Freaking, you know, these guys, they're not doing the process. Why are they so stupid? Why are they so lame? But, in reality, it's not them that's lame. It's you. Process design is easy. Implementation install is 10 times, 100 times more difficult. So, a great PM can not only understand, "Okay, how do you make a better process? I understand things from a fundamental perspective. I understand the situational context. Here for us is the best process." But, then, and more importantly, you follow through. You make sure that this process that you've designed is implemented, is installed effectively as well. And that is the more important aspect to, uh, to process

design. And uh, the next thing I want to talk about is like, so, how often should you follow up? How often should you follow through? And again, just drawing from the Bible, um, there's this biblical verse from Matthew 18. Then Peter came up and said to him, "Lord, how often shall my brother sin against me and I forgive him? As many as seven times?" Jesus said to him, "I do not say to you seven times, but 70 * 7." So, I have a PM in a personal kind of interpretation of this biblical verse. Then the PM came up and said to JK, me, "Bro, how often shall my coworker not follow my process and I need to talk to him? As many as seven times?" And then I said to him, "I do not say to you seven times, but 70 * 7."

All right. The last layer. The foundational layer. I'm just going to give you a couple of examples, but really, as as I mentioned before, philosophy, whoops, philosophy should underpin everything. What do you fundamentally believe in? What are kind of some of the values that you have? What are the ways in which you think you can be successful? And so, you know, there's a lot of, um, there's a lot of my own philosophies that I've written here, um, in the box. But, I'll kind of go over a couple of them just as again illustrative examples, so you understand the concept and then again for each of you, I think you should develop your own. First concept is a hedgehog concept. If you could be a fox or a hedgehog, which would you rather be? So, you want to take a crack at answering this question? No one from Lila?

Yes. And it's a philosophy, right? But, in his famous essay The Hedgehog and the Fox, Isaiah Berlin divided work into hedgehogs and foxes based upon an ancient parable and he says, "The fox knows many things, but the hedgehog knows one big thing." And Jim Collins in his book From Good to Great argues the value of doing one thing and doing it well and he based it on this concept, right? And so for us at Lila, we're not making five games. We're not making 10 games. We're making one game. We're putting every cent all the money that we've raised into one game. We follow kind of uh the the principle that was um popularized by Facebook and Mark Zucker Mark Zuckerberg around the North Star principle, right? We might have a lot of things that we want to do, but we try to focus on one thing at a time. Um from a management perspective, uh the co-founders at this company have uh this notion of a

bull's-eye. And so, we try to determine the one thing that we're going to work on and then once we complete that, then we work on the next thing. Focus. Not trying to do a lot of things, doing one thing. Uh another philosophy. What's the difference between a chicken and a pig in a ham and eggs breakfast? And I've been told that in India this this uh this question doesn't quite work. But, do any of you know the answer to this question? The difference between a chicken and a pig in a ham and eggs breakfast. You got it. You got it. So, the difference is commitment, right? In a ham and eggs breakfast, the pig is committed, meaning the pig is killed. The chicken just boop. You know what? The chicken's still alive after your breakfast. So, what does that mean? And what that

means is that the level of commitment, sacrifice, consequences dramatically impacts an outcome. And so for us, we have to think about systems. And again, you know, we're we're working on this, but at least for founders, it's like, you know, like I personally am taking a very massive salary decrease and if this company fails, all the sacrifice, all the commitment I've put in goes to nothing, right? That's I'm committed. I'm the pig. And so, how do you make people committed in your organization, in your team? This concept of how do you get commitment because there are things you will do in a do or die scenario that you will not do in a relaxed scenario. And when you often see big companies, why do they fail? Well, there's a lot of things they know about. There's a lot of problems in a big company that they know about. Are they going to work on those problems? Not if you're a chicken.

What if your company's going to go out of business? Will you work on those problems? Probably. Commitment versus involvement. Are you a pig or are you a chicken? Um okay, and I think this is the last uh concept that I talk about here in the philosophy section, but it's an understanding of fear, right? And what does that mean? Because a lot I've spoken about how some PMs don't address problems, you know, how there's like this difficulty in having tough conversations and things like that. But, I think it's very instructive to be thoughtful about fear and why are you fearful? Because I think the gap between doing what you should do for the benefit of the company and not doing it because of fear can be mitigated if you think through the the consequences. Really think about what Jamie Fox said on a podcast that I heard is like how he addresses fears to think about, "Well, what's on the other side

of fear?" So, if things go wrong, what does that actually mean or is it just uh you know, an emotional reaction? Because often times, what happens if you say the thing that you should say, if you do the thing that you should do, is actually not as bad as you think. And so, unfortunately, I would say there are a lot of characteristics of a typical employee that are held back by fear, right? Too afraid to speak one's mind despite knowing a big mistake is about to happen. You know, settling for the status quo even when you know things are not being done effectively because you just don't want to like rock the boat. You're afraid of what people will say or think about you. Not giving critical feedback to someone who could clearly use it because you are afraid of the consequences or it feels too uncomfortable, right? You're afraid to talk talk to them them about it. You're doing what's convenient instead of what is right in a project that is going the wrong way, just hoping for miracles. I know this thing's going to

blow up, but I don't want to like piss somebody off, so I'm just not going to say anything. Okay, guys. So, that's the framework. Um as I mentioned again, the four Ps PM operating system, the practice the work, process about operational efficiency, personality, meaning how you can be effective, and finally, philosophy. What are the fundamental things that you believe in? And the one other layer I haven't talked about, which is probably a different talk for a different time, has to do with a lot of principles around management and leadership and I'll just give you one example, one that I personally believe in um which has to do with optimism. And so, this is a quote from uh from Walden, uh which states, "I learned this at least by my experiment, that if one advances confidently in the direction of his dreams and endeavors to live the life which he has imagined, he will meet with a success unexpected in common hours. He will put some things behind, will pass

an invisible boundary, new universal and more liberal laws will begin to establish themselves around and within him or the old laws will be expanded and interpreted in his favor in a more liberal sense and he will live with a license of a higher order of beings." So, from a management and a leadership perspective, I believe in this philosophy that I learned when I worked at a company called Phone Plus about optimism, the importance of having at least cuz you're you're always going to have detractors. Even on this game I worked on, King of Avalon, so many people would always say, "Oh, we're going to fail. This game was not going to succeed." And I started off with that same mindset. But, it's important, in my opinion, and again, this is uh for you to develop your own personal philosophies, but I believe optimism is critical to manifest success. And so, with that in conclusion, I just want to kind of summarize that applying operating system framework

for your career can help you establish that roadmap to success. How do you get from here where you are today to becoming not an organizer and an analyzer, but to get to that point where you have influence and where you can make an impact. You can make a project go from failure to success. Are you that person? How do you become that person? That is the objective of this framework. And so, I guess just kind of in closing, I just wanted to leave you with a few thoughts. One is I believe you should start to build philosophy on what drives success, that underlying philosophy layer. As you gain experience and over time, think about what are the philosophies that you believe in. And have those philosophies drive up through the upper layers of the operating system, so that all of those things are consistent. Um and remember that by having these

philosophies, they're important because they help you make decisions fast and optimize success. You can make yourself more efficient because based upon your set of philosophies, your values, you you automatically know, "We're going to make this decision because of the philosophy that you already believe in." Think third, it's important to understand what your job and expectations include. Fourth, building a map and framework on what you can help you become great. So, once you've developed that framework, then you know, here are the things that I need to work on to get better and to actually get to the point where I need to. Fifth, always understand everything you do deeply and foundationally. And finally, always always attack every process, tool, and approach. Don't be lazy. Offense is defense. All right, guys, that's it. Any questions? Markov, you want to check to see if there's any questions from the audience?

Okay. All right, well, oh, go ahead. So, what exactly breaks the agility of What? methodology, what exactly hampers the agility of that process? Oh, okay. I I don't think it's so much So, first of all, I think that um there's a notion of a way of of doing something, right? So, whether it's Agile or Waterfall, but there's also this notion of what are the practitioners, the people involved, what are they good at? So, if you took if you took a team that has worked Waterfall for the last 20 years, and then you said, "Okay, we're going to do Agile now." Would they are they better off doing like you know, if your life depended on it, would you say, "Well, you know, we'll just we'll just do a Waterfall again." Or hey, you guys are going to

have to completely, you know, revise how you're used to operating, and we're going to hope for success, right? And so, there there's there's that factor. There's also this notion of and I would I would urge you to um to kind of learn about the Cynefin framework, but it's about complexity domains. But there is actually a best process for the type of problem that you're attacking, right? And so, for Waterfall in a simple complexity domain, um that's what you want to do. And for Agile, um it just really depends on the kind of problem that you're that you're solving. But it again, I think the thing that people miss is that it depends on the people. The people who are expected to operate in a specific way without the requisite experience and know-how, it's you can't expect um you know, them to be operating even if the process is better, you can't expect them to out of the gate do better do better as well. Okay. Yes. If someone's trying to get into the

product Yeah. trying to move from being a programmer or designer into product management, looking at that and that same model that you had mentioned, Yeah. which are the top two or three that you think they should focus on when they're trying to get into product Well, I I think that again, this is probably so the question for the audience if you weren't able to hear is if somebody is coming from a development background or other background and trying to become a PM, what layer or what what would you try to work on? Um so, I think it would depend on first of all, it would depend on what does a project need or what does a team need, right? And so, if it's um if it's a specific type of work, I would focus on that first. I would say that um when it comes to the practice in terms of the tools and things like that, that's all effort. Do you Do you understand what I'm saying? Like learning the tools like whether it's Jira or ClickUp or Monday or whatever, that's that's not a intelligence or personality issue, that's all effort. So, all the things that you can do from an effort perspective, you should just do right

away. And then all the things that require more nuance, more experience, like developing these philosophies takes time. It takes experience. It takes you having tried something in a certain way with a team and it's like, "Oh, that didn't work. Why?" So, all all the the the philosophical stuff at the bottom layer is the most difficult to develop. The stuff at the top is the easy stuff, right? So, I I would actually focus on all the things that you can kind of knock off easily, which are just more effort focused rather than experience focused. Mhm. Please. I was just thinking about the following framework, and after the whole session, I realized that why you actually asked that question of the cultural aspect of the organization. Yeah. Now, in an ideal scenario where the management is, you know, fully aligned to these frameworks and fully aligned to these philosophies, it's fine. But but then in a scenario where, you know, maybe it's from your own concepts like your neighbor criticizing your friend uh

in terms of the work uh or maybe pre-meetings, Yeah. uh if these are already there, and there are information holders already in your organization, then I think practicing these philosophies uh will be a little challenging. So, how do you, you know, kind of advise it? Right. And for the audience, the question was if you are in a company where there are certain cultural issues where you can't give direct feedback, where there are pre-meetings, where there are some of these problems, then what can you do? And so, if you remember in one of the earliest slides, I talked about the definition of PM as and and I focused on the word how, right? So, I think it's more important for you to think about for your situation, for your company, maybe, you know, there's you need to know that this is why it's important to first understand the scope and the bounds, right? Your scope, what your what kind of decisions you're able to

make, and also the culture of the company. Now, you know the impact, but within the operating environment, within the rules of the game of your team and your company, what can you do? And then, you have to then realize that the world is infinite, and that in the real world, there are no rules, right? I I think you know, I'm not a fan of Trump, but he kind of proved that. So, at your company, are there things where let's say one one issue, pre-meetings, one issue, the way we do meetings, one issue, can you talk to management and work on one issue at a time to help you become more effective? And so, again, just going back, that is so important to understand the how, right? Any other questions? Please. More of a I don't know, observation or clarification. Okay.

So, in the philosophy book, you talk about the ham and the chicken analogy, and there was this whole fear of failure thing Say as a founder, if I am, say a baker, you know, I'm the ham in this case, I'm putting all my commitments on the table every day. Isn't it somewhere in the back of my mind there is a fear of failure, and doesn't it like contradict the whole thing that you should not be Or are there like different kinds of fear that you want to bucket? Like some are good to have, some are not. Okay, and the question is the different types of fear. So, like my personal perspective on fear is that it's good. Um you know, uh Avinash is one of my co-founders here, but you know, we um as co-founders, we talk about a lot of issues we probably wouldn't talk about if we weren't fearful that the company's going to go under, right? And so, fear is wonderful in that it drives you. It's like, "Okay, I am more afraid that we're going to fail than I'm afraid of having a

difficult conversation with somebody, right?" So, I I think to your point, yeah, there are different kinds of fear, but I think that generally speaking, if you have that commitment, the fear that you will have because of the commitment will help drive you to do the right thing. Right. Yes. Okay. I think uh no other questions. So, that's it. Thank you very much for coming. For those people online, uh happy you were able to join us online, and that's a wrap. Thanks, everybody.