 Hi everyone, welcome for the session today. I'm Neha Kicharia from eBay, and today I'll be talking about how to ease the competing priorities as a product manager. Before we get deep dive into the session today, a little bit about myself. I work as a senior product manager at eBay Payments Platform, where we heavily focus on to launching the payment products to ease the life for consumer experience perspective and to simplify the experience, the payment experience for seller and buyer perspective. I've got an overall 14 years of industry experience, where nine years lies into payments and fintech. I'm a graduate in electrical engineering and I love building the product for consumer and stakeholder and to solve the business problem. Before we deep dive into the agenda, let's talk about what are we going to focus today? So I'll be talking about the product roadmap. How does a prioritization being done? Why is it important? How does a prioritization work? The decision making and few closing notes. So with that, let's get started for the session today. First, I would like to draw your attention onto a product roadmap, what and why of it? A product roadmap is a process which tells you why to take in action towards an ultimate vision and the path to achieve the same. As an organization, usually it's an yearly process like we already are in the almost in the age two of 2022 and I'm pretty sure come fast forward, Q4 of this year, mostly all of the organization will actually start talking towards and start planning towards what are their product charter and what are the business opportunity as an organization they would like to focus for the next year. And it is not just a team or a product or a domain but it's actually across the board in the organization. There could be a sales team which would have their own list of priorities which they want to focus on. There would be a business team, there would be a marketing team, there would be a legal team. So every domain, every BU have their own process of defining and listing down what are the areas, what are the focus area they want to actually deep dive into the upcoming year and the roadmap is not just restricted to an year to start with because it's a top-down approach. You start off with an overall yearly process but then it also gets sliced down into a quarterly process. You list down what you actually expect from your teams to be done the whole year and then you actually slice and dice into like quarterly and monthly and all the way down to the sprint planning and we'll get to that in the subsequent slide. But at a high level of product roadmap is a process where you actually define a goal and describe the vision and strategy to provide a guiding document for executing the strategy and get and making sure that the internals stakeholders are in alignment and to facilitate the discussion of option and scenario planning. In a very fundamental way, a product roadmap is a top-down approach to see what are the domain-specific area and the domain-specific product you want to launch as an organization and also as a part of business unit. The roadmap doesn't give the deep dive of what and when but it gives the vision. Hypothetically, let's take an example. Suppose you are in an organization which is focusing onto the messaging platform and for certain domains from your company, like say sales team wants to actually focus onto the user retention and user engagement. On the same side, the business team wants to focus on the revenue generation and the legal team wants to make sure that they are regulated and properly compliant by all their strategy initiatives. So based on here, we see we saw about three different views like the legal, the business and the sales, right? Each of them, they have their own set of priorities which they want to focus on a given year. Now, you really just cannot collate everything altogether and say, this is my roadmap, right? Sales team will have their own charter of the roadmap. Your business team will have their own charter of the roadmap and similarly, the legal team will have their own charter roadmap. And suppose if you are working as like say UI or a UX product manager for the messaging services for the company, there will be certain product ask which will be intersecting your domain and you will be expected to do the prioritization. So let's look a little bit more in detail about how things actually shape up. So as a starting point, everybody, every domain actually and your stakeholder, your executive team, your leadership team actually have their own focus areas which they want to actually go deep dive onto upcoming year or upcoming quarter. And then from there on the actual kickoff of prioritization starts shaping up. Continuation for the roadmap, I have taken a snapshot of a very simplistic way, breakdown of how multiple product roadmap works. I suppose again, if I'm a messaging app product manager and I have a prioritization of three focus areas. Like, if I've gotten the requirement that there has to be certain focus and enhancement for the web platform, mobile platform and localized CRM portal, right? How this slice and dice and slating off the different milestone under that product end to end. If you see the product one, which is the web platform here, it is starting, it's almost taking like, you know, the edge one of a given year, right? Like it's starting from January to May. But then how the different milestone and the different bucketization has happened across that overall end to end product lifecycle, right? There are certain aspect of API then security upgrade segment. So this is how a roadmap, when you are talking about multiple product roadmap, would look like, this is not restricted to just the only way of defining it, but then this is one of the way methodology where, you know, things are actually bucketized and then you are slice and dice over the different milestone. So again, as a quick summary, the roadmap's helped to create the alignment and excitement towards the product strategy. This visibility works for the product manager in advantage from top to bottom approach. As I called earlier, that it's a top stone approach. It's not a bottoms up. So which means that you actually start from the grand, like grand level of visibility and then, you know, you narrow it down to like, you know, features and enhancement and different kind of bug fixing or, you know, like revamping all together a particular feature which is existing today. Roadmap also facilitates the cross-function team collaboration and clarity around priorities. As I called out that, if you are a messaging app product manager and then not every initiative for a given year or a given particular timeframe would intersect or dissect your own domain, but then there are certain overlaps. Roadmap is a very good opportunity to actually jot down and list down for a given particular product upgrade or a product launch. What are the dependent teams would be required? Not every product team on an organization is required for every product launch, but maybe suppose for the first one, if you are launching for a web platform enhancement, right? You need a security team. You need your infrastructure team. You need your UI team, your UX team. Each of these team will have their product manager and then the backend they'll have your engineering partners, right? How do you actually integrate all together? Because just a priority one for my team doesn't mean a priority one for somebody else. So it has to be a very, I would say, like coordinated effort from all the teams where they all can work together on a given timeframe to deliver and launch a particular product. Roadmap also works as a powerful channel of communication because when you actually start calling out and jotting down the dependency from the different teams, this gives an opportunity to sit together and make sure that, okay, is there any missing piece? Are we actually overlooking any particular component which might be instrumental, but then we have not actually called out in the process? So this is pretty much the, I would say parts and parcel of what Roadmap does. And as a product manager, it is very important that whatever methodology you actually is being used in your organization, you make yourself well-versed with it. Sometimes there are different tools and different portal and different mechanism, how a roadmap initiation is done on our organization. And it could be as simple as also an Excel sheet or a Google document, right? It doesn't matter, agnostic of what methodologies is being implemented by the company, what matters is making sure that all the dependent teams understanding of what the ask is, making sure that there's a perfect clarity of what is being expected from your product region or your product domain or your platform. It's very important as a product manager that you stay on the top of the whole Roadmap discussion because when it goes from Roadmap to the either like backlog or prioritization, it's always helpful and beneficial that you know and you're aware of what's the ask about. So this is where the Roadmap comes into play and next now we'll go to the prioritization. Once you have, again, hypothetically, suppose in an organization, the 2023 charter is already created. The Roadmap has already been drafted that these are the five business area or the key area. As a BU or as an organization, we want to focus on like sales, revenue, user retention, legal compliance and say industry standard, like, you know, keeping up to date, like the technology. Maybe, you know, the fifth domain is to make sure that all your technology and all the supporting apps in the backend is actually up to the standard. You know, it's able to take the traffic, it's able to take the growth, the user growth and the incremental data. So if these are the five areas as a roadmap, which has been drafted for you as a product manager, look on to and of course your peers as well. Our product prioritization is a strategy which is used to decide what product feature or initiative or product management or engineering team should work on first. It's a discipline process of evaluating the relative importance of work, ideas, requests to eliminate the wasteful practices. In a simplistic term, if I try to oversimplify what is prioritization is as a product manager, you decide what feature goes first, what feature goes like, you know, later on and what are the feature which is probably good to have but then you really don't want to support at the given quarter or a month or a sprint planning, right? So prioritization does few of the key aspect in the overall product life cycle, right? So let's talk through like what does it actually does? It's all the problem quotient and the business opportunity. It helps gathering the requirement and helps to define the goals, right? Like again, suppose there's a product which is committed in the market to be launched in a Q3 of 2023. And here you are in December planning to do the prioritization for that product, right? As a product manager, it's very instrumental and very important where you actually have a very proper and a very specific planning of when does the dev completion happens? When do you actually want to start the UAT or the testing? When do you actually want to do the beta or the pilot or the smoke launch? And then when do you actually want to ramp it to like 100% and then launch it for the overall market globally? Ranking and scoping. And again, we'll go in detail about the ranking and scoping but this is again one of the very important aspect of doing the prioritization which means that as a product manager you rank and you scope all the charter and all the list of the product which is expected as a part of roadmap with a specific numbering or a grading which actually towards the end of it it actually gives you a clean and a very better visibility of what goes first what goes second, what goes later what goes deep prioritized for again a month or a quarter or a given year, right? That is very and based on the organization there are different methodologies which is being used. Some example being there's an ISF method there's a PD metrics and we'll go in deep about what the different methodologies which are being used. Communication with wider audience in a prioritization process it's not just very integral to use a very clean and a very transparent communication channel just with your stakeholder or your executive or your leadership team and your engineering team but you have to actually make sure that you are including whoever is relevant for that product launch. There might be as irrelevant as some specific group who has nothing to do with the product belt or nothing to do with any kind of integration with your product feature launch but at the same time that particular product launch is going to impact something if they are not involved, right? Sometimes it's very normal to overlook certain group whom you don't think have a direct correlation to your product launch but at the same time you have to as a product manager it's your responsibility to actually make sure whatever decision you are making and whatever notes and whatever kind of prioritization result you are drafting about it's being shared across as widely as possible because that's a very key important aspect of making sure that you are doing a good job in communicating the changes, the proposed changes and the proposed prioritization result with everybody. Sometimes some particular group is being overlooked and then later on it really hits harder when it's been discovered at the 11th hour of the product launch that hey, by the way, you are making this particular but as a part of your change something in our world is going to be impacted or broken and that time it's very messy situation to actually safeguard the interest of the overall project timeline and the health check and then it really like sabotage the whole product planning and the whole delivery aspect of the implementation part. Building the right product for the right user at the right time. I think prioritization is all about I mean, if I have to sum up the prioritization it's basically nothing but building the right product for a right user at the right time. There might be what it means is we'd like to elaborate a little further. Like you might have 10 different stakeholder as a part of your domain or your platform or your particular product area, right? And it's you and your responsibility as a product manager to make sure that which stakeholder and which request from a stakeholder group is what you deem as business critical and when you are actually going through the prioritization you make sure that wearing that lens of what is actually important for the company, for the group, for the result. You are actually picking and choosing the right product from passively a right stake like a particular stakeholder for a right user at a right time, right? There might be as important as a burning issue on certain bug fix which needs to be done as a part of current process and that's impacting like a particular country or region. Say in Asia, certain part of the user are not able to see a proper method when they're actually logging into the system and they're not able to complete their messaging. They're not able to send, their messaging failed, right? I mean, in an almost scenario, it is a P1 bug, right? Of course, it requires an attention. It's not nothing new. It's something which has to be enhanced, how it's done today and then needs to be delivered. But at the same time, as a product manager are you deeming it as, oh, good to have some time in Q2? Or you think that, hey, this is one of the key aspects should be delivered in like the month of January and February so that the user impact and the user experiences is at the minimum. They have the best user experience while using your product. So that's what a prioritization is something which helps across is to build the right product for the right user at the right time. Now let's focus on the different methodologies for prioritization, right? I mean, again, it's very agnostic of the tool and the method every organization have their own. Sometimes they have something internal. It's not just necessary that you have to use something which is like, you know, widely defined and industry standard. I have seen many organizations using their own methodologies and then, you know, excelling in there, like, you know, totally like nailing down the whole prioritization process. So some of the key widely known and widely, you know, like leveraged prioritization method which I've tried to jot down just for the sake of understanding these few. The first one is a Moscow method. Again, as the name suggests, it is basically, as a product manager, you try to tag each of the item and just like have must have, should have, could have or without, right? And then it is very self-explanatory when you try to tag your initiators in the roadmap with either of these tagging. It's very clear, you know, during the decision-making because when you're talking about the roadmap, you know, it's not just restricted to five, 10, 15, right? Sometimes it's like in hundreds, right? And across the organization, but then when you're doing like a roadmap between like 200 plus, 300 plus, sometimes 500 for a given year, right? This is where it helps because then when you can try to collate it into a bucket, sorry. Like say you have 300 requests and then out of 375 or 80 of them are must have. So that makes the decision very clear that, okay, these 80 are going in the bucket for Q1 delivery and then, you know, again, further slicing down into the monthly deliverables and then the, you know, like bi-weekly sprint planning kind of thing. Story mapping, this is again, traditionally it's used when you try to tag and bucketize all your initiators into the story, like, you know, Epic and, you know, user story kind of framework. So this is where it's used. The next is a rise scoring, which is basically as a product manager, you just try to like, you know, when the ask is something very heavy on user impact, right? Like where majority of the ask are user impacting and then this is basically a framework to actually score each of the initiative and how it's done is, you know, you just try as a product manager, you just try to see like, how much is it each, like, you know, how much is it each user reach or like, you know, user impact for that particular ask. You multiply that with the impact. And again, impact has a grading of, you know, like most impact, high impact, medium impact, low impact, no impact. And then each of them have like, you know, scoring point you can start with like three for the most impact, two for the high impact and then one for the medium impact, zero for no impact. And then confidence as a product manager, how much confidence you are, confident you are in that ask, you know, like 80% traditionally is graded as one of the very good parameter or a benchmark for the confidence level to be. And then you multiply that with the effect, right? How much is a PDF effort? And then accordingly, whatever the score, you just provide that score to each of this initiative. Next is the value versus effect effort, right? And again, this is something where you actually draw a graph or, you know, like a chart kind of thing. And then from there on, you basically try to group them into which initiative are like, high in value versus low in value. And then which of the initiative are high in effort versus low in effort. And then, you know, the intersection of value versus effect is where you actually group them. That also gives a very, you know, like a clear way of distinguishing that, which is basically you are going ahead with them, which is what we are going to ignore with. Product tree, team based scoring based on domains. Again, you know, like out of like 300 initiative, you can just group them into, okay, these are related to sales. These are related to revenue. These are related to compliance. These are related to say, you know, like a user experience. These are related to marketing. And then every organization that have certain things which are totally non-negotiable, right? I mean, traditionally, if you see something which has to do with like legal or regulatory, or you say like, you know, user engagement, I mean, certain things which are always high in the bar. And when you try to do the team based scoring, that also helps giving like a broader, I mean, ratization usually is not like a one day exercise where you can just sit for two hours with like 30, 40 people and then you're done with it. It's a gradual process. There's a kickoff process. And then, you know, like you keep refining. There's a multiple iteration of, you know, you start with 300 items and you go to 200. Then you again shrink it down from 200 to like, you know, say 150. So it's a multiple iteration based engagement. And when you start with the, when you actually apply the team based scoring, then also it really helps because as an organization, you know, what are the key critical areas where you want to base your prioritization on. The next is organization based priority themes and strategy. And again, this is basically when your organization is using their own, you know, methodology of priority themes and strategy. So that's where it comes into play. Then brainstorming on list of product themes to set the ranking. Sometimes, you know, this is also needful that in addition to any of the methodology you use, what is very omnipresent mechanism is to continuously being able to brainstorm the list of product theme to set the ranking, right? It's not as simple as somebody says, hey, I think this should be number one. And then, you know, rest of the room agrees to it, right? Like, you know, the rationale behind it, the reasoning behind it, the user statistics behind it. Like why you think something is like, is number one. What are the data and the supporting matrix which actually compelled to make that particular initiative number one? So brainstorming is again an integral part of the overall prioritization method. So one thing I want to call out is like as earlier, different organization leverage different methods or sometimes they use like hybrid method. They also use RICEF and then also use like, you know, value versus effort. So there is no like a right or wrong way of doing the prioritization in terms of the methodologies. I mean, whatever works for whichever team or organization or, you know, domain, that's what, you know, folks usually prefer with. So the different organization actually use different method or hybrid method to prioritize the roadmap feature. And that's something which exists and, you know, it works pretty fine for the companies and the teams. Next, I would like to give a high level snapshot of we talked about value and complexity metrics. So I just wanted to give like, how usually it works, right? I mean, you try to break it down into like, you know, four buckets, if you will. This chart is like, you know, it's accesses like, you know, the value versus the implementation complexity. And then you just try to feel like, okay, what group of projects goes as a high value and low complexity, which is here in the first bucket. And then which of them actually goes to the second bucket, which is high value and then high complexity. So it's very easy to, you know, make a decision when you go with this methodology because something which is high value and low complexity, that means like the cost is low and the output result is high. That means it's a quick win, you know, there's a no brainer and then you actually tag it as, okay, I'm gonna pick it up and this is a high priority. But then something which are complex ones, like, you know, something which is like low value and high complexity, that means, you know, if there is no like a output out of that initiative, but then, you know, it's also equally costly to implement that. It's easy to reprioritize something which is low value and low complexity, you know, that is something you can put in the revisit later or in the backlog, right? Okay, we need to do it, but then, you know, it's not like a burning topic to be initiated just right away. And the second bucket, which is a high value and high complexity, that means it is high in the value, but it's also equally costly to implement that goes into the strategic initiative bucket, which of course is delivered, but then, you know, there are more needful to be done to actually propel those kind of product features. In the next slide, I would like to talk about the importance of the prioritization, right? Like, why we do prioritization and what's gonna happen if there's no prioritization? So with, sorry. So without prioritization, the roadmap and the planning become chaotic, right? We know that, like, you know, it's a matter of fact that if you have like a hundred of initiative or the ask from different stakeholder and like, you know, also from your organization perspective, as a product manager, if you don't do it, that means everybody will think that, hey, it's a high priority and then it becomes chaotic and, you know, it becomes difficult to manage. Every ask and every stakeholder push for their ask is a high priority. I mean, that is something which is inevitable that if you don't, if you don't safeguard the boundary lines of, okay, these are the prioritization results that means everything will end up becoming high priority and then it becomes very difficult to set up the expectation at the last minute with every stakeholder. It actually causes the unmanageable product pipeline, right? It keeps piling up because not everything in a given timeframe is what you need to work upon on a given year or a given quarter. Sometimes there are late discovery. Sometimes there are some P1, P0 bug, which came as a part of recent product launch, right? So it's not just, it can hardly decrease, but it's most likely, like, you know, subjected to increase the product pipeline. So it becomes very unmanageable if you don't do the prioritization. Diagration from the core capabilities requirement for an organization. Of course, like, you know, when you have like multiple competing priorities, right? It becomes, it causes lots of, as I said, like, you know, churn and digression from the core capability requirement for an organization without a prioritization exercise. Chances of building incompetent product, right? Sometimes if your engineering team is like overwhelmed with like too many ask, right? I mean, there is a highly likelihood that the product will not be as competent as expected it to be. And prioritization also provides a clean sense of building a new launch versus enhancement, right? It gives an opportunity that, suppose something needs to be enhanced, like, you know, as a product manager, you wear that lens and you try to vet the option as to, oh, is it like altogether a fresh, fresh implementation or is it something, you know, which can be lived with the enhancement, right? Something is like very critical and high in complexity and high in implementation costs. Then, you know, at that time, you actually try to, you know, choose for like, you know, a little bit of enhancement or a hot fix. And then later on, you know, you can just revamp that whole product altogether. So that also give a clean sense of vetting that option of, okay, do you really want to launch it as a new product launch? Or is it fine with the enhancement? Now, a very interesting point in this webinar today is how do you, as a product manager, how do you pick the competing priorities? So based on my experience and what I've seen, you know, in my current role, as well as my earlier roles and other organization, like, you know, I've just listed some of the key dos and don'ts kind of things, you know, which really helped me to make a decision of when there are like multiple competing priorities. I mean, all of these points which I'm going to talk right now really helped me to actually make the decision. So I would like to share some of them with you, like, you know, the first one is, as a product manager, always ensure to get a good understanding of the ask, right? If you have like, say, 50 asks coming or like, say, 30, 40 ask coming for a given year or, you know, half yearly ask or like a quarterly ask, right? I mean, of course you cannot, you're not being expected to know like deep dive of every, you know, nook and cranny of that product feature ask. But then you should have, as a product manager, you're expected to have a good understanding of the ask so that when you're making a decision or when you're vetting with the different stakeholders and different teams as to, okay, this is the build I need to do. And I think I would need like other teams like ABCDE, you know, until you have a good understanding of the ask, you cannot make that identification. Set the expectation early in the process with all the concern team, right? Like, whatever decision you're doing, as I said, like prioritization is a iterative process, right? It's not just one meeting room full of people and then you're done with it. It's an iterative process. And also you have to do, much before actually you go into the meeting, you also have to do a lot of homework. You have to study the requirement. You have to make your own decision of do's and don'ts and good to have versus must have versus, you know, deferred later. So do your homework and then set the expectation early in the process. If suppose something is coming as a very pressing ask and as a product manager of that feature, you think that, hey, I don't think this is a very pressing ask for like say first month, we can probably do it in the end of the quarter. You should have that expectation set with a stakeholder early in the process. Prioritize the cross-domain communication. Again, as I said, it's a very important to actually jot down and list down all the different team members or the different teams who are required to actually build that product feature together with you and your team to actually ship end to end product. Act is an interface between leadership and domain team. Sometimes, you know, when you're dealing with the leadership team, at times it happens that, you know, only certain like a high level things are being asked from you, right? But then converting that high level ask into the detailed format of, okay, you know, matrix, supporting documents, chart, research, analytics, and, you know, like, you know, user impact and experience. So converting that one line ask into the multiple multidimensional result aspect is something as a product manager, you should always focus on doing. List the complete set of priorities, right? I mean, that's also one of the very key part to make the decision that, you know, you should have the complete set of priorities because what as a product manager, you are going to focus on a Q1 or a Q, or any quarter of a given year is not just it, right? There are certain things which would be like a carry forward from your previous quarter. There's something which are like backlog from the previous year. So it's not just the fresh ask which you need to focus on, you have to actually make sure that there is some bandwidth and some capacity reserve for items which are unforeseen, like, you know, previous year's backlog or previous quarter backlog, as well as what are the, you know, what are the capacity you are actually saving for something, you know, goes wrong or, you know, a production, so you have to actually as a product manager, just list the complete set of priorities, focus on the customer needs. I mean, of course you, what is required by the customer is always, always usually the number one priority as a product manager. So always like try to wet your need and ask from the customer perspective, like, you know, if this doesn't get delivered, how will the customer be impacted? Can customer live with it? Or is it like really a deal breaker for any customer to use your product or, you know, use your website or UI or, you know, like, or that feature at the least? Tag the must have versus good to have. As I called earlier in the prioritization process, it's always helpful, right? When you get like the whole list of, you know, multiple ask, always try to see, you know, just don't wait for the meeting or the prioritization discussion to happen. Much before that, you should do always your homework and try to see from your perspective and from your understanding and knowledge, what do you think is a good to have versus must have? And that makes, you know, discussion pushback rate of much easier in the later phase of the prioritization. Ask the rational for any pushing ask. You know, sometimes there are certain group who really want there, all they need to be met come what may. And when that happens, all this ask a question, it doesn't harm as a product manager to actually ask and get a clarity, as much clarity at the least to any stakeholder who's pressing hard like, hey, I want this to be like, you know, the first product to be shipped for a given quarter and this is a deal breaker for us and we really want this to happen. But then usually a product manager to stakeholder relation is not just like, you know, one stakeholder with one product manager, you have multiple stakeholder to cater to. So if there's something which you don't align to, always feel free and always have that behavior to actually ask the rational and understand more in detail for any pushing ask. Start from the MVP, right? Like that's again, like MVP, KPI, always try to envision your output or your launch of the product with the MVP, right? Like there are a lot of things as a part of product launch, stakeholder or the user would hope to see, right? But then what is the bare minimum you need to do or to ship on a given timeline on a given product? And then what are the further enhancement you can actually pick on on the subsequent months or the quarter? So you should always try to have that kind of discreet and thinking process in the back of your mind. Proposed trade-off is required. Like this is also certain things, right? Like as I called out, like, suppose you have three backlog from the previous quarter and then you have only capacity to support five ask in a given month, right? So you have three backlog which are already like high critical and then you have five new ask, right? What kind of trade-off you can do? How can, what kind of trade-off can you offer? But trade-off should not be, I mean, in my experience, trade-off should not be just as simple as, hey, you know what, do you want me to build like five new launches? These are the three trade-off I want to do. Like always like supported with again, the supporting document, always back it up, always back up your trade-off with, you know, subsequent evidence so that, you know, whoever is making the decision, your leadership or your stakeholder, sometimes the same stakeholder have multiple ask from the backlog and the new initiative, right? So when you're proposing that trade-off option to them, there should be enough data for them to make that easier decision, right? Rather than pushing back that, no, we cannot allow the trade-off and at the same time, you know, you also, they also expect you to deliver certain key products, communication. I mean, that is one of the most, most key integral part for doing either the roadmap or the prioritization. As soon as there is a decision-making done, right? Maybe your prioritization is a week-long process, right? There are three meetings on a week where you start again with like 300 products and then, you know, you narrow it down to like say, 120, 150, right? So whenever that is done, right? I mean, it doesn't matter. Like, you know, it's an Excel sheet, it's a Google Doc, it's a Gira dashboard or it's like, you know, some other ticketing base like, you know, Kanban or whatever it is be. Whenever any kind of milestone is reached in terms of the prioritization, always share it with your key stakeholder and, you know, your team, your engineering partners, your cross-functional dependent teams because that really helps making, you know, staying on the same page from everybody perspective. So that, again, in the middle of the quarter, you don't have any complaints from somebody else saying, oh, we didn't know that this is a number one priority. We have marked it as a number four priority. So we cannot deliver it till the next quarter and you actually committed your business to ship that product at the end of the quarter, right? So communication is the most important aspect while doing the prioritization. Even if you think somebody is not relevant, doesn't have to loop them in the communication channel, but then at least that eliminates the last minute discovery for a lot of the other teams. Now, in this part, I'll be talking about like high levels, somebody of what we have discussed so far, right? So, again, the overall methodology of beginning from the roadmap to the prioritization, like at a high level, the key points I would like to summarize again is emphasize on a clear and a well-defined roadmap, very important. Unless you have a very well-defined roadmap, it becomes a very high time when you make a size to even get through the roadmap and then comes the prioritization. Into the supporting data for the prioritization, again, if you are offering for a trade-off or if you are trying to push back on an ask or if you are actually grading something high as low, always back it up with certain data or some sort of evidence, like it could be like a market cap data, user sign up. Again, I'm talking in terms of if your company is focused on like say, again, user retention, user engagement, market cap, revenue, right? So always try to back it up with certain, and it's not just limited to these factors, but then some of them to name a few would be market cap, user sign-up cost, revenue, adaptation, customer feedback, et cetera. Share the product chartered well-in-advanced with stakeholder with weekly follow-up syncups. So this is again, you know, once you are through the roadmap, once you're through the prioritization, that is not just the end of it, right? Like always have like a close syncup and or like, you know, add the minimum of weekly cadence with your stake, all your stakeholder, where you actually go with the progress and the challenges and the roadblocks, or, you know, where each of your products. So once that particular quarter or, you know, the time period has begun to actually deliver the product, right? Like don't just stop after the prioritization. Don't wait for the team to notify that, okay, now we are a testing, we are ready to ship the product after the, you know, of the successful testing. Always involve your stakeholder throughout the process, you know, because it again, if something goes wrong, unfortunately, it gives you an opportunity to buy in some time and, you know, it eliminates the chances of complaining at the last minute. Documentation and tool triaging is very important. Again, you know, whatever, like, you know, as I said, like, you know, roadmap, you should have a complete and a very clear and a clean methodology of documenting, you know, again, if you're using like, you know, a ticketing system, you know, like, what is that, you know, you save that and you take a snapshot of it and, you know, save it in a wiki page or in a Word document, right? Similarly, what had been the prioritization result, like, you know, documenting it and keeping it in a central repository and then share it with all the key members and the stakeholder. Similarly, the overall product lifecycle, which is a altogether a separate topic, but then it has a relevance in this discussion. Wherever you are in the whole product lifecycle, make sure that everything is being, you know, updated to the teams, to the stakeholder, to the dependent teams, leadership on a timely manner that where you are and how's the health check for that particular project. So that's pretty much, you know, at a high level about the roadmap, prioritization, how to make the decision and then, you know, certain good practices I wanted to share in today's webinar. I hope that was helpful for you and that pretty much brings us at the top of the hour for the discussion today. I hope you benefited with this discussion and you liked it, you liked this webinar. So thank you so much again. Stay safe and feel free to reach out to me on LinkedIn. This is my LinkedIn link. Thank you so much.