 Hello, everyone. I am Ketki Kulkarni. I'm a Senior Product Manager at Microsoft, and today's webinar topic is Switching to a Product Role. This is mainly focused for early-to-mid-career professionals. Do you have a lot of product ideas that you want to see through execution? Do you feel energized by product design and product conversations? Have you already been doing product management but don't have the official title yet? Are you already looking to make the change but haven't had any luck with the offers? Or you have already made the change and you are in the new role as a Product Manager coming from a different discipline and feeling overwhelmed by the role? If you could relate to any of these questions, then I'm hoping you can take away something from my experience that I'm about to share here today. For me, being a Product Manager has been a journey. I have been through several roles through several industries. I made the transition to product about four years ago coming from data analytics space. A couple of disclaimers about today's webinar. What I'm talking is most relevant to a Product Manager role in tech, but there may be things that generally apply to product roles across the board. Also, what I'm sharing here is purely based on my own opinion and my lived experience as I made the transition. So with that context, let's get started. We are looking at three different phases of transitioning to a product career today. First, examining if you're ready for the change. The second part is actually making the change and how to prepare things to know. And the final stage is after you've made the change in your new role, how to set up for success. So let's dive into the first section. Are you ready for the change? And we will break this down further into three questions that you can ask yourself. Why do you want to become a Product Manager? Will you miss your current role and what kind of Product Manager do you want to be? Let's look at each one of these. Now, cliches are cliches for a reason, just like our first point here. Start with why. Why do you want to become a Product Manager? What is it about the role that attracts you? Are you running away from your current situation? Or is it something that will take you closer to your goal? What about product discussions energize you? Get these and all other types of reflective questions will help you do an honest self assessment and help define your why. There is no right or wrong here, but knowing your reasons and being convicted is going to help you motivate to make the change. So do an honest assessment and define your why. For me, the big picture motivates me. I was really interested in knowing the what and the why and contributing towards it. Also in my roles, I had had a taste of product development, product management and all of those aspects had felt really energizing. The other reason was also that my career path at the time, the natural extension would have been product management because there was not much room for vertical growth in there. These were my reasons, but let's begin with defining your reasons. So once you've defined your why, let's move on to our second question. Will you miss your current role? When I was in the process of transitioning, I was talking to a PM friend of mine and she asked me this question. Will you miss being in your current role? Will the components of your current role that energize you on a day-to-day basis, will you miss that? And to give some examples, let's say you're a data scientist then running some algorithms or writing a script or fixing some code or if you're coming from a developer background, there are daily deliverables or tangible items. Will you miss those? And the extension of that is would you feel that the investment you've made in your career path so far, is that going to be a waste? I would argue that no skill learned goes waste. You may be able to apply those skills to a product career even though not directly. So there will be transferable skills. And again, it's not as if the change you make is irreversible. It's just that since you're taking all this effort, it makes sense to ponder over this question a little bit. And the third and final aspect of examining your decision is knowing what type of product manager do you want to be. There are many types of product management roles and not titles, actual job descriptions like a UX PM, a research PM, a data and analytics PM, business PM, customer success PM and so on. What is it that you're aiming for? Is that close to your current role? Are there transferable skills? For example, coming from the analytics background, it was natural for me to be considered for roles that were focused on data analytics or product management. And that is how I entered the product role. Are you ready to step down a level and start from scratch? Speaking from personal experience, I also accepted an offer that was one level below, but looking back now that did not matter at all. You can always prove your credibility once in the role and show that you're already performing at a higher level. So just to recap this section, using these three questions will help you examine your decision. Starting with why, knowing why you want to be a product manager, looking at the aspects of your current role and deciding if you're going to miss that or do you feel like you're giving up on something. And then the third one is what type of product manager you want to be. Now, once you examine if you're ready for a change, the second phase takes us to getting ready for the change. And this is all about preparing or knowing certain things about the product role. We will again break down this section into five different aspects. Switching internally or changing companies, being aware of the titles out there, developing transferable skills, communication skills, and networking and resources. These are the five aspects that I work through and that really help me with the preparation. So let's look at them one by one. Where are you applying? If you're looking to switch internally, this may be a safer option, depending on how product focused your company is and how supportive your team or manager is for such a transition. If you can't switch, could you do any kind of rotation as a PM? All this to gain real product experience, which you can then apply when you're formally interviewing. But even if you decided to look outside of your company, all of these are good exercises to follow to build a set of PM skills, which you can then draw upon during your interviews. For me, I was open to looking both internal and external opportunities. And when the time came to evaluate an offer, I decided to go outside the company. The second aspect of this is titles galore. There are many, many program manager, product manager, product manager in tech, technical program manager, and many, many more titles out there. Even a given title may have different interpretation across different organization and teams within a company itself. So, if you're looking to switch internally, this may be slightly easier as you can talk to your colleague to try to understand the job description and what that role entails. If you're looking externally, then you have to do your research though. Ask a lot of clarifying questions to your hiring manager. Better even talk to product managers there and ask what their day-to-day looks like. What is the job architecture to understand the actual job description? Look beyond the titles. Transferrable skills. Now, in your current role, whether you're changing internally or externally, think about what are the transferrable skills that you can bring to a product or career. And if you think there aren't enough of those, then start working on it today. What do I mean by this and why is this so important? Now, let's say you're a data scientist, then the ability to make data-driven decisions, having a deep understanding of data, visualization, querying are all transferrable skills that will give you an edge in the product career. Similarly, if coming from a developer role, then understanding the engineering architecture, the technology decisions that drive execution, ways of working with and speaking the language of engineering teams, are all another set of transferrable skills that are going to help you a lot. The reason why this is important is then you can draw upon these skills and highlight them in your interviews. This is what will differentiate you from a person who's looking to start their career as a PM versus you who have been in the industry for a while but new to a product career. Instead of hypotheticals, you should be able to wear your product hat and talk about your current projects in terms of these skills and how you would apply when you run them as a product manager. If you're not doing this already, it is not too late to start. The more real project experience you have to bring to these interviews, the more the chances of you being considered for a product role. Fourth point is communication skills. If there is one skill you could build and practice as you prepare for the product role, I'd say it is the communication skills. Emphasis on written communication. As PMs, we have to interact with teams and people across the company, across disciplines with the executive team and even sometimes with vendors and customers depending on your role. And irrespective of what type of PM you are, this interdisciplinary collaboration is an important aspect of your role. Especially in the hybrid nature of work that we are in, asynchronous collaboration cannot be ignored and documents and one-pager are the best ways to get your point across, in my opinion. There are many freely available resources out there to work on your writing skills. Writing lengthy documents may be easy, but clear and concise documents articulating your idea well takes practice and PMs need that skill. And that brings us to the final point of networking and resources. The reason for including this towards the end is not because it's not important, but because it's highly talked about and there are many resources that you can find online about this just with a click of a button. Now, the networking piece of it is somewhat related to the titles point that we talked about before. Talking to product managers is the only way of knowing what the nature of their job is. And even if you don't know anybody personally, there are quite a few online forums, professional networking groups where you can join and reach out for help. I have definitely taken advantage of such forums for my preparation to understand the job architecture, to get resume review, interview help, and I'm still a part of those groups today to continuously improve on my product skills. Another set of great resources obviously books whenever faced with new challenge or a new problem, I generally tend towards books. And one of the books which is highly recommended and which also I found useful for the interviews is Cracking the PM interview by Gail Lachman McDowell. That's one of the books that I'll highly recommend for interview preparation. There are various other books that are popular in the product design, product strategy or product thinking category, the design of everyday things upstream by Dan Heath, The Power of Moment by Dan and Chip Heath, and then The Power of Habit by Charles Duhigg. In order to learn productivity and metrics, measure what matters is the one highly recommended book that I have also benefited from. So other than books, I also like to follow the work of certain product leaders either through professional networks or via their blog sites. And like I said earlier, there are a lot of online product forums. They also have conference and webinar content freely available on the online platforms that you can also take advantage of. So that is all about our second phase which is getting ready for the change. And now let's look at the third section, final section of this webinar which is after you've made the change, how to set up yourself in the new role. The structure here, the three buckets that you see, alignment, learning and execution, these are completely inspired by Deblew's blog about setting yourself in the first 90 days. Deblew is a respected product leader, one that I admire and follow for many years and she has a blog called Perspectives by Deblew and in one of the articles she categorizes the first 90 days into these three aspects, alignment, learning and execution. And now let's see how that applies to someone who's coming into a product role from different disciplines. Now the alignment piece may generally apply to any roles but there are some things that are specific to product. The first and foremost is about setting expectations with your manager and coming up with a 90 day plan. This is key because you're coming in from a different role and your onboarding plan may not be necessarily the same as the onboarding plan of other product managers on your team. So develop a detailed 90 day plan and what has worked with me across different roles is coming up with 30, 60 and 90 day milestones as to how you will track progress with your manager. The second part is absorbing the culture, rituals and history. As a product manager you must influence without authority. The more you get acquainted with the rituals and history and gain an understanding of the tribal knowledge the better integrated you will be with the product and the team. This is probably more applicable to larger companies and organizations that have well established routines. Now this is not to say that you cannot challenge the existing routines but unless you understand the context fully it will be hard to suggest and affect any meaningful change. You can note along the way what is going well, what is not and where the gaps are. And the third and final point in alignment is building rapport with the crew. This also relates to influencing without authority. Your product trial depending on your company and role may comprise of an engineer, a designer, a data scientist for example. These are people from across disciplines that don't directly report to you but you need everyone to be onboard and working with you to execute on the vision and on your product. Take time to understand the ways of working and build a rapport with your crew. This investment will go a long way in defining the success of your role and of your product. Now that covers the alignment piece and let's look at the learning piece now. The first and most important in this category is prioritization and being able to say no. Rootless prioritization and knowing when and how to say no is a must in this role. There'll be hundreds of things that are grabbing your attention but you'll need to know which ones to focus on and why. Your crew is going to look up to you to decide the what and why. So how do you make decisions and prioritize is something that is a key element of your role. You will be tested on this even in interviews. What data points do you consider when making a decision? Will depend on many factors such as customer feedback, business outcomes, engineering feasibility and so on. This will also influence how you plan and prioritize your own day-to-day work. The second one is the underrated art of note-taking. I realized this early on in my role as thorough and detailed notes I took the easier it was for me to ramp up on a given initiative or a project. Don't treat it as just another housekeeping item. You'll find out quickly that taking notes, good notes, is not that easy. So volunteer for taking notes in meetings, especially initially when you may not have a lot to contribute but you're there to mainly learn and listen. And the third one, which is generally applicable for any role is to be curious and always open to learning. Remember you're coming into this role from a different discipline and there may be a lot of acronyms, jargons, specific references to product frameworks and tools that you may hear. Don't be afraid to ask what these mean. There you have opportunities to learn from everyone and anyone. There's usually a product lingo that PMs on your team may be using but play your newbie card and try to absorb as much as you can from everyone around you. Books and resources can only take you so far but nothing like on-the-job training. And finally, let's look at the execution bucket. Lots of time in meetings and collaboration. Now, although I knew this would be the case it was still a bit of adjustment for me to accept all this time spent in meetings and to plan my day around that. Now replace meeting with any form of collaboration especially in this hybrid situation of work. Because of the interdisciplinary nature of the product manager role we are expected to spend a good amount of time in collaboration and again prioritization and focus will come into play in deciding what meetings you go to and what meetings you say no to. I believe this only comes with experience but be prepared to spend a lot of time in meetings especially initially. The second point is accepting that you may not have tangible deliverables day to day. Now coming from a data analytics space this was also another thing that took a bit of an adjustment for me. There weren't necessarily tangible deliverables daily that I could check off. For example, running a script, getting that ETL job to work, etc. And while there are project milestones and wins to track your progress along the way the final outcome may take some time from the time you have delivered your spec to seeing the final ship product. This is not to say that you won't have anything to do in between just know that what you call deliverables may not be exactly the same as in your current role. And the final point is to look beyond frameworks and tools. I felt that it's very easy to get intimidated by certain product frameworks and tools that are being used. There are tons of product frameworks out there and you may also observe that some of your colleagues are very loyal advocates of some of these but without knowing the purpose of a framework it can easily become a crutch. So if you capture the essence of what you would like to present in a form that's comfortable to you and easily understood that by your stakeholders don't feel pressurized to use a particular framework. Once you understand the fundamentals and the reasons behind using the framework though it can be a very efficient way of getting your point across. And again this also in my view comes with experience. That brings us to the end of this webinar. I will say one thing though even there are so many aspects to consider about a product role so far this has been one of the most fulfilling roles of my career. And even today if there's one thing that I remind myself daily is ruthless prioritization to gain focus. And there's a quote exactly that explains how that I want to leave you with as we end this webinar. People think focus means saying yes to the thing you've got to focus on but that's not what it means at all. It means saying no to the hundreds of other good ideas by Steve Jobs. And with that we come to the end of this webinar. I would like to thank Product School for this opportunity and all for tuning in. If you would like to connect with me or reach out for questions you can reach out to me on LinkedIn. Thank you again for your time.