 Hello everyone. I'm Bani. I'm here to give a presentation on prioritization because this is a topic that I hold in great regard. I feel very strongly about this. I think this is a skill that a lot of us need to continuously learn and improve on and that's why I'm here to share some of my knowledge and some of my learnings and again this is just directional because a lot of the recommendations I make here may differ made from case to case but I'm here and happy to share whatever I know. So let's get started. Before I dive deep into the topic, I just want to introduce myself. I'll give you a little bit of background. I was the ex-product manager lead for user engagement for Flipkart. For those who are not familiar with it, it's a $13 billion unicorn based out of India. I joined when we had not yet gotten our first billion dollars so I've seen that trajectory from it being a small lean startup to being a massive huge unicorn today and even this year they've received four and a half billion dollars of funding so Flipkart continues to grow. I'm glad I was a part of that trajectory and growth. I was their first mobile product manager and by the end of it I was leading their user engagement charter as a product manager. As of today, I've worked in Silicon Valley for the last couple of years. I've worked with a lot of startups. Recently I've worked with Shift which is an on-demand grocery service. I managed their entire member experiences across mobile apps and web. I specifically look at creating the life for experiences for users, retention and engagement. I've had the opportunity to work and this is mostly when I was back in India across a variety of startups. So I've worked with B2B, B2C. I've seen most of them fail so I have that sort of learnings as well. I worked across mobile apps, desktop, again developing and developed markets and I'm an architect by education so I'm very, very picky about my pixels. So I have a lot of focus on product design and business. I actually started my career as an investment banker so I moved from investment banking to venture capital so I know that side of the ecosystem on what it takes to be sort of on page with investors, what do investors look for from founders and product specialists so on and so forth. I have four topics that I want to cover during the course of this presentation very briefly at that. The first is why do I believe and this is my core belief why is prioritization a must-have skill in today's product management world. Is there and if yes, is there a right or a better time to prioritize during your or in your scheme of every day to do things to do as a product manager. How do you prioritize? So what are some of the popular frameworks that I have used or I continue to use and this is sort of the crux of this presentation I would say which is there are so many challenges along the way and anybody who's worked as a product manager would know that it's not always that rosy picture to say oh I know what I want to build and it'll go out there and we'll be able to build it. There are tons of roadblocks and I'm going to try and talk about some of those and how we can circumvent some of those. So why is this important and why did I choose this topic? Even today I'm very very sort of I love the product management community here and back in India and this is a common theme. I don't know how to pick the right thing. I don't know whether I should invest in an existing feature or build a new feature. I don't know whether I should pivot. What does pivoting mean? Why is this more important than that? How do I funnel in this stakeholder's request versus that? How do I prioritize? This is something that's a common theme even if you go online and check Google you will see that there is so much content around this because there is demand for this content. So every day this seems to be the biggest challenge that we face as a community and this is again a cross. This is an epidemic problem. This is a cross PTOB PMs enterprise consumer PMs, platform PMs, startup PMs, unicorn PMs, established company PMs and so I just wanted to reiterate that this is something we must do in order to make the right kind of impact at work and what I mean by right impact is you can either prioritize to make like Ken Norton says 10% impact or you can make a 10x impact and if you're good at prioritization you can do the latter or at least strive to do it. This is something that I chanced upon when I was reading something and I think it articulates this core belief very well which is that a lot of us as product managers we focus on making our product successful. So we are constantly trying to look at dashboards and trying to measure product KPIs which are how do we make the product successful but there is also something and a concept called product manager KPIs which is how well are you enabling yourself to make the product successful. So what I mean by that is of course the first thing is as a product manager my KPI would be how are my product KPIs doing which is the product that I handle which is the product that I manage but there are also more layers of abstraction which mean how well am I building the vision and does it take into account all my stakeholders am I keeping all my stakeholders aligned on that vision does everybody speak the same language and you would go back to that famous diagram where product is supposed to be at the intersection of design and business and tech right but are we keeping all those stakeholders aligned on that common vision and then this is sort of the summary of what this presentation is all about can you keep all those stakeholders working on the most important thing which is prioritization right. So again prioritization is not only key to the success of your product but also for you as a product manager to go to the next level if you can't do this well enough you will never make that 10x impact this is again something that I have come to learn by success or by failure I have seen that and you'll sort of agree with me on this product managers are continuously context switching high level backlog high level backlog backlog high level we are doing this every day every hour where we have to keep our eye on the 30 thousand feet view and the nitty gritties of the project you are executing right and in this context switching and going back and forth we need to realize where we should prioritize first so once you have a roadmap don't forget to go back to it to the high level themes to keep and to continuously keep prioritizing the themes because your themes inside a roadmap will map to sort of what I call the big herodicious goals of the company so keep going back to this to not lose sight of your roadmap or your vision in pursuit of the backlog and so what I'm the point I'm trying to make is when you funnel in everything and you make a roadmap and from the roadmap you make a backlog don't forget to go back and keep prioritizing this to churn out the right list there how to prioritize again this is a more sort of educational thing I don't want to dive too deep into it there are more than 20 frameworks available for prioritization I use a couple I have used a couple and there's a lot of content on this but the ones that I particularly find useful or I have used in the past this is a new one so this is called opportunity scoring and the premise of this framework is that every user on your service uses you to accomplish a job are you under serving them over serving them or just about serving them right for that job you can read up more about this or I'm happy to answer questions post but this is called opportunity scoring where you basically try to find areas in your roadmap or your backlog where you are either under serving somebody and hence it should be prioritized or you're over serving them and hence it should be deprived this is called opportunity scoring there's another one which has been around for a long while and we may not use it in this particular form but I think we all use it in some way which is the KNO model which basically says what do I absolutely need in the product for it to work just the must have what will I build and nobody will want it which is the indifferent what seems really attractive which is the blue line there which means that every time you increase functionality in that feature or for that theme you will get higher and higher satisfaction from the users and then there's performance which means that's something you need to keep maintaining and keep supporting for example your app shouldn't crash as you scale users and so these are two sort of frameworks that help you prioritize those tricky ones there are also a couple of other ones which you will which you're probably using already or you would have seen other pms using now one that I particularly like to use is the in is Ian's framework basically what it says is take your company goals have product themes around those for example retention is a theme virality is a theme or user engagement is a theme have those themes have your project ideas under those themes rate those project ideas by impact by cost whatever your prioritization criteria is for example burn for example resources whatever your prioritization criteria may be and then order them in there that is Ian's framework it's very popularly used by a feature is again one where you have you're trying to decide between two different approaches to solving the same problem or two different concepts and you get your users to say where will they put their money so you have limited currency and you say between these five things where will you put your currency and you basically so I have used this for example in user testing where I say I'm to improve search via this or via this these are my three ideas in search where are my users putting their currency to say this is what I want Moscow is again must have should have could have won't do again these are different names to sort of the same premise which is what is going to move the needle up the most and what is what what are those features which nobody is really going to care about or which is not going to move the needle again my idea of introducing this was not to say that you should pick one and commit to it it is to say that there is a variety of tools out there I keep moving between some of these for example when I'm really trying to scratch my brain to get out innovative things or trying to think of things that push myself to think of things where I'm we are probably not serving our users and we can do better I go for this I'm trying to do this example now at ship but the point again the point is that different tools that different frameworks do what's best for you and don't be afraid to oscillate between them and try each of them depending on your project or your team or the stage of your startup I wanted to do this and tell me if it's a good idea I wanted to actually do like a sample exercise with the group here just to get the energy up and this is a live example and it put me in a really tough spot when I was in Flipkart so I'm happy to share my journey of of how I managed it so there was this big feature that we wanted to release this is way back in 2015 or 14 I forget but we wanted to do this really new idea which had failed miserably in the West and so obviously India is leaps behind in terms of e-commerce trajectory from the West and so we always look to the West for best practices or ideas or inspiration and all the competitive research that and I this was like my baby and I come up with this idea and I was excited about it but obviously to my dismay I saw that it had failed miserably miserably in the West and it's a different story that we did end up building it but the exercise I want to do with you is there were two use cases of this feature we could go down this route or we could go down the other route and it was not either or it was which one should we do first which one should be prioritized first and so the feature was basically a messaging interface inside an e-commerce app and the use cases were should we allow Flipkart users to talk to each other via the messaging interface so you and I are Flipkart users can we talk to each other or should we allow Flipkart user to talk to the seller whose product I'm buying both are very very different use cases both seem very powerful and there was sort of a gridlock for the upper management to say no we want to do user to seller and me and my team had a different viewpoint which was to say we wanted a user to user and so I went we went back to we took a step back and said how would we prioritize this if this if we were to be unbiased parties to this exercise the first thing I did was what matters to the company right now we were at that phase where Flipkart had gone from when I joined them we had less than 5 million users across the mobile apps by the time we were launching this feature we I think we were already a 20 million so which was pretty much most of the Indian population that transacted online so what mattered to the company was not really acquisition it was engagement we wanted our 25 million users to come back to the app so that was the one company goal that we wanted the feature to align to the second was put the like I mentioned before what is your prioritization criteria what is your hurdle what is what is that thing that is going to block you for us was it dollars no for us was it engineering bandwidth no for us it was what kind of data are we going to get if two Flipkart users talk to each other about deals about categories that are trending about the kind of questions that I would ask my husband before I purchase something that is very very rich data for Flipkart to mine so I I use some of those criteria to score those two versus each other right another thing will this give us strategic advantage will this make us first to market will this be a differentiator for us because we were at that stage where we needed to do things strategically so it was again the company goal was not acquisition as much as it was engagement we had different criteria and so basically I scored all of those those two against each other on that the other thing was scaling with this I haven't mentioned it here but the other thing that stood out to me on the user to users versus user to seller was that user to seller will be restricted to the scale of the orders that we have on Flipkart which is I place an order once a month but and that will that will be my conversation with the seller so I bought this TV from you I want to know what is the warranty and it'll be very product specific but a user to user will scale those conversations will be about shirts about diapers about categories about sales about hey what is our budget for I don't know Amy's gift for her birthday or a lot of other things so we looked at we did the math to say this is going to be x number of sort of we are going to impact x number of conversations or x number of users this is going to be 10 times of that so like I said a lot of different prioritization criteria the second thing we worked with teams to make sure that they we had their buy-in in these criteria for example I ticked off that sort of tech cost was not a concern it was because I had the implicit buy-in of the engineering manager of the engineering director so the other thing that I wanted to highlight is again aligned to the company goal have your prioritization criteria put in place score your different ideas according to the criteria and do that not in silos but working with teams again this is what I said we did it because we wanted engagement not acquisition we wanted a strategic advantage and we were we wanted to bet on in-house capabilities so we wanted to build that infrastructure we wanted to push our teams to build to build that so our criteria was different and we went ahead with user-to-user because we were able to do this prioritization okay this is like I said sort of the this is the not the rosy picture of prioritization this is actually putting it into action there are tons of challenges I've highlighted three which might be most common which most of us would have faced first is resources I've faced this in a 20 member team at flipkart and a 200 member team at flipkart resources will always be limited especially because of our roles we are product managers but who are we kidding we manage our products it's not like we have teams dedicated to us we will never have designers 20 designers or 200 engineers completely allocated to our product so we will always have a shared pool of resources and they're always limited multiple stakeholders again that's just a virtue of our job we work with business with marketing with analytics operations with other fellow product managers who are managing other parts of the product say inside the mobile app leadership team and who not like every of course and customers so you have so many so many stakeholders and they all have their voice and you need to hear all of them and the last is and again this is something I have faced and I'm sure we have faced absence of data it's something that you really believe in you know it's going to be a hit it's something that's never been done before right but there's no data how do you sell it you know maybe because you can't user test maybe because you don't have the budget for it you don't have the tool for it you don't have time for it you don't have data for it so on and so forth and so then with these challenges and there are a couple of more how do you really execute on your priority list how do you actually get the most important thing to be worked on and according to my definition prioritization or the process of prioritization doesn't end up making that list it is constantly making some all your stakeholders working on that most important item which is the number one on your priority priority list right that to me is prioritization so how can you sort of overcome these there is hope like the slide title says limited resources cut back on your requirements and what I mean by that is make the perfect MVP which is your minimum viable product so even for example features that I've built a flipkart or features that I'm building at ship or other startups try to scale back on what is going to make the most impact out of your product idea right there will be 20 percent of it which will make 80 percent of the impact try to carve out that 20 percent and leave the riffraff that is called versioning or making the MVP or phasing it out whatever you may like to call it this is a very very good pushback to limited resources where you cut down on what's going to make the most impact multiple stakeholders what I have seen working in this particular challenge is align people it is very much a part of your job to keep everybody on your team aligned internally and up and across so up the ladder and across the verticals right it is very much our job and again whenever you feel the need fall back to your company goals another sort of recommendation here is try to get the bank for the buck so when you're trying to funnel so many different requests from so many different stakeholders like your customers and your leadership team or whoever try to cut out the noise and as you gain experience as a product manager you will very easily be able to cut off the not cut out the noise and try to keep the meaty stuff absence of data what you can do about that stick your neck out um I've done this once a couple of times but the ones that I really stuck my neck out it worked out well and it didn't work out well I'll tell you why it worked out well because I gained tons of experience trying to do this whole process over and over and over again with different stakeholders and different parts of the value chain and it taught me that if you really believe in something you need to stick your neck out own it so there will be many many times where you won't have data or you won't have time to test you won't have tools for it whatever the case may be own it list out the risks sort of have a plan for the risks say I know this is a known risk this is the associated risk and this is how I'm going to tackle it if it happens but sometimes listen to your gut and let your gut guide you um again always focus on making that 10x impact there will be some quick wins down the way and you must do those always keep your eye on the price which is how can I take this product from here to here and so I just wanted to sort of I threw in a lot of points here and there I just wanted to sort of later than wrap it up be an advocate for your stakeholders while you are prioritizing do not forget your stakeholders but be very very impact focused cut out the noise and ask the right questions this is how you will build a good base for your priority list things that you need to prioritize always when you have a priority list visualize it always keep it up to date and be very very transparent about it and remember your job doesn't end at visualizing a priority list it should be about you evangelizing that list you need to go from door to door get everybody together and have everybody motivated and eager to work on that thing that you think is the most promising thing and I've seen that shift when you have your engineering team motivated and kicked about the the feature versus not there is a world of a difference in the speed at which they work or the thought that they put in in just testing it just makes a world of a difference if your team is on page so evangelize your priority list continuously and like I said align them align everybody and drive your execution be accountable for execution of your priority list think of that as a part of the prioritization process and again I've mentioned this point because I've seen a lot of this happening where we make a list and you stick to it it's like our bible don't hold on to your roadmap or your backlog or your priority list go back and adjust it if your company goals change go back and adjust it if your prioritization criteria change go back and adjust it if now you have data versus before you didn't and do that continuously and again this is just a summary don't work in silos prioritization will not work that way if you want people to work on that next big thing you need to keep them aligned be open to how you failed in the past and what you can do better next this is both in terms of how you prioritized or which framework you use keep learning from the past and definitely adapt to changing goals of the company your startup or your company always be in a particular stage and that stage will warrant different company goals always align yourself to those goals thank you and open to any questions that you may have sure and thanks for the example that was very interesting sure and I was wondering if you had an example of a failed prioritization or time the time when not necessarily in your own career but the time when a bad prioritization happened and what kind of consequences it led to? I think this happens every day my memory is failing me I'm sure I've done a couple of those but every time and this is again my notion every time something that you did did not move the needle it is bad prioritization it means you did not do your user research you did not find the right metrics or you did not align to the right goal or you didn't execute it right it was poor prioritization forgive me because I can't think of a specific example I forget what Evernote did but they launched a specific feature I think last year which had terrible terrible feedback yeah work chat or something I forget it was poor prioritization because they picked the wrong thing and they prioritized it for business goals not forgetting completely the customer advocacy part of prioritization so they didn't have that criteria of how is this going to be met with from our users which are millions of users right so they dropped the ball in terms of fact is my assumption so I would think that is an example of poor prioritization sure right right sure right right right right right sure as a product manager again I think the onus is on us to be very in sync with what is our technology infrastructure enable us for example there may be a feature request for you to say um this is just a hypothetical example to say why don't you say this why don't your email say this as a subject line this is something 50 000 of your user set but if that does not go well with the branding of your company um you're going to hear that you're going to funnel it but you're not going to execute on it till it matches with your branding so whether it's tech capabilities or just things that and there are tons of these requests um in fact just to add to that especially users will continuously give you our solutions my take to that is and this is something which the jobs to be done I don't know if others are familiar with it basically what it says is the customer so my hypothesis or my theory on that is don't listen to the solution that the customer is giving you which is what they will do 99% of the time they'll say do this do this do this try to get to the heart of it what are they trying to they are trying to get you to change the subject line because maybe the subject line you're using makes them think it's spam so it doesn't have to be the subject line they are asking you to change to but when you get to the root of the problem you can you can work your way around to solve that problem for whichever stakeholder it will always be a mix it will always be a mix and that's where I specifically wanted to call out the gut prioritization there will be times and that's why we have facebook's of the world and google's of the world or slacks of the world these are people and teams and ideas that have been you know done and they've taken the world by storm it is because there was gut and some fair bit of quantitative data to back it so I think it has to go hand in hand there will be sometimes where data will just shout out to you to say oh we need to do this and there will be times when you will not have that and so you will have a mix and a you know pinch off your gut or your qualitative feedback sure interesting question I think my gut has to be strong for both of them um even if there's tons of data and I as a product manager have from learnings in the past or just best practice practices that I know or something similar I've done in other companies if I know that you know again like users can ask and ask and five million users can ask for something for flipkart that is very very strong data still if you think as a product manager um it is your job to to be the wall in between to say I have very strong data but this is the way I should slice and dice it maybe all the for example all those five million users are users from a particular state and so that means that the problem or the solution is specific to that state it doesn't mean it has to be on all of flipkart so to answer your question I don't know if I've done that well but what I'm trying to say is as a product manager you need to have your heart and soul to ever in a in a particular project to even imagine to get everybody's alignment on it you cannot be I have low confidence on this but it has high data and I have high confidence on this but this has no no I think the the competition would be this doesn't have data but this has data I have more instincts that this will work and I have less instincts that this will work but I still think both will work um did that answer your question to some degree yes of course you will need to validate it so there is that whole process of you take an approach you don't have data to back whether the approach is right or not but then you validate it there is post factor validation and that's where you get your qualitative and quantitative feeder you feed data into something that you think might work vis-a-vis you have data on something that should work yes yes and do a better job of of it hey so you talked about prioritization and how it is extremely important to prioritize tasks that help serve underserved means how exactly do you guys well sort of the process that you guys perform to identify underserved so I'll actually um that was one framework that is available to you so that slide was to give you just exposure to so many types of frameworks that are available that is one particular framework not everybody uses it and what that framework does I can talk to you about the after the presentation about it it's something that's called ODI basically it means that the framework maps satisfaction versus importance and it says the more important something is the more satisfaction it will drive and if you're not serving that quadrant it's basically underserved and like I I think I mentioned that I'm trying to do it more and more because I find value in it to to find those really hidden innovative things that we are not doing today so it's just a framework you can choose whichever framework works for you sorry the opportunity scoring framework sure so um usually there's a high level roadmap where you will have things like strategic advantage or user engagement or virality or growth or whatever your themes may be or user acquisition or activation or whatever your themes may be and then beneath below that whatever your visualization technique is you basically have this is what I want to do short term this is what I want to do medium term this is my long term goal and then when you're double click on one of those ideas they will they can be a sort of mini roadmap inside that to say this is the feature but this is my mvp this is my v1 my v2 my v3 depending on the scope of the idea it actually that's very dependent on the tool you use to visualize the ideal way and I think there are tools out there that help you do that is you have the high level which is this is what I want to do in quarter one this is what I want to do in quarter two which is like high level statements I want to solve for user retention in quarter four and then when you click on that the tool will allow you to see actual project ideas again cordoned by I want to do this first I want to do this second I want to do this third I mean double click on one particular idea there are tools like product port there are tools like some people use JIRA some people use clubhouse there are tons of tools out there but essentially you always start from the high level and then you can double click and double click and double click because when you actually get a feature executed there are tons of details on what you want the functionality to be and so on and so forth so sure hey oh oh so so we again that depends on the company and the culture within the company so yes I do and this is not a step on any team stores but it's generally a good idea to know where your team is spending its time and resources and it particularly goes back to the alignment for example if your qa team is testing a feature which doesn't need to go out for the next three weeks they're spending time and effort and overtime on that just because they do not know that we need to roll x feature out right now because we are fighting some fire this it is for the purpose of alignment and so that there is no communication gap so we we use slack constantly to make sure that everybody is focused on doing the right things great last question I think sure sure sure I think that's a great question so there are certain things where either those ideas amount to just customer delight or they just amount to better experience for example making sure that your app is not buggy it's not a it's not a metric that most of us have on our dashboards to say so many crashes happen today it's not something and all of us will be guilty of that but that is something that is an integral part of customer experience so yes to answer your question we should always strive to have five percent seven percent ten percent of our engineering bandwidth working on those things for example at ship we've just recently our qa team just recently made a couple of fixes for being accessible for people who are colorblind and people exactly and so we do try to carve out time for these things I mean these are not our top business metrics but we care about these things go ahead there is no method to that madness no to be fair I think it's just being persistent there's no math that you can do to say I want seven percent every one week and because it's seven percent I want so many hours spent on this it may not always work like that it is that your team believes that we need to spend time on this and you have that ready for them to work on so two things you can do as a product manager is to make your team believe that this is important enough for them to spend time on and for them to be willing to spend that seven percent of their time on it and second is to keep it available and in the right order so that when they have their bandwidth and they have a few hours to spend on it they have everything ready for them to get going and that sort of sets them up for success and that's something you can do as a product manager thank you for being such a great crowd I hope this helped