hey juan here in today's video i'm going to talk about the different product management frameworks or priority frameworks that are going to help you prioritize your different features or work that you have to do and you make sure that you understand how they measure against other items in your roma the first framework is rice rice is going to help you understand what is the value of the feature so the potential features that you would like to build and compare them with each other rice is an acronym and is referring to rich impact confidence and effort
and then is built into an actual score that will help you compare different features to each other or against each other although these words are going to be defined by some kind of metric as metric this one of course is going to be a slightly subjective so as always it has to be taken with a grain of salt the first one which is going to actually measure what is the reach of your future how many people do you think that is going to reach out to how many people is going to be benefiting from the
future that you're building or that you're actually planning so the rich score is going to be given by the people or the amount of people that you think that this feature is going to be benefit within a reasonable time scale of course you don't kind of think about years from now potentially you're talking about when these features launch and maybe potentially the first year let's say that you create a new feature that is going to actually lead to some new customers being acquired there is going to be about 500 customers this 500 will be actually
your rich score impact is going to be measuring how much people are going to make their purchase decision for your product based on the future that you are developing this obviously is going to be a very qualitative metric because it's going to be very difficult to actually measure it properly but basically you can score it from a minimum impact to a very high impact of the feature and this will give different impact scores for the minimum impact being around 0.25 and all the way to three for those ones that had the maximum impact by the
way these are the levels that intercom has defined i will link it below if you made it so far to this video and you actually are enjoying it i will appreciate if you give it a thumbs up it helps massively the channel and it's free for you as i said earlier rice is a score and a score is subjective so confidence is actually going to measure how confident you are on the scoring that you are giving so far so there's going to be uh from not being very confident on this on the different scores that
you have been giving or actually be highly confident intercom is giving different scores for this confidence starting from 50 up to all the way to 100 if you are completely confident that this that your estimates are correct 50 percent meaning that pretty much this is a moonshot and finally there's the effort the effort as you can imagine you have to work with engineer and you have to work with different units to understand how much people are going to have to work in this project to make sure that the future is delivered once you understand the
potential effort that is needed again potential effort you don't know for sure how much effort is going to need be needed that's why we have the confidence as well typically what you're going to do is measure it in person's month to give the actual score for confidence once you have calculated all these metrics rise score is going to be calculated as the product of the reach the impact and the confidence divided by the effort rise is a relatively simple way of actually trying to value different features against each other and seeing which ones are the
ones that could have the highest potential for you as a company as a business or as a product the next one that i'm going to cover is the moscow model again moscow is an acronym and it actually has couple of vowels on it so it actually makes sense or there's a word that you can actually pronounce because that's why we build acronyms isn't it so again moscow is a prioritization technique that will help you define for a product or a project what is has to be included as part of the project what is completely out
of the scope and two intermediate levels that will help you prioritize additional features that would potentially be beneficial for your users as for the acronym what it means is m is going to stand for must have s is going to stand for should have c is going to stand for could have and w is going to start for one half so if you think about your development about your project planning product planning feature planning as defining an mvp of what you want to release to your customers what the moscow framework would help you with is
defining what are the different levels and what are the different items or features that should be included or part of the deliverable for your users part of that product that you are going to be building your mbb must have obviously those are things that are going to be definitely part of the mbp this is definitely the very very minimum viable product things that you know that you have to deliver that without them nobody or people are actually not going to be interested in your product this can be things like features like very hardcore features but
it can be also designed it can be also appealing to the customer and bringing real value in an easy way that people actually can start using it should have is going to define what are the other features that if given time if you have the time to go for it you should actually go and include them in your product should have features can be a mix of quality of life features but also very important features for your customers that are going to actually improve their experience and improve the capabilities of your product could have features
are going to be features that probably are going to be nice to have features and potentially are going to be must-have features down the road for your users but at this point especially when you're thinking about the initial release about your mvp are not going to be that important or that critical and finally that's going to be the one half features this can be features that you are sure that you don't want to do because the goal against what your product should be but also can be things that you want to deliberately leave out of
the scope in this first initial part of the project think about could have features think about should have features and won't have features or features that are might not be that important at a certain moment of the development but down the line maybe one year or two years they are going to be critical for you to have available for your users so one half doesn't mean that you will have it ever it would it means that you won't have it for the first launch of that product or project that you're building and yes the o's
are only to make pronounceable the acronym so they don't mean anything at least as far as i know if you know otherwise please let me know i wouldn't say that i use moscow model as such but in many ways i have been using it because when actually defining a product and defining the different phases that is going to be built basically the way of prioritizing is the same one you define the first phase where you want to have your must-haves there might be a release or not by the end of the first phase but then
in the second phase you might have something like the shoot house or some even could haves that actually can be developed together with some of the must-have features that you have to continue developing and maybe then after the second phase you are able to release but you're already prioritizing some items there that you know that they might make it or they might not and it's not the end of the world if they don't make it so then it makes easier the way that you are facing your development and actually for the engineers to work against
a plan that is more clearly defining what are the milestones that they should be achieving they might make it or they might not and it's not the end of the world if they don't make it so then it makes easier the way that you are facing your development and actually for the engineers to work against a plan that is more clearly defining what are the milestones that they should be achieving next we have the canon model i'm not completely sure how do you pronounce it so sorry if i pronounce it in a way that you
don't understand i hopefully is written there this theory was developed by professor noriaki kano again sorry if i mispronounced that and it studies the relationship between the development of a product and the user's satisfaction of that product again this kind of model is going to look in different qualities for the different features to understand if these different features are actually improving the user experience of those users that you have or is actually detracting on the user experience is making your users happier or is it actually making your users unhappy or is just leaving them indifferent
so first we will have must be qualities basically this is the same as a mass of quality this is a quality that you definitely have to have in your product in many cases you can identify must be qualities or must have pro features relatively easily if you look up to what your competitors are having these are going to be the things that all the competitors have in common and if you don't have them you basically are not going to pass the cut they are not going to be the winning features though for you to win
the competition that's typically going to fall in a different category then there's going to be one dimension in qualities these are actually going to either make happy your users if you have them but if you don't have them it's basically going to make them very unhappy if these are fulfilled properly your customers are going to be happy but if they are not fulfilled properly your customers typically are going to have a bad user experience with you next we are going to have the attractive quality this attractive quality this is going to be your delighters feature
these are the ones that actually are going to help you raise above your competition to do something different from what the others are offering as the must-haves as the basic functionality that everybody should have you can think about this for example in phones phones usually they're going to have the basic functionality that everybody has to have but then that's going to be the delighters the dealers can be something like the actual experience of the user you can just think about iphone that they are very famous and popular because of their designs then there's going to
be the in different qualities typically the different quality are qualities of your product that you probably need to have but are going are not going to have a very direct impact or at all in your customer base or for your user experience think about the programming language that you're using to code your product probably in general that does have a very heavy impact or direct impact that users are going to be able to identify and yes if you're a software engineer you're probably thinking about the different performance of the different uh languages but in general
the users are not going to be able to identify that and they are not going to even care even if the performance or the optimization for a certain language is going to be better than other language unless actually the experience is affected by the language that you're using so as always everything depends and that seems to be the conclusion for every single video and finally there's reverse quality these ones are going to be features that are going to detract from the experience that your users are having or from the experience that the users expect to
have just think about for example if you are a product that is trying to focus a lot in simple user experience and simple design if you are a lot of options if you are a lot of complexity to the experience with lots of settings this is probably something that your users are probably not going to be happy about so one of the interesting things from the canon model is that how the user experience evolves over time so what you will see is that there's going to be a graph that defines how a feature once is
completed how it's going to be giving the actual good experience or better experience for the users but no matter what the experience is now all that experience and all that nice user experience even if it goes to the highest level to be a delighter is going to be actually moving down over time meaning that a feature that can be a delighter right now is probably over time going to be just too nice to have feature and on the very long term is going to be a must-have feature this is because we are just all the
time evolving and actually trying to improve the products and competition is obviously catching up and these are features that nowadays everybody has to have because otherwise they would basically not make it through the cut on the competition then there is the value versus effort framework this framework will measure the value that a certain feature brings to your customers or to your business because remember value to customers equals better business you build impact on the business by bringing value to your customers and it will measure it against the effort that it takes to actually develop that
feature the ideas are going to be measured in two axis the vertical axis is going to measure the business value with low in the button a high business value in the top and the horizontal axis is going to measure the effort with low effort being in the left hand side and high effort being in the right hand side once you are able to define if a feature is uh it has a high or low impact or it has a low or high effort to be developed you are going to be able to plot them into
this graph once you plot them is going to be relatively easily to understand the four quadrants in this graph in the upper left you are going to have your easy wins these are going to be features that are not going to take you a lot of effort to implement but are going to have a high impact on your business you could consider this as low hungry fruits that actually have a good impact on the business on the upper right you are going to have your big beds here typically are going to to be your long-term
projects your long-term features that you understand that once a building is going to take me a long time it might take me one or two years to build or even longer but it's going to have a really really high impact on the business on the lower left you are going to have your incremental features these are going to be features that are going to require a low effort for you but are going to have a relatively low impact on your business these are many times going to be features that promote retention amongst your existing customers
and finally you're going to have in the lower right hand side the money bits these are going to be features that are going to be very costly but they have very little to no return on investment so there's very little value for your users there's very little point in actually developing this because potentially this is not going to bring value to your users so it's not going to be bringing any impact on your business so you typically want to avoid these ones so many times when people actually look into this framework the way of working
is that anything that is in the easy wins are things that will have the highest priority then you have the long-term bets which you would try to schedule on the longer term that you know that are going to potentially give you a big impact on the on the business and finally there is the money pits these are the features that you want to avoid to develop at all costs and whenever you have time you will take features from your incremental box or your incremental quadrant because those are things that are going to promote and make
sure that people understand that you're paying attention to their needs but you know that for you and for your business are not going to have a very high impact and finally there is the priority poker this is very related to the agile planning poker what this one is actually promoting is something like priority or prioritization as a democracy but only as a democracy between the stakeholders that actually have a valid boat so what you will do in this case is that you will try to identify different features and you will have a different stakeholders voting
for that feature so the feature can be just the feature it can be a user story if you're thinking about agile it can be an actual product it can be quite many things just it's a way for you to help you to identify the highest priority items on your list how this typically plays is that everybody has a boat that they can give for each one of the features and the boat is just going to be a score between one and three one and five depends on how you want to do the scale obviously typically
starting with one being the lowest priority and whatever is the upper limit being the highest priority what you want to do when you play this priority poker is that you want to make sure that everybody votes anonymously and that everybody can cast their boat without having a bias from the rest of the stakeholders this is important because many times people just bought something because somebody else that they either respect or that they look up to has voted something they will just mimic the way of prioritization so with priority poker what you want to do is
that you want to try to identify what are the highest priorities for us as a group for us as that's what i was talking about kind of priority as a democracy and making sure that these priorities are given in a non-biased way an anonymous way to help you understand what are the priorities for this group i actually have used this method sentence for prioritizing features but also in workshops to understand what are the highest priorities are out of different items that have been discussed in the workshop and also in workshops that are built around designing
a new product so do you actually need to use these frameworks in order to prioritize your work well in my opinion no because typically this can be quite rigid and can look at priority sizing from just one point all of them combined make a lot of sense but it's difficult to combine into just one mighty framework as i said earlier i work with components that are present in some of the different frameworks and reuse them in the end what you want to have is some kind of a structure that you follow in order to make
priorities and that you actually avoid making gut decisions that is the main goal you have to have a structural way of working that is your own framework that can be based around of any of these models but it doesn't always have to be as strict and potentially rigid as one of these frameworks and i don't have anything against them in general i have tried some of some frameworks and typically you end up always redoing it to suit your needs or just using different components of different ones so how about you do you use any framework
do you use a mix of them do you think that these frameworks are the way to go or how do you actually do priorities for your work let me know in the comments below if you like the video give it a like subscribe to the channel it helps massively and i will see you in the next video stay safe