 Hi, everyone. My name is Malan Perera. Today, we are going to discuss about future part of session and what are the burning issues that we do see in the product management today. Since that we are going to cover, first I'm going to give a little introduction to myself and also how I started my career in the product management, and how we can split a feature backlog based on the number of requirement sources that you do have, and what are the things that we can consider in the future part of session, and advantages of having both technical and commercial skills as a product manager. Let's start with the introduction to myself. I had worked for MasterCard over 13 years and I did recently finish off my long career with MasterCard. My most recent role was a lead product manager. All these 13 years I did work in the loyalty side of MasterCard, I have seen how MasterCard has grown a lot, especially in the product management in the 13 years, as well as in the technology space as well. What brought me into product management? I started as a solution designer back in 2008, which I was loving that role during that time, and we were following Waterfall during that time, and back in 2012, we did transform from Waterfall to Agile. It took probably around good two years to get a bit mature in the Agile, and during that 2012, I had an option to work as a tech BAO or a developer. The reason for that is my management, they were thinking that I had that BA skills as well, and also I had that developer skills as well, because as a solution designer, you can't think how BA's are getting requirements and you'd regularly engage with the BA's, and also solution design, engage with developers hard as well. That's why I had the choice. I did really think about that, and I did select the tech BA role. The reason for that is back in those days, developers according something as per document. Like you just get a detailed design, and you just like code based on that, and you don't have that freedom to change something, or your innovation skills doesn't get actually shown up anywhere. As a BA, it's giving me that opportunity to engage in the project management lifecycle a bit early, and if I want to change it to common, I do have that freedom as well, and it doesn't cost a lot too, because it's at very, very early stage. That's why I did select the tech BA role, and I have seen how MasterCard grew from this Agile role in the last 10 years. First, we did name as a tech BA role, then we did rebrand that to the product owner, which is similar to the tech BA role, but you do have more ownership in the product space, and then product manager technical role, which you call PMT role, like a lot of bigger tech organizations like Amazon, Google, like Microsoft, they use this term called PMT, same as MasterCard as well. Within the PMT role, you need to have both commercials and the technical skills. You need to have that skill set to bring a new product from all the way from innovation to all the way to the live. That means you will be engaging with number of stakeholders at the upfront, and you define the scope, and then you take that product to your development team, and grown that, and then take that product all the way to the live, and measure in the success criteria, and doing all the press release as well, that will be the ideal PMT role. Hopefully that will give you a bit of understanding for you guys. So let's take about the how we can split a feature backlog based on the requirement sources. The reason I put in this slide is because I have attended many product management guilds, and I have discussed the burning issues in the product management with different product managers from different organizations, or product owners from different organizations. This organization can be small to meet, and some of these are even large organizations as well. The common burning issues that we do see is is stakeholders changing their priorities every day or every week. So therefore, we can't have a properly planned sprint or properly planned corridor release and stuff like that. And stakeholders might justify that saying we want to compete with the market, and we want to get things faster to the market, and we want to make a specific client happy. And another burning issue that we do see is if some team has to do some production support work as well, that means there'll be a content searching. As a developer, you will be working on something, product tasks, and all of a sudden you are getting thrown at a, like, a production support ticket that you had to work on, then you kind of have to drop your development work aside and then work on this issue, server to one or server to two issues, right? That's another issue that we do see. And I have seen some development teams which they do like 50% of their work in production support, which is probably not an ideal business model because you need to have a separate production support to do those initial investigation unless if there's a court change, you need to have that send that to developer to do that, right? And also in the mid sprint, you will get something urgent saying from the senior stakeholder, I want to get this change done. And I know it's unplanned, but when you get this done, maybe to again, to make a client happy or maybe for a, just to make the senior management happy, right? And also another big complaint from the product management is there is no room for innovations. Just say you are the product owner or product manager of that product and you are just building that base on the requirement from different people. And you don't have that opportunity to analyze the data train and bring something new. So the issues can be a funding issue or it can be you don't have that room because there will be too many requirements, all right? So what I did was I kind of thought, okay, how we can split features and I did lucky enough categorize this into four buckets. This is kind of work well, I guess for large organization and this percentage is such as rough estimate and you can change that based on how you grow in your product management and local luck. I'm a big fan of safe agile because it's better if you can plan for three to four months and then you're kind of committed your features for the next three months with all these stakeholders agreement. So for an example, just say your team capacity for future points is 100%, right? And here you can see we are allocating 40% of our capacity for business request and 25% for innovations. That's mean that give you that space to bring your ideas as a team. You can engage with your data analysis team or with your developers or if you have a BA within your team you can engage with that as well or you can look into your own analysis what computers do there and you can bring on your ideas and then take that to your stakeholders and get their agreement and then put that to your product backlog, right? And also you need to meet the security and the audit requirements. So you need to allocate some present page for that because your security and the audit requirements can change pretty much every year to keep your PCI standards and also keep your brand safe as well and keep your system safe as well. And also it has some allocation planned present page for production support. For an example, if you build something as a developer if there's an issue that code need to be changed that code change need to be done by that particular product team. So just say in ideal world production support team they investigate the issue and they find out there's a code change that need to be done that change need to come to that production support team or the development team who did work on that initially to go and change that, right? So that's why I allocate 15% for that. And also if it is one or certain issues you may have to allocate some investigation time with the production support team because you may not have that skill. Well, you may not have access for production data and production systems. That's why you need to have some kind of percentage. So in ideal world in each iteration I would have that kind of a story with a time box story, with the production support it can be like a two or three pointer then if something comes up you can allocate that. So I think this will work well for large organization. This is kind of something this is kind of like a correctly fit what we did follow at MasterCard as well. So I did feel like this is probably a good slide for large organization. So let's talk about the sample too. So this will really good luck in a really well fit for smaller to mid-sized organization. And again, we do see our quarterly capacity is 100%. And again, we allocate 40% for business requirement. In this case, we're allocating only 15% for innovation. The reason is you may not have that bigger budget for your own innovations and you will be heavily depending on the business requirement. And there's still you may need to meet the secretary and the audit requirements and also you'd have that 15% allocation for your production support work as well. And also I put this 20% for unplanned activities. It's kind of you're trying to plan the unplanned activity. That's the important thing here because you may get ad hoc requests in the mid-spring but you have a placeholder story to take that work. And in that way, you are not actually jeopardizing your sprint plan or sprint board because you had that story to take care of this unplanned activities or the production support as well. And that's kind of give you that opportunity to have a good sprint planning. In the worst case, what can happen is you may not get it, not get any ad hoc requests or production support. But that's okay. You can, you take a story from the next iteration and you can build your own the current iteration but it still is something comes up in a mid-spring and rather than jeopardizing your board and demotivating your development team, it's better to have a planned placeholder. Hope that makes sense for you guys. All right, so let's move to the next slide. Does that solve the regular complaints? I think it does at least the way that I can see because you're saying, stakeholders change priorities every day or every week to compete with the clients or to make the client happy. So if you go back, just say, you have that. If someone changed their priorities, you have some placeholder to deal with that. Right? And also some team has to do some production support work. You have a placeholder for that as well. And also you cannot wait for our sprint to be completed due to some urgent issues. Again, we go back here. We talk about this unplanned activities, right? And no room for innovations. Here we go, you had that 15% allocation even in a small organization for your own innovations. So if you can get this, if you can get this discussed with your senior management, if you can get on board with them, this is probably a better fit for all the product managers or product owners out there. All right, so key factors. So what I believe is if a business stakeholder unable to plan at least 50% of their requirements for the next three to four months in advance, that's a real issue on how they operate their business model. Because as a business stakeholder, you need to have your small scale goals well-defined. And probably your long-term goals can change, but your short-term goals need to be well-defined. And you need to at least get that right for 50%. So if the reason why I put 50% is you're taking 40% of the requirements, right? And then the innovation category is for product manager and product owner. And this company is bringing their ideas to improve the product. So as I mentioned before, as a product manager, product owner, you will know what need to be improved in your product because you're kind of dealing with that product every day. So it's better you have that innovation time for yourself. So talk to your manager and like start to bring that, like in a little room for your guys to bring your ideas. Now, let's talk about our next topic, which is feature prioritization. So all this prioritized features at the platform level. And I have seen this is a challenging issue in some organizations. They're thinking, we kind of allocate features based on our team capacity. And we've prioritized features based on our team capacity. And just say, you may be working on a feature because you have a room, but there is a dependency on that feature. You can't turn on that feature when you go live because there's another team that has to build their part as well and they don't have enough room. So how we can get around that? Paratops are featured at the product platform level, not at the individual team level. Hope that makes sense. And like in a feature prioritization, one of the basic thing that we do follow is build the highest value with the least effort feature as your priority, like in industrial kind of number one role. And best practice is to prioritize features in every two weeks with all the stakeholders, including your business team, product teams, tech leads and production support and your operation team and the audit and the infrastructure teams. And that way, all the stakeholders are great and also all the cross-functional team are great. What we are changing and if someone would change their priorities, they don't have that opportunity lot because everyone has agreed what everyone is working on as a team. And keep it transparent as much as possible. Then it's less likely some senior manager comes in to product or in your plan work. And also, if a senior manager come, even the CEO comes and say, I wanna get this one done. Just say this is how we have prioritized this. And now if a senior stakeholder come up with this new feature and use the same method, use the same discussion with all the stakeholders and prioritize that feature. In that way, you can go back to yours even to the CEO and say, this feature doesn't take that priority rating because of this issue, right? So keep it transparent as possible. In that way, you don't get push on your work. You can be very transparent by having that feature metrics. So next I'm gonna discuss about, I'm gonna give you an example like how we can prioritize feature. So I know there are a lot of tools that you can use out there to prioritize feature but I'm trying to give you a very simple way that you can do and you can use this one as an example. Again, so first thing that I would consider what will be the cost of building and unlocking many kinds of features we do size from a small to SL, given that a small is the considering one feature point and Excel can be considering eight feature points, right? And so the way I kind of score this, if it is a small feature, I give five points because that will be very easy to build. That's mean cost of building is very low. And so all this prioritization, the ratings, it works from one to zero to five within that range. And so if the development takes less time, a small effort, I'll give five point and if it is an Excel feature, I'll give a one point for that, if that makes sense. And the time to build, right? Again, I use that one to five ratio and based on the time, you will give one for the longest time and five for the shortest time, right? And then the third one that we are talking about is can we reuse it in another region or with another client? So if we can reuse that with another, pretty much all clients, you'll give five and if you can use with maybe some clients or some percentage of clients, you'll give a value from two to four and if you can't reuse that with any other client, it's a very specific thing, you just give zero, right? Because you're building something very specific for a very target client. And so you need to really think, okay, what's the part for that? And then the next one that we would consider is what does a computer just do at this stage? And if computers have something similar, we may not just say about to build the MVP product, right? And so if a computer has something similar, I would normally reduce this call and then if it has something new, I would give it the highest, like the number five ratings because we are bringing something new, then we do have our time to build that in our own phase rather than competing with someone, hope that makes sense. And then what's the cost of running after it launch as well? Because sometimes we build features with some manual work involved, right? So if there's a manual work testing, there'll be an operational cost in long-term and there'll be some technical depth as well, right? So if there's some cost of running after it got launched, then you give one point, right? If it is fully automated, you don't need to do anything, like you just turn on, it runs very smoothly, then you give five points for that. And how many customers will be using this feature from the total customer base? Because you need to think it can be, you may have just two clients, right? But you may have maybe 80% of your customers in one client and maybe 20% of your customer base with a second client. So how many customers can reuse this feature within your platform? And then you give a relative score for that, right? If all the customers can use it, you give five and then you give a relative score if the only a less percentage can use that feature. So you can see how I've given these values for these samples, right? And how this feature that you are building, so how this feature that you are purchasing is kind of aligned with your broader product strategy and the mission for your platform. If it is very correctly fitting, you give five points, if it is not fitting properly, you give a relative score based on that and for the one for the least fitting, right? And then there was the revenue as well, because as a product manager, you need to think, okay, what's the revenue for you? For five, we give the highest revenue and then you give a relative score. So based on that, you can see this is a small feature, right? And it's less time to build, but then again, it's a very specific feature for a very specific client and very small customer base. Even though it's less time to build, it's take 22 in the feature writing that I did put together. And this feature, if we talk about it, it is kind of a medium-sized feature, but it can be reused everywhere. So this gets the highest scoring. And this feature is kind of a large feature, and but then again, it cannot reduce in any other region. So it does get the less priority. So this one takes a lot of time to build and we can reuse that, so less priority. This one is take mid-sized to build, but can reuse it everywhere. And this one is less time to build, but cannot use everywhere. So that's how I would prioritize features. Hopefully this will give you a good example how you can prioritize your features. And the other things I would consider in the feature prioritization, are we meeting security and the audit and the regulatory requirements? If we aren't clear on that or if we haven't finalized that, don't bring that into even for your prioritization as well, because you need to clear that regulatory and the legal requirements before you discuss a feature with the broader business group. And what is the MAV product look like, right? Can we build like a small minimum viable product in the first phase or first quarter release and then you build on top of that as you go? And also another thing that you can consider what are the pros and cons between internally and what are the pros and cons buying something a third party tool and if it is available. So let's talk about our next topic. What are the advantages of having technical skills as a product manager? So I think as I did mention it very early in my webinar, like companies like Amazon, even Apple, MasterCard, Microsoft, they use this product manager technical or technical product management, technical product manager role, right? The reason is to give you that advantage having that technical and the commercial skills to see a product from both sides. If you have that commercial size, you just see the commercial side of it, but you don't know whether that technically feasible or not, right? And if you have only technical skills, you don't know what will be the business value that product will bring in. So having that kind of balance definitely help you and then another advantage is having that technical skills. You say as a commercial product manager, you may need to verify that requirement with your technical teams every now and then to see if they can do that, right? But having that technical skills, you don't need to go to that technical team every now and then you can make your own decision that ready a lot of leading time to bring a requirement or bring a feature to your product backlog. So that's one of the biggest advantage I do see having that both technical and the commercial skills. So I'll take a simple example. Just say we wanna build an API to send a payment confirmation from A to B, right? Normally in a commercial product manager, they would say, I wanna build an API with to send a payment confirmation from A to B and with some little tech details, maybe send these other request parameters and these other response parameters and this is what we are getting, right? This is the API that we wanna connect, right? But if you have that technical skills, you would say this is the API interface design look like and this is how we can connect and this is the port number to access it and this is the URL and this is the request parameters and the format and what is the response parameters and what's the format as well and what are the security protocols that you had to use or what are the maybe encryption that we had to use or decryptions or what are the validation rules that you need to put together on validating the request parameters and the response parameters and when to trigger that API, right? So definitely you can see having that technical skills adding a lot of value and also if reduce that number of discussion between A and the B getting that requirement clear. So for an example, if you had just a commercial product manager, you may need to have another maybe a product owner or a BA going to that B and discuss, okay, how I can connect from A to B, what are the validation rules that I had to put, right? And how we can call your API but having that everything in place from coming from one source definitely will help and definitely fast track all your work. That's the advantage that I do see. That's all I got for today and thank you for your time and really appreciate that and have a good day. Bye-bye.