 Hello everyone, this is Neerau Patel to introduce myself. I have over 20 years experience working with software products, started my career as a part of the technical team, and then gradually I moved into product management world. I have also experienced working with enterprise services team and implementing products like ERPs and CRM for enterprise customers. So thank you for joining today's session. We will be talking about number of product success metrics and the parameters impacting those product success metrics, but yes, we will be touching those parameters which are uncommon ones, not the regular ones that generally we can think of. So a number of these metrics and the parameters that I will talk about today are based on my past experience working with one or two of the products. So let's start what we are going to talk about. To start with, the first one is velocity. It's more about team's performance, how as a team we are performing. The another one is volume. It is more about how the product is used and how it is getting adapted in the market and the progress and the kind of consumption it is bringing. The third one is related to NPS and CSET, promoter score as well as customer satisfaction. It's all about customer health as you know. The another metrics that we will talk about is the cost that indicates the financial health of the project or the product. And the final, the one more is defects. It's all about product quality, as you can see. So let's get into product velocity, the first metric that we are going to talk about. To start with, the first parameter that I will talk about is interdependency. We all know how to kind of prioritize the backlog for product sprint, right? Generally, we all talk about either the value or impact and then we use the estimation parameters. But that is not sufficient, I would say. It is very important that how do you bundle the stories for particular sprint. If the stories are interrelated and associated for a particular role, persona, workflow, then the possibility of turning them around quickly is much higher because people will be focused upon similar functionality and developing them, testing them for the team would be much more easier and faster. So keep this in mind next time when you work upon it. The second parameter is involvement. How is your team involved with you in the backlog grooming as well as developing the understanding of the product? One of the important parameters. So what I would like to say is that does your team properly understand the product roadmap, release plan, upcoming features, etc. Do they have sufficient knowledge to say that yes, this story is ready for sprint in the sprint planning meeting or do you or the team leads are able to identify the need for skill upgrade, knowledge transitions or cross training needs before even sprint starts. These are some of the important parameters. If not handy, it can impact your velocity. One more item is right use of spike. I think you should be aware of spike what it is. If it is not, it's the kind of name that we use for the stories which are not clear and we need to do some research before starting working upon sprint. On an ongoing basis, we come across some stories that requires a lot of extensive analysis as well as system design before we can mark it ready for sprint. Now if we include this kind of work in the sprint, obviously stories cannot be completed. So as a product manager work towards identifying this kind of stories that require spikes much earlier. And then if the story needs to be worked upon in next sprint, you include the spike in current sprint and assign it to someone. What that means is individual can take a jumpstart and do the groundwork before that story is picked up in the next sprint. The next parameter is skills. And yes, this is not the technical skill. It is functional skill. How skilled your team is around the business functionality of the product. There are products which are focused on banking, finance, pharmaceuticals, or medical, or insurance, or retail. This kind of products require a lot of functional knowledge in terms of workflows, user journeys, personas, roles, access. And many times we hire developers based on their technical strengths and they fail to turn around these products faster. Why? Because they do not have sufficient functional knowledge. So this is one of the important parameter to take care of. Another part is testing. And I will talk about two part of the testing. One part is that automation. Yes, you all know automation. So try to derive those items that requires ongoing recurring testing sprint after sprint, release after release, build after build. Try to identify them upfront and plan for automation upfront so that your team do not end up spending the same effort again and again in the manual testing. The second part is that see if your team is unnecessarily spending effort in every sprint to taste something which is not touched directly in that particular sprint, this can save some amount of effort for you and that can help you to increase the velocity. One more parameter is expectations. How is the expectation set up with your team in terms of what you are targeting to deliver? Many times this is very important parameter to consider. Why? Because as a product manager, you may want to go faster to market. You may want to go with the dirty code. You might want to fail faster. You may not be targeting perfection but it is not clear to team and they may be targeting zero debt or the perfection. So ensure that you have right level of sync and expectation setup with your team in terms of what you want to deliver and that is understood very clearly. Another parameter is if your product is not stable enough or do not end up spending a lot of time on taste automation as well as DevOps kind of activities because many times this keeps on changing with the changing product and you end up spending unnecessarily a lot of effort behind this kind of activities. So let's move to next. On the next slide, we will be talking about volume and adepts and related parameters. What is that? So let's start with parameters that impacts your volume. I would start with alignment. How is your alignment or your products alignment with your company's goal strategy as well as your sales and marketing priorities? Why this is important? Because unless your product and your goals are not rightly aligned with your company and sales marketing, they may end up talking about something else. Why? Because their goal and your goals are different. Sales and marketing might be getting incentives on something else plus what they are selling might be different from what you want to sell. So please derive right level of alignment as much as possible. Another part is communication. Is everyone very clear about the purpose and goal of your product? And when I say everyone, its sales marketing is your leaders, yourself, your training and documentation team, your product, landing pages, social media, everything that talks about your product, conferences that you attend, because there are times when the core goal or objective of the product is not clearly conveyed. And so that customer do not know what you're offering. So make it very clear again and again, repetitive mode. The next point is MVP. What is it? So if you're launching new product or if it is already launched and volume is not coming up, check whether all the critical, most important functionality is included in the core product or not. If it is not, it's missing some core areas, so please plan to develop it. If it is already there, check whether those are working properly or not. If there are quality problems, if there are defects in the backlog for your core areas, obviously your volume will not pick up because core functionality is not working. So take care of them. Instead of developing new features, I would say fix the core defects first because it will help you. Another point is attention. So keep sufficient focus on your key accounts users as well as your net promoters. Try to understand their pain areas. See what extra they are asking. What is core to their day-to-day work which you do not have or which you do not have prioritized yet. Try to prioritize them and include it. Possibly that will help you to bring in more volume quickly from your large or enterprise-grade customers. And another parameter is keep understanding of market trends and consumer needs. This keeps on changing. You need to keep your roadmap and your direction aligned to this. Keep on changing. Why? Because due to COVID situations, international border issues or say political environments, travel restrictions, security requirements, things change and you have to keep it changing. So I will get into two detail points here. One is specific to volume. So if you are struggling with volume, you may need to get into little more detail in terms of where exactly the volume not coming. Is it a first-time user issue or users visit your page but don't start the transaction or user drop in the middle of the workflows or user went further but they don't complete the transaction. Each might have different symptoms that you might have to address as a part of the product manager work. So if it is low first-time users, you might have to check marketing sales incentives, alignment, social media reach, etc. If users are not starting the transaction after landing your page, it might be that you have complex look, menu, submenu, tabs, etc. Your goal is not clearly explained. If users are dropping in between the workflows, possibly it could be the data validation or browser issues. Sometimes the workflows are complex enough and then if users go up to almost end but come out before completing transactions and it's a different problem such as validation surprises at the end, some runtime errors or maybe the discount code or referral codes did not work. So check them. Fixing them can help you fixing your volume issues quickly. Many times on enterprise customers, you may want to check something different, some onboarding challenges. When I say onboarding, that means some data transition challenges or problems in configuration of the roles and permissions. At times, some primary scenarios are not working. Why? Because the parameters are not rightly configured or some open defects are there. Testing is not properly completed. There might be training or change management issues with your enterprise customers that you need to resolve with the help of the professional services team, obviously. And then at times it is just that it's not ready for production. Why? Because some integrations for your enterprise customers are not working or master data or profiles are not configured well. So they cannot work. So help your professional services team to get them fixed and that will bring you good volume. I'm pretty sure about it. Yeah, let's go next. So on this page, we will talk about the defects in flow. There are situations when you come across a lot of high inflow of the issues or problem, right? So how do you start tackling this kind of situations? My approach is little different here compared to everyone else. So when you have a large inflow, start analyzing whether this is an issue or a defect. When I say what I mean by issue and what I mean by defect, when I say issues, issues are something that does not require co-changes to fix the problem, right? No developments are needed most of the time. And based on my past 20 plus years of experience, I can confidently say that about 70% of reported problems are issues, not a defect. Okay. So basically, you checked and you found out that it is an issue. So what do you do to fix the issues? There are a couple of things. For example, it could be a wrong role or permission. It's just a training issue. Maybe product is incorrectly used. Just guide your users. Maybe the expectations are not rightly set up for the product. So guide them. It might be user experience issue. Provide some documentation. Or maybe some configuration is not correctly done. So fix the parameters, right? With this kind of quick changes, you can fix about 70 to 80% of your problems most of the times without co-changes. Yeah. Now, what if it is a technical defect? When it is a technical defect, it can be bundled in two different problems, right? Sorry. So when it is a defect, you can bundle it into two different kind of problems. One is the technical defect. One is the non-technical defect. So let's see how we address the technical or non-technical defects. And I'm going on next page. When you come across the technical defects, I still feel that this is comparatively easier to fix because when those are technical defects, it can be validation or boundary condition issues, security performance issues, maybe runtime errors, et cetera, right? So many of them can be fixed with some firewall configurations at times, enhancing the infrastructure or maybe some quick code changes. In a longer run, you may want to answer that you have right level of usage for tools, automation, DevOps, or right level of infrastructure, right? You may also want to introduce right level of testing. Or at times it might be the skill upgrade issue for your technical team. But all of this is comparatively easier to fix when you compare it to non-technical defects. So what are non-technical defects? Let's look at them. Many of these are related to functional areas. Now what are those? So these are the defects that require to develop better understanding of user journeys, scenarios, roles, and permissions. Maybe your team is not using right configurations and data to test the right practical user scenarios. It might be the case that because of the lack of the knowledge of domain, right level of testing is missing at story level, feature level, integration level, maybe regression level or end-to-end business scenarios as well. How can you fix this? Well, it's not a straightforward answer. For immediate needs, you will have to support them really heavily. But in a longer run, you need to build the right level of domain knowledge for your team. That's the only fix. Difficult one, long term, but yes, you have to build the skills in the team and it will take time. Apart from that, a quick thing could be that you quickly introduce subject matter expert on that domain from outside. Maybe this person will be a very quick help in the team to test and write down some of the basic scenarios and guiding your team. So moving to next, in this slide, we will talk about the NPS and customer satisfaction. What are the parameters that can impact your customer satisfaction and promoter scores? I always talk about transparency, a very important parameter everywhere and specifically for your customers. Always ensure that you bring in good transparency with your customers. Give them clarity on your vision, your roadmap, or how you are planning your future releases. On top of that, set up right expectations in terms of what your product is planning to support in terms of NFRs as well as what upcoming features are. Be clear about it. Be transparent about it, even if those are going to be delayed. That will help you to bring in more transparency. The second part is trust. How do you develop trust with your customer and develop healthy relationship? Well, there are a couple of things you can obviously try. No last moment surprises. No one likes and specifically your customers never do. Ensure that any issues that is coming up or it is there, they hear from you first, not from someone else. On top of that, it's not just about making money, right? Or share some tips and guidance in terms of how they can reduce the infrastructure or consumption cost. So when you share this kind of tips with your customer, obviously it helps you to develop the trust. What else? Do you empathize on their problems? Do you care about them? You really have to. You know what? Many times your customers might go through some critical situations, severity one problems, and we just leave it to our support teams to fix them, right? So what that means to you as a core product team or product manager? Well, it's your problem too. Please try to understand this kind of critical situations for your key customers, your enterprise large customers, and try to help them out. If you can't fix the problem quickly, at least ensure that right level of workaround is identified and it is proposed. It is your responsibility to ensure that your customers come out of their critical situations as early as possible. Otherwise, it is definitely going to impact your NPS and CSAT. Another part is protect. Protect your customers from compliance and data issues. It is always our job. Always build the mindset that you have to protect your customer data and reflect it in your ongoing conversations again and again. Ensure that they understand what you are intending to do, right? Just doing it not enough. Ensure that you explain it again and again to your stakeholders, to your customers. Proactively identify some of the issues loophole in the system, some upcoming issues proactively, and then ensure that you inform it to your customer along with some guidance in terms of how they can mitigate it if they cannot completely fix them. This is important one. Another one is how you give consistent common experience to your customers across the channels during supporting them. So what that means is nowadays we use different mediums like emails, chat, mobile, web, social, right? And we capture a lot of details and ensure that how you capture the details across different medium and use it across the channels consistently so that when your customers speak to you, talk to you via different channels, you give them consistent experience because otherwise they will quickly get fed up, frustrated and indicate that I have already shared that detail why you don't have it. So ensure that you have consistent experience building for your product. Yeah, I think if you take care of these parameters, definitely your NPSC site would go higher from where it is. Moving to next one, on this one, I'll talk about the cost. So what are the parameters that can impact your cost? So one of the area is infrastructure and cloud. So here I'm talking about this parameter later differently in terms of how you can bring down your infrastructure cost. So basically, how many environments you have currently and do you really need all of them? Can you bring down the configuration of some of your environments currently and bring down the cost? Do you really use or does your team really use all of the environments and services 24 by 7? If not, can you stop them for part of the time? Or can you shut down some of your environments that will significantly bring down your cost? And believe me, I tried that and I could bring down 30 to 40% environmental cost, ongoing cost month after month. Team mix, important one. So many times we don't realize that do we really need all the senior members in the team who are really expensive? Well, there may be time when introduction of one subject matter expert from functional standpoint can help you to bring down cost. Why? Because you will not need all the seniors. You need strong developers, but not all the senior people. At times you just need the functional knowledge in the team. So think creatively. Do you need full-time scrum master? Maybe one of the team members can play that role. When your product is in the early stages, do you really need separate L2, L3 support teams? Or do you need separate professional services team? Can you still continue with the same scrum team and do all of that until you reach particular stage when you have good revenue channels? So try this. One more is how is your privatization? Do you want to build everything now? Well, may not be. It is okay to not build the administrative module or configuration module right now. What if you do not have some of the features on day one? That is okay. You can go with some dirty code as well. It is okay to configure some of the data and parameters from backend. Well, you can hire some cheaper support member who can manually configure something for your customers, right? You don't need to automate everything right now. So obviously these parameters will help you to reduce some of the cost. People focus. Now this is a tricky one, right? So I always vouch for high moral and least attrition in the team. You would think that how that can help you to control the cost? Well, it does. High moral of the team boosts the productivity significantly in your team and it definitely does. When you have low attrition in your team, it helps you to retain the knowledge in the team, right? And when you have low retention, it improves the efficiency in the team. Why? Because they do some of the repetitive work, right? They are in the performing stage and they know each other very well. All of these factors help you to do the work faster, reducing the cost. Another part is don't reinvent. Your company might have many other products and many times the core framework components remain same for logging or for, say, security or for, say, configuration roles, permissions or something else. See what all parameters or framework parameters, validation parameters you can copy, paste and reuse. Please try to bring this in because it will help you and your team to save good amount of effort and cost both. One more is don't overbuild NFRs, the important one. Many times as a product manager, we want to build in everything. Perfect. It should perform very well. It should handle maximum amount of load, right? And it should have all the security features. It should have 10, 15 kinds of different roles and configured. Well, don't go for luxury. Don't go for everything. Clearly find out what you need to build, what is really required, document it very clearly, objectively and hand it over to your team. Don't go for everything. Go for only what is required for your product and it will help you to save some cost for CR. Yeah. So that was it for today's call. It was nice talking to all of you. Thank you very much for hearing me. And if you have any questions, if you want to reach out to me, here is my email, my LinkedIn and my page as well. So thank you very much again for attending this session and it has been pleasure talking to you guys. Thank you and have a great day. Bye-bye.