 Hi, everyone. Welcome to this webinar on prioritization of projects slash new features. Let me start first by introducing myself. My name is Sumit Thavan, and I'm currently a principal product manager technical in the Amazon Just Walkout team. To talk a little bit more about my background, I have been in the core product space for about 10 years now, but before starting in product management, I've worn many different hats throughout my career. I started my career in GE as an advanced manufacturing co-op engineer while still working on my masters in industrial engineering at Virginia Tech. At GE, I focused on lean manufacturing, supply chain optimization, and implementing manufacturing best practices. I was pretty passionate about this area and wanted to make a career in this space. However, I didn't really find a lot of opportunities in the 2008-2009 recession period, and that's when I switched to financial services. I led credit risk management and portfolio management strategies initially at HSBC and then later at Bank of America. So after a few years in financial services, I decided to go back to B-School, complete my MBA at the Indian School of Business in Hyderabad, and right out of B-School is when I started my core product management journey with the Aditya Birla Group. I was the product lead for Aditya Birla's digital lending products based out of Mumbai, and I collaborated with many of the top startups in India at the time and helped launch multiple consumer-facing digital lending products in the fintech domain while taking advantage of India's push on digitization and Adhar-based identity. After a two-year stint in Aditya Birla, I got the opportunity to join Amazon in their European headquarters in Luxembourg, and since the past five and a half years I've been at Amazon working in EU exports and expansion initially, then I switched to PeopleTech where I worked on a suite of internal-facing products for hundreds of thousands of Amazon employees, and for the past two years I've successfully been building products to extend Amazon's just walk-out technology to 3D retailers. That was a pretty long introduction, so let me get back to the topic of this webinar. One of the biggest and most challenging areas of responsibility for a product manager is to make the really tough decisions on privatization of new features and projects, and anyone who's ever interviewed with me, they know that this is a favorite interview question of mine because it allows me to go deep with a candidate, with a potential PM candidate, and dive into how they think holistically. Before I move ahead, I do want to call out that what I'll walk through is my individual point of view based upon my years of experience in product management. Now mark my point of view might not be shared by other PMs and some subject matter experts. I encourage you to think critically about what I say and make your own decision on whether it makes sense for you. Anyway, with that disclaimer, coming back to the topic at hand. So every product manager is familiar with a lot of standard frameworks that exist, and all of these frameworks attempt to make this critical decision making easier for product managers. And the way they try to do that is they try to convert a very difficult subjective decision to an objective score in which you can then compare multiple different projects and features and come to a decision. And one of the most popular and often used frameworks is called the Rice Framework or the Reach Impact Effort and Confidence. But my point of view is if only things were that simple, right? Because standard frameworks like Rice, they don't really work well in the real world in isolation. And I would advise product managers to exercise caution while utilizing them for critical decision making. One of the things that they're really prone to is false precision and might lead you down, you know, one-way door decisions if they're used incorrectly and plugged with, you know, guesstimates, which could basically be someone's opinion and not real data. In case you're not familiar with the term one-way door and we use this often at Amazon, it just means decisions which are very difficult, costly, or take a long time before they can be reversed. I mean, think critically about it for a second, right? If we did have all of the required data to plug into a framework, there would be zero uncertainty in decision making, correct? Don't get me wrong. I mean, if you're one of the few lucky PMs who do have all the data, I am extremely jealous of you. But like, that is really the case for the majority of us. But I do want to make it very clear that I'm in no way advocating for abandoning these standard frameworks because, you know, the concepts they're based on are solid. And my learning through my long career has been to utilize these concepts as invaluable guidance, especially when breaking ties. So as a very simple example, if you have two projects and you're using the right framework, and both of them are of equal impact, it's obvious that the one with greater reach, that is the one which is applicable to more customers, would make it above the line, right? So this is how I've found using some of these frameworks to be most useful because they decrease the risk substantially that you would fall prey to false decision making and, you know, myopic decision making, or sorry, false precision and myopic decision making. So, well, if what I'm saying is true, then the natural question that arises is, how should PMs then prioritize if frameworks are of limited use and you can't just compare projects with an objective score, right? Well, the honest truth in my experience is that prioritization by its very nature and complexity is an extremely subjective exercise. Many successful product managers, I know, they tend to rely on a much more holistic set of inputs and make a prioritization determination based on those in conjunction with their best judgment, right? I do want to share this broader approach with you today and I hope you'll find this useful. So from my perspective, there are three major holistic areas that I focus on to determine the right prioritization on the product roadmap. The first thing that I usually rely on is to create a robust working backwards process and I would encourage each and every PM to set up this kind of process for their area because this will be your biggest source for knowing what the right features and products to prioritize are, right? Which are the use cases you should target the most and I would also encourage you to develop multiple sources of inputs on these customer needs, product insights, customer feedback, product gaps, customer pain points, etc. And I'm going to walk you through some of the components of the working backwards process that I regularly utilize. So the first one of the processes that I utilize is UX research. Now, I do acknowledge that not all PMs would have access to UX research since typically only large companies tend to have dedicated UX research resources or departments. However, if you do have them, please do take advantage of them. Work to actively influence the UX research roadmap and utilize existing research if it's available to you to gather invaluable customer insights. And then finally, if it's not available to you, there's no law against PMs doing their own UX research, right? So we can definitely make some headway there. The second major mechanism of the working backwards process I use is any voice of the customer mechanism, right? So I would highly encourage PMs to work very closely with their stakeholders and partners on customer success teams, go-to-market teams, customer-facing teams and develop formal frequent mechanisms to gather voice of the customer feedback and have a dedicated mechanism to action those, right? These are basically coming from the customers themselves, although there would be some things lost in translation, but they're still a very valuable source. The third mechanism that I utilize and sometimes it clubs in with the voice of the customer mechanism is a direct feedback and input. So I would typically develop a dedicated process to talk directly to the source, that is talk to real customers to ensure that nothing is lost in translation when working through the voice of the customer mechanisms. So one of the ways that I do that is I have many times shadowed customer success teams or business development teams on real customer calls, sometimes participating, but most of the time being just apply on the wall and listening to how the sales process develops sometimes or what is the customer's reaction on listening to certain product concepts that the PDE is trying to sell them on and so on. So those are some of the ways business development shadowing is not actively applicable to every product area, but you get to just what I'm saying, right? The fourth component of a working backwards process that I utilize is a very robust set of metrics. My learning has been that instrumentation of a robust set of metrics is a lot of work, not only on the product side, but sometimes even on the tech side and what ends up happening is there is a lot of pressure, there are timelines to meet, you need to deliver X, Y, and Z features. And then the first thing that gets placed below the line are the instrumentation of a robust set of metrics. And I'm smiling because that has happened to me more times than I can count throughout my career. But honestly speaking, even if that happens, go back and prioritize these metrics and looking at them and instrumenting them and making them more robust and drawing insights from them because longer-term product success is basically impossible without robust metrics. And I want to stress this point because it's only the metrics that will point out early issues, customer pain points, product gaps, you know, and there will be very invaluable in guiding, you know, go-no-go decisions for any new features that you might be looking to launch. The fifth working backwards mechanism that I utilize quite a bit is A-B testing. So, you know, there is usually a lot of debate and a lot of subjective debate in the absence of data on which of the competing features in CX is the best one. And the only way to know for sure is to actually launch more than one, if possible, obviously, but to launch more than one competing feature or competing CX and then understand which is the right product or CX that the customer would prefer. And finally, and this is pretty important, but the final mechanism that I utilize for working backwards is competitive analysis, right? So, every product manager, in my opinion, should be aware of major competitors and their products and features. And you should generate insights from competitive analysis and they're invaluable in isolating where your product might be lacking, you know, that the competitors are smart as well. So maybe they've figured something out that you're still racking your brain on. So why not learn? Like not everything needs to be invented here. So that's all about working backwards. The second big holistic area that I focus on is business strategy. Now, why is business strategy important? Business strategy is actually often the most important factor when defining priority and phasing of release. So as a very small example, if your business strategy is to go abroad and expand into multiple verticals, multiple countries, multiple customer segments, it's very different from if your business strategy is to focus on one country, one area, one set of inputs, one vertical. And it will provide very different inputs to your prioritization process, right? So going abroad versus going deep is typically something that comes from business strategy. So I would encourage each and every PM to ensure that you're plugged into the overall business strategy and actually even contribute to it, right? If those conversations are happening without you being involved and your leadership is not proactively conveying those, please ask to be involved, right? You have a lot to offer and you should be providing inputs to the overall business strategy, but you should also be very attuned to what the business strategy is so you can make the right product and prioritization decisions. Now, standard mechanisms for business strategy at most companies are very similar, right? Including Amazon and they're usually things like company level goals or level goals for your particular VP. They could be directive goals for your team and these are often defined within annual processes and quarterly refresh processes, monthly prioritization reviews, quarterly business reviews, etc. They're very similar at most companies. So finally, the last area of the holistic inputs to prioritization is what I focus on is team and product tenants. So tenants are extremely helpful, especially in breaking ties and they will help you take the right decisions that impact customers. So tenants in my opinion provide guidance not only to the product definition itself but also to the prioritization of features within. I wanted to walk you through some of the tenants that my team recently wrote and hopefully you can see how they would help prioritize a feature or a product or a project over another as well as guide overall decision making. So for my team specifically, the first tenant is customer centricity. So we will strive to put the needs of the customers even above the needs of the business. The second tenant for my team is minimizing friction for customers. So the way that we look at this is we will build products with low barriers to onboarding. We will prioritize automation and self-service tools. So that adoption is easy and we will make sure that our products and onboarding does not require deep technical expertise. The third tenant for my team is reusability. So we obsess over time to market and we bias towards reusing existing solutions to meet an extent to new use cases. The fourth tenant for my team is data protection and security. So our customers trust us with the security and use of their data and thus we have decided that we'll prioritize customer trust even over customer convenience and we will solidly reject any solution that doesn't meet the highest standards for security and data protection. The fifth tenant for my team is fraud and abuse. So we assume that any CX with any kind of fraud and abuse loophole will be exploited by bad actors eventually. So on our side we will innovate to mitigate fraud losses so that there are no more than an acceptable loss to bring business and we will while trying to maintain a natural customer experience. And finally our final tenant is we will think two steps ahead and we'll make spot bets so we invest in solving long-term customer needs. So those are the three areas of holistic inputs before we take any prioritization decisions and I would encourage you to develop similar processes and mechanisms to make sure that you have a holistic picture and holistic inputs and can make the right prioritization decisions. But before I finish I wanted to actually walk through some of the major pitfalls to avoid and these will be helpful not only when prioritizing features or products on the roadmap but also when defining the product vision in the first place. So let me walk through those very quickly. So the first pitfall that I see a lot of product managers falling into is essentially working solution forward. What a solution forward, working solution forward mean? So solution forward is basically moving ahead with a product or a feature while already having a solution in mind and doing that instead of the more robust working backwards from customer needs process that I outlined earlier. And it's very easy to fall into this trap but my advice to all current and aspiring product managers is to always work backwards from user needs and never work solution forward. And how does this happen? Let me give you a small example. We see this many times even in just walk out. So often customers as well as customer facing teams will come back to the product team and they will demand a solution which they already have in mind and this solution is reflective of the current status quo. So the way we see this a lot in just walk out is because we are innovating with just walk out in retail and very often we are pushed to adopt solutions that have existed for a long time in traditional retail. Now this solution forward and the solution reflective of the status quo that's being pushed is rarely the best solution that meets the needs of the customers and would likely lead you down one way doors. As I explained earlier, what one way doors are. So be very careful on not working solution forward. The second pitfall that I myself have done it quite a few times in my career but I try not to do that as much as possible now is loudest voice prioritization. Do not and I repeat please do not prioritize based on the loudest voice in the room. I know the squeaky wheel gets all the grease but the loudest voice should not dominate your roadmap and this is honestly a lot easier said than done because it's very tempting to prioritize this way especially when you are facing escalations and facing difficult conversations both with internal stakeholders and your own leadership and even maybe external customers. So if you ever have this loudest voice prioritization problem and you're trying to deal with it I would encourage you to use your leadership to manage these escalations and get support so you can prioritize the right way. The third pitfall that I want to talk about is and I've made this many times in the past myself is not involving technical stakeholders early and this is a common mistake. So as PMs we are taught that we should practice what we call unconstrained thinking and that's how we will think big and get to the next path-making product out there. Now unconstrained thinking is awesome and I myself am a big fan and this is what I try to do and try to teach my team to do as well but essentially once you have practiced unconstrained thinking and laid out the broad vision you do need to involve the technical stakeholders which could be UX designers they could be senior engineers they could be software development managers or technical program managers and so on. So these stakeholders especially experienced engineers are a really good sounding board for the feasibility of your vision the products and features you have defined and they are very valuable in defining the phases of release based on any sort of technical limitations or historical legacy limitations that might exist in your systems. The final pitfall that I want to talk about is for product managers to have backbone but do disagree and commit. Now this I am actually stealing from Amazon leadership principle this is a very important leadership principle that we exercise day in and day out. So why is having backbone important? Having backbone is extremely important because as the product manager you are the one closest to the details and to your customers. If you disagree with leadership decisions please do not hesitate to put your point of view across and when doing so you should make sure and take the time and effort to provide cogent, well thought out crisp reasons for why you are recommending a particular course of action. This will help drive education and an in-depth understanding for your stakeholders but at the end of the day if despite your efforts a decision is taken and it's not the one you wanted you do need to commit wholeheartedly to make your product or your project a success. That's all I had today. Thank you all so much for listening and wish you a nice rest of the week. Goodbye.