 Okay. All right. Hello, everyone. So excited to be here and talk about the feature prioritization. My name is Anul and just a little bit of an intro about myself. I'm currently a senior product manager at Amazon and I have been in the product management space for about nine years now. I have worked on different projects, launched a lot of different products, a lot of consumer-facing products. Prior to Amazon, I was working at TD Bank where I was leading the development of some of the primary features in the online banking as well as the mobile banking app space. So yeah, that's a little bit about me and let's jump into the topic for today. So today's topic is feature prioritization. Now, one of the most challenging aspects of product management is essentially prioritization. So imagine the scenario, you have got a list of un-prioritized features and tasks displayed out in front of you, right? And your engineers are telling you that feature A would be really cool and it will take you to the next level. But some of the stakeholders, they essentially mentioned that no, feature B should be included in Veeven. And your data analytics team, they might be convinced that feature B is not really necessary and the users are crying out for feature C. So how do you manage all these different kind of situations? So this is what a feature prioritization is essentially. So in reality, product managers rarely have enough resources to achieve everything on their to-do list essentially. So think of feature prioritization, like it's like the art or art in size of deciding what's important to do now and what can wait until later and something we balance with cost and benefit. Essentially, think of it as resources required to build something versus potential reward associated with it. Now, what are some of the benefits of feature prioritization? So why the question arises why should you start prioritizing now, right? So the benefits again are endless, but some of the things which you know, where we can get started is by prioritizing, you can essentially improve the productivity. So you're basically reducing your own as well as your team's stress levels and simultaneously increasing the productivity of your team. The heightened focus is what matters the most and it essentially gives you flexibility for other features as well. It allows you to allocate sufficient time to complete a lot of different tasks and it also gives you some of those necessary adjustments to leave the wiggle room for any errors. You have that opportunity to, it basically gives you a little bit of a breathing room and ability to think straight. So when you are basically able to clear your head, recharge your brain, you are able to bring your A game and it also keeps you motivated so that you can notice results quicker than if you do not prioritize. So some of the, I guess, questions around prioritization comes, okay, which frameworks do we need to use? What is the right particular, what is the right framework for the prioritizations? And there are a lot of frameworks that have been developed. But the important thing is it doesn't matter which framework you use. The right prioritization framework essentially helps you answer some of these questions like, are we working on the highest business value item? Are we delivering the right value to the customers? Does our work contribute to broader business objectives or business goals? And can we get this product to the market? Or if the product is already in the market, if we are building a new enhancement, is this really helping our customers? So these are a few, I would say things to think about before going to the frameworks. And today we are going to discuss some of the frameworks that we use, primarily the Moscow method, KNO model and the value versus complexity quadrant. Just to recap off what I sort of discussed already, some of the things to consider before writing some of the features are essentially the level of effort. Think of it as like how difficult a particular feature would be to build. The customer value, how satisfied your customers are going to be. And from the business value perspective, essentially how much it would help our business in terms of the dollar value. Now the next part comes is determining the level of effort. So again, the level of effort in various organizations, different techniques are being used. But one of the most common techniques I would say is around the T-shirt sizing those estimates. So this is very, very widely used in the industry and essentially when any project is being sort of it's in the planning phase. You get these estimates from different teams, maybe the engineering team or maybe the stakeholders. You do some analysis on your own and determine how difficult this project would be or how much effort this project would take to launch. And then you can categorize it as like as extra small, small, medium, large or extra large. So these would have certain values associated with it. So for example, extra small can be something, the cost can be less than $250,000. Small is somewhere between $250,000 to $500,000 and so forth. And these are again very, very organization-specific things. So I would in want to define some of these metrics for you, but some of the standard practices that are being followed just hoping to discuss that over here. The next one, which is not as widely used but is still being used in a lot of places is like Babel, Rock and Boulder methodology. So it sort of follows a similar analogy, a very simple project or relatively small effort project would be considered as Babel. A medium project is think of it like as a rock and a very complex project could be considered as a border. Next, we go into the Moscow method. So this is one of the most widely used frameworks in product management. It is also known as the Moscow prioritization technique or Moscow analysis. Very commonly used in the agile principle, sorry agile product management techniques to understand what's important and what's not. It is a very useful tool for communicating to stakeholders in terms of what you're working on, why you're working on and the name essentially is an acronym of four prioritization categories, which is must have, which is MO stands for must have, should have, could have and won't have. Now, let's take a little bit of a closer look in terms of what these categories mean. So first is must have must have essentially means or it represents the features that are essentially the must have features for your product, right? So these are the features that you absolutely should not launch without. And this can be due to variety of reasons. There can be legal reasons around it. There can be safety concerns. There can be some business reasons. If it's something that has been promised to your users and it's essentially a huge driver for the value that you are being that you are providing as a part of your launch, then definitely it would be a terrible idea to launch without it. Now, to ensure or to work out if something qualifies as a must have, think about the worst and best case scenarios for not included. If you are able to picture a successful product without the inclusion of the speech and then sorry, let me rephrase that. If you cannot picture a successful launch without this feature, then it means it's a must have feature. Should have is essentially for the things that could be better to include, but you're not destined for disaster. If you don't include those features, could have again things that would be nice to include. If you have the resources, but again are not very necessary for the success. Now, there's a very, very thin line between, I'd say this could have and should have kind of features and to work out which features belong in which category. Think of how each requirement or whether a lack of any requirement would affect the customer experience, the lesser the impact, the lower the priority of that feature or all that requirement goes. So if the think of it as like if the impact is lower, then it essentially would go into the put have features if it's a little bit more than it would be should have feature. Won't have again really important something that is something we intend not to include at this point. Something to just be aware of in terms of won't have. When we say won't have it, I think we do not mean that this requirement is trash or it would never be included. We essentially mean that this is not being included at this point and this can be due to a variety of reasons. Can be like lack of resources, lack of time. And it also helps manage stakeholder engagement with the various stakeholders that you have been working with. Moving on to the next model, the next prioritization model. So this is something known as the Kano model. And you can see a lot of similarities between the Kano model and the Moscow technique which we just looked at. So the Kano models basically divides your features into three different segments. First one is like the delighters. Delighters are essentially the features that customers would perceive as something going above and beyond their expectations. These things essentially differentiate you or your product from the competition. The performance features, customers respond really very to high investments in the performance features. For the basic features, this is something that is actually expected by the customers to solve their problems. And without these, the product is essentially useless to them. So think about, just as an example, think about, let's say, a hotel industry. So when you go to a hotel, you would essentially expect that the hotel would be clean, the room would be clean, you would expect a bed, a mattress, a comforter over there in order for you to have a good night's sleep. So these are essentially the basic, the minimum expectation the customer has from your product or from any service. So that's something called as a basic feature. The main idea behind the Kano model is that you focus on the features that come under these three brackets. And accordingly, you can manage the level of customer satisfaction that your product is going to have. Now, to find out how customers value certain features, you can use questionnaires, asking about the experience of the product, and how it would change with or without the features that you're going to implement. Another thing as a part of this Kano model is, as the time goes along, you may find that a lot of the features which are initially delighters move down to more towards the basic necessities. And there can be a lot of reasons around it, right? It may be because the technology catches up on customers because of the continuous excellence in the product delivery. A lot of the features become sort of like a basic need. So it is very important to reassess all the features of your product periodically to ensure what becomes the basic needs and what are some of the delighters which you can use. The next one is the value versus complexity quadrant. So something, a very, very powerful tool again. So it's a prioritization instrument that essentially looks or works in form of a matrix. It's a 2x2 grid with a potential value or business value, in this case, is plotted against the complexity or the effort that's required to build a particular project. Now, to make this framework work, the team has to quantify the value and complexity of each feature update or any initiative. Now, I've been talking a lot about the value and complexity. So let's first define or do a little bit of a recap in terms of what the value is and what this complexity is. So value is, again, the benefit to your customers and your business that you get out of this feature or this specific launch. Is this feature going to alleviate any customer pains? Is this feature improving their day-to-day workflow? Is it helping them achieve the desired outcome? How is it going to have the positive impact on the bottom line of your business? These are some of the things which you would look at from a value perspective. The complexity or from an effort and standpoint, think of it as what does it take for you or for your organization to deliver this feature? It's often not enough that we create a feature that our customers love. The feature or this product should also work for the business. So can you afford the cost of building this feature in order to satisfy your customers? Does this have the right amount of operational cost, development time or the skill or the training or the technology that is required to build this feature? Do you have those capabilities right now? And these are some of the things which you have to think about in terms of the complexity or effort plan. Now, excuse me. So, again, value versus complexity, it sort of divides or puts the features into four different quadrants. And when we align it together, this criteria can make support several groups that objectively show what set of features to prioritize first, what set of features to build first, which one to do next and which one to not do at all. So if you look at the upper left quadrant, these are something known as quick wins or low hanging fruits because of their high value and low complexity. These are some of the opportunities that we should execute with our top priority because these are those low hanging fruits which essentially provide the most value with the least amount of effort. The second quadrant, look at the upper right quadrant. So these are the major projects, big bets or some of the potential features. These initiatives fall into this block that are sort of big project releases that we know are valuable but are essentially too risky to take on because of the cost or resources involved with them. Then come to the lower left, which are like fill-ins or maybe so in this quadrant, the features or the products are actually positioned which are nice to have features. These are like small improvements, maybe some interface improvements or some small, small enhancement that can essentially make your product look better. And the final, the fourth quadrant is or the lower right one is called time sync features. These are the initiatives that we would never want our team to be working on because it's essentially not providing business value and it takes a lot of time for us to or our organization to create So the value versus complexity quadrant, it is an excellent framework to use for teams, especially working on new products. It's a very simple framework. So this framework is really helpful if you need to make some objective decisions fast. If your team lacks resources, then the value versus complexity quadrant is also an easy way to identify about some of those low hanging fruit opportunities. However, there are also a couple of potential pitfalls as a part of this specific framework. One of the drawbacks of this value versus complexity quadrant is that it can get quite busy if you're working on a really, really major product with a long list of features. So in that case, this would not be probably the best, I would say, framework to use, but it can still provide you a good insight in terms of what to prioritize and what not to prioritize. That's a bit of what we wanted to discuss today. Thank you for your time and happy to hear if you have any questions.