 Hi everyone, a very good evening to those of you in Europe and a good morning to those of you in other parts of the world. I hope you've all had a great start to your new year. And I'm super excited to be here with you today. As most of us PMs and aspiring PMs can relate, we're always trying to find that secret formula or the recipe or the playbook for a PM, where we know that these are the principles and practices we need to put into place to be the perfect PM. Funnily enough, from all these guys that we can find on the internet or wherever, only about a quarter of this is stuff that actually sees action on a regular day in the life of a PM. Most of the important stuff comes from actually ensuring that we have mechanisms and practices in place that can only be done by imbibing it in the culture of the environment we're in. And one of those practices include how we as PMs can drive the creation of self-sustaining teams. Thank you for Product School for the opportunity to talk about a topic pretty close to my heart. And a big shout out to all of you here with me today. I'm Zain Alam, a Senior Technical Product Manager at Amazon. And I like to talk to you a bit about creating self-sustaining teams. All my views shared over here are my own purely. And they're based on my experiences over the last seven years in tech, working in different roles as well, from business intelligence, to software engineer, to product manager, to finally product manager, which is what I actually found my passion. So without further ado, let's get into it. And I'd like to begin by talking to you a bit about who you'll be listening to for the next 20 or 30 minutes. So I'm Zain. I am a seasoned product manager. I've worked in different tech organizations during the entirety of my career. I began my career working at a rocket internet-backed e-commerce company called Linio. From there, I moved to FinTech in a company called Connecta. And from there on to Rapi, a quick-commerce Latin American super app. So I worked in different roles across these companies, but I got to see all faces of tech in the booming tech scene. And I was pretty lucky as I got a holistic experience working in e-commerce, quick-commerce, and FinTech. So that's what I did for the last seven or eight years. Until last year, when I decided to take a break and go back to school, complete my MBA. And I was fortunate enough to get an opportunity working in product once again, which I realized is where I really wanted to be. I'm currently working as managing branded shopping pages at Amazon. So let's get into the agenda of our talk for today. I like to begin by taking a couple of steps back and taking us a quick look back in time and thinking about teams historically, why teams are crucial to product managers and product management today, the essential or general idea of team design in organizations, the importance of actually being able to create a self-sustaining team, and the blueprint to constructing these teams. Now, as I said, taking a couple of steps back before diving deep into talking about teams or what were the importance, what is a team essentially? A team is defined as a group of people who perform independent tasks to work towards completing a common mission specific objective. Once we take out all the action verbs, which is performing independent tasks, working to accomplishing objectives, et cetera, what are we left with? We're left with a group of people who have nothing who don't really know what they're doing. And that's essentially when you put order and mechanisms onto a group of people to get a team. What's the historical significance of teams and what kind of impact has it had on the world? Teams have existed as a concept since the dawn of time. Teams and the idea that cooperation has led to and cooperation between humans is something that has been passed down generation to generation across human culture. Cooperation to entities have allowed us to believe that teams can contribute and have contributed to value-creating activities, for example, such as agriculture, building, trade, and even zero-sum activities such as war. Cooperation has been a keystone of human survival, even though I'm talking about essentially activities which have created destruction, it's generally allowed humanity to advance forward. Traditionally, team members have been made to care more for the greater good than individual joy and pleasures. I'm wondering, I question if that has actually changed a lot in current day, but what we do know for a fact is that these teams were behind some of the greatest dynasties and civilizations that ever lived, the Egyptian civilization, Greek Empire, and the Roman dynasty. So now we've talked about all the good things that teams have done historically, but these dynasties don't exist anymore for a reason. Taking a 180 turn, all these ancient teams collapsed for a different set of reasons. There were internal disputes and rebellions, for example, in the Greek Empire was wrought with internal rewards. There were at least 100 recorded rebels before the Greek War of Independence. So that gives you a good idea that this team probably wasn't the most united. There was a lack of clear path to sustain growth. Now the Egyptian civilization was one of the oldest civilizations in the world. But for centuries, they were plagued with foreign invaders, droughts, economic crises. So they had a bunch of stuff on their plate. All of them seemingly urgent and important and they weren't able to address each of them in the correct manner that led to their downfall. No shared understanding of long team goals. So the vision or the long-term plan for an empire was concentrated within a few people. This is especially, I'd say this is also a bit reflective of what happens in today's world. But going back, this is very reflective of the Roman Empire, which was so focused on overexpansion and military spending that all other levers of growth in the empire were left unchecked. Siloed communication. We've talked a lot about examples more than 500 years ago. But let's take the case of the Ottoman Empire, which was a little over a century ago. Simply due to the fact there was no rounded communication. There was siloed communication leading to information asymmetry between two sides. The Ottoman Empire ended up supporting the losing side in World War I and ended up having two thirds of their empire decimated. And that was the end of that. So we see there were these specific elements or specific patterns we could analyze. We can actually analyze and pick out that led to the downfall of these great, once great empires. Now, why the preaching and why the history lesson? What does any of this have to do with product management? A bit more than we might think. So we can actually mirror some of these themes to standard PM practices we see today or team practices that we see today. Internal disputes. This happens then in almost all teams that exist today. And how SPMs, how do we resolve this through stakeholder management and expectation settings? We ensure that internal team discussions are able to be resolved as and when they pop up. No shared understanding of long-term goals. If a team has no idea what they're working towards or why they're doing what they're doing, what is the value that they're bringing? There's not going to be any motivation to work. They are going to understand why they do the things they're doing. And the final end product is now going to be as expected if there's no alignment on this end. And that's where it comes as a PM to explaining the vision. Where a PM needs to ensure that his or her team understands the vision that they're working towards. Lack of a clear path ahead. Prioritization. I think prioritization is one of the elements that all PMs suffer and grow with as well. When you have a bunch of stuff on their plate, each of them seemingly urgent and important meant for yesterday, it's up to the PM to figure out where they need to go next. And silo communication, which is one of the critical factors that can destroy a team is when a team isn't able to communicate freely. When a team doesn't believe that they have, do not believe that they have a space created safe enough for them to share what they feel or the important things on their mind without fear of being reprimanded or shot down. So it's very clear to see that even looking at elements in history, all of them kind of actually reflect on modern day product management practices. And they can actually be extrapolated to teams that exist today. Okay, I'm going to stop with the history lesson here, but I promise you that these are important and we're going to circle back to them in a bit. So what's actually important for a product manager in today's world? Well, now anyone who's done a free online marketing course or an MBA at Harvard knows the four piece of marketing. I want to talk a bit about the four piece of product management. Now, these four piece are particularly interesting because they actually give you an idea of what being a PM entails. And you'll see that being a product manager is only one part of it, actually managing the product. Because before that you need to be a people manager, then a process manager and finally a product manager. Starting from the bottom up, the product here refers to the digital or physical product service offering that you or your company is selling to the customers. The process is the set of actions that I take it to ensure that certain functions of the business are met. So this is customer service, marketing, sales. So everything that needs to ensure that the product gets into the hands of the customers or that it's in a sustainable manner. Finally, people, the workforce. These are the guys that make things happen. So you might have a kick-ass product, you might have airtight processes, but if you have known to execute on these two items, it's pretty much a lost cause and everything kind of falls apart. So you know that being a product manager and being a PM entails a bunch of different things. And when it comes to teams and making sure teams work in a self-sustaining manner, it's important to be a people manager first and everything else next. So I'd like to talk a bit about how teams dynamics work generally in organizations. So in organizations, we generally, let's be looking at two different, two different levers. We're looking at team stability and the complexity of tasks. When we talk about team stability, we refer to people, they're being fixed resources and people with defined, and persons with defined roles and responsibilities inside the team and the level of complexity of tasks. So when we look at this diagram, we understand that it's kind of evident for PMs, aspiring PMs and engineering teams in general that they veer more towards being process teams where you generally have tasks of a bit of higher complexity and it's not very common to have a team with members who keep entering in and out of the team or much fluidity within the teams. That's not very common to have. At least in organizations with some amount of structure. Now, of course, as with any kind of, any general product management principles, what means is that the resources and the time is fixed, but the requirements are not constrained. So you kind of work on these levers, having fixed, having requirements that are fluid and liable to change, but your constraints are time and resources. So that's where product management kind of veers towards being more process oriented teams. And I'd argue even being cross functional as not all product management tasks need to be high complexity or engineering tasks. So we kind of, so product management engineering teams kind of circle or revolve around these two areas or being cross functional teams and process oriented teams. Now, when it comes to what makes a team self-sufficient, right, actually getting into the topic that we're discussing here at this webinar, I'm gonna take, I'm gonna mention a 30 year old definition based on the scrum software development process that self-sufficient teams are self-organizing, cross functional, units capable of getting the tasks done with the given resources without seeking external help or support. Now, something that kind of, something that most product managers and all engineering teams tend to debate is scrum, right? How much importance do we need to give to it? This is a 30 year old definition today in 2023. Yeah, this is 30 years old. And I think that this is, it's a great guideline, it's a great framework and us as problem solvers need to kind of adapt the best of this framework and use what works for your organization, for our organizations. So I, so below I have a bit of my own twist onto this definition is that I believe self-sufficient teams are work units that function optimally with minimal supervision and which are empowered to grow and learn mutually with other existing units of the organization. So when self-sufficient teams put on them upon themselves the restriction that there will be zero interaction, zero external help or support, I feel that's a very limiting factor. And I don't think what makes a team self-sufficient is that they never ask for help. I feel that they, I believe a self-sufficient team needs to know when they need to kind of, when they need to shout out and call for help and make use of the resources that they have within their constraints. That's what makes a team truly self-sufficient. Not the fact that they don't need help, but that they use the call for help in the, they use the call for help in an intelligent and optimal way. Now, why is self-sufficiently important in teams and organizations? Why are we spending so much time talking about the need to create a self-sufficient or self-sustaining team? Firstly, because it eliminates the need for micromanagement, an empowered team is a team that can get stuff done on their own. A team that knows that we trust them to get stuff done. There is no, us as PMs, our job is to eliminate impediments, blockers in the way, get information for the team. We're not there to breathe down their neck and see if, how many hours they're working. Empowering a team to be self-sustaining means that they get the job done and there's no micromanagement necessary. It removes effort on our end to be constantly watching anyone and it gives the team, it creates a level of trust in the team that they are the ones in charge with getting a deliverable, with getting a deliverable done. In a self-sufficient team, a self-sufficient team doesn't depend on external factors to eye them and tell them whether they're doing well or doing bad. Of course, there are moments for these kinds of reviews, but in general, a self-sufficient team is continuously learning from their progress and they're continuously improving. That is the idea. So if a team knows that they're going on a path that's probably not aligned with the vision, they're forced to self-interest and correct course. Correct course in due time to ensure that deadlines and projects are met. A self-sufficient team is driven by collaboration due to the sense of trust that exists, a trust that us as managers have given to this team. And this of course extends to even outside of software teams. This is, these of course can extend to teams within a group of product managers, product managers and designers, designers, engineers, product managers, designers and engineers. So at the end of the day, this is how we work. This is how the teams should function and work in general. A self-sufficient team is accountable for their actions. It's accountable for the self-sufficient team is accountable for the delivery of a product, for when a product is late or for when or for any sort of break in communication or error that happens. So it is pretty important to understand that self-sufficiency does play a role in any sort of organization and in any sort of team as well. All right. So now we know why self-sufficiency is important and that's great. But how do we as PMs actually ensure that this is implemented or what can we do to drive the creation of self-sustaining teams? I'm going to take us back to the four points we extrapolated the four lessons we learned from history on how to drive self-sustaining teams or the patterns that led to the collapse of great civilizations and great older teams and how that's relevant in today's world. We're talking about stakeholder management, expectation setting, explaining the vision, learning to prioritize and feeling to communicate. So I'm going to start by focusing on stakeholder management and don't worry, you won't have to memorize these as such. I'm going to give you an intuitive way to remember them at the end of this towards the end with my blueprint. Let's talk about stakeholder management and expectation setting. It's all about people at the end of the day. You need to identify who your stakeholders are and they aren't just the internal marketing and sales teams hounding you when you know the product is going to be launched or if a bug has just occurred, your internal team members are your stakeholders. They are probably your most important stakeholders, I'd argue. They're the ones who ensure that you and the team function and deliver. As a PM, it's going to be your engineers, your designers, your QA team. Those are your core stakeholders, your core stakeholders or your direct stakeholders. You need to ensure that you have their buy-in and they're on board with you. Triple check everything always. That's when it comes to expectation setting. People don't necessarily understand what you understand and most communication breakdown occurs because team members are not clear about what's expected of them. Was the deadline to deliver the product yesterday? Wasn't it just to get our product out of staging environment? Was it this button supposed to be blue? I thought it was red. Always ensure that during communication, you and your team members know what's expected of each of you. That is critical and key to ensuring that your stakeholders understand and understand what's going on and are aligned with your expectations. Explaining the vision. Now, this is usually the biggest miss that occurs when it comes to creating self-sustaining teams. The PM has an amazing revolution. Let's think of this idea. The PM has an amazing revolutionary idea for the product. He or she knows exactly the customer pay points that are being targeted and how this product slash feature aligns with the company's ideals and missions. The PM knows exactly what they want. One problem, they do not share their vision with the team. In the majority of the cases, that's because they take for granted that everyone's on the same page. It's not because the PM wants to keep the idea for themselves or they don't trust the team to share them. We just usually miss that as PMs, we sometimes feel that everyone gets what we get. We feel that the engineers or QA team or designers are on board with what we see. It seems like such a simple and stupid error to occur, but that's what happens most of the time. And we assume that our vision is crystal clear to everyone. Most process-oriented teams fall apart because team members don't have a compelling enough reason to believe what they are doing has a purpose or makes an impact. They don't understand why they're doing what they're doing or the value of their work as we talked before. And as a PM, it's our job to ensure that the message hits home hard. Our vision is always a long-term goal. It's meant to be a stretch goal, but realistic. And it's your job to sell the vision. Now, we can't always get everyone on board with our vision, but it's important for them to know what that vision is. It can be as ideal as we want it to be. Our mission, the mission for our company is to eradicate world hunger in 10 years. So now that's lofty. Is that completely unrealistic? I don't think so. As long as we have all the mechanisms in place to get our product out in the correct manner. Next, we go to prioritizing. If everything is urgent, nothing is. And we've all been there. We've received a bunch of requests, our requirement, all marked super important and meant for yesterday. What do we do? This is especially relevant for self-sustaining teams since the expectation for them is to get the job done with minimal interference. Now, you can't expect a self-sustaining team to implode on itself and suddenly bombarded with an avalanche of urgent requests. This is where it's important to establish mechanisms for explicit prioritization. It's all a learning experience. And I experience this, I, by self-experience, this innate need to please everyone in my early PM days. It's just not sustainable. At the end of the day, no one is really pleased. If you try to please everyone, no one is pleased. And as the PM, you end up taking the hit for all of it. Now, how do you know what to prioritize or how does your team learn what to prioritize? This goes back to the previous point regarding explaining the vision. If the team has clear what the product is meant to be doing and not be doing, it'll be very evident what tasks and what requests are priority and what are not. Now, let's say it's easy to think about it this way. Let's not waste efforts focused on trying to do what's more important. Rather, focus on putting the more non-clearly important things on the back burner. If it doesn't contribute, if it doesn't move the needle in any way, making you closer to your vision. So urgent and important are two levers I'd recommend using for sure to make this happen. Freedom to communicate. All the points above are actually held together by the team being able to communicate. And I don't mean just saying things for the sake of saying, does that mean the team needs to talk about everything all the time? Not necessary. But there needs to be a safe space created for the team so that they're able to communicate anything that's on their mind. The worst thing to do that a team can do is leave conflicts and resolutions which then festering and create a snowball effect and actually eventually damaging the team. And this doesn't extend only to conflict resolution, but the fact that a team needs to believe that they can communicate without being shot down or reprimanded and that they can be themselves within that same space. And it's possible that not all team members are super on board with the idea of opening up in emotional conversations with everyone all the time. But there are many communication exercises that team can use to build up trust, have one-on-one meetings, use bottom-up communication within a team to ensure that everyone is heard and that no voice is ever left unheard. Now, all of these seem like a bunch of ideas. And I'm gonna give you a blueprint to remember this. And I think it's the most into more, I can think of a more intuitive way for us to actually remember what self-sustaining teams need to thrive. Stakeholder management expectation settings, explain the vision, learn to prioritize, feel to communicate. First letter is self. I believe that this is the path that most of us, as PMs, aspiring PMs can take to driving self-sustaining teams within our organization. And again, this doesn't, as I've mentioned, this doesn't have to be restricted only to product managers working with software engineers or vice versa. This is a blueprint that can be extended to any sort of team or any group of people working together to achieve a similar goal. Thank you, everyone. I am, it was super exciting for me to be here. I'm super, I was super happy to do this with all of you guys as well. Thank you once again, Product School for the opportunity. I'm super excited to receive your feedback. I'd really love to receive feedback, things you agree with, things you don't agree with, things I could have done better. I'm leaving my LinkedIn here on the end of the presentation as well. And yeah, looking forward to chatting with all of you super soon. Thank you guys and have a great day ahead.