Product Management: Documentation and Metrics

1. Introduction: Hi, everyone. Welcome to the introductory video of this class. This is Shreya Jen. I work in the product team at Phonepa. Phonepa is India's one of the leading Fintech brands that does over 350 million transactions per day and has over 500 million registered users. Prior to this, I have worked across b2b and SAS firms as a platform product manager and has over ten plus years of working experience. I started my career as a data scientist and I have a computer science degree from Bitspani. So in this class, we will learn two key fundamentals of product management, which is documentation and metrics. So we'll learn the relevance of documentation to ensure that all your stakeholders are on the same page. Stakeholders can vary from engineering, business, designs, analytics, and so on. It also clears the air around assumptions made for your product. The second part is the metrics, the relevance of metrics in day to day life of a product manager, whether it's for feature prioritization or defining your core product metric or even for user research. The detailed key takeaways from this class would be, firstly, the kind of documentation, which can be a product requirement documents, better known as a PRD, a technical documentation, a GTM plan, a sales enablement document, and so on. Second, we learn how to build PRDs. Like we discussed, PRD is one of the most critical documents to align everyone to be on the same page. It also gives a very clear picture of the objective, the background, the pain points due to which this feature or product came into being. It also defines your future ready strategy and the metrics that you need to look. Thirdly, core product metric, which can be your north star metrics, primary metric, secondary metrics, and so on. Last is the rollout strategy or release strategy. The key metrics again, that you need to look for while you are releasing or doing a launch of your product. In this class, along with going deep into concepts and frameworks of the s two categories, we will also do a couple of case studies so that you can embed the same in your day to day life as a product manager. This class ends with a really cool project where you get to define your Northstar metrics, your primary metrics and your secondary metrics. Nod Star metrics is the core metric that your business runs on. Primary metrics are to check whether how your change is affecting the product, whereas the secondary metrics are to ensure that the change is not affecting negatively to any other parts of your product or your company. Let's get started. See you in the first lesson. Thank you. 2. Why Documentation?: Hi, everyone. Welcome to the new lesson of why documentation. So we'll go through a couple of reasons why and how one by one. First one is abstraction of product vision and strategy into writing. So when you're creating or thinking about product vision, ideation, talking to stakeholders, there are many thoughts that come across that needs to be concised into or abstracted out in the form in the form of a written document. Written document is important to ensure that, um, whatever your thought process was now has taken a shape of very few key items that will be used by different stakeholders. A detailed form of documentation of how a product works, its features, the integration, how to use it, if it's a b2b product, how it needs to be integrated to different clients. If it's a BTC product, what aspects has been taken care of regulations that your compliance that you have, the requirements that you have, how it is expected to show up in the product and so on. Third is iteration and vergoning as your product continue to evolve, the iterations in MVP versus Version two or Version three. What are the set of features that have been introduced? New set of problems that have come up, some assumptions that you have taken to create those features. All of this is important to ensure the next set of versions and iterations that happen are intended in the right manner. GTM is another form of documentation where it's taken as a one pager to all the sales team and the marketing team to figure how the product is intended to launch in the general public. This again, becomes important because marketing and sales team will follow very different strategies and to align them or to keep themselves motivated on one single objective. This documentation serves as the right format for GTM. Another reason is focus on clarity. Like when you write something down, you write with the most intent as to something that is being said verbally. So a lot of clarity comes when you actually put or produce something in the form of documentation. And along with this comes accessibility. Since it can be shared, it can be used to take feedback from stakeholders. The feedback again, can be addressed in different formats. So it serves as an exercise where stakeholders give you feedback. It is seen by every other stakeholders, and the right intent or right amount of output can be produced with minimal time spent or minimal confusion that might come up if you were to spend one on one verbally with each of the stakeholders. The type of documentation or the use case of the documentation may vary because when you're trying to create a GTM, it is intended for a different purpose. Hence, the language needs to be slightly different. The use case and clarity of thought needs to be addressed in a more business and a sales format, versus when you are writing a PRD or something for developers, it needs to be more straightforward, more direct, and more executable. So a for example, in a PRD, you would start with an objective, but very soon you will go into the nategrities of your feature specifications, right? So in that case, you would at every point, you don't need to justify why we are doing this because you have already written down an objective. But focus will be more on nategrities. A couple of more use cases would be that it serves documentation will serve as a single source of truth and is exhaustive in nature. So any competitive benchmarking done, the summary of that comparative benchmarking. A design guidelines that were given to designers, the documentation of that will help the designs also to be more scalable. Um, so from ideology to design to engineering until the point of GTM, everything, having a clear and crisp documentation, ensures or helps stakeholders see a very clear vision of why it was started, how far we have reached, what the progress we have made, the assumptions that you have taken, and how it's going to be more scalable to, you know, wider audience or even consumers. Um, like I said, different formats for different use cases. So in the next lesson, we are going to see different use cases or different documentation that are going to help us in talking or aniging with different stakeholders. Thank you. 3. Key Product Documentation: Come to the new lesson of pre product documentation. In this lesson, we are going to go through some of the critical documents that is used company while and different stakeholders, business stakeholders, product designer, even external stakeholders. Starting with product requirements document, which was famously known as PRD, this forms one of the most benefited documents across the company as it's used by different types of stakeholders, and it outlines at a very high level all the critical information that will be needed around that product. Uh, critical information in the form of objective of launching this feature or building this feature, some background on what was missing, why we are building this feature in the first place. Impact metrics or success metrics, once we release this feature, what we intend to we intend for the success metrics to grow. Also, it features very high level view of how the feature is going to look like, either in the form of Figma or whimsical or just plain flow chart. So these flow charts or user blocks is important from an engineering point of view so that they get an understanding of where exactly the user is moving in the flow, which is important for their development. For their technical development. Now, for business stakeholders and product, it gives a very high level technical information of what it takes to build out this feature. So for a business stakeholders, since they are slightly removed from technical understanding, this gives a good overview of why this feature is going to be built in three months versus a one week. PRD therefore forms or a good PRD should be very concise to the point, as well as highlight the most important category of information that is needed to build a certain feature. Now, depending from feature to feature or product, some of the categories in a PRD can be simply omitted, or there might be need to introduce newer categories depending on the feature type. For example, if you are building payment specific feature, regulation or compliance forms or security forms an important category, which might not be needed for other types of features. A second user documentation. So this covers everything that from help guides or FCs or even manuals on how to exactly use the product, which can support both external and internal parties. Things like if I am buying a new product as an end consumer, how am I supposed to install this product or how am I supposed to configure different modules through this product? Third is technical documentation. This is primarily aimed for developers or technical stakeholders. But this is very critical because a miss here and there in this document can lead to, you know, very significant damage. The lack of, you know, posting information in this document proves or, you know, makes a space for ambiguity. So these technical documents are highly concise in nature. It need not be fully verbose in the sense it always grammatically correct, but it needs to highlight all the critical information required from an engineering standpoint, starting with how the architecture is built in this product. How is the flow of information going? Is it going from service A to B directly, in some cases, goes to C as well? Um, so this highlights, uh, this is critical for engineering stakeholders. Fourth is API documentation. API documentation differs from technical documentation in a way, where API documentation lists out all the API endpoints that is needed to configure or, you know, install your product. Um, even external parties or clients can use this API documentation. Let's say I have a product that is a B to B SAS product and a client A is trying to use this product. So technically, how one integrates this product is primarily through API endpoints. Hence this is supposed to have a good testing ground as well, and an exhaustive list of API endpoints that should be used by external parties. This documentation over times again, becomes more important as you keep adding versioning to it. So for example, one API endpoint had to be updated. So that leg of versioning also needs to be provided through APA documentation, so the scalability or extensibility on the product can be well managed. Release notes. Release notes in very proper, again, concise manner is important. A, it gives visibility to the end user on the end client of when I'm upgrading this feature, what exactly I am getting. You might have seen the same when you update your iPhone version or install your updates. That also lists a very key view of what all has changed. Fourth is onboarding, fifth is onboarding materials. This basically forms a set of tutorials, videos, recorded material, even user manuals to onboard a new user or a client to the product. Um, all the information, basic information that might be needed for a new user to start using or exploring this product is included in the tutorials. As people who are already in the company might get comfortable using the product. So in order to remove any bias from any new user, whether it's an internal company employee or an end user or client that is looking to use or explore this product. So the onboarding material will help people ramp up to a point where the information is readily or the updates can be readily consumed by them. Next is marketing material. Uh, this is, again, critical from a business or marketing point of view, because marketing folks would be slightly removed from the internal happenings around the product in the company. So most of your stakeholders like design, engineering, analytics, product that who are building this product might be aware of the latest updates or some historical context, but marketing or PR teams, they also also have to be updated on certain features that are being built. Um, so one feature might be very important in their PR activity that needs to be highlighted to them and thus document henceforth be created in a way that highlights the criticality of that feature. So for example, if there is, if you have introduced a cashback in your website. Now, that cashback as a feature might be more critical to a PR team rather than other features, let's say. Hence, the formation of this document is slightly different. Next is support documentation. Again, it's somewhat similar to user documentation, but it focuses on troubleshooting guides. So if an end customer is raising a complaint on my product is not working or some help from customer support, they need to have a defined SOP on what needs to be done for this kind of problem. So support documentation will help us, reduce the burden on call or support people and also address the customer's query in the most meaningful way possible. The last one is compliance documentation. So anything that requires a regulatory or a compliance overview on your feature, whether it's in the finance or healthcare industry, because these documents are actually a you know, given out by agencies, government agencies on the procedure or protocols that need to be followed when you are building a product in distance. Hence, it forms a different structure, primarily governed by the respective legal entities that are releasing it. But each company or each product should also view this and understand in its own form, which can be applied to the respective products. So uh, these were the different category of documentation, uh, and these are the documentation primarily either created by product people or at least reviewed by product people. Hence, it becomes for a product manager to have an understanding of different types of documentation. Thank you. 4. PRD: Hi, Jan. Welcome to the new lesson of details of PRD, how to construct a PRD. So first, we should answer the 45 WH questions. This is posted on top right. Starting with what do you want to build? So this category covers everything that includes user flow, detailed feature understanding, the positioning of that feature. For example, if you want to when you're trying to, let's say, improve conversion on your digital app product. So with that impact or with that objective in mind, what is exactly that you are building? Are you focusing on improving the conversion from page A to page B? Or are you trying to address a major drop in the funnel that happens for a certain reason? Whatever the objective is, what exactly are you building or what exactly are you going to do about it? The details would include the exact user flows. Detailed FNL conditions like if the user moves directly from A, page to page C, then what are they expected to see? Everything that forms or comes in FL condition of flow chart, which will be or might be supported with the help of designs or wire frames, that gives a detailed understanding to your engineering stakeholders, how they're supposed to execute this feature. When they're trying to execute, they need to create maybe a new database, neon messaging layer. So this needs to be detailed and exhaustive so that they can take better decisions on their architecture as well. Second is, why do you want to build it. This includes category of goals, objectives, very concise goals and objectives with also an additional information of why we are building, what is the missing gap today in the product or what is the missing um feature in the product due to which we are building this particular product. Um, it also emphasizes on introduction of some metrics that are quantifiable. For example, why we are building this, we want to improve conversion or success metrics by 5%. So it can be more quantified as well, along with the theoretical understanding that you give to the end user. Third is who is your target audience. It's important to understand the different types of user persona that are going to use your product, and also a quantified assessment of what these user personas bifurcation is. For example, if it's a right hearing app, you would expect most people with the age of 25 to 40 or 45 are using this product. And hence, your features that you built will be more aligned with that user persona. Right? And the impact metrics also should be judged in a bifurcated way. That means with this feature introduction, your user persona A is leading to the maximum conversion or maximum impact. So both in terms of identifying what the right feature and language should be, as well as the impact metric needs to be judged at a more bifurcated level, which is your target audience. When do you need it. So like I said, the above three questions gives you an understanding of what and why we are building. Now, coming to the execution timelines. So when becomes really important because there are many teams that are trying to support or do their part to build out this feature. Hence they need to be aligned when we are releasing Version one of this product and Version two of this product. Um, it helps give more clarity to your end customers and other stakeholders as well, forming a definitive timeline and the reason for those timelines. So if you say that this product or this feature is going to take two months, there has to be a justified reason of why it is two months. Hence, the timeline to PRD also becomes really important. If we divide this into multiple categories like we discussed goals and objectives, again, here the trick is, um, when you will first start to draft this PRD, you might be all over the place, right, because everything that comes to your mind, you will feel that this is really important. When you are taking a second look at it, you need to cut out or cut down those verbs points into a very clear crisp bullet points. So the trick is that stick to the must have, remove the good halves or put the good halves in the second version or some sort of summarized version, but important to stick to must have to give a crips understanding to all your stakeholders that this is what exactly we are. If you go too much into including good to have features as well, it dilutes the whole purpose, and it may seem like you're building anything in a grid, user persona and target users. Again, a more detailed version on your target audience would be challenges, interests, background that is supported or, you know, documented in a way that highlights why this particular user persona is a separate category. Uh, you can also highlight business related details in the form of that category A or user persona A is more inclined to or has most spending propensity, right? It can be more revenue or business related that way as well. So you'll have to figure depending on your product and the stage of your product, who are your primary user personas are and why. Uh, user stories. Like I said, these are basically user flows, which is molded in a fashion where it highlights your customer needs as well. So every time you will hear terms of being more consumer empathetic or user centric, because it is a product manager job to cater to the right set of features, that understands that includes end users, uh, you know, empathy or understanding. So, uh, it is important, again, to keep it short and to the point. But when you are building this, you will get to know the fact that, if I introduce Cashback here, this is the delight that my customer is going to see. So it's also for sure, cashback is also coming from a business point of view. But when you are building user stories of flows, you should always keep a user centric view in mind. So you understand where exactly this should be positioned, what should be the color scheme of this. At what point in the journey would the user likely to pay more heat to Cashback being introduced. If you introduce write away on the top, this might not be the best strategy if they have, let's say, DTC commerce website, they have added products to the card. If you keep changing cashback amount when the product or the card price is increased, it might have a more profound impact on the end user. So when you truly think about user empathy or from a user's point of view, you will get to understand how to tweak around the same feature. Both a technical design and specs. Again, wireframes, Figma, dependencies on different services on different teams. So if you are, let's say in the payments team and you're trying to introduce a new cashback module, you might have a dependency on your, you know, the CRT team, let's say, or the catalog team to give you the entire product value. You might have a dependency on compliance team that helps you figure what maximum discount that can be put on each product. So these dependencies have to be highlighted, reviewed and approved by the dependent stakeholders. So they also include those tasks in their roadmap. Metrics, success metrics like we already discussed and release criteria. Release criteria is basically what is your rollout strategy going to be? Are you going to roll out to all the users? Is it a beta release? Is it catered to only 1% or 5% of the users? And once you release this, what is the expected metrics that you intend to see? Post that, which you will do 100% rollout. That is the meaning of release criteria, which can happen in phases. Post release retrospect. So it caters to all the learnings that you will get in terms of whether is there any tweak that you need to make in user stories or user journeys? Impacted or the impact metrics or the success metrics, are they in line with what you had expected? And it will also give you a clear idea of how your next versioning should look like, based on the learnings or the feedback that you have gotten after your first release. FAQs are basically in some basic but important questions written out in a Q&A form. It can be very direct questions like, how should I search for cashback in my product? Or how do I know if my product is eligible for a cashback? So the question can be very straightforward like that, but in your answer, you want to include a very detailed and a formal structure to your answer. For example, when the question is such rudimentary like this, in their response, you would want to write, um, that for products such and such, the eligible cashback is this, for second category, it is that, so you need to be exhaustive with your answer. Uh, the only reason it is put in a QNA form, it is better, more relatable to the end user because that's a question that is coming to their mind. If everything is put in a structured form, it might be too much information in the PRD. Hence, it's put in the Q&A form. These were the basic categories. Again, depending on your feature release, there can be more. You can choose to omit a few, but a well done PRD would include, most of these categories. Thank you. 5. Rollout strategies: Hi, Ron. Welcome to the new lesson of release strategies or roll out strategies. As as we discussed different products depending on their use case, market conditions, business goals, end user personas, follow different release strategies. So in this lesson, we are going to discuss some of them with a few examples as well. Starting with full scale launch, when you follow this strategy, this is basically releasing your product to the entire market all at once. This is primarily followed by well established physical brands where consistency is really important for all the users at once. So for example, if you have, let's say, change the composition of your product or let's say if you're building a burger or you have a beverage as your product, then the composition needs to be changed for every geography all at once because inconsistency in customer experience that my kola tastes differently from here versus there can lead to significant questions or repercussions for that brand. Second is phased rollouts. In this sort of strategy, follow we select customer segments and introduce or release product in stages. So this is done to gather feedback and allow for it to be a testing environment as well before you do a wider range. So for example, if your product is a digital app, you might want to, let's say, uh release it only to power users or 5% of the users. So you can actually test, whether this release is technically working fine or is working as expected and also to gather feedback, imaged feedback or high impact feedback, do iterations, and then do a wider launch. Third is pirate launch. This is basically not a full product launch. It is to conduct a trial in a very limited area to check for sometimes for ideation or sometimes for performance or, in general, gather more user insights. So one such example could be like how Bumble or dating apps were launched. So those trials were conducted in colleges or universities where it was a good testing ground for power users, where the product was not released in its whole capacity, but primarily to see whether it was peak interest of the users and if yes, what is the insight or the direct most impactful areas that the product manager needs to look into when they're thinking of such an audit. Four is soft launch. Now, soft launch is not very different from a full scale launch, but it helps to gather insights again and test out before you do a complete PR of the launch. For example, if you are already a well established company, you're introducing a new product line at scale. You expect, again, the scale of users using your product to be very big because you have a brand name. Hence, a phased out release might not be the best strategy because you would expect the growth of users on your product to be really high. You might not get enough time to do iterations. Hence, a soft launch where you are not doing a general release of the product, but just people who are aware of this release are using this product intensively, so you can maximize on your improvements. If this Beta testing. Again, it's similar to pirate launch, but in this case, you are intending to release the product that you have built, already built, but after a few tests or round of testing is done. This differs from pirate launch in a way, pirate launch is primarily in the ideation stage versus a beta testing is where you have already built out the product, but you are testing it out slowly. Beta release also differs in a way that it has not taken care of all the thinness of the product, but has covered most of the important functionalities that you want to test out, right? So for example, the UI layout might not be the best. There might be some sparkles missing in your product, but functionally, you want to test it. Geographical rollout, it's basically when you are a global company, your product might require different tweaks in each geography. It could be language, it could be a little bit of change in user flows as well. It could be how different the regulations and compliances are. So depending on all these reasons, you want to do a phased out geographical rollout because even the products are slightly different. Segmented rollout. Again, it is a variation of phased rollout, but it is more granular or more nuanced than that because now you are focusing on different bells and frills around a certain demographics or certain user categories. So if you see more if you identify a user persona or target audience with higher propensity to pay, you would have to tailor some of your features according to that. So segmented rollout would mean that some of your features are slightly different, as well as it's released in different stages to different user personas. Channel based release can be thought of in a way where let's say you have DDC brand and you market on Instagram, Facebook, and a couple of other social media, and you have introduced a new feature and you want to do PR. So you want to start with one of the channels first, get feedback and then distribute to other channels or even the physical or offline channels. Last is seasonal rollout. Again, it's seasonal rollout is basically when you are releasing some features or some campaigns or launches that are applicable only to that season. It could be like a Christmas season end of year sales, big billion day. So this is to maximize your visibility. This is for business point of view, it is done for different reasons. So if you have a lot of stock building, you want to remove the stock, you would want to then conduct one seasonal release or one seasonal campaign. There might be other reasons to do so. But here, seasonal rollout is important because it's not going to stay permanent in your product launch. So if a season like Christmas, comes. You want to introduce a new sort of layout. You want to fluctuate pricing a little bit more. You want to put a deadline of purchase for some items. And these items or these features have to be controlled by a feature flag because like I said, it's temporary in nature. Hence, a different Rise strategy technically also needs to be built before you can follow, you know, execution of this strategy. So these were a couple of release strategies depending on the nature of your product and your business goals. You have to choose this wisely and make time to instrument the release as well, okay? 6. Metrics: Relevance: Welcome to the new lesson of metrics. So in this lesson, we are going to cover different types of metrics, not just Northstar performance metrics, but also analytics from an analytics point of view that can help you decide what features to be wed, how to prioritize features, how to make your work or launches being conveyed to different stakeholders. So anything and everything that requires at the bottom of it the relevance or relevance of metrics, we are going to discuss that, starting with performance metrics. So a these are basically Northstar metrics which will be looked month over month or quarter over quarter by business stakeholders. And any product development that you do has to lead to improvement in these performance or Northstar metrics. So some of the examples can be, let's say, if it's a ride hearing app, then it means number of rides that are getting booed. Number of rides started getting booed is directly correlated to the revenue that you will generate. Now even within this North Star metric, you can have certain categories, number of rides that are booked in the premium category in the normal category or in the economy category and so on. Other such examples would be, let's say, again on a dating website, number of users have registered on your app, or number of paid users on your app. So depending on your business goal or the positioning of your product, the performance metrics might vary in nature. Uh, it is critical to have uh, only two or three nostr metrics so that you are not swayed by improving, you know, the good to have or, you know, granular metrics. But everything you do has to lead to improvement into two or three such nordstr metrics, which should not be very detailed image. Second, there is metrics to identify opportunities and challenges. So things like let's say you get customer you start getting more customer complaints, right? So you have to analyze how many complaints are there, what is the nature of those complaints to figure what can be done to address those complaints. Do you if this, um if these complaints are rudimentary in nature, do you want to introduce a chatbot so that most frequently asked questions can be addressed? Or these are highly complex in nature or does it cater to just one single problem? Then you might want to build a feature to improve that status. So the assessment of just the gravity of the problems raised by different stakeholders needs to be looked from a quantifiable or quantified lens as well in order to identify and truly justify the opportunity or the challenge that you are getting. Third is feature prioritization. So let's say you have numerous problems listed. How do you figure which is the most important or the critical problem to solve. Now one of the ways is to look at those numbers in the metric form. Again, if let's say the problem is in your entire funnel, uh, the users are dropping off when they lead to the land onto the payments page, right? Now, the features that are the supporting features to improve that should be prioritized because this is the biggest gap in your product. Now, apart from the metrics, there are some anecdotal evidence. There needs to be a strategy, a brand strategy as well as to why will you prioritize those features. But important thing here is that, uh since you have a lot of problems or a plethora problems, how to prioritize one problem over the other, which is to say that, if I address this problem, this is the significant potential impact in my North Star matrix I can expect. And so it becomes easy to prioritize and justify to your stakeholders as well and ensuring that you are moving in the right direction. Fourth is testing and experimentation. This is more of a metrics analysis or analytics done through AB experimentation. So for example, if let's say you are increasing the price of your product. Let's say you have a subscription app or subscription newsletter, which cost 2000 rupees or $20 a year, and you are trying to increase it to $22. Now, uh, because of this increase, you can expect some potential backlash where people might not be okay with this much increase. But so you have to do an AB testing. What is your right price point B? In order to validate your hypothesis now $23 or $22 work for me without leading to a significant temporary or permanent impact in terms of users dropping off their membership. So in this particular example, you might want to look at 23 metrics from a long term and a short term point of view. It may so happen that on a temporary basis, some users will definitely drop off. But in the long term, if it's leading to, you know, increase in revenue by a substantial amount, then it might feel like a better strategy to cope with the increased pricing. User insights. Again, these are granular metrics built under your performance Northstar metrics. That helps you gauge the impact of each feature release in the most direct manner. For example, if you introduce, let's say, support, a chatbot support, then your NPS or your customer satisfaction score should increase. Now, increase in customer satisfaction score might not lead to direct increase in your Northstar metric. Hence, granular understanding of user insights is really important. Another example would be, let's say, a number of rides getting booked on your Ride hailing app. Now, if you have let's say retention rates as well, any customer who is booking a ride on day zero, are they still booking rides on day 30 or day 16. So that'll help you gauge the lifetime value that a customer can provide through these matrices, which might not be directly visible in your Northstar metrics. Uh, metrics tendon competitive analysis. So the trends that are going outside in the market, things like, for example, let's say there is a new social media app. That's coming. Would you want to build a strategy to advertise on that channel as well? Or you see that most people are now, you know, started to use or started to, you know, use more secured products. They're afraid of fraudsters or scamsters, right? So this is a trend that you analyze, and you see what can be done to your product to address the same problem that you're seeing, you, you know, in the outside so the impact or the learning that you can take out of here is introducing more trust factors in your app, ensuring it is more secure, it's more compliant, as well as convey the same to the end user, and they feel more secure within your application, which can be a distinguisher or differentiator from other competitors in your space. Lastly, communication with stakeholders. Now, since you as a product manager, work on your product day in and day out, hence, you are aware of all the product not star metrics and even granular metrics. But other product or team members or other stakeholders, other product managers might not be as into or inside of your product as you are. And hence, a visibility of how well your product is doing needs to be given to stakeholders in the form of, again, a few metrics. It can be a combination of your North Star metric plus your user and site matrix and again, the testing, small testing that you are doing. But it is basically all the metrics important ones that are needed to be viewed within the company, so that A, you can get, um, you know, feedback. You can convey how the progress is being made, as well as some stakeholders that have a vested interest in aligning with your metrics, it is important for them as well. So a classic case is when you have teams like a growth team and a risk team within your company. Growth teams objective is to increase the number of users. Risk team objectives is to while they focus on growth, but it should not come at the expense of rods that are being made. So hence, a delicate balance between these metrics are needed, which is taken care of by different product managers. And so important to convey in the very technically sound metrics so that this balance does not go So these were a typical set of matrices and this might help in more than one way, both in terms of assessing how your product is doing, as well as through analytics, what your product needs to do better for your own internal anomics. Thank you. 7. Product Metrics: Hi, everyone. Welcome to the De lesson of metrics. In this lesson, we are going to discuss different types of metrics, covering business metrics, support metrics, technical metrics, and in general product metrics. We'll also discuss different examples which industry or which product each metrics might be most relevant to. Starting with usage metrics like DAU, which is daily active users or monthly active users or session durations. So this type of metrics is important for apps or products like social media where just the users coming to the app or keep coming. When they keep coming to the app, it is an important metric by virtue of their business model. Let's say if you open Instagram, you would be counted as one of the day day active users. Now, since the business or the revenue model is primarily, let's say ads based or ecommerce shopping base, this increases the propensity of you viewing an ad once you are active on that platform. Same is for session duration. So if you are on that session for 10 minutes, 15 minutes, the more ads views, the businesses will get out of that customer. And hence, daily active users or a DAU becomes important for these type of platforms. This also indicates roughly what is your market share within this ecosystem. So let's say if you are a payments company and there are three or four players in your industry. Monthly active users will also indicate what is your market share within that industry for your platform. Second is engagement metrics. Metrics like retention rate. That means if I am on your platform on day zero, the same user is on your platform day 15 and day 30, what is the retention rate looking like? What is the churn rate? That means the same set of users in one month, let's say, there were 200 million users active in one month. And if you take the same set of 200 users out of that many, how many have churned. There might be some increase in new users, and there might be a dip from the existing set of users. So churn rate is also really important to gauge how much growth you need to make in terms of acquiring new users and ensuring that the users who have come onto your platform do not leave the platform, right? Churn rate is also important because it takes a lot for the user to actually start using your product in the first place. So as long as they are in the product, you can do changes or you can entice user to stay on your product. Uh, hence, tone rate, apart from new user grade growth becomes important. Third type is customer satisfaction. So there are very creative ways to measure customer satisfaction. Typical famously known metrics are NPS or CSAT, which gauges the NPS metric gauges, what percentage of your users are likely to promote your product to their friends and family or acquaintances. So this gives an understanding how when you really love that product, you want to talk about Okay. So it gives you an indirect measure of how satisfied your customers are. CSAT is measured either in the survey form. That means, hey, I am using you are the customer of my product. How do you like your product? Rate my product, right? So this is a CSAT score. The idea is to ensure that it's improving in the right direction, and also it has a respected CSAT score. So let's say many users are coming onto your platform and they are not at all satisfied. That makes a case to benefit or invest more time in improving the quality of the product. Four type is market fit. Again, there are very creative ways to measure it. But if you are in the zero to one stage where you are finding PMF of your product, which means you are finding whatever you intended the product for, are the customers happy to use that product where you have found the minimal viable proposition of the for. So again, there are creative ways to measure it, but the idea is that if you are into the zero to one stage or how far you are from reaching to that stage where you can call your product as a market. Conversion is another very important type of metrics because it's highly correlated to business metrics as well. Conversion rates are very straightforward to understand and measure and highly critical to monitor. So a typical example would be, let's say for a ride hailing app, the conversion rate would be number of users who are landing on your the first page of ride booking to actually completing the payment or actually ended up booking the. So there is a whole three, five step process to it. Conversion rate would mean how many of those user did end up booking a. And funnel analysis would mean where exactly the user is dropping off from which point in the journey, exactly. Another type is business metrics. Business metrics are very straightforward. How much revenue is coming off all the customers who are using your product. Uh, top line revenue, again, revenue can be thought of in very different ways. The top line numbers that you make, that means, let's say, for your paid subscription of your newsletter, 100 users are paying 2000 tropees or $20 per year. That is your top line number. But after you deduct everything, which is the infra cost, people cost, creative costs and everything, what is the hand net revenue that is coming into your books? Again, revenue has different stages to be measured. Uh, average revenue per user. In this case, what is the average revenue that each user is bringing? Average is important here because there can be different tier of subscription prices or subscription plans. And hence, average is important. So if let's say you have three different pricing, $20, $30.40, and majority of the users lie in the $30 bracket, the average will read closer to a $30. Customer lifetime value means that if the same user keep renewing your product over years, then that is the customer lifetime value or an average customer lifetime value that once you acquire this customer for good, in its entirety, how much revenue they can bring. Another is acquison again, really important in terms of business or your PNL, which is cost per acquisition. So since there is plethora of platforms or apps for every type of problem or industry, and hence, acquiring user for your use case to your platform is tremendously difficult. So let's say you have three different ride hailing apps in your country, then a person might be using just the two. The third player has to really spend a good bucks to acquire your acquire the customer. Hence, it becomes important. Now, traffic sources, again, these are various acquisition strategies that you can follow in order to acquire this customer. You can convince the customer to use your app through an Instagram channel through, you know, different brand strategy, PR activities, and so on. Another is operational metrics. These are the end customers technical satisfaction metrics. That means if you are using a payments app, or are the payments going 100% of the times? This qualifies for a system performance. That means of the hundred times that you are trying to make a payment, how many of them are going through. Second category is support tickets. If there's something wrong in the app or the platform, how well are you able to take care of the customer through the means of support channels, whether it's a chatbot or exactly an end human user catering to that request. So last one is retention, which is a cohort analysis, which is basically a derived version of conversion metrics, but in a cohort sort of form. So cohort in this case would mean that a particular target audience or a particular type of cohort, how is the performance measuring against them? So these were the typical Northstar or various category of metrics that can help gauge A, the kind of features that you would want to build, the health and the progress of your product, and even the future, long term plans with your product. Okay.