 Hello, everybody. My name is Mrdula. I am a senior product leader at Amazon currently and I am extremely happy to be here today to talk to you about product management. Obviously, I chose this as my profession and my career, so I'm extremely passionate about it, but I'm also super excited to be talking to the product school community. This community really helped me when I was an engineer and trying to break into product management and I was trying to pivot to product management and this is my opportunity to give back to all of you so that we may all grow together. Happy to field any questions after the presentation. You can also reach out to me. My information is provided by product school in the blurb below the video, so happy to field any questions after. But with that, let's get into the topic today. Today I want to talk about PMs and product life cycles. And there are a lot of things that I want to cover. Here is what our itinerary on this journey is going to look like. I'm going to start off with the product life cycle with a focus on the voice of the customer. And almost always we always go back to what is the problem that you're trying to solve and I cannot stress this enough so I actually made an entire slide for it. I'm also going to double click on a few aspects of the product life cycle itself, mainly strategy and product definition. Then we're going to round it off with like the go to market strategy for the product life cycle. And because I've been a PM for a while now, I'm going to round the presentation with a few lessons that I've learned along the way. I really hope that everybody who's listening and who's here today learns from these mistakes and we grow together just like I mentioned earlier. As you might have known you probably read articles around this, you probably heard other people talk about it, but there are so many ways to actually conceptualize a product development life cycle. And there are so many aspects to making a successful product. Almost always it starts with vision and leadership. It's an idea that you have in mind and you want a solution for a particular customer problem that you've seen that others have told you about. Then you go into the product life cycle management where you probably start with the design and then the product roadmap. These are all parts of strategy in some companies, their individual topics and others, but they almost always are part of the product development life cycle. When I talk about design, when I talk about roadmap, they're all in place because almost every company has resource constraints, which means every product has a backlog. And our roadmaps, our planning, our strategizing, our prioritization techniques are a way of making sure we are on the right path to that vision for the product that we've established. Along the way, again, a lot of PMs also do a lot of modeling. They could be prediction models to kind of see if our product is the right fit for the market. They could be business models or financial models to kind of assess the impact and the money that the product is going to bring in for some times. And finally, there will be a lot of project management also and product management where you have to collaborate with a lot of partner teams, stakeholders, and continuously align people towards this goal and this vision that you've established. Having said that, there are some core elements. And you know, all of these core elements involve exploring, I'd like to think, four basic questions. Number one, what is it that you want to build? Number two, how are you going to build it? Number three, who's your customer? Who are you going to sell it to? And obviously a lot of questions about them. And finally, number four, how are you going to make money off of it? So one, what are you going to build? Two, how are you going to build it? Three, who are you going to target for your customers? And four, how are you going to make money off of your product? Along the way, like I mentioned, every part of the product lifecycle, you will need to coordinate your partner activities. This can be research, data science, design, experiments, everything that you can probably do in a silo or with a team, but also other important areas of management like operations, finance, marketing. If you are in a smart vehicle or autonomous vehicle space, then compliance, data privacy, all of those partner activities. You also want to keep in mind data and dates and milestones, because every time you work with multitude of stakeholders, dates, milestones and the why is almost always the way to make sure everybody is aligned towards the same vision and goal. I did mention this in our opening. What is the problem that you're trying to solve? If I had a penny for all the products that didn't actually work. And almost always, and this is my kind of observation, that almost most of these products, what they have in common is that along the way somewhere, they've lost track of the problem that they're trying to solve. But there are a few examples that I want to talk about today that did not lose sight of this. For example, Google or any other search engine started off with a basic tenant. They wanted people, they wanted to give people the ability to search for anything on the internet. That's it. It was as simple as that. Slick deals, which is Thanksgiving is top of mind for me right now. So slick deals is another website that I'm visiting a lot lately, but slick deals had the same simple tenant. They wanted to provide people with the best Thanksgiving deals year round. And as long as you identify that simple customer problem, and as long as you keep that problem center of mind, everything else will follow. Now, a lot of budding PMs come up to me and ask me, how do you figure this out? How do you know it's the right problem? How do you know or pick the one problem that you have to solve for among the multitude? Constant vigilance. Now, I'm a Harry Potter fan. I really like Madi Moody. So that's the term that comes to my mind. But the answer to that is you have to keep your customer in your focus all the time. You have to constantly listen. You have to constantly be aware and you have to constantly research. You have to not just ask customers what their pain points are, but you have to observe and you have to think for yourself. Unarticulated customer needs is friction and friction is opportunity. With that, we move into strategy. So now we have an idea of what the product lifecycle looks like, then we know the problem that we're going to solve. Next, where do we go from here? We strategize on how to solve this particular problem that we've identified for a customer. Now, strategy is always long term. Strategy is always forward looking. It's always big picture. You have to always think of where the product's going to be 1, 3, 5, 7, 10 years from now, depending on the lead time and the environment and the industry you're in. But strategy is always about audacious goal setting. And it's also about moving forward. Oftentimes, as soon as you think of a product and oftentimes as soon as you obtain buy-in from your customers, you start developing. You start engineering things and then you lose track of the big vision. Strategy is a way of tying your product, of tying your roadmap to this problem that you're looking to solve for the customer and all the milestones that you want to achieve along the way. Good strategy should be extremely obvious. Now, basically you have to take something that looks like a woolen yarn ball and then you have to just be able to straighten it out. Now, after you present a strategy as a PM, if an engineering leader comes up to you and says, hey, this is so obvious. Why have we not done this yet? Then you know you have a good strategy in place. And if you are thinking, oh my God, it's extremely ambiguous. How am I going to kind of untangle this mess? You're not alone. Product strategies are guides to the future, yes, but they're almost always based on the information that you have at hand. And this is why it's extremely important for PMs to be adaptable and flexible. You have to meet the needs of the company. You have to meet the needs of the company that you are in at the time you are in. You also have to meet them as you go along. And this is why strategy is almost always revisited. You revise it, you add to it, you adapt it as you go. The second phase after you strategize is writing a PRD. Now, as a young PM, this is the area that actually I use to struggle with the most. Now, on paper, a PRD is a product requirements doc. What is that? That is basically converting your customer requirements, your use cases, your customer needs, everything that you've captured into technical requirements. Something that your engineering team can take and basically run with it. You are basically informing the engineering team of your vision and at the same time giving them the tools to be autonomous. You are setting clear guardrails as to the vision and how to proceed in a particular direction for a product. But you also are giving your stakeholders and your partner teams and your engineering teams the way and the path to actually take that product and build a solution for it. Now, a lot of people have asked me, what does a good PRD look like? And I'm going to give you the MBA answer. It depends. A good PRD can be a sketch and a piece of paper. It could be a living doc that you are constantly editing with your team. It could be a bag of napkin virtual cycle, but it almost always has one thing in common. A good PRD matches your company style and your team needs. I think the best practices for a PRD are to include a few things. Number one, the purpose, which is who is the customer? What are his or her needs? What is the problem you're trying to solve for them? Number two, what are the goals that this product should achieve? And not just the goals for the product, but also goals that can help the engineering team actually transform into engineering plans. These customer needs that you have laid out. Number two, something that the teams can use to measure what they've built. Three, success criteria or some companies also call this exit criteria. Now teams need to be able to measure the effectiveness of a product, measure the effectiveness of a strategy. Because building a product is just one thing. Understanding how good the product is always lies in the metrics. You've got to be able to understand what the product's contribution is to your business. Has it impacted negatively or positively? Hopefully, positively. Customer engagement, any other metrics, if you're tracking satisfaction and satisfaction, if you're tracking total addressable market than that, whatever metrics that the product you want the product to hit, they all need to be spelled out in that PRD. And I'm a strong advocate of making sure that your metrics are defined before you build the product. Because almost always, if your metrics are defined after you build the product, you run into problems. Four, prioritization criteria. Resources are always constrained. You will never have enough developers in the world. You will never have more than 24 hours in a day. Resources are always constrained, which is why prioritization and figuring out the vectors along which you want to prioritize is extremely critical to a product's success. And for prioritization, there are a lot of things that you can look at to prioritize, but almost always what's worked for me is answering two most important questions. Where are we? What are our strengths? What are our weaknesses? And what can we manipulate easily and better? Number two, how do we get to where we want to go? What are our opportunities? What are our attributes? What is our leeway? What can we reverse? All these decisions, again, product management to my earlier point, you are creating a path into the future based on the data that you have at hand right now. But you must always be adaptable and flexible. These plans take you to account current day opportunities and current day weaknesses, but they're not set in stone. Finally, okay, now you've understood you've identified a problem. You've identified a customer. You've gone through the product lifecycle stages of strategizing, road mapping, PRD, and the engineering team has finally built the product. What do you do? You take it to market. What does go-to-market mean? Lots of different companies do it a lot of different ways, but GTM at its core is marketing the product. It's your playbook for how to reach customers and reach the right kind of customers. Otherwise, your product will not be viable. An excellent product needs an excellent go-to-market strategy for it to truly become a really good product market fit. I think another way of thinking about go-to-market strategy is to just take a pause and understand how can you ensure product distribution? How can you penetrate markets? How can you grow a product at scale? That is along the lines of good GTM strategy. So if you can answer those questions, then your GTM strategy is going to be solid. Now with that, I want to round the presentation with a few lessons that I learned along the way. Number one, product development is not linear. When I stepped into product management, I had the naive idealistic view of how products were built and I thought, okay, we have an idea. We go and ask the customer, hey, this I think is a pain point. Do you agree? And they validate that problem. And then you design, you iterate, you prototype, you develop and you launch. Oh boy, was I wrong? Because in real life, it is not at all linear at all. You have an idea, then you have to jump through a bunch of loops where you have customer research. Sometimes that goes back again into your feedback because you might learn something totally different. You might learn that it might not be a customer problem after the drawing board. There might be so many other loops that you have to jump before you get to product launch, but it is all worth it. Number two, always keep the problem that you're trying to solve top of mind because it not only helps you, but it also helps all the other teams that you're working with. Because it's the original point of agreement. That's where you started. That's how you convinced people. That's how everybody rallied around you to actually build that product. So it's key for alignment. And every time you find yourself, when you find things going off the rails or if extensive discussions are being had, always ground the team around the problem that they're trying to solve. Number three, nothing is perfect, but you got to build it anyway. And this is a hard lesson that I learned. I expected a minimum viable product to be minimum lovable. That always doesn't happen. You have a lot of challenges along the way. You have partner challenges like engineering teams probably want to work on technical debt and maybe not push features out. You might have cross functional challenges where the legal team probably doesn't want certain things implemented a certain way. Or maybe due to the politics and the environment that the product is in, laws changed. This is happening with privacy today. Maybe you have global changes such as your infrastructure probably is not designed or third party cookies can one day just be turned off. Finally, you can have timing challenges. Maybe you have to launch something in time for Thanksgiving or in terms of like I'm working with a taxation product where you actually have to launch it before the tax laws can change with the next presidency or in five years. So you might have a lot of timeline dependencies and timeline challenges. It will never be perfect, but you have to build it anyway. Finally, what is going to help a PM succeed? A lot of times PMs come up to me and ask me, hey, I strategized. I did a lot of customer research. I did extensive customer research and I put together a wonderful road map in place, but due to resource constraints that never saw the light of day. And that happens a lot. And then the obvious next question is, does that mean I failed as a PM? Absolutely not. Because one way of measuring impact as a PM is looking at the products that you've helped launch. But a better way that I have realized at least that works for me is about understanding what tangible benefits you are bringing to the team and yourself. Personal growth too. A few things that have helped me are clear communication. You definitely as a PM should be able to talk multiple languages. And when I say multiple languages, I mean be able to talk to the legal team, be able to talk to the marketing team and the engineering team, be able to talk their language, effectively communicate. Number two, advocacy. As a PM, you will almost always wear multiple hats. One day probably you are talking to a customer understanding their pain points. The other day you have to probably talk to the legal team and understand the legal implications of a product. The third day you have to talk to the infrastructure team to understand why something that works in one region is not working the exact same way in a different one. But all of these also mean that you are the epicenter. You are the hub to the product. You are the one throat to choke. And you also have the responsibility of shielding the team from all of this ambiguity. You should be willing to take hits for the team. You should be willing to take hits for the product. And that will definitely make your products, in my experience, the launches go smoother. Finally, you need to be three steps ahead of all the products and all the customer research in your area. You need to be able to, and this is a muzzle that people built over time, but you need to be able to understand where the next roadblock is going to be and how you can prevent it even before it actually happens. But that, I hope you had fun and I hope you took something away today. If not anything, I hope I've normalized being a PM and the ambiguity that comes with the job to a lot of who is listening right now. Thank you.