 Hello, everyone. Welcome to this product school webinar on the topic of why product managers pick a problem first approach. My name is Ratika Maheshwari and I'm a senior product manager at YUP based out of the London office. Before diving into the topic, I would like to introduce myself and also talk about my journey so far. I didn't really start out as a product manager. I actually started working in the consulting industry. This opportunity really helped me develop my analytical skills which has really shaped how I ship products. It helped me develop a data driven mindset which drives how I ship products as a product manager. I transitioned from consulting to product manager role after completing my MBA. I really wanted to complete the life cycle of executing on my recommendations as a consulting firm. Fortunately, I've had the chance as a PM to work across multiple products such as advertising, sellers, data products. And finally, I'm working on search products now. I've had the chance to solve different types of user problems across firms of different sizes. The common thread that I've noticed across all the products that have shipped so far or across all the industries is the importance of having problem first approach. This has really helped me grow as a product person in the past five years and I'll be discussing the same today. I'm currently working as a search UX PM at YUP in the London office. Moving ahead, what exactly do I mean by when I say a problem first approach? This comic strip by Dilbert really highlights today's topic well. This shows that Dilbert gets product feature requests from different stakeholders and what are the consequences of shipping all the products or rather being solution first approach. Generally, product changes are discussed in form of feature ideas or solution and I'm also having guilty of this previously. But I realized focusing on solution misses some very key aspects which go a long way in determining the product success. Just because you want to build certain product features does not mean that's what users find valuable or aligns with their product goals. In nutshell, the recommendation from today's webinar is to not to be tied to the solution rather focusing on the value that a user derives or what is the outcome that the user expects from the product. Jumping into today's agenda, we'll primarily be talking about three topics today. First, I'll be discussing why should PMs have a problem first approach. A common behavior across PMs is to start with a feature idea which can come from multiple sources, PMs themselves, senior leadership or probably the user itself. Unfortunately, this approach leads to suboptimal results and we'll be discussing the benefits of having a problem first approach. The second section will focus on what exactly does a good problem statement look like. A good problem statement basically contains three aspects which it should be able to answer. These four aspects when answered helps define what the customer needs and not what the team thinks the solution should be. And the last and the final topic that we'll be focusing on is how do we identify these user problems. This, as per me, is one of the most difficult aspects of product management, but if done well, contributes significantly to shipping successful products. Moving on to the first section, why is problem first approach even important? Problem first approach helps us answer two very important questions in product process. One, are we building the right solution? Secondly, are we creating the user impact? The first question, are we building the right solution? The problem first approach helps us explore and prioritize different alternative solutions to the same problem. Whereas solution first approach is title particular solution, which might not be the best solution, both from an effort and impact perspective. Secondly, if we have a problem first approach, even if the solution fails, it does not invalidate the underlying problem. Hence defining the problem before the solution helps us in exploring other solutions if the first one fails, which is not the case when we have a solution first approach. This reminds me of a very famous quote by Henry Ford. If I had asked people what they wanted, they would have said, passed to horses. By focusing on solution which was passed to horses in this example, the team would have restricted themselves to a suboptimal solution and not really revolutionize the automobile industry. It's important to focus on the problem here, which is wanting to get somewhere faster than the solution of faster horses. I have also faced this as a PM early on in my career. For example, when I was working as an ads product manager, the users when asked what they would like to improve on the app always mentioned the number of ads should be reduced. Although when these users are pro for their to understand the problem with ads, the outcome was not the number of ads need to be reduced rather the distribution of ads. Users primarily had a problem with ads during certain use cases, which was basically continuous usage of the product. Hence the solution pivoted from reducing the number of ads which would have greatly impacted the revenue to changing the distribution of ads for such users. Focusing on the user problem helped us understand and explore different solutions. And also those solutions, which one was the best in terms of minimum disruption to revenue at the same point of time, maintaining the user experience. Moving on to the next aspect, which problem first approach helps us answer is are we really creating a user impact? If we have a problem first approach, we can understand what is the right hypothesis that we're trying to validate and make up and have like freedom of decisions based on what should we build and what should not be built. Whereas solution first approach makes this really tricky because we don't really know what users find valuable. And this reminds me of an interesting article that I read earlier, which is don't serve burnt pizza linked in this deck where the author highlights that if you serve users burnt pizza, you're not getting feedback on whether they like pizza. You only know that they don't like burnt pizza. In this case, being solution first, they don't understand that users find value in the pizza itself. And hence this product feature has been declared a failure, although the underlying user value has not been tested. Secondly, it helps us answer are we even solving the right problem? When we are solution first, we don't really know if there are other problem statements, which will deliver a better impact to the user. And hence if the problem is not defined up front, the solution can be testing the wrong hypothesis. Without a deep understanding of user problems, we end up building solutions which might not be delivering the highest impact or might not be testing the right hypothesis. And that's why it's very important to have a problem first approach and not have a solution first approach. Moving on to the next section of the webinar. Now that you've established that why do we need to have a problem first approach? What really constitutes a good problem statement look like? I would like to start off with a quote by Charles Keatring, which highlights the importance of a good problem statement. A problem well stated is problem half sold. A good problem statement not only inspires and guides the team, but also makes the evaluation and iteration way easier. Today, I'll not be focusing on what a good problem statement format looks like. Rather, what I'll be focusing on is respective of what format we pick up. We should try to answer these four questions. If these four questions are answered in the problem statement format, that means that's a good problem statement. The first question that we definitely need to answer is who is the user? It needs to clearly define the user for which the problem is outlined. As user needs differ by segment, it's possible, it's all not possible to have the same problem statement for each segment. For example, users using Yelp for restaurants have will have different needs than users using Yelp for plumbers. Secondly, each problem statement should clearly define how does it impact the user. We build products for our users and the core of a problem statement is a clear description of that. It should describe what the outcome that users are seeking to achieve and not the product feature. A problem statement should always focus on the user's Y and not the business Y. The third aspect which a problem statement should really focus on is how does it ladder up to the overall firm strategy? And why is this important? It's important because to highlight why a firm should invest resources into solving a particular problem statement. Highlighting this not only helps in rallying and aligning cross-function stakeholders, but also ensures that the right problem statements are prioritized as resources are always limited. Fourth and the last point is how do we validate if the problem statement is solved? Good problem statements are always measurable. At times certain problem statements are not measurable directly. Then how do we understand if we have been successful in solving the problem? One method that I've used in the past is to focus on measurable user behavior, which is evaluated over time to understand if they achieve the intended objective. For example, my problem statement was that users do not understand Yelp's value proposition and hence they do not retain. How do we know if users understood the value proposition as retention is a lagging metric and cannot be experimented with? We identified that users who engage with certain content are more likely to understand the value proposition and retain. Hence, engagement with that certain content was defined as a success metric for that problem statement. And engagement with that content was then tried to understand how it impacts attention over a longer period of time to basically validate the hypothesis. Coming to the last section for today, which is how do we actually identify these user problems that we've been talking about so far? There are primarily three steps at a very simple level if I have to talk about it. First, you always need to discuss and have a clear product vision for our product, which we need to align with different stakeholders. Based on that product vision, we need to define what user outcomes are needed to achieve that vision. For example, if the product vision is to increase user retention for new users, some possible decide user outcomes could be users engaged with content on the app or users search in their first session. These could be possible user outcomes that could help in the retention of new users and this needs to be understood through a variety of methods. For example, user research, data analysis or probably some past experiments as well. Based on the outcomes that are aligned with the team, the next step is to map out a step-by-step user flow for that particular outcome. Because it's important to understand the motivations and barriers that each user's face in each step. For example, when I talk about search, I know there's a huge cognitive load when users need to search for something new, as they need to decide on what exactly should they type out to get the answers that they're looking for. This can only be identified when I start creating a step-by-step user flow. Mapping out the user flow helps me in understanding the user problem at each step and this helps me identify the biggest key behavior that will help me get to the desired outcome. This also helps me in user problem prioritization. Based on the barriers and user needs at each step, I can understand which user problem should be prioritized. And this at a very simple level are the three steps that everybody needs to follow to identify the user problems. Last but not the least, I would like to wrap up today's discussion with an insight from an article which I've linked in today's tech. And this captures the essence of today's webinar, which is never start with solutions. Just because you prefer the hammer or the screwdriver does not mean it's the tool you need to fix what's broken. I hope that was helpful and thank you for spending time with me learning about this topic. Thank you so much.