 The recording starts after this. Hello, everyone. Welcome to this edition of Product School Webinar, Life of a PM. I'd like to start by first thanking the Product School for giving me this opportunity. Life of a PM, an anthology of PM tasks, is my story as a PM in Microsoft. My goal here is to present the full picture of how I work as a PM and how I'm able to be productive and in the process, what are all the challenges that I've encountered, how I'm trying to improve myself. It's not quite a list of things to do for you or a success formula for a certain objective. This is how I am doing my work. It's rather a window into how I operate. Many times I fail and I'll share that with you and I will talk about how I'm measuring myself in terms of the successes that I've had. Every PM has their own way of working and often achieved their personalities, that the team that they work on and the product or the organization in which they work. But there are parallels to be drawn and tips that one can take away to help in their own journey. Hope this talk inspires you all to have a growth mindset, learn from everyone, listen to all points and charge your own course. My name is Divya Chappan Padur. Everyone calls me DC. I'm currently a PM in the SharePoint team and I've been with this product team for a very long time. In fact, all of my PM life has been with this one product for the past nine plus years. And before that, I was a developer in the Bing advertising platform for about two years. And then before that, I completed my education, my master's at the University of Cincinnati and a bachelor's from Pondicherry University. The one thing I'd like to call out here for everybody is I don't actually come from a computer science background. So I have an electrical engineering degree for bachelor's and master's, but Microsoft made a bet on me and I'm really glad that they did. And there is a growing trend where tech companies are not actually requiring computer science degrees of the candidates, especially in the product management discipline. So if you are one such candidate, you will definitely have an opportunity with the right employer. What are we here to talk about? So the first thing I would like to do is what I call the bluff or the bottom line upfront and we'll get to that right after this. Then I like to talk about why me, why do I think I have value, what value am I trying to add to your PM life journey? The next is the reality. We'll get to the crux of the premise of this conversation. We'll talk about how I do my PM activities and the holistic approach to how I'm trying to be productive. The last one is about success. While we are all working towards something, we would like to be successful in what we do and I'm presenting how I've been measuring success, the challenges that I've had in that journey, I'll share that with you and then hope you take away the lessons that you need from this session. The bottom line upfront, in all of my communications, I strive to serve the audience with a quick overview before I get into the details just in case they have limited time. For this talk, it is my bottom line. It's always about the people. What I've realized so far, which I did not know earlier on, is product management is not about building the best, having the greatest idea or building the best product. It is about making sure that all the people involved in the process, from the customers to the developers, everybody is enjoying the process and enjoying the process interacting with your product. The product is what is bringing together people and because it's people, they're all complicated as you are, as I am. As a person, I bring my own flavor and my own experience with life experience into the mix. So it's very, very important to have the empathy and the grace to allow for differences to mesh together nicely so you all enjoy creating the product. So fall in love with the problem and the people, not the product. Next, getting to the why me. The three reasons I want to talk about, one is obviously the experience. I started out from a non-computer science background, as I had mentioned, and when I started as a developer, I had no idea there was a discipline called program management. I used to ask my dev manager early on, hey, who's this other person who tells me what to do or gives me the project ideas and why are you not telling me? That's where I understood the role that PMs play in trying to build products across disciplines and across different teams and have a cohesive experience for the end customer. That excited me a lot. So I switched from being a UI developer for two years to a backend internal tools, PM and the SharePoint team. I spent five years in there and then another five years now ongoing as a customer product PM in SharePoint. I think there's a unique perspective in having been a PM in one product for a long time, having worked on different ends of it, coming from a developer background and a non-computer science education. I'd like to share my life experience with you all. And of course, there are many ways to be a PM. This is my way of being a PM. I love the trade. I think there's also a great opportunity for me to learn. So I'm very excited about having had this opportunity. Thank you again, Product School. And pay forward. I've heard it. I've learned a lot from various sources, including Product School and other resources online. I think the product management community is very vibrant and up and growing and we need more product managers in the world. More product managers is more empathy is very good for our world. And I'd like to do my part in that. Now let's get to the reality of what I do. Before we talk about my activities, it's important for you all to understand what product and what domain I work in. So as I mentioned, I'm a PM in the SharePoint team and I work on what's known as the SharePoint portals or the employee engagement business. Most organizations have an internal information systems experience or digital real estate and an internal website. All of these things are things that SharePoint can power and we work on those experiences. The where our product is in the overall growth is where now we try to reinvent how people get to work, especially with the pandemic driven hybrid work situation and the work from home situation. We wanna make sure that the employee engagement is prime perceived, very important for our customers is being made easier and there are more easier and innovative ways for getting work done and having engagement with each other. We wanna empower our customers to achieve more. With that context of my business, let's talk about my day-to-day activities. What I realized putting together this talk is I don't think that every day is that exciting. I think at least we wanna look at like a week scale is a little bit more interesting than a day-to-day scale. So three-bar, three largely big buckets of what I work on. Number one is, I spend my time on meetings. I spend my time obviously on emails. There is no escaping emails or instant communication and then I spend a lot of my time writing. So what's worked for me over the time built my capability to do is collate to the busy work. So it's very easy to be busy all through but not actually have had outcomes, right? It's not activity that counts. It's the outcomes that count. So but you cannot escape having this busy work. Somebody needs something. You need a chart. Somebody needs your manager needs something. Your developer needs a quick question to be answered. All of these things are important to your function as a product manager. So it's absolutely essential to not shun them away but you should sort of roll them into your work schedule so that nobody is blocked on you and trying to collate the busy work. And meetings are very effective in bringing people together and having discussions only when everybody's on the same page. So over the time again, what I've learned is not to start a meeting cold. You want to come in with some written content that you can either pre-share or spend time in the meeting first five, 10 minutes where everybody reads a few framing statements to get on the same page, then have discussions and have those discussions be captured in the document. So one thing I've realized is a lot of these things has also been shaped by how we worked in the past two years of the pandemic. This is not how I worked pre-pandemic. The pandemic has taught me a lot as well. And hopefully that's sustained as we move into the hybrid world of working going forward. And the last thing I'm struggling with and I'm trying to constantly improve as well is what I call as carving out the thinking time. Every day it's essential to have a couple of hours for your mind to settle down and where you can stare at problems and have a focused time to write down what you think you should be doing in there. Focus is absolutely a superpower. I did not come up with that coinage but I truly believe that. So looking at, as I mentioned so while we're looking at the weekly scale where I talked about the meetings and where I spend my time I wanna spend a little bit more detail on exactly how, what meetings do I have? So the number one kind of meetings that I prioritize are one-on-ones with my stakeholders. Again, this is something that's happened because of the pandemic. I'm still working from home. A lot of my colleagues still are. So while we don't have the chance of running into each other often it's very, very important to have this constant touch to point with your key stakeholders so they feel informed. Starting with your immediate IC developers, your designers, your managers, your engineering manager, counterparts, everybody. Make sure you have a regular rhythm of business meeting with them. And what's also useful for me here is it's not just a meeting to just talk about things we make them collaborative working sessions where you literally are on the same in a meeting and working on the same document together. That's where you can also make progress while you are having a meeting. Feature crew meetings are also absolutely essential. We try to have an iterative monthly sprint planning. So it's very important for the feature crew to feel that they're connected to with each other and make progress and have a shared understanding of where the project is heading. I also want to make sure that there are specific chat threads and meeting teams channels that I'm pinning. So I'm always on top of those things. I anticipate my input to be important in those scenarios. And that's not a static thing. Month over month, I try to prioritize what chats and what channels that I want to be involved in and, you know, approve that list on and off as needed. The last one is what that's worked for me here and it might not be a typical list. I actually have many documents open all the time because you never know when inspiration strikes or you're talking about a project with somebody and then suddenly then you make a connection with something else and you're like, okay, I got to capture it. So I make sure that things that are very relevant are open documents somewhere so that I can immediately switch over and capture it. I think this has been a great use for me in throughout my week is to be able to capture that. Writing these things forces the clarity of thought that I think is very useful for being a successful PM. As we talked about day to day sort of scoped into a week and the Uber sense of what to do in a week. What I also realized is there isn't a typical week. So there are just like the seasons we have, there's a seasons of, you know, there's typically planning and strategizing cycles that's set in early in the semester planning. That's about 30% of the time. And then there's 50% of the my weeks and execution weeks and then 20% we focus on customer interactions. Which is not to say that we don't interact with customers other times. These are customer interaction heavy weeks where we are preparing for a conference or a summit or we have like a big rollout coming and we need to prepare the communications, whatever they be, right? So depending on the, there is a flavor to the week and these are the major flavors that come in. And all of the nature of the work changes but the style of working remains the same as in having the meetings, having one-on-one sessions, having larger syncs, strategy sessions and writing down documents, pre-read sessions and sharing and making sure that there's durable closure captured in documents. So that's how I've been working so far. What I'd like to share with you all is how did I get to this places? I did not, the style of working that I've been talking about is not how I've always worked. So my first six months of a PM, I pretty much walked the corridors of our offices with the notepad and a pen, trying to figure out solutions to problems. So one of the pieces of advice that I heard from my manager, well, hey, be a firefighter, be a hero for people, raise your hand and solve problems for people. And that's what I did. Every day, there was a ship room, we go in there, people discuss problems and I raise my hand and say, I'm gonna go fix it. I don't know what it is, but I'll go fix it. This helped me a lot in connecting with people. I was being upfront and telling everybody that I know I'm brand new to SharePoint, I have no idea how this product is set up but I'd like to help solve this problem. Can you point me to, can you give me an answer or point me to somebody who can give me an answer? So having that humility and having that drive to go knock on people's door was very useful for me and now those connections have come in handy throughout my PM career here in SharePoint. I know people because of those first six months of just knocking on doors and asking for help. So don't be shy. The first six months are the best time to basically be the starter who knows nothing. So it's okay to raise your hand and ask the questions. No matter which level you're joining in in a brand new team, the first six months are a gift. You can ask whatever question, knock on anybody's door and everybody's welcoming to help you out. And once doing that, when I actually deliver a solution and help solve a customer's problem, you earn the trust of the people that you work with and it's been invaluable lesson for me in my first six months. And I try to do that sort of whenever I start a new project, even in the same team. Even though I've been in SharePoint for long there are still so many things I do not know. So when I start a new project, I try to spend a couple of weeks trying to be the newbie in the team trying to learn what's going on. As I mentioned, my first five years as a PM was as a backhand infrastructure developer tools PM. So the best part about this was the people that I worked with and the people who are impacted by the work that I do are right next door. They're all the developers in my team. So it was a great opportunity to be able to just walk into a bunch of devs rooms. This person isn't available. The other person is available. There are different flavors of devs, early developers, senior developers, principal developers. So you get your pick of customers to speak with to understand the problem and then go quickly work on it. So that kind of work, product work is not possible in the customer facing world, in the customer facing product world. It's getting better with being able to use a testing and customer phone calls, but it's not quite the same as walking into somebody's door and asking those questions. And being able to whiteboard solutions right in that office, capture it, take a picture of this, put it in a document and that becomes your spec, right? And what we struggled with in that is a constant change. Not all developers want the same thing and you really have conditions that are constantly changing. And you also wanna make sure that the new work that you were developing and coming out with is well understood in the team. Because you don't have the luxury of doing a conference presentation or public documentation. So you wanna be able to reach your internal developers with your internal documentation much faster than you would do with external rollouts. And that was a challenge and that was the thing that I had to learn. The last thing was to get technical. Being a DevTools internal infrastructure PM, I had to get my hands into the code and running scripts and helping my developers and understanding truly what is it that they face. So that's all of these things were possible with the style of setting up meetings and walking into one door, into their offices for one-on-one sessions. But I think getting technical was the outcome that I was after and it was very successful. And coming back to the current product life that I have with the customer facing product. I transitioned from a backend PM to a UX PM that immediately introduced two different disciplines that I thus far never worked with, which is the product designers and the user research. Things have been changing now, but at least at the time when I was there, all I worked with was, I was a PM, there was a Dev and worked on solving our internal customers problems. But moving to the customer facing product life with the external customer facing product life where we bring in the design and the search team. And it was early on, quite challenging for me to figure out how to work with designers. What do you bring to the table? My five years of experience talking to developers was great in the people connection. But in terms of how do you drive the conversation with the designer was something I had to ask my peers and ask actually the designers themselves, right? That stuff that I've observed is the best way to work with people is to ask them, hey, what do you, what can I do to help with this project? What do you expect from a PM in this project? And I made sure that those expectations were met. The next thing was customer conversations. What external customer conversations are very invigorating, but you also have to be careful about how you speak about the product or what kind of analysis and understanding you have of customer conversations. Everybody gives you different inputs. Sometimes the customers tend to design the product for you. It's a skill that you learn by doing and observing others that do. My first few weeks, few months, I got on calls with customers where other senior folks who are leading the conversation try to understand how they interact it and then internalize that and use it for my own conversations. And my biggest learning or growth that I had as a PM after having moved to this customer-based product life is that I've been writing a lot in writing strategy documents and trying to justify products and prioritizing features whilst others is very, very important. Written documentation comes in handy when you have so many different stakeholders and disciplines in play. And that's, again, a learning thing that I'm still not the best at it. And I'm constantly working on improving that. So the summary of all of this I talked about what I do day-to-day, how that shapes my entire week of operations and how different weeks manifest. Then we talked about how I spent the first six months as a PM and then my backend or the infrastructure PM life and my current customer-facing role. While all of those things were great learnings, they did not come without challenges. And I wanted to talk about at least one slide on where I struggled and how I've constantly improving myself. Writing is an absolute must for PMs. You need to be able to clearly and in lucid language talk about the problem. And while it might feel like it's in your head and everybody seems to be repeating it, unless it's written down in a document, it is not doable. So it's very important to make sure that you are able to write down your own thoughts with others input in clear language in terms of strategy, goals, priorities. And we all know how to write documents, but even then it's very important to iterate on those things so you get the message into a more sharper contrast. And one thing I've struggled with is my first versions in my mind sound correct. And I've always not felt comfortable getting feedback on the document. Hey, this doesn't sound right. When somebody says that, it used to bother me and it still bothers me at times. So that's the learning that I'm trying to improve myself on. People are just expressing what they feel from the words that are written down. So it's important for us, if you wanna bring everybody along together to get the words right. And that in general is something that I'm constantly working on throughout my PM journey. That's been a challenge for me and I'm constantly trying to improve on that. And your own career growth is not going to be stunted because of this, but if you want to have more opportunities for growth, and I'll talk about it in the next slide as well, it's very important to get the clarity and the ability to drive clarity across a large set of people. A few more things that I'm constantly working on is how to have opinions that are loosely held and focus on the people and empowering them rather than you trying to solve the problem yourself. Early on as a PM, there is a lot of drive and solving problems. You become the problem solver, but as you grow in your journey, it's important to not just be the problem solver, but you should also be the encourager. You need to encourage others to solve the problem. And if they're heading down the wrong path, how do you help them understand that? And it involves time. You might feel like, hey, I can just do this faster in a week. Why do I have to spend time? So it takes two weeks for two others to go to it. But in the long run, the latter is a better strategy. The last one is about how am I perceived? So this has been a sort of a pendulum for me. Early on as a PM, I used to get feedback on different facets of being a PM, how I show up in meetings and how I'm including inclusive and how I showed up in meetings. After a while, I've realized that there are things that I should constantly try to improve and something that I challenge myself to improve. I identify certain superpowers for myself and I am spending a whole lot of my time honing those things and building a brand around that. So nobody can be the best of every aspect of product management. So it's important to keep growing. I'm not saying you stop other things. You must keep growing and keep improving. So overall, you are a good PM, functioning PM, but identify your superpowers and spend a whole lot more time so that that becomes more prominent for your colleagues and your partners to understand. Now I'd like to speak a few minutes about how I've been defining success in my career. Even though titles and money is at the bottom, I will admit that forever I've been chasing promotions and titles. And in general, what I've come to realize is that is in fact a proxy for the first three things. And if I actually step back and look at my career, I've had a great, like I've been lucky as well. There's a little bit of luck on what products you get to work on and sometimes projects get shelved and you have to start from the scratch again. But in general, I've had a great opportunity I started. I was a developer. There was good foundation on how Microsoft works as a software company. Then I moved into a backend infrastructure system. I understood the specific product. Then in the same product, I was given the opportunity to move to the front end customer facing product. All of these things were learning opportunities for me to grow myself as a PM. So that's been fantastic. The next thing I keep looking at is a scope of impact. I used to work on a one specific set of problems that solved three customers problem. Then I worked on solving a thousand developers problems. Then I worked on solving something it's a brand new thing that was a headline item at a conference that was being that Microsoft was hosting. That was like, Hey, look, I'm working on a big thing that gets talked about by my PPs in a conference. Then I'm working on things that are for millions of users, millions of our customers. So I understand how the scope growth is happening. And while you are in it, you sort of don't get to see it. So it's always important to step back and take a look at how are you growing and are you having that growth? The last one is the influence. In terms of are you a, we start from a place of, Hey, somebody tells you what is a problem and how it will go solve it. Then over the time you get to the place where you identify what are all the most important problems in the domain and in the business you are in. And then advocate for getting funding and getting those things fixed. And do you have the platform for being such an influencer is important for you to understand. And then this changes from stage to stage. And currently where I am, I feel like I have all of these opportunities, even if the titles and the money are at a different thing at a different scale. So it's a collection. And I'm constantly reminding myself that these are all the facets of success that I should be looking at, at least from a purely career point of view. And it's a work in progress for me. And I'll add with that. So the parallels that you can draw, what can you take away from this conversation today? People first, always. So my hope is that what I've learned over nine years, I'm able to at least present to you as a nugget right now. So even if you don't immediately internalize studies it's sort of ringing in your mind constantly on. If you have a problem start with the people who are related to the problem, always start with that. Try to understand why they come in with their viewpoint. Then you will understand the problem a whole lot better. I myself have done a lot of times where you focus on the problem itself, the technical challenge itself, rather than or the disagreement itself, rather than the people who bring in those disagreements. So always start with the people. The next thing is that I've realized that you become a PM but then you can't be successful the exact same way with all the teams. You have to be the PM, you have to be adaptable. You have to be the PM that your manager needs and your team needs you to be. The same set of formulas doesn't work everywhere. So it's important for you to go in with the learning mindset where even though you might have been a firebrand execution PM in one team, you might need to be a strategy PM in the other team. And it's very important to understand what your team needs and spend time in there. And that's the way I discovered that is by having those connections with the people, the one-on-one meetings with the early stakeholders and being asking the questions and being vulnerable and saying, no, I don't know the answer. Can you help me with that? That helped me a lot. Growth, as I said, the definition of success. I've come across this thing that says, sometimes you are behind, sometimes you are ahead, but at the end, the race is only with yourself. And it fits the product management discipline a whole lot because there are so many aspects of product management, so many products to go work on, so many ways that you can actually keep growing. So challenge yourself for that. And I'm telling that to myself every day as well. That brings us to the end. Hope you all had fun and I was interested in conversation for you. You can find me on Twitter at DCFarore's My Handle. And good luck to all of you all in all of your endeavors.