 Hello, everyone. Welcome to this week's Product School webinar. Thanks for joining us today. Just in case you didn't know, Product School teaches product management, coding, data analytics, product leadership, digital marketing, and UX design courses online and at our 16 campuses worldwide. On top of that, every week we offer some amazing local product management events and host online webinars, livestreams, and ask me anything sessions. Head over to productschool.com after this webinar to check them out. Today, we have an awesome guest presenting. I'd like to introduce you to Partha Dash. Partha is a product manager with over six years of software engineering experience in diverse areas such as financial services, insurance, and ed tech. Currently, he works as a product manager in one of the customer-centric teams at Babel, Berlin. Partha has a lot of experience in defining and prioritizing product features, managing backlogs, and executing overall product strategy. Also, he's passionate about solving customer problems, utilizing his strong analytical mindset and digital product experience. Feel free to leave any questions for Partha in the comments of Facebook, and I'll be sure to ask him them at the end. And without further ado, let's welcome Partha. Thanks for joining us today. Thank you, Dan, for the nice introduction. Let me share my screen. Looks good. Yeah, you can see my screen, right? Cool. Sir, so today's topic is what are the tools and framework for a product manager? Before going into the topic, let me give a quick background about me. My name is Partha Dash. I currently work as a product manager at Babel in Berlin. I have two plus years of product management experience in companies of different size and scale. I have done my MBA with major in finance and entrepreneurship from SP Gen Mumbai in India. Apart from that, I have around four years of software engineering experience. Entrepreneurship bug has beaten me once and have failed miserably. So this is all about me. Today, basically we will cover this topic. I would touch base the role of a product manager. Then I will talk about the tools and framework, which is mostly today's topic. In this area, I will talk three things. The problem space versus solution space. Then second thing, design a solution with a data-driven approach. Third thing, learn a product, lean product development process. After that, we will do a small case study and we'll have some time for question and answer. Cool. So what is the role of a product manager? I think you have already seen this kind of a slide or this kind of a framework already or so many times. So product manager essentially is an intersection between three things, the customer, business and technology. So as a product manager, in the customer side, you should know who is your customer, what are their needs and problems and what is the job your product doing to solve that problem or need. In the business side, as a product manager, you should understand what is your business model, how it is the revenue structure and cost structure and how is your business goal aligned with your product vision. Under technology section, you should know what is your technology stacks, what kind of platform approach your product is following. Is it like mobile fast or is it like a desktop fast? And then how you are solving the problem. This is a typical product development cycle. Like it's more like agile product development cycle. You start with idea, then you define, then you build a prototype, then you build it and test it. So this is more like all the product development cycle happens more like a small iteration nowadays. We call it agile. And this is a typical process happens in each iteration. So what does a PM do in each step of that product development cycle? So if I relate each step with different function, we can see like these are the activities usually a product manager does. So if you see starting with ideation, you do as a product manager, you do a lot of user research, market research, competitor research. Whenever you are defining the problem, you talk to different people internally, externally. You facilitate the discussion, you do a lot of stakeholder management, you analyze what is the problem. And during the solution page, you try to decide what is your MVP. You try to negotiate with the different people and prioritized different solutions. And when you define the scope, then you deliver that solution, it's more like project management. And after you deliver the solution, you do the data analysis, like you may try to measure the success. And once you measure the success, then you move to next action or the next iteration, more like a decision-making. So basically these are all kind of roles you play in the different phase of product development cycle. So what are the tools and framework for a product manager, which is the basically today's topic? So I will divide this section with different tactics. So I will talk mostly the tactics used by a product manager or what I use in my day-to-day work. The tactic one, start with the problem first. So as a product manager, you should be quite sure about who is your user, what is the problem you are solving, how many users are getting affected by that problem. Like it's based on the platform, based on the geography, based on your business model, it could be like three user or the paid user, lead or customer. So you should quantify like how many users are getting affected by that problem. Once you know that, then you need to understand whether it's like, how do you know that this is a problem? Did you get from user research or you got it from market research or you have some feedback from direct customer service or anything else. So once you validate that, you need to understand whether do the customer really care about this problem? Like is it something like nice to have or most have? Usually we use the terminology like vitamin versus painkiller. Like if you don't solve this problem, whether your customer will go away, then it's more like painkiller. Like you need to solve that problem. So it's most have. So the tactic one is start with problem first. Next, differentiate between problem and solution. So whenever you start ideating about a problem, lot of time different internal stakeholder or external people jump into solution. People debate about it's my solution, it's your solution, my solution is better than your. So it's very, very critical as a product manager to differentiate between product space and solution space. And whenever people jump to the solution, you should take a step back and say that, hey, this is the solution, this is the problem we are trying to solve. So differentiation between problem and solution is quite critical. Then next tactic is always communicate using why. So whenever you communicate some idea to the stakeholder inside your agile team or outside your agile team, always communicate using why. It makes your job easy. So whenever you communicate using why, people get a lot of context, what you are talking about. And they basically, it helps you to bring them into your side or it creates a lot of influence if you communicate using why. So I will always put it in this model like what you are trying to do, how you are going to do, maybe you don't have a clear cut idea, you can give it to your agile team and you should be quite clear about why you are doing, what are the problem you are trying to solve. So this is basically tactic three or the tool set three. The fourth point is always design a solution with data. I mean here data, I mean the KPI. So whenever you have defined a problem and trying to come up with a solution, it's you will be tempting to find a solution quite large enough. So at that time as a product manager, your job is to define the MVP as small as possible where you could validate your hypothesis. I would always start with your assumption like what are the assumptions you have or what is the riskiest assumption you have based on that build your MVP and validate your MVP through that MVP test. And during that phase like whenever you have an MVP, have a hypothesis and the KPI what you are going to measure for that MVP and define what does that success look like? Like how much that KPI is good for this hypothesis to be successful. Next point. So whenever you are, as I told, whenever you are defining the solution, the MVP scope is quite critical. So as a product manager, your job is to define that scope carefully with different people internally in your team or externally with outside your agile team so that MVP scope is minimal and you can test your assumption or the riskiest assumption as early as possible. I would put the four points what you should define in your MVP. We call it the value risk, the usability risk, the feasibility risk, viability risk. First point, value risk is basically whether this solves a particular problem or not, whether the user can find some value with this particular MVP or not. Then usability risk, it's basically whether user can use this feature or not. The feasibility risk is basically whether we can build this feature or not. The viability risk is basically whether we can build the solution and without going bankrupt. So these are the four risks. Identify which risk you want to validate during your MVP and based on that formulate your hypothesis and KPI. If you want to know more, I would suggest to look at a article in Silicon Valley product group from Matic again. I like that article much because it gives you a lot of idea about defining the MVP scope. Cool, next tactic is basically iterate, iterate, iterate again. So I would say don't stop with your MVP. So whenever you have defined your MVP, you build it, you measure success, you try to learn something, then think about iteration one and iteration two. So my mantra would be you iterate, iterate again. Don't stop with MVP. Whenever you are defining your MVP, always try to come up with a quantitative model or some kind of a model where you could define your KPI, like how it is going to be impacted by this feature. We will see towards the end of this presentation how we can come up with a quantitative model. But for the sake of this framework, let me just go bit theoretically. So as a product manager, whenever you are building a new feature or building an MVP, you should understand what are the KPI you are going to impact and whether these KPI are the leading indicator or do they have any driver or not. And once you build this feature, what are the impact on the KPI? So basically you have to consider your baseline data, like what are the current edges data you have at this moment and then you need to take some assumption. Basically, if you build this feature, that will have some impact on those driver or the KPI indicators. And based on that, you come up with an expected outcome. Like this is my expected outcome of this MVP. So you should build something during or before your MVP itself so that you have a clear-cut idea what you are going to achieve if this product or this MVP is implemented in the product. So let's do a case study based on whatever the tool set we just went through in the last 10 minutes. So here is the case study, just a simple one. So you are a product manager of a mobile app which sells audio books and podcasts to a consumer and you have a monthly subscription model. And recently you are seeing a decrease in the weekly active subscribers and monthly active subscribers in your platform. So this is the scenario, hypothetical scenario. So what is the problem here? So we have a decrease in weekly active user. Let's say as a product manager you went ahead and you try to dig into the problem, understand why we have a decrease in weekly active user and came up with this hypothesis like people don't have a time and they forget to use your product with their day to day busy life. Now let's say this is the basically you have defined your why or you came up with this why after your investigation. Now we are going into the MVP or the solution. Now you are basically debating with brainstorming with your team, your engineer, designer, some external stakeholder and you understood this is the problem and this is why this is the problem. And you came up with the MVP that reminder setting and notification. And you have a hypothesis that if we implement this reminder and setting and notification that will help to increase the weekly active user by let's say some X percentage. And so you will calculate this X percentage using the quantity model which I told you in the last slide using your KPI and metrics. In this hypothetical scenario, your KPI and metrics could be the number of users setting the reminder after you launch the product. This could be a hypothetical number based upon your current weekly usage. Then we could have a next line of metrics like number of user getting notification who have opted in. Then third point could be number of user coming back to the product after clicking on the notification and number of user listening to the content. Basically your content, the podcast and audio after getting a notification. So this is basically a small MVP you built and you are measuring the metrics right from the notification till the basically job to be done which is basically listening to the content, listening to the podcast or audio book. So you have defined these metrics and KPI quite clearly in the early during the MVP page and you have a clear-cut idea what you are trying to achieve by this particular MVP. And once you deliver this MVP then you will measure that success like whether we achieved this X percent or not. All right, so this is the summary or this is the key takeaway from this 15 minutes presentation. I would summarize with five point. Always differentiate between problem versus solution. Second point, communicate using quite. Third thing, design solution using the data which is basically the KPI and metrics. Fourth point, tackle big risk early during MVP. Fifth, iterate, iterate, iterate. Don't stop with MVP. Thank you. So that's it for today. Thank you so much for that presentation, Parth. That was great. So one question I always like to ask our speakers is do you have any advice for aspiring product managers, a piece of wisdom, a quote, something that you would tell someone who really wants to break into product management? Definitely, Dan. I would always say do some side project or like even if it's free of cost, do some side project, read a lot of blogs and product related books or maybe you can join the product school like where you have an excellent opportunity to learn those skill sets and the framework. Yeah, these three things I would basically summarize like do some side project, read blogs and product related books, join product school or some other boot camp if you have access. Awesome. Thank you. So I have another question here in the comments. It is what's the relevance and role of research in the tasks that a PM must perform? It's quite critical. Like whenever you are building a new feature, it's as a PM, you should have a context like what is the problem you are trying to solve and for whom you are trying to solve and so I would suggest it's quite essential to do those research. It could be qualitative research or bit of quantitative research or see your customer feedback through customer service desk or if you have a mobile app, see your app store review and understand what is that problem you are trying to solve and it's quite essential as a product manager if you are building some feature to have that research only during the product development cycle. Awesome. Thank you. And for our last question, what was the hardest part of making the transition from software engineer to product manager? So whenever you work as a software engineer, you have a mindset that you can do by yourself and basically as an engineer every time you think that this is the problem, this is the solution I'm going to do, you think more in a silo way and as a product manager you talk to different stakeholders you try to get more like more information from the different cross-domain. So basically you try to gather input from the different cross-stakeholders or stakeholder from various domains. So that's become quite important. And what is the challenge? So challenge would be if you are an engineer you have a bias to solve by yourself so you need to come out of that bias. And second thing you will always think about like an engineer but you would have an temptation to think like an engineer. I would say that's good but you should come out of that temptation and think like more like a product manager and rather focus on the problem and give the solution to your agile team who can try to deliver the right solution. Awesome. Thank you so much for those answers. So that about wraps it up. Thank you Partha for joining us today. Thank you for your awesome presentation. It was a pleasure. Yeah, thank you Dan. Nice to give a presentation. Thank you. So before we leave I wanted to give our audience some more information on product schools upcoming courses and events so they have the resources to become a product manager. Our product management, product leadership, coding, data analytics, digital marketing and UX design courses are taught by industry experts working at companies like Google and Facebook. In addition to that we offer weekly online and on-site events at our 16 campuses across the US, UK and Canada. So if you're located near campus make sure you stop by one of our weekly events every Wednesday and Thursday. You can find us on social media at Product School and keep up with the latest product management content at the product blog at productschool.com. Thank you all for joining. Enjoy the rest of your day and I hope to see you next week. Thanks a bunch, Partha. See you later.