 Hi everyone, my name is Maria and thank you for joining me today to talk a bit about and try and debunk one of the biggest myths that I have seen about getting started in the world of product management. Firstly, I wanted to share that all the views everything that I share today is my opinion alone so it doesn't reflect any of the views of my past and current employers. And I also wanted to say a big thank you to all of you tuning in and listening from wherever you are and also a big thank you to product school for inviting me to talk here. I love product school events. I've been following them for a while and I think they're doing a great job. So it's really an honour to be here today. So let's get started with a question and that is, am I technical enough for this product role? Now I'd like you to think about whether you've ever asked yourself that question. I know I have. And I think it's a question I see very common in the world of either aspiring product managers who are trying to get into product or those who are looking for the next step in their product career. And if I have one goal for the end of this session is to hopefully try and get at least one of you, if you've ever asked yourself this question, to reframe it and think about technical skills in relation to product slightly differently. So before we do that and to give you a bit of context as to why I'm talking about this today, I want to give you just a little bit of background on me. So like I said, I'm a senior product manager at Amazon currently, but growing up I was born and grew up in Romania and 10 years ago I moved to London to study. Growing up in school, we used to have this very clear divide between you either went down a science, a maths path, or you went down a humanities path and a creative path. Now I went down the math science path and I don't regret that. But throughout growing up in the school, I always felt like I was somewhere in the middle, lost in limbo. I loved the practical applications and the analytical side of science. But then I also loved the creative element of all my extracurricular activities and some of the more artistic humanistic studies and activities that I was doing. And I remember in high school, I actually was lucky enough to study computing and programming and I hated it. I remember to this day, one time sitting in the computing lab and being asked to basically turn around a palindrome. So a palindrome for anyone who doesn't know is a number that is written the same way whichever way you read it. So 101, for example, is a palindrome because it's read 101 either way you read it. So one of the things that we had to do was just reverse that through a programming exercise. And I just remember not understanding what the purpose of that was. Why am I sitting here writing code to just turn around some numbers? And thinking back on it now, I realized just how powerful that could be in terms of graphic design or game design, but at the time I just really couldn't understand like how that, you know, was doing anything good. How was that useful for me and it was just boring to be honest. But fast forward a few years I came to university in London and the shout out to the tech society at the time and my friend who built it, who actually just reopened and restarted my love for technology. And that started with one very simple thing that they did, which was through an event they got people to code a Notting Crosses game. And that just clicked for me. It was very similar to the palindrome exercise, but it had a practical application and it was fun and we could play the game. And, you know, I wrote that and I could see the effects of what I'd done. And that was really incredible. And ever since then I've been, you know, falling back in love with technology. So now fast forward a few more years. I am a senior product manager. I've worked on various different products, whether they've been new products or established products as they've been big or small and whether they've been more complex from a technical side or more complex from a stakeholder management side. But I really loved that. And I hope that more people can consider a career in technology. So hopefully this gives you a bit of a background as to why I'm talking about this today. And it will make sense as we go through the talk. So what is the actual agenda for today? Now I've talked about myself. I think that's enough. Firstly, what is the product manager will go a bit through the basics? Where do technical skills fit into the PM role, which I think is really important. And then the other thing that's really important is where do technical skills fit into your hour, my career. And then finally, I'll go through some tips on how to build tech literacy as a PM if you want that and final takeaways before we close. So let's start with the basics. What is a product manager? And I've pulled here, I've done a very basic search because I wanted to mimic what someone who's looking to get into product management or understand this firsthand would do. So what is a product manager? And you have here two definitions. One is from Marty Kagan, pretty prolific in the product world from inspired. And then the other one is Wikipedia. Now, decidedly, that's reliable, but I thought it'd be interesting to look at the two and compare them. And according to Marty Kagan, a PM's job is to discover a product that is valuable, usable and feasible. Sort of similar, Wikipedia says, you know, product manager is responsible for development of products. They, you know, specify functional requirements, they own the product strategy, and then also they coordinate a lot of different functions, including software engineers, data scientists, product designers. And I think that you'll see here on the slide this Venn diagram that I feel like if you're in the product world, you've probably seen this around or seen some sort of illustration of it. But I think this shows nicely that in my opinion, you know, product here in this case, you sits at the middle of all of these, it's at the middle of tech, UX and business. So for engineering, design and the business. And there are other functions there that could come in, but that's the call. So then, why is there such an emphasis on tech and why does that arm get so much more importance or create or is a bit more scary, I'd say, for someone they try and get into technology. Anyway, I thought we could look at some data, you know, my product manager role and looked at a bit of the data. So according to Google Trans, you can see here searches for product managers and product management have grown over time. There is definitely a lot of interest in the space. And so there's a lot more literature, a lot more descriptions of jobs and what product is that help people get into product management. Equally, there's also more questions and this is when I was searching for the same thing. Here are some of the, you know, top questions that appeared on Google when you search, right? The first one is why is it so hard to get into product management? And then do you need to be technical to be a product manager? Those are questions that so many people have asked me. I know I've asked myself and they are really barriers for people to be able to get into product management. So I'd like to, like I said, rephrase these or reframe these in our minds a little bit and talk about how technical skills actually fit into the PM role. Now, I will caveat this by saying that I'm not trying to say that technical skills are not important in product. They are 100%. They make a difference. And I think they make a difference in a few different ways. The first one is technical skills help you understand the limitations of your team, their capabilities. It allows you to prioritize better. Knowing that definitely helps with the product role. It also helps to build stronger relationships with engineering and tech leads and engineers. Knowing their language, understanding where they're coming from, knowing what questions to ask will definitely help in building those relationships. And then finally, it also helps you just understand what is possible, not just in terms of prioritizing and determining capacity, but also just in terms of the product vision and knowing what you want to do with a product. However, like I said, I don't think that technical skills at the end of be all for most roles. And again, for the whole of this talk, what I'm trying to talk about is just a broad and overall understanding and thinking about product rather than individual roles. Of course, there will be roles that may be highly technical and they should specify that. And if you don't have that technical ability, then they're probably not the right role for you. But I'm thinking more about product as a whole and how you think about just considering a career and product on its own rather than individual products. And here is why I think I'll take the first example here, understanding limitations. Here is how I think of it when we think about someone who maybe has technical skills, maybe a technical background in university versus someone who doesn't. I think, first of all, if you're new to a team, you will need to understand that team's capabilities and the way they work anyway. Whether you have the technical experience or not, you will need to understand how they particularly work. Teams are different, people are different, there will be differences. So taking that out of the context, whether you have or don't have technical experience, you will need to understand that baseline anyway. So taking that context, let's say someone who doesn't have tech experience or technical background, they might have to get more help from engineering teams. They might need to spend time with them and ask questions and understand where some estimations come from, how the team works, what timings are feasible. That will take some time on both parts. Someone with a technical experience might not need that, they might understand the concepts, they might already know what questions to ask, they might be a lot quicker in that sense. However, they might also get a bit bogged down in the technical elements, or they might get a bit more into debates around what should be done and how. And in different situations, that isn't necessarily better. So I'm not trying to say that one is better than the other. I'm just trying to say that they both have their pros and cons, and that it's important to consider that and not think that just because you don't have the technical skills, that's somehow worse for a role. I want to have a look at some practical elements as well. Having looked at the product space myself, being quite passionate about it and thinking about my career as well, a lot of the things that I've seen are things like this. What does a product manager do? What does a technical product manager do? And here's this framework with labels, and one background is more business and marketing for products. The other one for technical is more engineering and software development. When you look at skills, the product manager might be better with user research and understanding the market. Whereas a technical product manager is good at coding, might even know how to code, they understand APIs. And then also, you look at things like pay, a lot of times a product manager lower paid than a technical product manager. And I think that that ends up creating this sense of competition, or it puts one against the other. When in my opinion, I think we should look at product more holistically, look at it as a role, rather than trying to put these labels all the time when we look at overall the product space. I think they are definitely helpful when you look at organizations, especially as you get bigger, you do need to create some sort of differentiation or to be clear about what you expect from a role. But I don't think this is particularly helpful when you're looking at career growth frameworks or when you're looking at explaining the product industry and how product works. I think that actually this kind of divide actually ends up creating more barriers for people to consider career and technology. So what I would like to do and propose is actually looking at product and product management role as the sum of its parts. We've talked a bit about the fact that product sits at the intersection of a lot of different organizations and teams and skills. So thinking of it as this graph, you know, you have business know-how, you have technical literacy, you have user experience, data analytics, product vision. These are just some that I've put together, obviously, depending on the role team, your individual preference, there might be more things that you want to consider. But I'd like to think of it as these are all the things that make up a product manager. These are the things that are important to build products and to build good products. Where do we sit on that map? And you can do this at an individual level, or you can do this as an organization when you look at the different types of product roles. So let's take this at an individual level. Let's say I'm M in this graph. So I have great business know-how. I understand the business. I have good product vision. I can build that. And then I also, you know, an experience with user experience. I've maybe done some research, but I might be not as strong on technical literacy and data analytics. Does that make me a bad PM? Not necessarily. No. That just means that I can look at the sum of a whole. I know what I do great. And I can just look to plus on the technical side if that is needed for my role. Equally, let's look at D here, who has great technical literacy, much higher than mine. Good user experience, data analytics. They already have product vision, like, you know, product vision is somewhere in the middle. And business know-how is not as high as mine, let's say. Does that make them a bad product manager or a better product manager for being more technical? No. Again, just different. They will need to flex different areas. And so I think this helps put things into perspective. And it helps move away from the idea that there is this divide between technical and non-technical. And then that's all that matters. Because I think, and I'll go into this in a bit, I do think that a lot of things can be learned. And that's really important to consider when you think about this. So I would really encourage everyone to try and reframe the way that they think about product in this way. If you find it helpful. And here is how you can apply that as well when we look at actual job descriptions. And when you're thinking about applying or considering trying to enter the product management space. And I've taken these two jobs from LinkedIn. I just pulled the responsibilities. And you can see here, so in the light blue color, that underlines some of the things that I saw that are very similar between the two. Both of them require you as a product manager to define the vision for your product. They both require you to work collaboratively with a few different functions, including engineering. They both want you to understand the competitive landscape to understand the market that you're in. But equally, there are some differences. So in the green or greenish, you can see some of the differences. The one on the left is clearly to my reading a bit more on the marketing on the user side. So you work with the marketing organization. You get under the skin of the problem. You bring in the right teams across research, across analytics. And then you understand also the long term part of the business, what they're thinking about, what their strategy is, and the core user journey. Whereas if we look on the right hand side, the other job is a bit more technical, I think, or at least tries to bring out those more technical elements like building a roadmap. You need to write user stories. You need to write product requirement documents. And you also need to collaborate very specifically with IT stakeholders. And then you find that you also need user experience. You need user interface design experience, which could lead on to the design side. But again, there's some very clear things that are a bit more technical. The same person I think could apply for both roles. I don't think this means that, you know, if you don't have some technical abilities, you can't apply for one or the other. So I think really think about job roles in their description, in their whole and look at where they fit with what you have and how it compares to what you have. And if you don't have some of the criteria, especially if it's on the technical side or even if it's on the technical side, don't concern yourself with that too much. Because then you can think about, you know, how do these technical skills fit into your career? And you can start working on that and building on it if that's necessary. So firstly, what I suggest is evaluate your natural affinity to technology. Do you like technology? Is this something that you're interested in? If you do, that goes such a long way. If you understand technology, if you re-text you, if you're interested in it. Then sometimes you might know just as much as someone who did a degree in computer science but maybe doesn't operate in it anymore or is not as interested in it. And it doesn't even have to be a comparison. You can have great technical skills if you have an affinity to technology and you're naturally interested in it. The second thing is identify the technologies that you're interested in or equally the ones that you're not. Right now, there's a lot of technologies, you know, machine learning, there's AI, they grow in popularity and shift inside and people become more and more interested in them. And a lot of times that might seem prohibitive. And in some cases it might be. If a role needs someone with deep machine learning experience, you don't have that, then maybe that's not the right job for you. But if it is something that you would be interested in and you'd like to learn, then you should also be able to go and do that. You might understand where your strengths lie and your interests lie and try and plos on those technologies and don't think of it as a barrier but more as an opportunity for you to learn something new. And then finally, think about how these technical skills are built towards your long term goals. Do you want a career in technology? Is this something that you're interested in and would you want to build those technical skills? Or is it not? And then it's just a matter of finding product roles that are not highly technical, whether you need a high degree of knowledge and potential coding experience. Just go for the ones that are more on the user side or where the company might need a different set of skills that you might have. So if you do want to build literacy as a PM, tech literacy as a PM, how do you do that? And I'll say I come at this as someone who has done that themselves who, like I said, I didn't come from an engineering background. I did business management in university and then I started in a commercial role, moving slowly into product management through different stages. And I've purposely tried to build my tech literacy as a PM because I know that I'm interested in it. I know that it builds my career. So how do I recommend you do that? There are a few things that I've found have helped me and I know from others as well. The first one is courses, online courses, in-person courses. They're like really easy to get now. There's a lot of platforms like Coursera that do free trials and you can get a really good basic understanding of some concepts like SQL or SQL and the use of Agile. I did that recently a few months ago. I took an Agile fundamental course on Coursera because whilst I use Agile in my day-to-day job, I wanted to just really know what the theory said and then compare with what I was doing. That was really helpful to just have an understanding of the basics. And it was really not prohibitive at all. I managed to get a free trial and do that all without even costing me anything. The second element, and this is the hardest one to get, I will fully admit is hands-on experience. If your organization, your company, your circumstances allow you spend some time with people in those functions. If you're interested in product management or interested in engineering, spend some time with those engineering leads, engineers, with product managers to understand what they do. And that can be a really good way and a quick way of learning PM skills if you don't have them already. And that doesn't have to be, I will just say, you know, necessarily going into, you might not even realize if you are doing that or not. So think about every skill that you might want to learn from that, rather than having to do a product role or a product project. And I'll give an example here in my very first role, my very first year out of university. I was in a commercial role. I was doing PNLs and all the commercial stuff. And I got a project that I started building myself that was looking at customer experience. And I'd never worked with engineering before. I didn't know what an MVP was, a minimum viable product. And I didn't know how to go about it. But what I ended up doing was actually build a minimum viable product, came up with, I had customer research, I built that. I went to an engineering team and shared that with them. They committed to give me resource. And we worked on that, we reduced the scope of the experiment. And then we ended up running that. And I had no, absolutely no connection with that team. I'd never worked with engineers before. And I did it out of instinct more than anything I recognize now. And so what I want to say is a lot of times we think about frameworks and we think about things that should be done in what way and the experience that you need to have. But I think sometimes we forget that the frameworks came from experience and that people just did things before these frameworks were created. So don't be afraid to think about what are the skills that I need to get and how can I get them rather than thinking of it as I need to do a product role or I need to necessarily work with engineers and on this project. Just think about the things that you want to, skills you want to develop and look at them that way rather than getting bogged down into the details of frameworks and details. Now a third thing that you can do that I think is also helpful is shadowing. Whilst maybe you can't get firsthand experience. If you know people that are in product roles or in roles that you're interested in spending some time with them, even if it's a day or a week, you know, ideally learning what or seeing how they do things is so helpful and it can actually be a proxy for hands-on experience. And finally, but definitely not least, PM community is super important. If you know people who are in product, you can join things like this. You can take part in activities from product school and talk to people that you know in the space to understand how they do things is again a great way of upscaling. Similar to the course that I did on Agile at the same time, I also spoke to people and friends that I knew that were in engineering roles or were in product roles at different companies of different sizes and I asked them how they did things and that was super helpful to get an understanding of how Agile works in other organizations and it was actually really easy. I didn't spend that much time. It's quite enjoyable to learn about those things. So, the final point that I want to make on this slide is how important curiosity is and I mentioned that on a bit earlier but I really think that your affinity to technology, your interest in learning can go such a long way and can even trump hard skills because a lot of these things are learned if you're looking at it as a whole. If you're not looking for something super specialized, curiosity can take you a super long way in building that tech literacy and tech understanding where you can do a great product job without having to have that background as a degree or even as experienced prior. So, what are the final takeaways before I let you enjoy the rest of your day? Firstly, like I say, I really hope that I've been able to at least get one of you to reframe the way that you think about product and technical skills in a way that is helpful to you to be able to maybe go past the barrier that was once there before that maybe prevented you from thinking about considering your career in technology or thinking about how far you could take your product career. And I've looked at takeaways for both individuals and organizations because I think it's important to make some changes on both levels. But I'll start with individuals. I think that's the easiest to implement. The few things that I'd like you to think about or take away are firstly, think of technical skills as part of a whole. Again, then on the end or be all, think of it around all the other great things that you do and how they complement them rather than making them a blocker if you don't have them. The second one is know your affinity to technology. Whether you're interested in technology makes a huge difference to being able to do a great product job. And that's super important. You don't need to let the idea of needing to have some sort of technical background be a blocker in you being able to get a job in product. The third one and my favorite is stay curious. We can always continuously learn. That's really important in upskilling. That makes a great way of also getting to meet and know people and build better relationships with any kind of team including engineering. And it's a great way of continuously learning. The final point is don't be intimidated by job descriptions. Again, a lot of times technical, technical, technical, technical can be quite intimidating or certain skills required can be quite intimidating. But really take that at face value and don't let the things that you don't have our way the things that you do. Don't be afraid to talk to hiring managers to really ask about what people are looking in a candidate and go past those CV requirements and actually look at the skills that you have and you can bring to an organization. And then equally on the other side, if you're a manager, if you're in an organization and you have the power to change structures, recruitment, to influence it, have a thing about these few things. The first one is be precise with job descriptions. Be clear about what you want in that job. Is it that you do want someone highly technical or do you want someone who's great with user experience? And then similarly to that, be clear to what is actually a requirement. Do you really need a product manager that has computer science as their background? Is that really necessary? Because putting that in will definitely deter people who don't have computer science background but might have great skills from applying with that. The third one is focus on potential, not pedigree. Similarly, look at someone's interest in technology. Look at their skills. Look at what they've been able to achieve and where you see them heading in the next few years and how you can grow them rather than whether they have a computer science degree or whether they have worked with machine learning in the past. And then finally, don't create unnecessary barriers. Like I said, I think there are many situations where the technical element is focused on too much or people being maybe detracted from thinking about a career in technology because of that. As managers, people with influence just be careful of encouraging people to consider a career in technology and product and to help build those skills rather than creating it as a barrier. So with that, I want to thank you all again for joining me today and for listening in. I hope this has been helpful and if you want to talk about this more, if you want to continue the discussion, please reach out to me on LinkedIn or social and I hope you all have a great rest of your day wherever you are.