 Hi, everyone. My name is Mariam. I'm a senior manager at Microsoft Teams, and today I'm going to be speaking about two key topics. One is day in life of a product manager, and second is how to switch to a PM role. Let me start with a quick intro about myself. My academic training is an electrical engineering, and I have an MBA. Prior to my MBA at UChicago Booth School, I worked as a lead integration engineer at Maxim Integrated Products. In my role at Maxim Integrated, I was responsible for two key things. One was leading teams in understanding the root cause of the semiconductor chip failures and implementing a fix for them. And second was on a very regular basis to present to senior executives within the company. That's what led me to spike my interest in the business side of things and led me to my MBA. During my MBA, it was a fantastic opportunity to learn about the different opportunities available post-MBA. I was really interested in strategy because that would help me think through as to how C-suite executives make decisions and be able to advise to them. Given our background in technology, that's what led me to Microsoft in the strategy unit. A lot of my experience at Microsoft came back in the strategy team, and it was a fantastic opportunity with a lot of impact in advising C-suite executives. But one of the things that I was missing was my interactions with engineering, and that's what led me back to the engineering org and as part of the product team. Let's get started. I think one of the things that can help us calibrate is in terms of how the day-to-day looks of a PM is based upon where in the PM cycle one is really in. So let me share my perspective on the three different, like at an entry level, at the mid seniority level and senior leadership level as to what the responsibilities for each one of them look like. At the entry level, at a more junior PM role, one would be solving for a particular customer pain point and there would also be a lot of focus in terms of execution, making sure that the vision that has been given to them that they execute flawlessly on them, the problems are more well-defined for them. As one basically progresses through in their particular career, at mid seniority level, one defines the vision and strategy for a particular area that they are leading. Many a times that involves leading cross-arc initiatives, also if someone is interested in the people management side of things, they're usually leading teams or mentoring junior PMs within their team. As one progresses further along and at a senior leadership level, at that point in time, one is determining what the key investments are going to be, what the strategy and vision for the entire org really is. There are many areas under them, the PM teams are way bigger. And also many a times it would entail leading projects, charters which are outside their area of direct authority. Let me share in my tour today as to what are the key partners that I interact with on a very regular basis. One is the first one is the customers. Customers are the king, they are the ones whom we are building the product for to solve their particular pain points. So having interactions with them is key. The next is what the user experience is going to be and that's what works with design and user research on a very day-to-day basis. The next is engineering because one works with them to understand what is feasible versus not and making sure that the vision lands into reality. The last is but equally importantly is marketing. Whenever we are working towards releasing a particular product or a set of features for our customers only for those pain points, we need a very strong partnership with marketing to make sure that our customers know that we are working on this, on the products that they have shared with us. It is coming and in case the adequate visibility, the press releases that are needed. Next, let me share with you the different phases and in my view it's a very cyclical process that one goes through as this particular chart shows. So it starts with generally building a feature backlog which is a set list of features that have been requested by our customers. The next is basically like planning, prioritizing as to what we can build and why we should be building. Next is executing on that particular vision and then the moment that all PMs are waiting for which is releasing the product Rev1 which we also call a lot of times MVP. Let me go into and give a deep dive into these different areas that I just spoke about which shapes a lot of what my day-to-day looks like and who among these different partners that I shared about, am I interacting with more? That is also determined by the phase that I might be in. So let's start with the first one which is building the feature backlog. That entails three steps. The first one is you might wonder where all the requests are coming from. So there are actually different avenues from which we can hear as to what our customers are asking for. The first one which is also the most important one is the PMs should have like a direct one-on-one connection with the customers have regular interactions with them. Besides that, there are other avenues as well. For instance, depending upon the company one is in there might be a customer PM role who are fantastic allies in terms of understanding what some of our strategy customers or what the small, medium businesses are asking for what their pain points are. The next is there are many a times many online forums like communities in which our customers are actually going and sharing their input in terms of what pain points that they are seeing what they would like us to solve for. And lastly, also there are internal teams who we are a key partner to and they need our help to land some of the vision that they have for the charter set they are driving. So there are requests that come from that avenue as well. Once one has a good understanding like in terms of all the different requests that one has in terms of what problems, pain points for our customers we need to be solving for. One of the things we need to understand as a PM I think is very critical is what we are trying to build and why we are trying to build it. And as far as there is basically one thing that this is something, yes, it would have a huge impact. One should start with like the PM I think at a basic level have the what and the why documented and also have basic set of like PMR or design mocks that we say from the PM perspective have the wire frames ready. And then last piece is in terms of making sure as any PM can walk forward there are actually many, many requests that come one space. So there needs to be a system to which one can actually track that within Microsoft that is a tool called ADO that we use but across different companies that could be very different tools that they are using. Let's jump into the next phase which is planning. In the planning phase the very critical step the first step is prioritizing. As a PM one of the key skills is one should be able to ruthlessly prioritize. The question might come like, okay how do we actually prioritize? How do we have a structure to that? So some of the things that I actually look for is while I'm making my decision is in terms of understanding what is going to be the impact to my customers through this. Second is also like across the companies there basically are certain areas that senior leadership is investing and there is executive alignment on that. So making sure that directionally I'm moving in that particular way is another input. The next one is looking at compete in terms of the publicly available information that they have analyzing against that and seeing what this provide us an edge. And equally importantly is understanding what the cost to build that particular feature or feature sets is going to be. Once you have all of this there are different ways of quantifying one particular way can be using a rice core in which some of these inputs can be provided and one can actually get a more mathematical number in terms of being able to prioritize that particular list. The next one is the key piece also in this phase is like involving full on like your design and user research team and having discussions with them. The PMR and the wireframes that we talked about just a little bit ago in phase one come in very useful in this particular in the planning phase when we are talking about when we're talking to design and user research in sharing about what the vision is what we are trying to build, why we are trying to build it and basically iterating on the initial set of design with respect to entry points, the discoverability of it the ease of use for it. Those are the key things, key discussion points that we have. Also in that particular discussion one of the things that I think is super critical is rather than deciding necessarily on like one particular design talk to your user research folks, design folks and have explorations, have customer sessions get input on that in terms of like run AB test as to what is more preferred have both qualitative and quantitative feedback on that in terms of what could be statistically more significant as a design choice. The next is having finalized specifications what is also in some companies maybe call as the PRD document. In that one needs to make sure that all the use case scenarios are documented along with all the edge cases. There is finalized designs that we have and very, very importantly as a PM one needs to make sure one defines how we are going to measure success for what we are building and having those metrics documented from the get go. Next is in terms of once we are show already having funding discussions with our engineering managers. So there's an engineering manager counterpart that is generally assigned into a particular area. So one would have a conversation with them and with them along with them there would basically be a couple of things that would come in discussion as to one what is the cost meant to be built for it? What are the engineering trade-offs involved? How is performance going to be impacted? Making sure those metrics are looking really good and there is no negative impact to performance at all in that regards. What is also the dev resources that are available to us? What are the dependencies on the other partner teams especially in cross-organizators? There are multiple dependencies across the different teams. We need to make sure we work alongside with those PMs and engineering managers to make sure that it is funded and we can make sure that everyone has a buy-in on the vision that one is pitching for. And then there are like some orcs can have this really fantastic idea which is UX reviews. We have that within at Microsoft and there is very similar leadership like at partner level both from product and from design who are part of that committee and one presents about their vision in a step-by-step or at any different phase like one can and seek input and iterate further on that. Once we have closed on what we want to be building why we want to be building what the design is we go into the execution phase of it. During the execution phase there is a lot of interaction that happens actually with the developers who are implementing the feature alongside with the engineering manager. During this particular phase there's also a lot of interaction with our customers again. That's customers as a constant team across the board and we run both qualitative and quantitative feedback sessions with the customers. When I say qualitative what I mean by that is that there would basically be for instance the customers who are under NDA one can actually go and show them some of the initial design thinking for instance that one might have had or what are you basically trying to build showcase that, get that input. The second would basically be once we have the code some pieces of the code implemented that our customers who are under NDA can actually go ahead and try that. We give them a set of instructions in terms of the different use cases that they should be testing for providing us feedback. The other key thing also is ask for customers for open-ended feedback also ask for questions in terms of which might not just be like direct like, okay, do you like this feature or not like this feature? But also in terms of like trying to assess how much time they spend at these different entry points what that means for them. Them, is it easy to find? Is it intuitive for them or not? Those kind of things also a set of things that one can actually get feedback on. Once one gets the feedback it rate on that along with the developers the design and the user research team depending upon what stage you get feedback on in the development cycle as the code progresses is it in very early stages or is it towards the very late stage and what the nature of input is is it something which might be a blocker versus not? Take all those decision all those inputs into your decision making and use the judgment in that regards in terms of like what are the things that basically we should address before the MVP release versus what can be the things that can come as fast follow. So again, can't be precise more prioritization having great product sense comes in very useful. Once all of that the other key piece also that we do is the complete the internal product reviews. So for instance they're making sure that the product meets the compliance standards the security, privacy, accessibility there are internal reviews that happen for those making sure that all of those have been completed before any product launch is done. And then as I've said before like working with marketing with respect to the announcement and the press releases becomes super critical. We want to make sure that all the work that the team is doing to solve for the customer pain point that we ensure that the customers are aware of it there is enough excitement on the ground that, hey, this is coming and making sure like increasing awareness within our customers for that. The last phase is the releasing which all of us have been waiting for from as a PM releasing the product but at that point again like in terms of what the customer feedback is going to be coming up with like what are the feature enhancements as more and more like customers try it out and importantly tracking the metrics that we have set for success how is that comparing to our goals and making sure we have a good story there and if there isn't one understanding the factors which are making us not meet our goals and what we can do what we can change to make sure that we do meet the goals that we have. Switching topics now the other key piece that is a bunch of folks that reached out to me and asked for was how do we switch to product management? So let me share in terms of what my perspective is with regards to that I think the very first step that starts with is having clarity on your goals. For instance, what kind of PM you want to be? Do you want to be a client side PM versus a backend PM? The reason I bring that is because a lot of times there's a question like am I suited to be a PM? Do my skill sets match? Is that something? What skills I should be looking at, et cetera? So generally in my experience backend PMs are more technical than the client side PMs and generally do have like a CS background versus client side PM I definitely think it helps having an engineering background it makes the conversation with engineering easier one is more comfortable and at ease but I've noticed client side PMs to have very diverse backgrounds. And so make sure that you tailor which kind of people you're wanting to be to your strengths. The second is also work backwards from your goals. Sometimes I understand like it's very hard to know like down the line like what do you want to do but maybe if you can break it down to a five year map if that's not possible what is your two year vision for yourself and what is it that you want to achieve? Are there folks who have similar career paths with similar backgrounds as yours and have transition into a product management maybe from their journey you can map out a journey for yourself as to what you want to do. So having clarity is basically on your goals is super, super critical. The second piece is building the skill set. Some of the things that personally for me have been very helpful is having a coding experience and also having an understanding of business. So I would highly recommend to take foundational programming and business courses. I think that would really help making sure that when you are speaking to your key partners you're speaking the same language and have an understanding of what they are doing. So first is foundational programming courses one can actually take courses in Python C++ C. I think that would be super helpful if there's an intro to AI course if that's an area that interests you I think that would be helpful as well. Similarly in terms of business courses I would say there's a course on strategy or entrepreneurship to take that or if there are particular lab courses if you're an MBA student I would highly encourage like that you take a particular lab course that is available in which there are actually real companies who come in and give projects to work on. The next is also one other avenue can also be within your own company take a stretch project and help a PM maybe in your native way interactions you do talk to a PM in your interactions like for instance sometimes I notice like folks from marketing do interact with PM and maybe that's something you want to be switching into. So maybe you can have a conversation with them talk to your manager and see if that is something like you can take on as a stretch project make sure that the current responsibilities that you have you're doing really well in that particular area before you sign up for a stretch project. The second key thing that could be very helpful is having a PM leader as your mentor because folks who are ahead in their career than where you are starting from would have might have a better perspective and can share like their insights, their experiences also if there are opportunities that they know of and think that you might be a great fit for they might basically recommend you for that or share that with you that hey, this might be something that might be of interest to you. The second thing if that's not really possible within your company, try and see if you can do a side project outside your company for instance, if I've sometimes noticed my friends they would work for like a startup just for a particular project over the weekends or they might be willing to build something of their own those could be things that you are basically interested in and can build the necessary skills which you can basically share in your estimates. Until the pep talk for the interview I would suggest like understand the business of the company that you are targeting, I think that's super critical what are the different business lines who their customers are, who are they catering to what your understanding is based on the publicly available information. The next is I would highly recommend like practice mock interview with folks who are PMs and if possible, like a couple of years ahead of you because again, they would have perspective and they can share their insights they also will be able to calibre better because they have seen other folks in your situation and can share what your strengths and weaknesses in comparison might be. So that could be something you can try and one of the other things I've noticed sometimes folks do not like that they wait for the interviewer to start prepping, it might work well but I think it might be better if you actually give yourself a little bit of time start preparing before you actually like start interviewing so that sometimes the interviewer timelines might be actually at a very short notice maybe in a week or two weeks. So make sure you don't sell yourself short prepare beforehand. The last pieces like landing the interview there my advice would be try to get internal referrals if possible. I would request like get it from folks who you have worked with before and can speak to your strengths and the reason I say that is because I would my guess would be that a lot of companies have something which is similar to here at Microsoft which is when one is internally referring someone they ask like have you worked with that person before where have you worked, et cetera. So if there is someone you have worked with and had a great experience with and they can speak really highly of you I think that will go much further along the lines. The other thing is also like try to network with folks who have similar backgrounds as yours and have transitioned successfully have online session with them or have a coffee session with them one on one and basically just learn about their experiences what tips and tricks that they might have which might actually help you in that situation. And then one of the things that I wanted to share from my own personal experience which helped me when I was internally switching within Microsoft from the strategy role to the product role. One of the experiences I had was I had taken part in New Product Services Lab during Booth and the experience I gained from that I will quickly share about it that helped me speak about my experiences as a product manager that was something I also did post. So I had taken a project for manufacturing IRT and it was by a leading tech company who had given that project and what that entailed was there were actually like four phases as outlined here. In the very first phase we tried to understand what are the customer pain points that are there. So for that we interviewed actually 11 customers came up with the 120 tertiary needs that they have and we then bucketed those particular needs into a particular area per se. Then the next one was the second thing we went after was selecting the top needs to solve for. One of the things I would highly recommend is in general and that applies also to a PM it really helps if you have a structured thinking if there is a particular framework that you can apply. So when you're making decisions and make decision based upon facts based upon data rather than basing it off on what you think might be good. So in our case what we did is we looked at the market attractiveness for that particular area that we had bucketed. What the strategic fit to the company would be what is the feasibility of that particular idea. And once we had our recommendation in terms of what we think the top needs are we went back to our client and shared that with them and sought their input made some adjustments based upon that in terms of what their insights are. And then we had a mutual consensus on what we think are the top needs we need to be solving for. Once we built that consensus went towards like the product idea. So me and my team we conceptualized three product ideas in which we basically defined what the problem statement is and had our pitch as to why it is a good idea why customers should be really buying it. And then we went ahead and basically had the process of selecting the top idea. What that process entailed was again as I've said multiple times the presentation we need to get input from folks whom we are building for. So as part of the lab course that we had our professor helped us recruit a bunch of folks who can actually like take our survey it matched the persona that we are looking for and basically get input on things like for those different ideas that we had three product ideas were conceptualized what is the willingness to pay is it an idea that is innovative or not is there already like many solutions available to it or not. So we tried to get all of those inputs in there and basically based upon that but those set of inputs and also it was a mix of both quantitative and qualitative. We basically shaped our recommendation in terms of what should be the top idea that we should be going after. And we backed that up also looking at like the financial projections across three different ideas that we had as to what the financial opportunities what the revenue profit opportunities for that would be. So we modeled that aspect as well. And then again like it is all like one team big team effort. So we sought our input from our client and shared that this is what we are thinking. And for our particular project it was a success. We had alignment with our client in terms of what we came with what we had heard from the customers that this is the idea that we are actually is worth pursuing. And then next step the reason I outlined all of this is because it's one thing to like basically read a lot of information absorb I think that's a great starting point but it also helps if there is something that one has done in real in actual that one can speak to. So for me this was the particular one of the things that I spoke to in my internal transfer interview but that would be something like find that particular thing for you that you think you'd be proud of sharing and go ahead with that. And lastly, but very importantly thank you for coming and watching this webinar. And if there are any questions please do not hesitate to reach out to me. You can reach out to me. We are LinkedIn DM me there or you can email me and I will try my best to answer as many questions as I can. Thank you, bye.