 Hello, hi. My name is Jerry Socrari, and today I'll be working you through managing trade-offs during product development. Just a little bit of background for myself. I'm an ex-Amazon and ex-NATWEST, where I manage multiple products along the way. One of the hardest things within the product management life-circle is basically being responsible for core product delivery and being a problem solver and also being a strategic thinker within the product circle. Most of your role will revolve around managing trade-offs during the whole product development. I'll work you through the journey and we'll start with just explaining what trade-offs are within product development and then working through the importance of trade-offs, key areas to evaluate during trade-offs and managing trade-offs and the techniques and also very key points is decision-making tips within product management as well. What is trade-offs? Basically, they're just like analyzing rigs and probabilities and issues that may arise during product development. You could have these within big or small organizations, which basically you're looking at delivering a product and you're being put to a challenge whereby you have two competing priorities in order for you to choose from what to go live first or depends on what the scenarios are. In that instance, you have to make a call to say, okay, I want future A to go live and future B to be on the backlog whilst we still walk around how we're going to deal with whatever rigs or issues that may arise from not having future B in the backlog. Basically, trade-off is just you managing the product delivery cycle and ensuring that things are still moving smoothly without any delays because as a product manager, you have to have this at the back of your mind that you can deliver everything. I'll get more into that in later on in this presentation. Trade-offs are very, very important within the product lifecycle and product development. One of the key areas within trade-off and one of the key importance within trade-off is that it gives you the opportunity to map out your most have and you're nice to have within the product lifecycle. It also gives you key insights into increasing the speed of delivering functionalities of features, improving efficiency, also increasing revenue uplift and reducing costs during product development because in most cases, you're working on a product where you're given a tight deadline and you're given a very tight budget as well. You then have to come up with creative ways to manage your team around that and also manage the product around that. Sometimes you may come to a roadblock where you have competing priorities like I mentioned earlier on where you then have to pick and choose what exactly goes first or what exactly comes after during the product development lifecycle. These are key in decision-making when you're carrying out such, even though it's a medium-sized or large-sized product delivery or project at hand. It also gives you the opportunity to go to market fast and gain feedback from customers, which could be defined in the simpler terms as being agile within the tech workspace or product development workspace. Being agile is key within one of the key benefits of trade-offs being important because you tend to deliver faster rather than waiting for the whole thing. You have to communicate with your stakeholders to then understand what was important to the business, depending on what the business vision and what the business goals are. In terms of key areas, I've actually structured it in three critical areas within products where you could manage trade-offs. If you're looking at a product, the entire product lifecycle, it comes through the business phase, then goes into the design phase and then goes into the technical phase. Within the business phase, where in terms of evaluating trade-offs, you could have an example of you looking for a third party to use to deliver some additional functionality or to plug into play or to build on their technology and integrate it within your own wherever you're building. You have to look at what technologies are available in the market, what companies have these technologies and the pros and cons of these companies in terms of working with them. For instance, I've worked on projects where we had two really good competitors out there in terms of what we are looking for in terms of the product development. I think the key difference within one was the time difference and where they're based. They were based within the Australian region, whereas the other partner was based within the European region. It was easier for us to then narrow it down to what the business actually wants. They offer similar products, but we had to look at in terms of resolving issues, how quickly can we respond to it, do we want delays or what are the other criteria we could look into. Within the business phase, it's key that you manage such trade-offs along those lines. There are multiple other examples where you could actually add impact and add value into the business phase in terms of managing trade-off. Then when moving into the design phase, you end up having iterations of designs coming into the pipeline and getting feedback from customers, from colleagues, from different stakeholders within that project. It's key that you understand the overall goal of the business in order to manage those trade-offs within those phases. I'll give you more insight into the techniques to manage trade-offs. Technical phase, this is just when you're within the software development lifecycle phase and you're working directly with the engineers and they could say, okay, you know what, we are looking at these tools to use these tools. These are the advantages. There's advantages of using these tools. These are the advantages of having a setting in terms of going to market strategy. We want to ensure that you're going to market to these particular sets of audience, that we have the technology to cater for that, and what are the pros and cons of using that technology and work screen within the whole software development lifecycle. That is important to understand that if you're given a project, let's say, to deliver within six months, you could look at various areas and see how you're going to maximize your time and improve the team's efficiency and deliver the product on time to customers as well. These three areas are key in decision-making because whatever trade-off you're managing within each of these phase contributes to the wider goal of the entire product itself. In terms of techniques for managing trade-off, I have five techniques here that I use to manage trade-offs, which is very important. The first thing is that you need to know your trade-off. In terms of knowing your trade-off, you need to understand the problem you're trying to solve. Understanding the problem is key in every aspect because if you don't understand the problem, you won't be able to brainstorm or communicate what you're actually trying to achieve from having trade-off A as, I mean, having component A and not having component B. You need to understand what problem you're trying to solve out there in terms of what the customer actually, what the business goes is so that you could tie that back into the business goals to say, this is why we're doing A instead of doing B. Also, communication in terms of trade-off management is very important. I think communication is one of the key areas where lots of people tend to just underlook in the sense that they don't really see the importance of how important communication is in a bigger, wider scale of things in terms of product and managing stakeholders, ETC. Communication also creates visibility to the team and all the stakeholders because if you constantly communication, it doesn't matter if it depends on what product you're working on and who your stakeholders are and how they like to work. You could see when building a product, most people communicate daily within the stand-up. There's just one set of stakeholders and you could have bi-weekly meetings with your external stakeholders or your wider stakeholders, which is also key. That is really important when managing trade-off so that everyone is clear on the vision and is visible to the organization, is visible to the wider organization or wider team on what you're trying to deliver so that it could focus on the product itself and let everyone know and carry them along. Also, another one is prioritization of trade-offs. I use this approach called the rise approach. It sounds fun, but it actually works. In terms of choosing and picking what trade-off to actually present within when you're having these conflicting priorities, first of all, you need to understand the reach. If I'm using trade, if I'm using component A or if I'm using future A and future B, what impact, what was the reach, what audience is it going to reach? What's the customer side of things in terms of the advantages of doing that and the disadvantages of doing that, so you need to compare and balance it off. Also, you need to understand the impact, both the positive and the negative impact in also doing that, which would give you an idea of saying what the customer impact might be, what the, what was the probability of that impact actually materializing or those issues or the risks you've raised actually materializing ETC. Also, you have to look at cost as well. Do you have, how much is it going to cost you to go for option A or option B? Whereas, if you're going for option B, is it cheaper and is it going to deliver less of value or is it going to deliver more value? And sometimes within the cost experts, it's kind of dependent on what the goal of the organization is and or what the trade off is you're actually trying to manage. Because sometimes you see that you could go for like a much more expensive option because of what the value added is to the product. And also the effort required when you're within the product management space and when you're within the managing trade off phases within, depending on what feature or what functionality of products you're trying to deliver, you have to, they have to be compromises in place whereby, you know, you know, your team efforts, you know, how long is going to take your team to, you have to understand how long is going to take your team to deliver option A, where an option B, and you need to look at your team to see if they have the capacity to actually do that. Because sometimes what happens is that when managing a product, you come to, you get to a roadblock where you have, you know, the team already working on existing functionalities or just working on something else. And you have to, you know, bring this priority that you say, okay, this priority weighs more than whatever you're working on and take a team member out of what they're originally doing, which is going to impact the team momentum. And, you know, if you're working on a product, if you've worked with engineers, you could tell that within any sprint or any of the sprint that they're working on, once you, you know, just change the momentum, it impacts the whole team, because they already, they have to, you know, really look at the whole product you're bringing into the pipeline, the additional product, etc. So you need to understand the team effort and the team morale as well in terms of, you know, what priority is actually, you know, very, what priority you can use to actually actualize whatever product you're building. For example, I've worked on a product where we were building a new functionality for our customers, and we then had an incident which was impacting our life customers. So at that particular point, it's always clear that whatever you're doing, the incident comes first because that's impacting your frontline customers, and customers are actually out there. Whereas if you're building a new product, no matter how high up in priority that product is, you need to prioritize the incidents because the incidents is impacting real life customers, whereas the other product is not life yet. So it's very important to understand, you know, priorities in terms of managing these trade off. And also documenting trade off is actually key as well, in the sense that, you know, when making decisions like this, most of the times the decision is quick and, you know, swift and, you know, developers can just get into the rhythm of making these changes. But from a product manager point of view, we have to make sure that we document these decisions we are making and get relevant sign off from the stakeholder to say, this is what we agreed to. It's just like one of those tick box exercises so that if you're not here tomorrow, you could, you know, people could go into the folders to then say, okay, let's look at why this decision was made over this decision. And let's read, you know, if there's change in business goals or business priorities, you could then revisit that and see what the reasons are. So documentation is always key. And also trade off gives you the opportunity to actually innovate around, you know, setting issues and setting dependencies. So, you know, when you're innovating around trade offs, it's actually very key to understand that sometimes it makes it easier for you to walk around the trade offs in the sense that you're able to then say, okay, you know what, instead of having A and B, we could have A and a little bit of B or B and a little bit of A. So it's a bit of a mix and match. It creates like, you know, conversations going within the team and brainstorming and saying, okay, how are we going to innovate around this? Do we want to go through, you know, maybe if it's something that has to do with systems, do we want to do this manually for now? And, you know, just push the changes out to customers whilst we then work on the bigger issues or bigger things we have to like, do to make sure that we don't miss our deadlines. So that's actually key as well. And just one of the final things I would just like to touch on is, you know, decision making tips during the product development, which is also key because as a product manager, you're always making decision at the go. You know, a lot of the developers, the designers, the business guys, governance, regulatory operations, regulatory bodies, depends on what product you're working on. You always have to make a decision at the go and decision making is key to building a very great product. In terms of decision making tips, never try to be a perfectionist because within our world, there's nothing that's been perfect. You know, we're working in a very agile and, you know, streamlined environment. So what that means is that you always want to go to market first, test the waters and get feedback from customer. That's how you build a great product. So if you try to be a perfectionist, you just end up, you know, just going back to the waterfall methodology ways where you want everything intact before going to the customer. You know, within the product, you know, development, it's not like a physical infrastructure where, you know, you have to build, you know, make a foundation before you put the roof on or else a building collapse, yada, yada, but at the end of the day, you're building a software development project. And, you know, it's key to actually learn how to, you know, build and shape and build and shape and continue with that iteration and it's going to make your life much more easier. And also, getting rid of confirmation bias because sometimes when you've made a decision, you then start doubting the decision you made based on lots of information coming in after you've done your homework and after you've like gathered, like, you know, all the information you already have, you know, for that particular functionality or product and it gives you the time to then, you know, to then start questioning that, oh, you have already made the decision, but I'm getting this information. They're not new information. They're just like other ideas coming into, you know, the pipeline and it creates a whole, you know, forum of never ending ideas and brainstorming. So it's good to actually have that, you know, just get rid of the confirmation bias to say, you know, when you've made a judgment, just try to make sure that, you know, that whatever judgment you're making, you've done your checklist of, you know, it's data driven, it's fact driven. It's like as the goals driven in terms of why the organization wants to be ETC. So once you've done those checks, it gives you a much more stable mindset to actually say, you know what, let's focus on this first, and maybe later on in the future, we'll think about the other things coming into the pipeline. That's it for me. Thank you and goodbye. And feel free to message me on LinkedIn. Cheers.