 Hello and welcome everyone to this webinar on the most common product management mistakes. Today, I'll be speaking about some of the most common mistakes that product managers are likely to make, especially early on in their careers. You'll find a lot of resources, books, articles, podcasts that talk about everything that product managers should do to launch successful products. But there's also a lot of things that product managers should not do. I learned about a lot of these things either about making these mistakes myself or by observing my peers and colleagues making some of these mistakes. Now, I see many junior PMs whom I mentor make these mistakes repeatedly as well. So my hope is that after learning by learning about these mistakes and some simple tactics on how you can avoid these mistakes will help you become a better product manager. A little bit about myself before we delve into the content. I'm Shipra Kanoria. I'm a principal product manager at Amazon. I am currently leading the product strategy for Amazon Comprehend, which is a collection of APIs within Amazon Web Services that helps developers who do not have any machine learning expertise to extract insights from text documents. These insights can be sentiments, entities, dominant language, or even keywords that you want to extract from your documents. Before Amazon Comprehend, I was with Alexa, where I was responsible for many successful launches. Some of them are timed music actions that allows customers to ask Alexa to play music for a specific duration. You can say, for example, Alexa, play jazz music for 30 minutes. Another one is voice notes, which allows customers to ask Alexa to remember anything. You can ask Alexa, make a note that my nephew wants a Nintendo Switch for this Christmas. I also launched a lot of small features such as alarm-based routines and grew the engagement of Alexa overall by increasing the engagement of the products that I was responsible for by 30% year over year. So before we actually delve into the content, I want to make a quick note here. All the content that I share today is based on my personal experience and it does not express the opinions of my employer. And here's a quick agenda of what I want to cover. I'd first talk about the most common mistakes. I'll share some examples from my career journey and also talk a little bit about how those mistakes may look like in practice. Then I'll talk about how can you avoid these mistakes early on. And I'll end with the biggest mistake that all of us are really likely to make. So let's start with the first mistake. The first and in my opinion, the biggest mistake that product managers are likely to make is to already have a solution in mind and then to try to map a customer problem to that solution. And despite the golden product manager rule that always start backwards from the customer problem, this mistake is really ubiquitous. And in my experience, this mistake is most likely to happen when you're working in a very disruptive field. So you're working with a really cool and disruptive technology. You want to bring that technology to market. You want to build products that use that technology. And in our quest to bring that technology to market, we often overlook if that technology solves a core customer problem. I believe this happens because of two big reasons. The first reason is we are told that, hey, customers don't know what they want. And if you build a product, customers will come. So let's focus on building both of those are untrue. No matter how complex your solution is or how elegant your product is, if your product does not solve a core customer need, your customers are not going to use your product. The second reason this happens in my opinion is there is a race. There is a race to be the first one to get a specific technology to market as there's a lot of pride associated with it. It gives a first mover advantage. But once again, none of those really help increase adoption for your product. If the product does not solve a core customer need, your customers will not come. And you can see examples of this mistake all around you when you see products that had a lot of PR and marketing behind them, products that were using the latest technology, but that failed to gain any customer traction. Think about Google Glass or any AR device for that matter in particular, which were really cool technologies and some of them really elegant products, but didn't gain any traction because they were not solving for a pressing customer problem. I actually made this mistake early on in my career when I was working on Alexa and voice technology was fairly disruptive several years back. So a lot of the features that I was thinking of or I was building focused on the voice aspect of it. That is the technology aspect of it versus really thinking about does voice do a better job at solving those problems for customers? Or does voice present a benefit to customers that's not available to them with existing technologies? So let's say you have defined a problem you want to solve. You're not working backwards from the solution, but you have defined that, oh, this is a customer problem that I want to solve for, and this is a customer problem that I want to build products for. The second mistake that product managers are likely to make is then to use user research to confirm or validate their hypotheses instead of understanding true customer motivations and behaviors. And what this really looks like in practice is asking leading questions such as what features would you like? Can you rank these features in an order of priority or amongst these end choices, what products do you want? The reality is that customers want everything. You will tell you that I want A, B, C and D, but what they say in a survey is not reflective of the actual adoption or whether they'd adopt or not. This can also manifest in the way we analyze our survey results. So let's say you conduct a survey and you're trying to understand how many customers really have the problem that you're solving for. And 40% of the customers say that, oh, I have this problem that you're solving for. 35% of them say I am indifferent to this problem you're solving for, and 25% say I don't have this problem. What happens when we are using user research to validate our hypotheses rather than to understand customer behavior is we focus on that 40% number. We say, oh, 40% of our users have this problem. So it gives us an indication that this is a problem worth solving, but we ignore the 60% that is either indifferent or does not have that problem. And really delving deeper into why they don't have that problem or why they're indifferent to the problem would really hone your product thinking and help you build a better product. So now you have identified the problem that you want to solve for, and you have also conducted user research to define what's the minimum viable product you want to build. You have worked with your engineering team to understand how much time it will take you to build the features. You have added ample buffer to some of those engineering estimates and you've created a really solid product roadmap with milestones and a launch date. Now your team is in full execution mode, and which brings me to the third mistake that product managers can make is as they're moving closer to the launch. They tend to prioritize a launch date over some of the features. What will happen is as you move closer to the launch, you will discover problems. Some tasks took longer than expected. Some integrations are not working as you expected them, and your product testing revealed certain bugs. So now you're faced with this choice of should I delay my launch and prioritize these features and bugs, or should I stick to my launch? And can I de-prioritize some of these features and bugs and maybe launch them as a fast follow? And there is so much emphasis in the product management world on delivering results and on launching products that often product managers would prioritize launch. And they'll say, okay, let's launch and we'll fix things later, or these bugs are not as critical to customer experience. Let's launch without really fixing them and we can fix them later. And once again, in my experience, that tends to be a very, very costly mistake. I made this mistake when I stripped down the minimum viable product for a product that I was building towards bare minimum, because we wanted to meet a specific launch date. We wanted to launch the product before Christmas so that we could get holiday marketing for that product. We could get adoption from a lot of new customers that try our product during holiday times. And we thought that it's really, really critical for us to launch before the holidays to get a good adoption for our product. So, yes, I was like, okay, whatever did not fit within the launch schedule was de-prioritized and we made the launch. And as expected, for the first four to six weeks, we saw really, really good adoption of our product, because we knew that we get a lot of new customers. We know that we get a lot of new trials and we were covered in all the holiday marketing. So customers were trying our products and we were very happy about that. But then we found out that those customers were not sticking around. And when we looked at the reasons of why are those customers not sticking around, they were complaining about the same features that we had de-prioritized to make that launch date. Or they were complaining about the same bugs that we were aware of, but we had de-prioritized to meet the launch date. And that's why I'm saying this is a very costly mistake because once you typically lose customers, it becomes very, very difficult to bring them back or to use your product on a continuous basis. So, let's say now you have launched your product. All your product goals are now focused on increasing the engagement of your product, which actually makes a lot of sense because now that you've launched your product, you want a lot of customers to use it. But that brings me to my fourth mistake, which is you start investing in product growth before product market fit. And what this looks like in practice is you're trying to increase the number of customers who are using your product. That is, you're trying to increase your acquisition, you're trying to increase your trials without first understanding what's the retention rate for your product. Without first determining that is there a core group of users that is using your product regularly? And what happens when you do this? If you don't understand the retention or if you don't make sure that you have a healthy retention before you start optimizing for acquisition is that you end up with a leaky bucket. You have a lot of users that are trying your product, but none of them are staying. None of them are coming to use your product repeatedly. And hence you have a leaky bucket, which is usually very, very difficult to fix. So it's always better to make sure that your product has a healthy retention, has a good product market fit for a core set of users before you start driving more acquisition and more trials for your product. So I spoke about the most common mistakes that I typically see. And here's a recap on how those mistakes map to different stages of a product development life cycle. Early on, when you're thinking about what problems you want to solve or early on when you're in a product ideation phase, you're more likely to already have a solution in mind and work backwards from that solution. You're also more likely to then use user research to confirm your existing hypotheses rather than to truly understand the motivation and behaviors and needs of your customers. As you get into the building phase or in the execution phase, the mistake that you're most likely to make is just a wrong trade off to launch your product at a certain date or to kind of meet a certain launch target, you will just prioritize the date over the right set of features, which can be, as I said, a very, very costly mistake. And after you launch the product, the mistake that you're most likely to make is that you start investing in product growth, you start running marketing campaigns to get a lot of customers to try your product before really establishing a core product market fit for your product. So now you must be wondering that, okay, we know about all these mistakes, but how do we really avoid these mistakes? And the way to avoid these mistakes is really simple. Yes, you may be wondering, ask the right questions, but yes, it is that simple. Asking the right questions at each stage of product development would really help you make sure that none of these are blind spots for you and that you are launching a product that customers want. So how do you ensure that you are working backwards from the problem instead of the solution? The first step is to define who your customer is. What is your customer persona that you're solving for? I'll give you an example in my current role. We build product for developers, machine learning scientists, business people. And the first thing that we always start with is, hey, what's the customer persona we are solving for? Are we solving for a developer who does not have any machine learning expertise? Are we solving for a data scientist who has machine learning expertise? Or are we solving for a line of business user or a business user who has no technical expertise and wants a lot more simpler solutions? So it's extremely important that when you're thinking of what you want to build, you first identify who your customer is. And then once you've identified your customer, you think of what is the customer problem that we are solving for? Once you identify that problem, then you should think about, hey, how do I solve for this problem? Is the technology that I'm using or is the technology that I desire to use even the right way to solve this problem? Or are there other ways to solve this problem? And then you also want to make sure that the problem is big enough for you to solve. There is a big enough market for you to actually be successful as you solve this product. And you typically do that by asking, how do we know this is a real customer problem and how big is this problem? Which brings to user research and to make sure that you are using your user research to understand customer motivations and behaviors rather than to confirm your existing hypotheses. You should ask some of these questions, which is, why is this a problem for customers? Really go deeper into understanding where, what situations your customers are in when they encounter this problem? Are they at their home? Are they at office? Are they in the park? Are they driving? Who are they with? Are they with somebody else? Are they by themselves? Are they with their kids? And really understanding where the customers are when they encounter this problem would make sure that you have a really holistic solution for that problem. You'd also want to ask, how do they solve this problem currently? And the answer to this question may help you determine that, oh, the current solution that my customers have for this problem is good enough. And my solution does not offer any incremental value, and it can also help you determine the size of the market that whether this problem is really worth solving. To make sure that you're making the right prioritization between the launch date and the features, you should first and foremost ask, hey, why is this launch date important? In a lot of cases, the launch date can be important because let's say you have a PR event tied to that launch date. Or especially for retail products for kids toys, you want to launch them in Q3 so that you get a lot of sales in Q4 because a lot of customers buy a lot of toys in Q4 as holiday gifts. So some of those dates become extremely important. But for most software products, you would find out that it is a target that is just set and then is treated as a movable target. Whereas if you delay the launch date by a couple of weeks, it would not really hurt your product as much, but it will really help you increase your adoption, especially if you're prioritizing the right feature set when you delay the launch date. It's also extremely critical to understand the value that the features you are deep prioritizing offer to the customers. Are they truly P1 or P2 features? Are they truly good to have features? Or are they must have features? Do you expect the customer engagement to drop by deep prioritizing any of these features? And understanding the second order consequences of the prioritization decisions you're making. The first order consequence is often very easy because it's like, oh, if we don't have to build for this feature or if we don't have to solve for this bug, we'd be able to launch faster and meet our launch date. But the second order consequences is customers do not like the product or they do not use the product or the product does not work as they expected. And it's extremely important that you are clear about some of those trade-offs as you make this decision of whether you want to deep prioritize features or the launch date. And to make sure that you optimize for product market fit for product growth, you should have a very good understanding of what the retention for your product looks like. In fact, it should be one of the key metrics that you measure in days or weeks after you launch a product because that really tells you there is a core group of products that coming to use your product repeatedly. How often or you measure retention actually depends on your product. The frequency of use depends on your product. A product like Instagram would have daily retention. A product like Amazon would have weekly retention. Or a travel product like Airbnb or Expedia may have quarterly, half yearly or even yearly retention that they measure. But it is extremely important that you first determine what's the frequency that you expect your customers to use your product at. And then build in ways to measure retention for your product. Because if you don't have a core user set for your product, you'll just keep getting a lot of trials without having any repeat usage. The other way to make sure that you're optimizing for product market fit before product growth is to ask what is the churn rate for my product, which is typically the inverse of retention. How many customers are just leaving or not returning back after using my product. Sometimes churn rate can also be measured, especially if you have a product that requires sign up or creating an account. You can also determine how many customers are creating an account. How many customers are signing up for your service versus how many customers are just using it as a guest and then never creating an account. And then you want to think about how can you improve your retention and churn rate. And one advice that I have here is you want to avoid strategies that only increase your retention and reduce your churn in the short term. One of those strategies, let's say is offering discounts, right? You can say, hey, come back and try us. Here's a 25% discount. That's a very short term retention strategy because that customer will come back, avail that discount. But then the next time you want them to use your product again, you'll have to give them another discount. So make sure that you're not overusing those strategies that increase retention just one time. And the best time to use a strategy like offering discounts is when you have made significant improvements to your product and you are looking to capture lapsed users. And you know that by offering those discounts, you can get those customers to try your product, but then your product is good enough. It has taken care of all the prior feedback because of which customers churned in the first place, so they're not likely to churn. And that's a good time to use discounts, but otherwise you should not use strategies that just improve retention in the short term. So I spoke about the most common mistakes and also some ways to make sure that these mistakes don't become blind spots for you or to make sure that you avoid these mistakes. I now want to talk about the biggest mistake that all of us make as product managers, which is to not think about our own career as a product. We are so busy launching and growing our products that we don't take the time to pause and adopt the same mindset to our own careers. I'd highly encourage everyone to think about what a product mindset looks like when applied to their own career. What's the three to five year vision for their career? What are the different milestones they need to achieve to make sure they're making progress towards the vision? And then how can they measure progress against that vision? So yeah, to quickly summarize, I spoke about the most common mistakes that I've seen product managers make. These are working backwards from the solution instead of the problem using user research to confirm existing hypotheses instead of truly understanding customer motivations and beliefs, making wrong prioritization, prioritizing a launch date over features, and lastly, investing in product growth through soon, increasing acquisition and trials before establishing there's a product market fit by having a healthy retention. I also spoke about some of the questions you can ask to make sure that you don't make these mistakes. These are not the only mistakes that product managers make. There's a lot of other mistakes, but in my experience, these have been the most common mistakes that I've seen product managers make repeatedly. And I hope you found this discussion helpful today. Thanks again.