 Welcome to today's session. My name is Maurizio Gianluca, I'm a PM at Microsoft, and today's session is titled Questions and Frameworks for your day-to-day as a PM. A little bit about me. I am from Venezuela, I was born and raised there. I got my bachelor's and master's in industrial engineering, and this picture that you see here, that trust me, I'm an engineer, was in my gown when I graduated, that's why I'm so fond of it. I've been a product manager at Microsoft for almost four years, and just a bit more about the background for this talk. When Product School reached out to me, I wasn't really sure what to talk about, but I had a manager that whenever I wasn't sure about a specific situation, he didn't give me an answer straight up. He always replied to me by asking me a follow-up question that would give me more clarity in the situation, or he would suggest a framework that I could use to get on block. When thinking what to talk about, I really like the idea of sharing some of those questions and frameworks that have helped me in my day-to-day as a PM. That's where the title for this session came from. To provide a little bit of a level-setting context, let's start with what the life of a PM looks like. Normally, we start with leading or being asked to lead a big initiative for the team. Once we understand that initiative, then we talk to the customers to understand what their pain points are. When we have a good understanding of their pain points, we write those thoughts down, normally in the form of a spec that really helps the team understand where to go. But as many of you know, that is not a one-on-one type of thing. It is a very iterative process that requires a lot of collaboration. But once everybody is clear on the direction from the spec, then you start to drive progress. You start the execution mode. Either at the end or throughout the process, you start to look back and see where the team is, so you get a chance to improve. This is a very simplified version of what life of a PM looks like. It is actually very common to have many projects going on at the same time. So you can be going through this cycle in parallel multiple times. It doesn't have to be in this specific order. Sometimes you'll talk to your customers and then you'll discover a big initiative to drive. But the steps are more or less correct, the order may change slightly. Again, these areas by company, by organization, by team, so follow this process, follow the questions and frameworks, and you'll succeed. So let's start. Leading a big initiative. This can take many shapes and sizes. We've seen this all over the place. It can be as simple or as complicated as improving customer retention by 50 percent, or a little bit more binary, like create a data quality program for the organization or launching a feature to improve customer satisfaction. Again, this depends by work, your function, your team, all of those. At this step, at the very beginning of a project, I like to ask myself a set of questions that help me get the right thinking in place. These questions are, what are the players in this phase? This really helps me list out all the people that I need to interact with, the people I need to convince, my allies, my not-so-alliance, all the folks that I'm going to interact with throughout this project. What are the next five moves? This helps me get started. It forces me to think beyond the next action, and whatever that first action is, once that it's done, at least I know, I have an idea of what to do next. It's okay if it is not exactly what you thought of, but it forces you to think beyond that first step, it forces you to think in that right direction. Last, what are the options, what are the risks? This is way too early to get it right, but that's okay. The point here is that it forces you to write down some of the paths that you can take, and what are the things that could happen in each of them? The idea is to identify some of the options that the team has. At this point, in the beginning of the initiative step, the framework I like to use is the pre-mortem. A pre-mortem is when the team imagines that the project has failed and you evaluate the reasons why. It may sound negative, but it really allows you to think through the reasons why the project failed, and I personally like to do it with these people. I'm going to be working the closest with, normally in a room of four to six people, since that allows me to see different points of use, not just mine. Once the group has a good understanding of the top reasons why the project might fail, we can take the right necessary steps to mitigate those risks. This is really important because before the party has even started, you at least have some understanding of what it is to watch out for. Perfect. You understand the initiative. Now, before jumping into any solution, you have to talk to your customers to understand the problem that you're trying to solve. Granted, in some cases, like I said before, you'll talk to your customers and then you'll derive the big initiative based on the feedback they gave you, that's okay. When talking to your customers, I like to ask myself this set of questions to get a better understanding of what I want them to do. Why should a user or customer use my product? You have to know the answer to this. Through the PM, if you cannot explain this and make it part of the product, then your users won't be able to tell either. You have to make this research apparent in the product itself. What do my customers want to achieve? This gives me a sense of the user's flow, the user flows that they will go through when using the product. This is very important because it sets up the next question, where they're struggling. If you understand the user flows, you can at least hypothesize as to where the flows that they will struggle the most. When you talk to your customers, you'll be able to see if they're struggling in the places where you thought they are or if you have to reshape your focus. The framework, it sounds simple, but it's very important. Research how to do customer interviews. This is super important because you'll do many of this throughout your PM career. The idea when doing this is to keep the questions open-ended. The top two questions I like to ask are, what is the most frustrating thing about using product X and what do you wish you could do with product X that you can do today? Those are the top two questions that I asked in my customer interview questions. Something to keep in mind is that when you talk to your customers, you want to understand their problems. You're not looking for them to tell you how to fix it. They can, aren't they? But you have to be careful. In many conversations, your customers would say, if I had X feature, they might probably will be solved. But you know the feature X makes no sense with the rest of the product that you're building. You want to understand what their problems are, not design a solution with them on the go. Again, the point of this is to understand their pain points, understand what they're struggling, so you can send the right product to solve their needs. Perfect. At this point, we understand the initiative and the customers. So what now? We write the spec. I was listening to an event the other day in product school and they were saying about the importance of writing in your career, in your PM career, and I truly believe that. That's why I emphasize writing to all of my peers. I think it really brings clarity to the team, but especially to yourself. Because through writing, you can make sure your idea is sound. You can get clarity in your thoughts, you can get clarity in the options that you have. So before writing the spec, I'd like to ask myself two simple questions. Whose feedback and bios do I need to get? This allows me to get a sense of all the people that will need to review and approve the spec before the deaf team starts to go. I want to be proactive about getting that feedback, and I want to develop relationships with those people. Because this is important, since we need to make sure that the team isn't the same page before we start the execution. Then the second one is, what is the takeaway that I want people to get? I asked myself these questions because I want to be intentional about the points I want to punch in the spec. For example, if everyone is super clear on the problem, then I want to spend more time focusing on the UX, for example. Still explain the problem, but I don't have to spend that many sections of the spec on that. Whereas if not, everyone is super clear on the problem, then I want to make sure I spend a lot of time backing up my claim to make sure everybody agrees on the need we're trying to solve. At this point, I'm going to do a plug to the products for the framework that I like to use is the template spec in the product book. I think this book is a fantastic book for PMs, especially those in early stage in their career. The template in that book is really helpful to get you started. One of the first things I did when I was reading it is I copy pasted the content and created a word doc called template, and that is the one that I start every project with. It really helps me get the right framework and I get a good idea of all the sections, all the things I need to think through when I create my spec. One of the things that I especially like is the PR FAQ sections. Those are very common in Amazon, but not so much in Microsoft. But reading this and using them has allowed me to think through the perception of the product and the kind of questions I want the users to ask before the product gets launched. Again, I want to be super clear about this. This is an iterative process. I cannot emphasize it enough. It is not a one-on-one thing. It is an iterative process. You will iterate a lot before and after the first review and throughout the duration of the project if you want to keep the project, the document correct, you should. So make sure to work with engineering, design, other PMs, all the people that you are dealing with in the project. You don't want to surprise too late in the game that changes the direction of the project. You want to make sure you're being proactive about getting that feedback. At this point, the spec is done and you move to the next step, driving progress and making sure the project is going as expected. Keep in mind, a lot of progress is driven through meetings, whether those are ship rooms, monthly product reviews or whatever other forum your organization uses to make sure everybody is rolling in the same direction. So what I'd like to ask myself in these forums is somewhat straightforward. What is the next action? And once I understand that, who has to do it, buy one, and what happens if they don't? Once I know that, I can make it clear to the team and we can all be on the same page as to who has the accountability to drive the progress, to do the next step. In those meetings where you want to drive progress, I recommend something very simple, but very effective, taking notes. Good note-taking is a very underrated skill. In fact, more often than not, if you're taking notes and you're projecting or leaving the whiteboard, you can leave the meeting in the direction you want. You almost control the room, so to speak. So something I like to do when I take notes and send them afterwards after the meeting is that I want to record the important aspects of what was set in the meeting. I want to be very intentional about bolding whatever decision the group took, so everybody is clear and it's recorded that we all agreed on it. I want to clearly call out the follow-ups, specifically what is and who has the next action. If you do this well, you're going to drive more progress for yourself and for the organization than you're speaking to people left and right. So it is very important. I know PMs sometimes get a bad rep for the key notes, but I cannot emphasize it enough. It's one of the most important skills that a PM can do. And almost as important as leading the meetings is making sure you're going in the right direction. So the questions I like to ask myself at this step is did I achieve what I wanted this week, this month, this quarter, whatever time period and evaluating it? And if not, why not? This forces me to be intentional about the deadlines for the team or even those that I set for myself. So it is important to understand whether you're hitting the right milestones that you have for your project. If not, you can question that. You can understand the reasons why not. And you can look back and see the reasons for the pre-modern and see if those match. The second one is, is this an issue that we're facing? Is this issue that we're facing a one-off? Or do we need to do something more concrete about it? And this helps me understand if we're overreacting to an issue or if we're facing or that we're facing or if we're, okay, it is important to not over-correct when a one-off things comes up. Because you have to keep calm. You have to understand how does over-reacting changes how the team spends resources. Another thing that this question helps you understand is if, for example, there's something more concrete, they need to go about it. Maybe there is a resource conversation that you need to have with your leadership team. Maybe you need to ask for more resources because something you didn't thought of came up. And that's okay. The important piece is to be intentional about this. And last, am I spending my time in the things that provide me the most value? And this is very tricky because PMs have to do a bit of everything to keep the organization moving. So the most valuable is very subjective. But at least be deliberate in asking the question and making sure you're spending time developing the skills that you want. This is super important to take the next steps for your PM career. The framework I like to use to keep me in check is the weekly review. I learned this from the book, Getting Things Done, from David Allen, which advocates for what is the next action framework. I actually took that from that book as well. And I love this weekly review format because it forces me to look at the list of initiatives and to do's that I have. And it allows me to make sure that I have a next action associated to it. And I understand that PMs are incredibly busy. Our calendars are probably one of the most chaotic for the whole organization. But try to leave 30 minutes a week to clean up your to-dos, your calendar, and see your list of initiatives. And make sure that you have the next step associated to each one of them. Once I do this, this really helps me understand the week in the right directions. I normally do it on Friday afternoons when the whole week is calming down. I like to do this for that Monday morning. I know exactly what things I need to do. And that's it, that completes the cycle. Like I said at the beginning, you're going to go through many of this at the same time. And when one is done, there are other initiatives that are still ongoing. So there's more work to do for sure. And there are more initiatives as well that can be picked up. So you'll go through this cycle or a version of the cycle many times. You can define what works for you and what really helps you define your PM career. That is it for the session for today. I want you to take away three things from today's session. The first one is ask yourself the right set of questions before starting an initiative, a project, or a meeting. That way you understand who are the players? What do you need to prepare? And what are the outcomes? What is the outcome that you want to get? This again sets you in the right framework and you can use all the questions that I said during the presentation to get the right thinking in place. The second one is frameworks are a great tool to get you started, you have to take it the rest of the way. They're tools, they're not the answers to everything. You can use them and you should use them, but you don't rely only on that to give you all the answers. And the last, don't dismiss the importance of note-taking. If you take notes, in many cases, you control them. I see many PMs not wanting to do this. I think this is one of the things that you should do as a product manager. I think really helps you understand the product, really helps you try progress in the right direction. So don't dismiss this skill. All right, perfect. Thank you so much for having me this session. This was questions and frameworks for you today as a PM. You can find me in LinkedIn at MauricioLuca and thank you so much everyone. Have a great rest of your day.