 Hi everyone! My name is Maria and for the last 10 years I've been building Korea in Product Management. I've been working in various roles and were wearing various BM hats. Thank you so much, Product School, for asking me to share a few of my learnings and also propose some framework and approaches that I will share with you today regarding the ways you can scale your BM career moving forward. So, first things first. Let's start with Elephant in a Room and let's talk a bit about who is Product Manager and what is actually PM role is all about in software development teams. What does it mean being a Product Manager? Or if I may put it this way, sometimes Product Manager is even called Product Leaders. So, who is PM really on? Let's start with this question and let's try to look into it and maybe cover a few thoughts that have been around for quite a while regarding what is the purpose of PM and what is the main issue that PM addresses through Korea and how development teams. So, you know it better than me and I guess you've read it in many, many publications all around the internet that sometimes PM is regarded as chief executive officer of its product. And yeah, you all have heard at least once that PM is the CEO of a product or a product team. To be honest, I find this way of thinking quite risky. Being CEO in majority of cases implies that having direct authority over your team members and product managers and usually you simply do not have this authority. You cannot fire people, you cannot hire people to your team. You need to figure out how to influence without direct power over people in majority of the cases. So, I wouldn't refer to PM as a CEO. I think it's a misconception. You need to ask your question. Do we want to comment or do we want to enable people? Because if you are CEO, you always have this power to tell people what to do. And if you're a PM in majority of the cases, you need to help people to figure out what to do and how to achieve their goals so it will be beneficial for the product and its strategy. In reality, to get the things done, PM need to have impact and not the authority. They need to lead people and get results using communication, vision and influence. Alright, let's cover the other very, very common determination of who PM is. And this is a person who says no. It's the other common myth that PMs is someone who says no all the time. No extra feature request, no to stakeholders, no to what abouts. So, you are the guy who protects your team and constantly says no. Again, this is a very, very common way of looking at what PM does. I still want to actually challenge that because if you always start with no, people start bringing the input to you. And for PM, it is super essential to actually listen to people and make sure that they bring business input to the table when they discuss product decisions with team. And moreover, when you constantly say no, people start listening to you and they start trying to go over your head and try to persuade people within your team to work on their requests, to address their issues. So, I wouldn't call PM the one who says no and I would encourage you not to act this way. Alright, PM is not the one who protects the team and constantly says no. And PM doesn't have a necessity to actually proclaim himself as a chief executive officer of the product. So, when you look at a team collaboration and product management, who product manager really is? I want to offer you one concept of how you can look at yourself as a product manager and I think it's really helpful for you to actually then figure out how to develop your skills and scale your career moving forward. So, I would offer to call a PM a catalyst. So, you know from chemistry, from all chemistry lessons that there is this substance called catalyst and some chemical reactions and catalyst is usually an agent that provokes or speeds up a significant change or action. If you remember, catalysts do not take part in the reaction itself but their presence speeds the reaction. Similarly, PMs do not write code or do or work on designs or create something with their own hands besides product documentation of course. But what they do is they help others to succeed so they can together build something the customers would love and appreciate and something that will help business to grow and scale. So, basically, PM is more or less a enabler or a servant leader of the team. So, let's try to answer a few questions. How do you progress in your career with this mindset of being a catalyst or being a servant leader? How do you progress with your career if your job is to provoke speed and change in the end of the day? Okay, I have few more fun pictures for you and few more concepts that I want you to consider. Let's start with a definition of what sort of reaction you are in because the further you go in your career, the more complicated situations you'll be facing and the more complex reactions you need to speed up as a catalyst if I put it this way. So, let's look at this graph. You have ambiguity on one ASIC and scale and complexity on the other ASIC and that is your career path. So, usually, as a PM, you start with a relatively... I wouldn't call it simple, nothing is too much simple when you're working as a product manager, but with relatively well-determined projects. So, it has relatively low level of ambiguity. So, basically, you are... the things that you're working with are quite predictable and quite well-defined. And in terms of scale and impact on complexity, it's also usually quite simple. So, you're working on a specific screen of the application or on a specific function. And by talking to a customer, gathering feedback and looking through numbers, you more or less can quite well estimate what the impact of the change would be and what exactly a customer needs. And that's what I call as a simple project in the beginning of your career. But as your career evolves into the future, you start working on projects where you don't even know what the customer problem exactly is and it's your job to define it. And you also drive projects that probably need input from multiple stakeholders, multiple teams across the org, and sometimes they need involvement of partners which makes these projects really complex. And scale, of course, scale increases over time when you are a senior PM or a principal PM and some works you are trusted with project that might have a significant impact towards the business and its strategy over the years. Let's talk a bit more about what is ambiguity. So, as I already said, we start with short feedback loop and well-defined problems, something like customers feel very uneasy using this screen. Customers do not like that they don't have a sign-up button. Next to the input field. All these simple and very well-defined requirements that we might get from customers or from the market. And over the time, we evolve into very well-defined problems with different spectrum of solutions to fulfill these problems. Sometimes customers might explain you what they need as an end result. Sometimes it's really hard even for the customer to identify the exact problem. They just can explain some feelings and tensions and underlying needs. And you as a PM need to formulate this job to be done, this problem, by using different methods like customer research, personal analytics and things like that, to actually define your problem space first and then to look into number of solutions that can be a very well-passed to resolve the problem for the end customer. So as I said, you start small, you work on one screen. It's usually UX UI problems that you work. First is a junior PM and then as you move forward, you try to resolve big problems, big issues for end customers, being that someone who is using V2C product and you help people, for example, by building a messaging app to communicate with each other or being a B2B product and you help customers of your B2B product scaling the revenue moving forward. Scaling the revenue sounds like a really, really, really big and ambiguous problem. You might have different sub-problems that you will need to identify and for which you will need to come up with a specific solution. And that's what I'm telling about how the scale of ambiguity actually evolves over time. And let's talk a little bit about the other basics which is scale and complexity. So we usually start at a junior level with features for one persona with a relatively small impact. So let's say we make an improvement of the screen usability and we see increasing signups or we make an improvement of checkout screen and we see that more and more people are purchasing our product or we improved conversional world. And then as we grow in our career, we evolve into working on multifilter initiatives with long-term impact. It's sometimes really hard even to determine an impact at any given day because what you start building today will only deliver first results in a year from now which is something that you need to get used to live with and try to work with and understand what kind of proxymetrics you can enforce in the middle of your project to move in towards the right direction. But more or less when I'm talking about scale, I'm talking about this level of impact of the project that you're working with as a PM. And this level might be very different and the further you grow in your career, the greater level it becomes. We understand what is the field we are operating with. So we understand that there is like some scale and then there is some like ambiguity in terms of customer problems. But how do we progress over this field? What sort of skills do we need? What sort of things that distinguish junior PM from senior PM are? I like to explain this whole thing using a Lego metaphor. So we all love Lego. We all use Lego. Some people start building something from Lego from, I don't know, even when they are younger than one year old. So they're using these big Lego blocks. So when you are junior PM, you usually build something simple with big, very bright, but very simple Lego blocks. So this is where you are as a junior PM. Then when you go to the next level, let's call it mid-level, PM, senior PM, somebody like that. You already can build more complex instances, more complex things out of your Lego. So you know how to use smaller details. You know how to attach those to each other. And you come up with something that, as you can see on the middle of this slide. And then when you become really advanced, and I think like you are seven, 10 years in your career, you can build very fast stuff at scale. You already know how to build the whole Lego city. And you know what things you need to keep in mind to make sure that it is a success and this Lego city appears in a reasonable time. And actually that city represents customer needs and wants of those who asked you to build this city. So basically whenever you start, you're doing the same stuff as you can see all the time. On the starting level, on the middle level, on the advanced level, you're building things from Lego. But the blocks that you operate with are different. And the things that you're building are a bit different in terms of their complexity. So this is how I try to explain what's going on with development of PM skills. So those basically are products, the structure of products, the structure of projects that you're working on becomes more and more complex over time. And of course, like people need different skills, cognitive skills to operate with different Legos. Same way people need different set of skills to operate on different level of this product management journey. So what skills do you need? No matter where you are in your career, there is a foundation which I would call product management methods and tools. All things related to how to do customer research, how to determine personas, how to work on jobs to be done, how to scope development work. You need those skills all the time. It doesn't matter if you are just focusing on building one small feature or optimizing one screen of your application, or if you're building a whole set of features that will go into a big new product launch, you still need to master those basic product management methods and tools. You need to know how to interpret the data, how to talk to a customer, how to write PRDs and product press releases, all these kind of stuff. So this is what you need all the time. The other one aspect of product management skillset, which is basically as important as foundations, is analytics. The further you move into this ambiguity, big scale kind of projects, the more you need to understand how to interpret data, how to make decisions when you don't have the full data, and how to continue with moving forward with your product development based on the data that you get. As I say sometimes, junior PMs are usually lucky because they are trusted with the projects with a shorter feedback loop. So if you're working in B2B, you sometimes can just talk to your customer, ask them to join you on Google Meet and ask whether they like the feature or not. Or you can immediately observe through the chart if conversion or some other metrics that you're optimizing for is actually increasing or decreasing after you perform some changes to your product. Whenever you move further into your career, you need to understand better how to set up checking, what measurements you actually want to track, what measurements you want to optimize for, what is not stuff for your product. So you need to train your analytic muscle. You need to be really hands-on with data and you really need to understand what would be the framework that empowers your team to make data-driven decisions. At the same time, you need to be in a position to challenge your team whether the data that they bring in is clean and reliable and robust. And at some point in your career, you will be tasked for the first time to come up with something like a KPI drivetree for your product. So basically, you will need to come up with a whole set of metrics to define the success. And that requires another scale and another understanding of analytics. So whenever you see some trainings or coaching opportunities regarding analytics skillset, jump on it. It never, never, never, something that you can disregard. It's essential for product managers. But as you move in your career, there are also other skills that are very, very important to develop. So usually as a junior PM, you work with a very limited number of counterparts. A couple of developers, maybe one designer, something like that. But then at some point, for the first time in your life, you're asked to work on something like a cross-team project when to enable some functionality you need to drive collaboration of several teams. And further in your career, you might be in a project where it's not just teams that are in your organization, but also some partners that need to deliver some functionality on top of yours. So collaborative leadership, how you can motivate people to drive the project forward. And those people might be with different backgrounds, with different points of views, with different cultures. It's also really important product management skill if you want to get your things done. And I guess it's a must-have for someone who is going above senior or principal PM to be able to involve collaboration between different teams on the different org levels and across orgs as well. Then as you go further in your career, you're more and more talking to people who actually give you resources and money for your project. And that means that you need to become a pro in terms of commercial leadership. Usually senior and principal PMs are in charge of creating a business case and really proving that something that they're building will drive value for the business. And they can actually connect the dots of how by solving customer problem they can actually also solve business problem. So it makes sense to invest this 15 developers for a couple of months into your project. So understanding of such things as profit and loss balance, error-wise, and all basic business terms and all basic business skills is super important if you want to move forward in your career. You cannot be a good PM without ability to write a proper business plan or at least a proper business case for the future that you're building. So yes, the more you become advanced, the more you become closer to this like high-top levels of PMs in your career, the more you need to look at whatever you do from a business perspective together with a customer perspective. And then on the top of this whole schema, I put coaching because this is something that you really need to develop maybe in the beginning of your career, but it becomes really essential when you become a people manager or a principal PM who is driving big projects with a deep level of complexity. You cannot do everything hands-on. You cannot even write every PRD by yourself anymore as someone who is acting as head of product or director of product or as I said, principal PM in charge of a very big project. So you need to teach other people how to do it. You usually lead a team of PMs and you need to coach them well and the better you coach them, the better team performs. So coaching is something that is really essential to move forward in your career especially if you want to jump from this individual contributor position into something where you want to manage people because again the better they perform, the better your results. So the best thing you can do is to coach them well and to make sure that they perform well. So this is the whole set of the skills that you need to develop and as I said, I think you need everything. Depending on where you are in your career, some skills are more essential, some skills are less essential in the end of the day. You need all. So when you just start knowing basic product management methods and tools is the most essential part. So you can prove to your boss and to your team that you actually ask them to do something that would drive value to the customer. The further you move the more important those things as analytics and collaborative leadership become because you need to analyze ambiguity and you need to look into the ways how people collaborate and how you can empower and motivate them to move forward with their goals. And as you get closer to leadership positions, as you get closer to more complex projects those are such things as business skills and coaching become more and more important because you can do less work hands on and you need to do your results through coaching and influencing other people. Okay. So how do I develop those skills? How is a PMI start small with knowing basics and learning basics and how I move forward into all this advanced knowledge that I need on the top of my career and I'll get back again to this Lego block metaphors that I used in the previous slide. So to train yourself you need to choose the right kick. The truth is that you can of course join some institutions as product school to study basics and to learn from experienced PMs based on their experience but nothing can train you better than hands on work on a specific project. But you need to choose your kick really, really wise. So you usually start simple make sure that your first job gives enough opportunities to test in practice what you have learned in school by listening to courses by going through some sort of articles in literature. So if you're just looking for a first kick on a PM journey I would suggest start with some projects where you need to optimize really simple things so you can try everything that you know in practice. As I said, big simple Lego blocks start with that. Then as you actually get more acquainted with how to practice product management you can move into more complex projects and this is where the tricky part comes in I interview around maybe 20 PMs per year at least for the positions that I have open in my team. What bugs me a bit is that once you learn something you just reproduce that all the time. So basically you start simple you manage to practice, let's say few approaches and methods and frameworks for bitable products and then you go and pick up projects where you can reinforce this learning where you can practice the same things over again. So you work on this thing and that's the only thing you know and that's why I think it's really important in the middle of your career to pick your next gig really wisely so you can practice working with different Lego blocks. As you have seen to build a Lego city you need to know how to adjust and move all these different pieces and all the different details. So make sure that when you choose your next project you actually choose something different from what you have practiced on the previous one. So let's say in one you worked really close based on personal approach choose the next one which will give you the opportunity to practice user journey quite well. If you work quite a lot with B2B segments and with business segments and with SAS solutions pick up the next one where you will have an opportunity to work with B2C segments or maybe just some like mass B2B SAS products that actually are quite close to B2C products as well so you can practice different stuff all the time 10 years on these, 2 years on that and then you kind of will have all these skillset around you where you can work on different projects and more or less know how to adjust different Lego blocks and then in the end of the day you will be the guy who is able to build your own game. So you can look at whatever they bring to you and you can figure out how to put things together so you can build a city a castle whatever, business is in need right now. So you can better understand what are the essential things that you can pick up from your experience. Basically that's something that is really tricky because once you learn one thing people are super happy to offer your job with a similar requirements with a similar position but if you really want to progress it's all about how many different things you can operate with in the end of the day. So as I said that will be my maybe most essential advice and the biggest takeaway I want you guys to remember from this talk choose your next gig wisely and make sure that you practice versatile approaches and versatile products and that will be really easy for you at some point to build your own game and to actually work on a very complex project on the top of your career. So I hope that I shared some good learnings with you today. Good luck, be prepared it's really fun to be a PM. It's super fun to be a PM who has been working on different projects. It's really fun to build stuff even if you start simple and it's amazing to build stuff when you know what you want to build as a creator from a different Lego blocks. Thank you so much for listening to me have a great rest of the day wherever you are right now. Bye bye.