 Well, hello everyone and thank you for joining this webinar around can I become PM slash tech PM without a technical background? And firstly, just to kind of put a pure disclaimer out there. So any of the comments or any of the statements I'm making are mine alone and should not be considered a review of my employer. Just wanted to throw that out there before we start. But just to kind of cover what we're going to look at in this session. Firstly, I want to kind of define what a PM and a PMT is. In a lot of ways we are talking about a very similar role. The core difference is being the fact that a PM may work on a bit more customer facing tools and a tech PM may work on a bit more of a backend tool. So for example, you may have backend of search or a bit more complexity around it. And a lot of this can change. Like so there is no one size fits all or like there I can basically say here's this general statement that basically says, okay, everybody's going to get these particular things and it changes so much. And that is also what we're going to kind of cover throughout this doc, throughout this PowerPoint. And also, I also wanted to put some space in here to kind of showcase like some of the things you should probably look at from a PM PM by review. I think these resources, especially when it comes to like technical understanding and how things work, I think it's super useful to still know, regardless of whether you want to be a PM or whether you want to be a tech PM or you still just discovering stuff because I think the value behind knowing some of this stuff is very important. And throughout this experience, I'll try to share a few stories from how I got to where I am and also some of the challenges that I faced because I think those are probably more valuable to you as people listening to kind of see what my story looks like and how the world experience looks like. So just to show a quick agenda, so we'll start off with who I am, like why should you actually listen to me. And then we're going to talk about a bit of the differences between a PM and a PMT then looking at kind of job roles and how does that kind of differ and be advertised around. And then we'll look at like overcoming technical lack of technical knowledge. So for example, if you don't have a broad like you didn't do a computer science degree like me, what does that look like? How do you kind of overcome that? And I'll show you a really cool story from one of my old managers who had a very low technical background and how she delivered like some of the most amazing questions that I have ever seen. And then I'm also going to talk to you a bit through like a couple of the technical skills that I think are worth looking at and kind of walking through what those stories look like and what are those options and then and also like how do you help with interviews and also a bit of options that are mentoring as well. So with that being said, let's get started. So firstly for my, so I've been working in, my name is Josh as we covered earlier, but I've been working in product management for the last six to seven years. I worked on quite a few very sorts of products. So big ones, small ones, like small features, large features. So what are my probably recent ones which some of you may have used with Amazon Diagnostics. So we sold like a COVID-19 test kit for Amazon. So if you used any of the portals in the UK, that was part of my product. So if you did, thank you very much. And I kind of got into a fact of specializing into a whole D2C product development aspect. So that's kind of where I've been kind of focusing most of my career on and it's more of where I'm landing in. And yeah, and for fun, I play a lot of tennis, maybe a bit too much. So with that being said, let's just dive straight in. So I guess what is the difference between a PM and a PMT? And if all of you are expecting me to say, oh, here's the answer, you're going to love the next slide, which because it's just going to say it depends. And yes, it really does depend on the team, the role, the company, the organization, the industry, the size, and so on and so forth. Like there are so many factors in what determines whether a PM is a PM or a PMT because if you work for a small organization, so I worked for a startup. I was literally building and like I was talking to engineering working on all the nitty gritty gritties of working within the role, like actually having to discuss the technical fronts, how what are the databases we use and what are the architectures we might use and so on and so forth. And whereas when you go into a much larger organization, you may have a bit more of a clear differentiation where you as a PM may look at a bit more of the strategy, long term vision, things like that, and maybe less inferences on to tech. And whereas if you're a PMT, you may have more inferences on to tech, sort of like trying to work through architectures, much more technical problems. You may also work on a very technical project. Like, so for example, if you work for Google Cloud, you may be working on like cloud functions, for example, or cloud infrastructure. And so that can all vary by industry and by product type and by company size. So I think there is no fine answer, but what I kind of want to go through this was ways to kind of potentially detect what the problem might look like and also what are the key differences that I would, for me personally, what I would classify the PM as the PMT. So firstly, let's talk about a work, like the features and products. So you kind of work on products and features, regardless of your PM or PMT. So that kind of raw years and change. Similarly, going through a product lifecycle, pretty much doesn't change. You may have some uniqueness to it. So for example, if you're a B2B PM, you may have slight differences compared to if you're a B2C. You also have a very, like for example, you work on games, that might be a very different CX, like development journey compared to if you're working on, I don't know, hardware based one. So for example, you're like creating wind turbines, what that might look like, could be very different. Again, all of you will still work on vision strategy, but the extent of which you might work on may change, depending on how the teams are structured. The access to tech teams might also change, but again, you will have some sort of access, even it might be a bit distant, but you will still have some sort of access. And I think where I kind of drawn the line, kind of I've seen a bit of more differences is around whatever features you end up working on. And so like for example, the focusing on the business features is a bit more selectable to the front end CX, the front end UI, whereas PMTs may have a bit more of APIs or a bit more of a technical capabilities for one. And this is by no means a clear differentiation sign, right? Even though there's a line drawn. So in my last role, I was completely a PM and I was literally owning the front-end and back-end and such. So I literally had to do all the technical stuff as well as all the front-end stuff. And because I had a much more technical experience, I was given it, but because when we kind of shifted to another slightly different working model, I kept the technical aspect of such because I was much more technically enabled compared to a couple of my colleagues at that time. So it allowed us to kind of shift and prioritize things differently. But when you have a bit more technical understanding, you end up working on a bit more technical products and you may end up owning a more technical side of things or looking, focusing on more on the technical side of things. And also you may have also a slightly different pay scale. So I know like within Google and Facebook, that basically if you have a technical association with it, you tend to have a slightly higher pay scale compared to if you were just a standard PM. And I don't know what the greatest differences are, but I've heard there are differences. So based on what I've seen, that would be kind of something to just to consider as well. So with that being said as well, so just to kind of outline a key statement all of this, right? So there is no one size at all and there is no key statement that I can put out there that basically says, hey, this is what a PM is, this is what a PMT is. That basically can give you a good grasp when you look at job descriptions or when you look at roles to be say, hey, okay, that's a PMT role, that's not. Titles are super helpful, but generally sometimes they're not. I want to kind of give you a good vision for that, like with one of the stories that I had. So when I first started my role within, with one of the travel organizations that I worked for, the role that I had, I was literally working with UX, I had my own dedicated tech team. So I had about eight engineers, I think, all together including back in tech search tech teams. I had a dedicated strong master. I used to be involved in very much architectural conversation. I used to have like digital discussions with architects. And then I used to have very detailed conversation on how we store stuff in database, what the growth plan for that is, and developments around it. And then I switched. So when I moved into working for my current company, I looked at what that looked like, right? So I was trying to work out, hey, is this a PMT role? Because I thought my barrier of a PMT role was much higher and I thought it was going to be more technical side. And I was like, no, I want to work on the front-end CX. And it turned out like what we had defined as a PM in that team was very different. Like I was not working on any of, like trying to launch things in sprints. Like I had no agile development cycle. Like I was very much focused on the future. I was looking at the vision, the strategy, the finances around the business. So you end up having to skew a lot of those variations between teams, between companies and between worlds. And for me, that is one thing that I found is that I had to, like recently I was searching for jobs, I had to actually investigate and dive a lot more deeper into every single role to determine like, is this what I'm looking for? And I think that is key in what we're doing. Like his job descriptions are sometimes not what they seem to be. And let's go on to that because I feel like I'm talking quite a lot on the next topic already. So as we kind of was talking earlier, like how do I know what the role being advertised is for PMR PMT? So I think this is kind of a good space to kind of talk about a product manager, right? So with a product manager, I'm pretty sure most of you have seen this sort of Venn diagram, right? So generally what you would like to see is like this equal split, right? You know, the perfect balance of everything, which generally does not always be the case. And sometimes you may end up being pulled in one particular way or pulled in a different way. So in some instances, you could actually have, for example, this section here, you've been pulled a lot more in the discovery and validation side, or you could be pulled a lot more in the business side. Or in some instances, you could be pulled a lot more in the discovery side. So where the Venn diagram then gets a bit skewed to basically be one way or another. And that could effectively change the type of role it is. And especially if you're starting out as a PM, you want to have a bit more of the balance. You want to kind of try out all the areas, get an equal balance, get the agile product management experience, like building products from releasing on a frequent basis. And that's where the overarching aspects of being product, of being a product manager becomes very useful. And I think that the key learning point for me, at least when I was trying to starting off, is like when I switched roles, like how much I rely on still the foundations that I picked up from my earlier jobs within my current job. And the early jobs still have provided me a lot more value in my current role in being able to deliver some of these products and using the same mechanisms and the flows and the journeys in what I have today. Because you'll be very surprised in how different one organization is against another. And some organizations where you think are super, have a super high bar, you'll be actually quite surprised in sometimes what that shift looks like. And teams and team by teams are also quite different as well. And to give you a bit of a story as well behind this. So when I was looking for a role within a different company recently and what they had articulated in the job description was nothing really, nothing similar to what they had, what I thought it was. Basically they had described it in such a way that nowadays if you look at most job descriptions, it's just like a pretty much a copy and paste of other ones. And it's just like these few minor changes like, oh, you should do this or you should do that. And that's where I've kind of gone, okay, I kind of have to dive a lot more into what the interview is. So I spend a lot of time doing the interview trying to figure out what is this role. Like I asked them, like, do I have my own dedicated tech team? Do I, can I work with UX? Like, do I have X? Do I have Y? And like what are the most important factors for me in being a product manager? And how, what this is talking is that over the last few years, especially as I'm going through different companies and different roles, is that because product management is so different and some product management roles are actually marketing roles and like even in my last company, we have a product manager for tech and a product manager, like digital product manager and a regular product manager. Regular product manager does not do anything similar to what a digital product manager does. And all of a sudden you have two different titles, right? So it's not the same as what you would have expected before. So those nuances are very, very hard to find and articulate. And the only way to kind of do that is through the interview because I think at least for me, when I started the interview process, I never used to dive as deep as I used to, as I do now. And I've had previous friends and colleagues who were literally, she spent about quite a lot of time literally trying to figure out what type of company it is, what type of product development process do they have? Do they have a good foundation piece? Does the product team have a good structure in place? And she has completely loved it. And I have to echo that when I started diving a lot more deeper into each of the roles, I have found it a lot more easier to find the role that matches my needs and matches my requirements. So, and I think just a quick bit of advice for everyone, especially looking to start out as a new PM, I think it's much more important to learn the fundamentals of being a product manager than actually being, trying to go for the biggest company in product as that's out there. So like for example, I would probably not apply for, if I was starting out now, and if I knew everything that I know now, I would not apply to Google, Facebook, Amazon, or any of the big fan companies fast. I would try to find, because the problem there is that these teams and the roles tend to be quite different, depending on which team you join, which roles you join, the type of company, because they can focus on the future quite a lot, because they have that space and that gap to go for it. Versus when I found that basically, working for a small to mid-sized company, you kind of get a lot more of the experience, hands-on experience that you probably might not get. And you will also have a lot more, be able to kind of flex that role, because they don't have, like in my last company, we didn't have a dedicated PM, we didn't have a PMT effectively, it was like a basic product manager, that's it. And so that switch, like effectively being able to trial both sides and being able to see the different aspects of product and being able to kind of have those instructions on. And yes, and over time, you can kind of tailor it to where you want to go and kind of say, hey, look, I want to be a bit more on the business side. So let me find roles which are more business-oriented than tech-oriented, or I want to do more of this and you can kind of switch between one or another. And then also I think, especially if you're new to PM or looking to become a PM, like the B2B, B2C, and like trying out different industries is also very useful. It is so different what you want in the street or not there. And I unfortunately have not had the experience to work in a B2B space as much as I'd like. I kind of advise people on it. I've kind of seen a few spaces of what I look like, but it is so different. Like the way you gather data is so different. And when I was starting again, I would totally recommend people to trial all of these industries, trial all of these specialisms to then work out like, what is it that you want to focus on? Kind of as I kind of outlined earlier on, I kind of specialized, industrializing quite heavily on on the B2C side and kind of showcasing and building what, like direct to customer side, where I was actually going to the market launching a new product and building that like, it's great, but I would have liked to have played around with the B2B market for a bit because I think that'll be quite cool. But yeah. So yeah, let's quickly move on. Just cautious of timing here. So how do we overcome the lack of taking along? So I really, really wish this was a bit more interactive session in some respects because I would love to see your responses here. But in my way of looking at it is basically ask a bunch of questions. And I want to kind of share a good story here. So because I think the story would actually help articulate like my technical knowledge, like having done a computer science background and all of those kind of things. I've like, I would have never come up with this question. So my previous manager at like my last company, so she had basically, she, I don't think had a thing. She had a graphic design background. She's been working in the product manager for a while. And she was going through, like I was working on a project at this time, which was like to kind of read organized search around how to find alternative with hotels and alternative responses. So we were looking at kind of those variations. And one of those things that I was asking like very generic tech questions, like what does this look like? Where are we going to find this? What does the algorithm sort of look like to generate some of these recommendations and so on and so forth. And my manager had asked some of the most brilliant questions that I did not even think of. And she had asked like questions like, oh, how about how do you handle like, I think it was the comparison between two countries or certain regions and things like that. And like those were like very, very basic business questions, right? Like the fundamentals on it. I ended up by default, defaulting to the technical side, right? Trying to solve the technical problems. But by her asking some of the more fundamental questions and asking a lot more like just basic questions like how can you do this differently? Can we do this a bit shorter? Or can we, is this a easy way to maintain it? How can we get a lot more people updated? Can we increase the capabilities of it in the future? What does this look like? Brought out a lot more of the technical questions and like a lot more of the answers to how the design and the infrastructure work. And there is an element of you need to understand what that looks like and understand it. But I think the ability to ask the questions has for me far a ways any sort of technical knowledge that you can create. I have found that I have gone into meetings after meeting after meeting with colleagues and there are, PMs were really good and the ones who are really good from my personal perspective are the ones who can ask very good technical questions without having any sort of technical background and I've been completely amazed by some of these PMs who have actually asked very interesting questions and you're like, wait, why did I think of those? And so just so for all of you who don't have a computer science background or any of these things, just ask questions. You may think it was like, oh, this is a very silly question but it actually might be quite profound and like can change the way things approach and change the way we deliver things. And that's always happened for me. And I think even, yeah, just ask questions just ask questions to say. And so I just kind of dropped down like some of the key questions you can probably think about like what you could ask. This is not by any way a favorite template. Like basically this is not like say, okay, cool. For every question, for every product you go ask these five questions, you will have all the answers. I think these are like some of the questions you should ask like gives you an idea of a template like how can we automate something? I think that's a very good question nowadays, especially with how far technology and AI kind of have progressed. I think it's very useful to know the answer to that question, right? So like how can I automate something? How hard is it to maintain? I think we very much underappreciate maintenance. We sometimes completely more maintenance in our development cycles and it ends up becoming a bit of a pain point at a later point. And like so asking these questions can be huge and can be very interesting. And I think the one statement I would like to make and kind of reading completely off the slide here is like own your knowledge. Yeah. You know, know certain things. Make sure you capitalize on that and basically ask the basic questions because asking those questions can help you learn one, but two, it might actually be a very interesting question that they may not have someone else. And so yeah, just own your knowledge. Yeah, that you have. And I've kind of started to do this as well. So although my SKU is a bit more technical and I worked on a lot more design, like my business side is a lot less. So I tend to ask a lot more business questions because I try to figure out more of that side of things. So like each PM as you kind of build out your career, you kind of will pick one side or another to kind of float into. So just as I said, ask a lot of questions. Great place to start. So yeah. So just for the next few slides here, what I wanted to talk through is what is, what are some of the things you should kind of know? All right. So if you were kind of saying, okay, go, hey, Josh, this all sounds great. This sounds like something I want to explore. What are some of the things I should kind of look at? Like what are the different technologies I should know of and lead to have a basic conversation? Right. So I think this is a very set of useful basic skills, basic set of information to know. I'm not expecting each of you to go in and start learning to code or starting to build any of these things or doing any of these things. It's just useful to know how some of these things work. So here's like a basic list of some of the things I've thought of. So like the JavaScript framework, I think given the world we are in today and the number of websites and number of tools that are built using frameworks like JavaScript, like JavaScript frameworks like React and Angular and Vue are pretty much 80% 90% of the entire websites are out there, right? So using, by knowing what these frameworks do and how the frameworks work, I think gives you a huge advantage. So just to give you another story here, when I was in my last company, one of the things my engineers were doing was kind of explaining, oh yeah, we need to rebuild all of these things and so on and so forth. And I was like, wait, why are you rebuilding them? Can't we use a module? Because effectively React works on modules and can we use one of these modules? And like knowing how that works helps you understand like how they are looking to build it, right? Because effectively React affects stacks on one module over another which you kind of create with small components and knowing that information helps you kind of figure out, oh okay, when they build this module once, I could probably use this module in three other places. So that means that if I'm creating a whole new webpage, could I reuse this module that was created somewhere else? Like there might be some technical challenges associated with it but the fact that you know that can be achieved and how that roughly works and how the data is stored within like Angular React and Vue, you kind of get a good gist of what that looks like. And personally, I'm a big fan of Vue. I love working with Vue, especially when learning from my basic stuff. So if you're looking to try something out, try Vue. Quick plug there. And then like database storages. So one of the things, especially when it comes to interview questions, especially if you're looking to get into PMT role, database questions, architecture, architectural questions, things of how things work, the layout, all those kind of things, is super important. So one of the technical questions I got asked during my technical interviews was how would you build a restaurant notification system? So I had to kind of define like what kind of database I would use, and why I would use those databases. And I think the advantages for each, for you, if you don't have a technical experience is that knowing some of this information actually helps you kind of figure out how to improve your platform, right? So it's, imagine this is, say for example, if you were working on a search results page, and if you wanted to increase the speed, and currently you're using a really old SQL database and your technical engineers are quite busy doing that, like thinking about how you could use Elastic Search or how you could use like NoSQL to kind of speed up those responses, save money. Like you can do amazing things if you just like, just by knowing what these things are. Like one of the things recently I was working on basically around a headless CMS and like the advantages of using a headless CMS versus a regular CMS is huge, right? So like I don't have to worry about a whole lot of things. I can basically still integrate with existing platforms, all those kind of things. And if you're curious what a headless CMS is, I will let you Google that because I don't want to give you all the answers yet. And I think one of the key things to also take away is here is we are moving into a much larger AI driven world. Every tool, every platform, every company, anything that I've heard of is very AI driven. And I think as PMs, especially as we go forward, I think it's very important to know what AI can do. And these are a couple of the models, a couple of things that you can do. I think one, understanding how data works within AI, like, for example, data collection and what is needed for training in AI, I think that is huge. I think knowing that personally, I think will be a very key skill over the next coming years. But knowing what AI does and how to basically work with AI will become such a big thing, right? Because all of us have to build, like companies are now expecting us all to build AI models, right? They're not expecting us to generate things out of, like, before we used to do rule engines, to do search with a lot of prioritization. Now we're all looking at AI to do search and prioritization, right? So AI is probably one of the things that we share where I would say you probably need to dive a bit deeper on to kind of figure out what is this and what are the different models that can be used. I don't think you need to learn how to build an AI model. I think over the last couple of months, even years, I've never had to really build one myself. I've done it for fun personally, but I never had to kind of build it. More have to figure out, know what they need. So that way, when my engineering team, when I go to my engineering team, hey, look, I need to build X. I know, like, okay, cool. And I will need to give this, this, and this to help you build a model. So they are completely aware and I know what they need. So when you're going to them for those expectations, they're not kind of thrown back. And also, like, if you have data scientists as well, they can totally help you there as well. And yeah, and I think the one last thing is there is no extensive list that we can all say you look at, but I think a big part of this is know your product, know how your product works inside and out. And I think the value behind that is huge. And I think just knowing how it works, I think has a lot of benefits. It's just good to know, like, where's my data coming from? Where's the architecture coming from? And as you do this several times over different products or different variations, you will actually end up knowing a lot more on how things are supposed to be built because once the engineering team maybe have very different from another organization, then the caliber, the skills become so varied that it actually works up quite well. So I think, yeah, just know how your product works, know what the technical background looks like, all of this kind of thing. And yeah, so just to finally leave you with a few things to kind of think about in terms of mentoring and interview support. So I'm just going to list out a few couple of items here. One, which is if you're looking, if you're looking to start interviewing for PM roles, one, check out how to crack a product management interview by Gail McDowell from Product School. Great interview, like great talk. Even to this day, for every interview that I have gone through, I have literally watched it over and over again. It is brilliant. It is really good. Just watch it. Like I literally have spent hours watching the same content over and over again. It's just super useful to kind of get that through. The second one that I've kind of looked at, especially in terms of interview prep and kind of getting good answers to things is Exponence YouTube channel. They do quite a good interview set list of what you should look like and how you should follow through and what type of questions you should ask, how you should dive deep on a question, all of those kind of things. Great set of resources there. Just if you just Google like, I think product management interview questions and you'll probably find a lot of them. And lastly, so I work with an organization called ADP who does mentoring services and there are loads of amazing product managers on there from Google, Facebook, Amazon. And so if you are looking for advice, I would totally recommend reaching out. And yeah, feel free. I have very limited schedule at the moment. I have moved countries. So I'm still trying to get used to the movement. But yeah, definitely feel free to reach out to PMs across the board. Most of us are very happy to help, especially when there are companies and teams like ADP which kind of help support mentoring advice for free. Like definitely we're checking them out as you kind of try to dive into product management. But with all of that said, thank you everyone for listening and I hope that all of you have a good rest of the day and I'll look forward to speaking to all of you soon. And if you do have any questions, feel free to drop into the chat or feel free to book a mentoring session with me on ADP or reach out to me on LinkedIn. Thank you.