 Hello, everyone. Welcome to my webinar, my day as a product manager in 30 days. I'm Rakshat and I'm with Amazon. And I'm also a mentor with PM Dojo, and I'm doing this with Gnabra Project School today. All right. So the first question to everyone before we start talking is, how was my day? But as a PM in Amazon, right? I would want to talk about how was our day as a PM rather than just talking about Amazon stuff today, right? So the biggest question we are trying to answer is, how was your day going? For any product managers, right? There are a couple of things what we always struggle with. One, not sure where we start when we open our laptops in the morning because there are thousands of emails, thousands of things and lots and lots of customer calls and emails that are sitting in our inboxes. So we absolutely not sure how do we start and how do we prioritize things and how do we handle so many things that are going on. Product managers being the center of the hub and spokes model and everybody is depending on you or waiting on you or, you know, waiting for you to answer many, many questions they have or to set the path or the direction where the entire team want to march towards to make or to launch a successful product, right? That's one of them. And I'm really, really dealing with the same problem because I was on a vacation for the last week and coming back yesterday, it was completely a mess. Anyways, we'll dive deeper to see how I managed to get through it. The second thing I also want to focus on is how do we strike balance between our customers? I know we have a lot of angry customers. We have happy customers, but at the end of the day, everyone wants the same thing that is the priority or the importance slash attention, right? Our customers need attention and they want everything to be done yesterday. So how do we go on balancing the asks that we are getting from our customers? How do we keep them happy? That's something which we'll also be talking about in the next 15-20 minutes. The third and most important struggle, all of us are faced, which is part of my life as a product manager is context switching. Yes, there have been times where I have been on two meetings, dialing from my phone, dialing from my laptop and keep listening to both meetings. Am I being successful in that? That's a different topic we will discuss later. Or we may not even talk about that. But anyways, coming back to context switching, right? As a product manager, we have to tackle many, many things. There might be questions coming from legal, there might be questions coming from marketing, there might be pre-seals, documents what we need to create, we need to create PRDs and then engineering teams might have a lot of questions around the prioritization so legal might have some require or attention. So how do we switch? How can we be more effective in switching the context or answering multiple people from multiple different domains? And that's a bigger headache, all of us are faced. And the last topic which I also want to talk or a key takeaway, which I want to, last key takeaway which I also want to talk is what I call it as 60-second strike. What is the 60-second strike? A problem which never existed 60 seconds before, how did it become a problem? And how do we handle it? And what do we need to do? So that is something what I call it as 60 seconds strike because that will strike you hard and you will not have idea just 60 seconds, even 60 seconds before it happens. Okay, so this is what we'll be talking and these are the four different key takeaways which we will be taking away from my job as a product manager. Right, sorry. How do I start my day? The first thing I always do is kind of schedule my day where I can have a 15 minutes of kickstart. When I say kickstart, all I do is open my outlook, scan through my emails which have been come from previous evening all the way till the morning. Yes, I know overnight there could be a lot of customers across the globe, time differences and also there are a lot of colleagues and peers who would love to respond to emails maybe in the night or because everyone has their own schedules. Right, so that's where I start off with scanning through my emails. Remember, I'm not going to answer them until I know what everything is. So I just scan through and see which one kind of stands out, which one is an emergency or which one really, really needs my attention. Then scan through my pings and scan through my calendar to get a good idea of what meetings are there on my calendar. What is that I need to go to where I need to be and whom I need to respond to either in Slack or Teams or Chimes or any of those things. So this is exactly what I will be doing in these 15 minutes. So this will give me a very good idea on how I set my day. And once that is done, the output of that is the next point where I say, I'm going to define my day saying, hey, I'm going to invest half of my day on this particular product. I'm going to do either half and writing this particular document. And then these are the different things what I will be achieving today. So it's kind of like, if there are five to 10 bullet points that are come out of my 15 minutes kickstart, maybe I have going to be time for five of them. So I'm going to say these are the five different things what I will be achieving, which are the top most priority. And then one other thing is that product managers always have a dock request coming from different folks. So how do we do that? So one thing you always need to remember is constant prioritizations between the existing and the new items that come up. So basically it's going to be a queue. So what I do is if there is a new item, I kind of compare it against the existing one. See if that's the top priority, if it's not the top priority, then I'm going to respond and say back, hey, I might not have bandwidth to get to it. This could be delayed or can this be waiting? So basically, I prioritize, let the folks know that this is something which I'll not be able to get to, or let the team know that I'll not be able to get to this and still continue with the existing ones. So in case if that's the one, the new items, the top priority, of course, you drop everything and pick that up depending on the, on the emergency of that meeting. Now, the other one like we also scan the calendar is one of the biggest pain points for all the product managers. At least my entirety is double booked, sometimes even triple booked, right, with different meetings. So what I do is I just, I just go through my meetings and I skip where I feel I do not add any value, or maybe I feel that I'm not required there, right? So always feel free to skip meetings, but if you skip your meeting and if you think that you are not going to add value, let the host know that you will not be chiming. The simple rule of thumb is I always color code my meetings. Like red is a must go, blue is something nice to go and gray is something I can completely skip kind of a scenario, but it's the choice of colors are left to you, right? And the other thing also it's more like the must go meetings are some of those meetings to where the meetings cannot get started without you, or the decisions cannot be made without you. So those are the must go meetings is how I define my meetings as. So that's something which everybody needs to understand, but sometimes, yeah, I end up being into meetings, I'm still on it. Then the next point is basically all of these things you need to clearly identify which of these need attention. It's like, you know, you have three kids and you know, you need to identify which kid needs the most attention. So you pick that kid, give your attention, pay your dues and you're out of there. So that's exactly what I would do. That's how I plan my day and an easier way to do is I have lots of to-do notes. I just keep scribbling, ticking and pushing things around. So this is how I start my day and plan my day. So couple of takeaways from here is feel free to skip meetings where you don't add value. Let the folks know that you will not be joining and then try and plan things, prioritize what needs to be done. Try and push, if something, if overflowing, try and push which are not important. Right? Amidst all of this, don't forget to care for yourself. If you're tired, just, you know, take a break, take a five minutes break, go for a walk, grab a cup of coffee. But at the end of the day, self-care is very, very important. I and I pay a lot of attention for that. Right? So that's about it. That's how my day starts. Statement of communication, right? Like we were talking, there are always angry customers. They're happy customers. It's not just the customers as a product manager, you deal with cross functionalities. It could be legal, marketing, engineering, any one of them. So what do we do? Number one, I always follow this principle of over communicating. That's fine if you're spamming a couple of folks, but it's also important that they know what you need to be said. And a couple of times I've been in scenarios where I've communicated once folks have forgotten and that kind of become a problem or escalation later. So I always suggest my mentees and all the folks as a product manager is to over communicate. It's sometimes, you know, you feel, oh, I just sent an email yesterday, but there's an event happening today. Maybe be subtle, say, hey, a gentle reminder about the seven artists. They don't forget to join us. Whatever. That's right. So over communication is really, really good. And it also helps a lot of stakeholders to understand what is happening. It drives transparency. And it also helps you gain trust with your stakeholders because they feel involved. If you don't communicate, they always feel that, oh, I'm not sure what's happening. I don't know when these things changed because there are a lot of things. And usually PMs communicate with executives. They have multiple things going on. So over communication is really good. Right. So that's what I do. And the other thing is whenever you talk to our customers, my go to my safe place is that I start with empathizing with them. So that way, you know, if there's customers angry, not satisfied or even if it's an internal customer, they're really, really not happy with your product. They come back to you. Or if you're missing a deadline or if the requirements are changing, you just sit there. Listen for 20 minutes. Let them cry. Let them crib. Let them do whatever they need to say. You sit there, empathize and just say, oh, yes, I understand. Okay. I hear you. That gives a good, comfortable feeling for your customers. At least at some point in time, all you need to do is sit there and listen to them. So they get a good feeling about, okay, there is someone who can listen to me. Who's listening to me? So that is exactly you need to do. Sit there, empathize completely here out and then maybe start adding your thoughts and say, oh, maybe this could be done this way. This can be done this way. Oh, you know what, you know, we are delayed. I know, but we are giving you XYZ, which can offset ABC, but definitely we'll be rolling a couple of other changes. So the best tip I've got so far and has really, really worked for me is to sit there, empathize. That will give more comfort to your customers. And then trust me, whatever point you're trying to make, it'll make you much easier and it'll be much faster. All right. So I think I have always been followed throughout my career as a product manager. Then the other one is as a product manager, you need to be very, very proactive than being a reactive person. So let's say you have a marketing event which is coming up and you do not want to wait for the marketing team to come back and say, oh, can you give me the GTM or can you prep for a presentation or let's say in a stakeholder communication, maybe you are kind of delaying or you have seen a risk in your timelines or you are seeing some legal issues that might pop up. So it says that you can just go be very subtle, dear customer. Hey, hope you're doing good. We are working towards this. We are trying to get to the finish line, but there could be some minor XYZ issues what I'm foreseeing, but nothing is concrete yet, but the team is completely working on in case something changes, I'll keep you posted about it. It's all about being proactive and keeping them long. So that's what I always do. If there is something which I foresee, I kind of communicate. But at the end of the day, I wait until I have some solid information to make sure that it is the right foresee what I'm doing. Again, we don't really need to create false alarms. That's a very, very fine line between be proactive and raising false alarms. So make sure that whenever you see the risk, you spend time. Ask that understanding of why is this happening? What is it happening? And how is it happening? And what can be done? And what are the different solutions that could be possible and kind of a scenario? Just have a good understanding, learn about the situation, learn about the risk what you're looking at, and then give a subtle proactive communication to your stakeholder. So that way, they even might start empathizing you and you will start getting their trust as well. So that's something I would say. Then as a product manager, your customers will look for the recommendations than open big questions, because this has been really working for me off late. Rather than saying, oh, hey, here's the thing, I have a risk or maybe the product is delayed. What do you want to do? I know that you have planned an event across rather than you go and tell, hey, you know what this? The product launch has been delayed, but I have five features out of five. There are three. How about we demo three or we go to a customer with those three features, and then we will be doing the rest two in a week or a month or whatever it does, right? That's one of the examples. Let's say for the sales, instead of saying, hey, a new product is coming. What do you want to do? How do you want to launch and stuff? How do you not do the sales event? Maybe you can go back and say, hey, you know what? There is a new product what I'm launching. How about let's let's host some pre-sales event. How about we do a, sorry, we do some road shows kind of a scenario. So every time our recommendation is for customers of like off late, the new generation or off late, the customers want to hear what they like to know what to be done rather than giving them the options of saying, okay, this is what it is and they're figuring out a solution to it. So I would prefer recommendations or open-ended questions and this has actually paid off really well. Even with the executives in my company, that has really helped me a lot. Rather than going them with a problem, I go with the recommendation saying, hey, this is the problem. Maybe we should do XYZ and that would help us solve the scenario or this would do some damage control kind of a scenario. And it's pretty much easy for them. They don't have to think. They just need to act. So that would really help and that has helped me a lot. And then as a product manager, when you sit down with your stakeholders, have some communications, it could be your engineering, it could be your sales, marketing, customers, legal, PR, whatever it is, be ready to disagree and commit. Yes, this is an Amazon term. I know one of the leadership principles, like you might have already guessed it out. But anyways, the meaning of disagree and commit here is that yes, you kind of disagree with what they say, but you are still willing to commit because your customer might have more information. Your senior management might have more information. At some point in time, when you disagree, you do definitely need to give them the solid reasons on why you disagree with that and that kind of completes the principle what Amazon says disagree, sorry, have a backbone disagree and commit. So that is where the next point, what we're talking about is the data-driven communications. That's really important. Let's say there is a proposal of what your customer is saying and you want to disagree, then you need to list out why do you think that you disagree with these things. Maybe what the way you're thinking, the customer might have already thought and that could not be their problem they're trying to solve something else. In that case, they have a bigger problem that you don't have a good understanding. But anyways, the idea here is be patient, listen, understand what the customer is trying to say or what the stakeholder is trying to say. And then if you think that's the right thing to do, be open-minded to disagree saying, okay, I might not agree with you, but it seems to like the way forward. Maybe I will comment and let's go in that direction so that it will really help towards the greater good. But back every time, back your communications with the data data. Say for example, you're sending out an email to your customers rather than say, oh, it's really good. Oh, we are doing really great. Oh, we are on track. Maybe you can explain a little more. You can say that, hey, out of 10 features we have already launched or we have deployed eight features to go. It's coming up in the next two weeks. And then you might be able to do some demo blah, blah, blah. So always go with the data. So data is everything and it helps you convince a lot of folks. It's a good way to paint the picture of facts. And it's also easier for the audience to understand what you're talking about. That's the data driven communication. Context switching. What do I do in the mode of context switching? The context switching, the first thing what I do is delegate. If there are too many things on my plate, don't feel sorry to delegate. Go to appear and say, hey, I don't have bandwidth to do this to you. Will you be able to help me out? Go out, let your manager know, hey, maybe I'm not able to do this. Will you please help me out? Or can one of your teammates pick it up? So start delegating things. You're not the sole person holding everything together. Of course you are, but ask for help when required. The second thing, feel free to say no. There are three things you're already dealing with. You don't want one more thing. In case if you think that you're not able to do it, just say no. There is no magical number, which is you have to do three things at a time. You have to do just one thing at a time. It really depends on individual capabilities. Or it also depends on how comfortable that person is with the product. There are a lot of times where I do three things, four things at a time. But I know if I'm dealing with a product that I'm comfortable with, if I'm starting to work on a new product, maybe I will have 100% focus on that because that's a new place. It's a new learning kind of a scenario. So it's completely left to the individual choices. So feel free to say no. The other way to deal with the context switching is just a reminder. Focus on one thing. Maybe spend two hours on one particular thing. So get to the next one. That's more like a sequential way of doing things, but again, slicing and doing things. If you want to do things really in parallel, then maybe you can set reminders. You can write notes. That's how I do. And then sometimes you also tell your peers that, hey, maybe can you just help me understand or can we recall the last five minutes? Or can you please bring me up to speed? Can you just help me recollect a couple of things? Feel free to just ask them so that you kind of recollect what you were doing before when you're coming back to this and then you can start fronting. And then I call this as a dynamic to-do list. Keep juggling between the items what you need to do. Up and down, prioritize, prioritize, and see what is really, really important for that day because you don't really need to spend your time on doing things which are not required for today or tomorrow or even day after tomorrow. Rather focus on the things that really, really need your attention right now. The biggest thing what happens in the context when spokes come back, come to you and say, hey, you know what? This is what I'm working on. This is really, really important to me. Can you please get to it? At some point in time, there is a lot of emotions that go into these kind of asks that are coming in and when there is a thing which is really, really critical, you feel there is a lot of emotions that go into it. So all you need to do is take a step back, kick the emotions out and then think logically. Maybe you can just hear out the person. Okay, I understand. Okay, that's fine. Okay, then make them feel comfortable and then go back and ask, hey, okay, why do you think this is important? What is that? What happens if we don't do this? Go back and analyze and leave the emotions out of it, be more logical. At least when I do that, for me, 70% of the time critical scenarios have kind of dropped down when we do these emotions out. There is an issue that has popped up and folks are going full gaga over it. Then you go back and say, hey, what's happening? Okay, I know there is an event coming up and there is a launch coming up. I know this issue has popped up. Okay, let's take a step back. Let's understand why it gave, how did it come? What is that going to happen if they don't fix this? So half the times are more than 50% of the times. It's the emotion that kind of make things very time-sensitive or critical rather than actually they are. So kick the emotions out and think logically. So that will really, really help you and reduce multiple things in the context for context switching as well. So this is something what I always do. And yes, I also keep switching context and I think that's one skill every product manager needs to have. I know it's not the best thing you want to hear, but that's the fact. Okay, 60 second strike. This is something which I really like about it. It makes you more dynamic and it makes you more challenging. The word like explained before the 60 second strike is a problem which never existed 60 seconds back, which means that it's a brand new problem that's coming your way. When you say problem always or on slash issue, we should always think about, okay, what is it? Is this really a problem? Or is this an issue which we need to focus on? Is this really, really an issue or a problem with the codes? So all you need to do is, okay, just calm down, take a step back and analyze what the problem is. What is the root cause for it? What is it? Just calm down, think for two minutes, take a deep breath and start thinking about it. Then you will be able to say whether this problem is actually a problem or not a problem. Or it could be a problem, but does that need to be dealt right enough kind of a scenario? So first define the problem. This will, for me, this has solved 70% of the time, the problem will go back to stage, right? And if it's not a problem that needs to be dealt right this minute, then I'm happy to push it out, focus on the important things, and then all of these be happy to revisit and see what needs to be done, right? So this logic kind of kicks out 70% of the problems or the 60 second strikes that are kind of coming away. Then you need to do is damage control. That's the next step of the 60 second strike, go back and communicate to all your stakeholders and say, hey, this is what had happened. This popped up 60 seconds back. We didn't know about it. Let's see the teams are working on. I'll keep you posted on how it goes, but just wanted to keep you all in the doing. So that is the first thing you will need to do, and that's going to solve a lot of problems, and that will help you to set the right expectations. Now your stakeholders are aware of it, then you can go back and say, oh, this is what, this is what. This could be delayed. Maybe it's not delayed. It's not a P0 and other, you know, the rest remaining 30%, another 15% problems will deescalate when you have that conversation with your stakeholders and they might say, oh, okay, that's fine. Even though the launch is there, this is not a launch blocker. Maybe we don't need that right away. So that kind of helps you as well. Once you have this damage control, don't worry, just get into the planning phase. Trim all the fat, trim all the unnecessary things. Trim all the P1s and P2s. Focus on the issue, whatever is P0 for that particular issue. Focus on what is that quick hack. If that's required, but is that the right thing to do? I wouldn't recommend. But is that what the customer in the business wants? Then you need to be smart enough to make that decision. Maybe a quick hack, long-term solution, short-term solution, and then focus only on what is needed for that moment and then rest of the add-ons can come in in the next phases. So don't be scared to go back to the whiteboard. Do the thing once again and see where it lands, right? And then involve the right folks that are required to solve this problem. The next one I would suggest is I always do as whole people are comfortable and responsible. So let's say there is an issue that needs to be fixed or there is a problem that needs to be fixed. And then you have folks from different functional teams, marketing, legal, development, or it could be sometimes your customers or whatever, hold them accountable. Let them know that, hey, look, this is the problem. This is what we need. This is expectations. This is the timeline. So hold them accountable. If something is not working, go back to them. Have that conversation. See how you can offer help to that. Yes, and make them feel responsible that, oh, okay. We are really responsible for this. This is what it is, right? So at the end of the day, you are a leader where you need to lead people either from the front or back. It doesn't matter, but at the end of the day, make sure that they feel accountable and responsible for what it is. That's something I would say. And the last one is define the right success criteria. If you don't define them, then you don't know what you're going towards or you don't know if the problem is solved or not. How do you measure success? What is that? Either it could be your KPIs or it could be your ABC items that is called the success criteria or the success criteria or whatever it is. But define them and have an agreement across all the stakeholders. So that is how you deal with a 60-second strike and maybe you can give it a try with these things. Right? And then getting to the next one is the turn-off productivity and turn-on personality. This is one of the most spoken or talked topic across these days given the pandemic and all of those are working from home. So a couple of things what I do to turn off my productivity and turn on my personality is asking myself every time, once at the end of the day, something comes up that my first question is, can this be till tomorrow? If no, why? So that is where the why needs to be stronger and it needs to be important than your personal life or it needs to be really, really critical, sensitive and time-critical. Again, don't involve emotions in answering these why. Right? So that's what I do as the canvas wait till tomorrow if yes, then I'm not going to pick it up. Right? That's one way. The other way is I usually don't answer or things after work hours when I say, okay, I'm done, I'm done. So be comfortable not answering them in case if there is something really, really critical, like let's say GCP is going down, AWS is completely down, then folks will chase you irrespective wherever you are, whether your laptop is closed, your phone is off, whatever it is, people will chase you and they will reach out to you. So be free not to respond to pinks after office hours. The other good thing what I have done at work is I keep sharing my family stories, like I don't have kids, of course, but I share my travel stories. I share my parents are here. So I share those areas with them where we took them for vacation where me and my wife and I were traveling on all of those things. So the peers know that you have a family too. There are multiple advantages. One, it kind of creates a very good healthy environment when you start sharing those stories and second, people will start respecting your time saying, oh, he has family, he has things to take care of and it kind of constantly reminds them that, okay, he works in his different schedule, he has other things to take care of, let's go and he bought them if it's really, really required. So I always have this line in my email which says, my arse, my arse, your arse, your hours, please feel free to respond to them you can. Just because I'm sending an email late in the night doesn't mean that the other person needs to respond or compile to respond. So it's just a way of making sure folks feel we value their personal life and once you start doing it, you also will start getting it back. So maybe I think if you feel that there is no work-life balance, maybe that could be the first step you can take and then rest of the team will definitely follow you. So that's something which I kind of tell my mentees as well to share their personal stories which are shareable with the colleagues and stuff, right? And then always have a shutdown ritual. I always do that. If I'm shutting down for the day, like closing my laptop or any of those things, I kind of plan, okay, what are my items on the list for tomorrow? How do I plan for them? So just, you know, that's a wind-up ritual and I always make sure that I plan my personal activities right after my work. Let's say you want to do a dog working or your yoga class or you have a massage therapy or whatever it is, schedule it right off the work so that kind of forces you to, you know, close on time. I mean, so that way you don't, your office work don't creep up into your personal life. So whatever it is, if you're having a playtime with your kids or whatever it is, maybe just schedule it right off the work. So it kind of forces you to stop on the dog and you can let your teams know that, hey, or in your meetings, if your meeting is running over, you can say, hey, I have a hard stop. I need to go, I need to take my dog to work. I need to go to my yoga class. I need to go pick up my kids, whatever it is. So that's some of the ways what I try to work around so that I could turn off my productivity and turn on my personality. So that's pretty much how I do and there are multiple ways. These are not only the ways pick anything that works for you, but if you really like these, maybe you can, you can follow these attacks as well. Right. And then finally, questions. If you have any questions, please send an email to me. Happy to answer. You can find me on LinkedIn by my first name. Feel free to ping me and happy to connect with you. Thank you everyone.