Why product delivery excellence starts with united global teams

Speaker A: While it's very important to know your audience regardless of what setting you're in, and really know how to speak to them, as a product manager, it's also important to reflect on what brings you together in the workplace.

Speaker B: I think this is something which is the new reality for us right after Covid and after like seeing remote work being so popular and dictated by employees

Speaker A: all over the world, we try to

Speaker C: learn more about the world, about how people work, how products work. And uh, in this way we can build better products, we can educate ourselves, and we can think better and broader about the product we're bringing in.

Speaker D: Hello and welcome to another episode of Shine, a podcast by Star. Uh, and today we are asking the big question, how can organization create effective product delivery teams across the globe with individuals in multiple countries and time zones? So to help illuminate this topic, we are joined by Star's very own Liza Veretinakova and Anastasia Afonina. And then we're also joined by Nida Sara, who's a senior growth PM at Atlassian. And so in today's discussion we are going to be digging into the vast experience of DA experts, uh, and external guests focusing on managing product teams that are distributed around the globe. So we cover the culture that's needed to ensure a effective product team and then also the tools and structure of the team in order to do this. So let's jump into that discussion and the first voice you'll hear will be that of Lisa.

Speaker C: Hi everyone, I'm Lisa. I'm product manager here at Star. I have uh, quite a big experience of launching the products around the globe and since COVID uh, started we have distributed teams in multiple locations in Star locations. So really it was very interesting and exciting to work with this experience and I'll be happy to share it here.

Speaker B: Hello again, my name is Anastasia. Um, I'm delivery manager at Star. I've been here for eight years now and I've been in various projects and managed cross location teams for almost like all my career. And um, be happy to share the experience here with you guys.

Speaker A: Hi everybody, I'm Nella. I'm a senior product manager at Atlassian. I've worked at over three different countries and I have almost a decade of experience in product management and software companies.

Speaker D: Awesome, thank you for the intros. My first question, going to keep it broad is whilst delivering product with distributed teams around the globe in different countries, what are the most important aspects for a product manager to consider? And Lisa, I'd like to go to you first please.

Speaker A: Sure.

Speaker C: So I guess when you're managing and delivering the products across the globe, working with uh, teams in multiple time zones and in multiple locations, it is very important first of all to be synchronized. It is very important to understand the end game, game and to understand what's the product you're building, why you're doing this and make sure that the whole team understands what they are doing. The next step I would say, or the next stage would be defining the key roles in the pro, in the product and within the team as well. So understanding with responsible forwards from whom you are, you might expect some input and what is the output and afterwards also it is important to understand the culture. Right. So if we are working in different countries, interest in different cultures, we should understand what is the culture of communication, what is the culture of managing um, the product or releasing the product there, the culture of users or the culture of people with whom you're working in and like understand best practices of communication with this or that nationality and so on.

Speaker D: Yeah, that's something that I actually wasn't considering at all. Obviously you need to work out how these people are going to work together in different areas, but then you also need to understand how different people work. So Nida, maybe we'll go over to you on that thread, like do you have an experience of working with people in different cultures and the process you went through to build an effective working relationship when there might be a difference in culture?

Speaker A: Yeah, great question. Yeah, I've been fortunate enough to work with very, very diverse teams. Not just in a remote aspect or across different time zones, but also just co located in Sydney because Sydney is very diverse. While it's very important to know your audience regardless of what setting you're in and really know how to speak to them, as a product manager, it's also important to reflect on what brings you together in the workplace. Like for example in Atlassian we have five common values that are shared across most people and they get vetted before coming into the company if they do align and believe in those values. So while you do have to curate your messages and your style of working with people based on how do they work. For example, my designer really likes to work Async. They prefer videos over verbal communication. And then I'm also more inclined on making short loom videos or recording myself while talking on Zoom and sharing some videos with him so that he can review it offline. But the developers in my team are more uh, verbal and less visual and they prefer long form content. So those are some tactical differences. Across teammates that have nothing to do with time zones but are just bound to their personalities. I like to still try to tie the thread across all these different people and think about the shared or common bond or values that bring us together in the company. So while, uh, it's important as a PM to pander to all these different audiences, it's also equally as important to bring balance in that and not over index on any extreme.

Speaker D: Yeah, I think that what you're part of what you're saying is that actually because by, uh, the very fact you're working with these people, they've come through some kind of filter for your value system as a business, and therefore you can rely on those things or you have some idea of how they like to work or how they like to behave or what they believe because they are in your business.

Speaker A: Yeah, because when, you know, like Lisa, you were saying, we have to make sure that we try to, like, factor in someone's cultural context or where they're coming from, their background. That is awesome. And we have to be very inclusive and mindful of everyone's differences. But sometimes people's backgrounds may work in conflict with trying to get something done. For a, uh, good example that comes to mind is from Kim Scott's book Radical Candor and how she was asked to set up a team in Google in Japan, and she struggled with getting people to actually be vocal about their feedback, their concerns, their risks, because their culture is very quiet and they don't really talk up to their bosses and just openly divulge all their secrets. So that is counterintuitive towards improving a process or evolving a process with a team. So what I'm trying to say is know your audience, work with them and not against them, but also try to figure out common ground and common values that you all agree on and reinforce that in every single conversation. In Atlassian, we really believe in not screwing the customer. So every time we have discussions around how to build product, what is good, what is right, what sort of matrices do we have to think about while making a decision, or what sort of verticals or components that do have to factor in when making a decision, I'd like to remind everybody, hey, whatever core values is, we don't want to screw the customer and bring them back towards that point so that we can all align better.

Speaker B: As you were like giving an example from the book, I was also thinking about one of the books that I recently read. There was an interesting finding about the culture, uh, distance. So basically, uh, probably not the cultural difference, but the interesting fact that was described as an example of an airplane crash because the distance between the manager and the employee was quite high or big, that they didn't have a chance to communicate properly that there was an issue because culturally they cannot speak up to the person who are higher in hierarchy. And this caused a lot of issues and actually caused an air crash. Right. So those distances and those cultures with those distances are uh, like there's a whole range of those. And you should probably also consider those when building a cross natural or uh, national cross cultural team, cross location team. And I think this is something which is the new reality for us right after Covid and after like seeing remote work being so popular and dictated by employees all over the world. So yeah, something to mention as well.

Speaker D: So that's culture. The other part I believe of this discussion or important point is going to be time zone. So does anybody have experiences where you've managed to work effectively in extreme time zones like here? We actually, this is actually a case in point. It's not product, but we have three different time zones with about around a 12 hour, uh, 1012 hour gap here. So can anybody share how to get around the time zone issue when delivering product in multiple locations?

Speaker B: I can come in here a lot. One of the projects that uh, together with Lisa we delivered was across eight different time zones and people were located all over the globe. We had Japan, Vietnam, France, uk, Ukraine, Poland, United States and Canada. Uh, it was actually amazing how we managed to get that working. And there's quite a bit of different tips and tricks that we used. But probably the important thing is to be on the same page with the whole team when you actually have this availability. If you're eager to shift your working hours to meet with your teammates, maybe early in the morning or late in the evening, but instead takes them like few hours during the day. Then setting up your calendar to include all of those time zones and having this like regular meeting slot in the calendar for everyone if we need any ad hoc meetings or anything, putting a timely notifications in our channel and like in chat for the team when you're available or not. This is like a common, common sense things like hygiene that make all of the magic happen and to collocate virtually all of those eight time zones in one meeting. But I would say that was a huge challenge because Japan and United States or Japan and UK are drastically different time zones. Specifically when we are talking about product delivery.

Speaker C: I'd also add here, uh, maybe the aspect uh, of communication, like having one source of communication is also very important because uh, for example one Slack channel or one document or one um, one chat, uh, somewhere for the whole team where everyone posts the updates and keeps everyone updated. And also I guess it is important to sync up within each other and to plan the work because like, and in the end of the day we ended up talking with uh, Nastya, uh, and saying, okay, your morning, you're going to do this, this, this, my evening, I will do this and this. Until the time you wake up, I will have this ready and this up. So I must admit that at some point this time difference was also worth helping us because uh, we were working 24 hours and we were delivering the result like 24 hours a day. And that was really interesting and exciting.

Speaker A: So I like to, you know, test and learn. I don't think that anyone has actually solved for this. Your particular question. You're talking about extreme scenarios. We don't even really need to go to extreme. Even having two time zones like Australian time, Australian standard time and California's uh, Eastern time or Pacific time is hard enough because you're giving away so much by going Async, uh, and then on top of being remote, you don't have the same core working hours. You may have, if you're lucky, a couple of hours where you do overlap and that's about it. And depending on the function of the teammate who is further away from you, things can get harder and harder to a certain degree. If it's your designer as a product manager and you're working on a front end heavy product, then that becomes excruciatingly hard to align, update, involve them in important conversations and get stuff uh, rolling. So I would say you can look at what Apple is doing and what stances are they've had where everyone has to be in the office five days a week and co located and then you get to see the reddits and the WordPresses and they've been remote first for the longest time prior to Covid, only remote with almost no physical presence. Uh, globally. What we've been doing in Atlassian is we've acknowledged that this is a genuinely hard problem and that while we may have amazing tools such as Zoom or Figma or Miro or the Likes that help us get awesome collaboration done, Async, no one has solved for it and perhaps it's not something to solve for that's done and dusted that is very context specific and very much a mirror or a reflection of the product that you're working on. The team, the culture and the type of people you're working with. So my final TLDR with wisdom is test and learn. Know the the group that you're working with, the who, the what, the why, and then see what works best for you. Just like in my previous example, some people just prefer videos over text, some people prefer text over video, some people prefer waking up to Slack messages and so on. So make your own guardrails, set your own expectations and boundaries early on, test with your team, and see what gets you into that rhythm of good flow. Totally agree here.

Speaker B: For us, a little tom of a chat bot worked really, really good. So we managed to get timely updates from everyone and not disturb anyone in a chat separately or anything. We just had a chatbot that was asking like three key questions every morning and you wake up to just Slack messages to just see that, okay, we have all of the updates, we are unlocked and we can go on or we are blocked now. Need to figure out something. But everyone gave a little bit of a personal touch to their responses in that chatbot and it was not just like you're reading a machine update or something. It was also fun and this helped a lot.

Speaker D: Awesome. So we're actually naturally now coming onto tools and organizing work. So we've had the chatbot, which I assume was within Slack. Neela, you also mentioned Figma and a couple of other tools. Can anyone share? Like, it's probably not great to give like single recommendations, but like the types of tools that you may need to do this effectively and yeah, any, like single recommendations if you have a tool that works really well. So I'll pass that back over to nida.

Speaker C: Yeah.

Speaker A: Three tools. Something to help you draw, something to help you record a video, and something to help you chat. Won't name brands. Not playing favorites.

Speaker D: Very simple. So it's drawing, video and chat.

Speaker A: Yeah, I mean, what writing text is a given, so you have to have your Word or Google Docs or your Confluences. But yeah, I'm, um, not including that as a text because I think whether you're async or not or different time zones, you will have to write PRDs or spec docs in some location. It's either paper or digital. Most likely digital. I would say outside of those, anything that can help you bring in a visual, anything that can help you record, and then anything that can help you send text messages for easy Q and A. That's super, super helpful tools. And it could come in various flavors from aha to loom to figma to Miro to mural to the tons and tons of apps out there.

Speaker B: I would just add on top that Sunita something to be the single point of knowledge for all of these tools where you can just consolidate everything that you have. So if you have a newcomer to your team, a new member, you can just throw one link to the knowledge base and that's it. And he or she then uh, would find out what you need to do and how you need to find, where you need to find information, how you do that.

Speaker D: So makes total sense. So we've covered culture, we've covered time zones, we've covered tools. Now I'd like to talk about team alignment. If you have your six product managers in the office, you can go for lunch together. You can talk about the vision. What's different when you have team members of different cultures, time zones about aligning people around the common goal of making this product. How have you guys encountered that obstacle previously?

Speaker C: I would say that first it is important to understand like what roles do you have right. What role of each person is uh, within the team and then make sure that this person has enough input about understanding what exactly they are expected to do or not expected, they want or need to do. I would also add that it is important to keep everyone aligned to show the strategic goal to show where we're moving on. Because sometimes this might uh, might happen that if person is located somewh without a huge time overlap with the rest of the team they might feel kind of separated without having much communication and doing this work, your work from a kind of small cell might be sometimes challenging. So it is important to align everyone to show general goal that's uh, I guess first and second. I assume that it is important to understand that you're always working with the person you're always working with uh, with person who has their feelings, emotions, they have maybe feedback to share and this stuff and it is important to listen to even though you have like 30 minutes for, for ah a call. Um, but it's nice to ask their feedback on what they think about this and, and stuff.

Speaker B: Yeah. For, for our particular team it was really helpful to have like one once a week morning coffee together where we can just chat. Like not product related, not work related stuff but just about anything. Right. So you could like talk about your kids or your dog or book or a movie you've seen or anything. It was really like a uh, team bonding activity. But at the same time you learn whom you work with and you get to know people much better based on their preferences, based on how they, they're talking about what they like or dislike. This is really beneficial for the team. And during our releases and all the regression testing that we were going through in all of our locations, we would order some beer and pizza for everyone and just sit together with camera on or off, in the chat or in a video call, whatever. But we knew that we all have shared the same pizza at the same time. It's just knowing this is really fun. So that helped a lot.

Speaker D: Got it. Now, having remote teams, do you think that forces managers to have their team be more autonomous than if they were in the office? If yes, how do you enable different members of your team to work autonomously while still also getting to the good product at the end?

Speaker A: Yeah, that's a great question. Honestly. Yeah, I think it totally depends on the context and I always like to answer these type of things by going very broad, breaking down into a concept and then actually following up with a practical example of how it would be executed or operationalized. It depends, honestly, and I know that's a very cheeky answer, but again, it depends on the team, your level in your career, and also the product or the type of thing that you're trying to deliver. If I were to piece the example that you gave, it would be hardest for someone who's just starting out as a PM and who needs a lot of management support to understand what actually constitutes the how towards the vision. But if you put senior devs or staff engineers along with senior PMs together in a room and the vision is clear enough, it's broken down in a story that makes sense and everyone has genuinely aligned to it, there's very little handholding needed. You don't really need to tell the pm, please do X, Y and Z and then follow that up. Uh, with A, B and C. Neither do you have to do that with a dev team. Right. So I think that it's been interesting seeing grads join Atlassian. It's been very interesting also for me to transition from a platform team into an experimentation and a growth team, which in and of itself has been sort of like a career change for me. I do acknowledge that in a remote context, with people dialing in from PST time zone, from Amsterdam and from Sydney, from Bangalore, has been hard. But you got to ask yourself, what sort of company are you working for? Do you have a halo of time zones that you fall under and that you can collaborate with? If yes, can you get some zoom time or some face to face time with the other person? If yes, then your life becomes a Lot easier, right? Then you just have to set up some time with your manager on a weekly basis and have very intentional conversations on what issues you're facing and then ask them for support. And hopefully they're not just supportive, but they're also competent enough to give you those answers and you know, spoon feed you how to execute. But if you don't fall under that, that halo of shared time zones, like you're not working with some overlap, at least like an hour of overlap, then you have to ask yourself the next best natural question, which is, can someone sacrifice their core working time zones? Can they meet me once a week at a time? That's very uncomfortable. So I'll give you a specific example. We have one project where we have folks dialing in from Utah and Bangalore and Sydney. That is an impossible, impossible time zone. It is impossible to align that without breaking the rules of physics and teleporting yourself. Right? What we do is we just beg for forgiveness and set up times at 1 or 2pm in Sydney, which makes it a miserable 10pm or 11pm in Utah and then a 5am or 6am in India. It is very, very miserable for these both extremes. And um, we get to have like the more comfortable time zone. But it's something that everyone understands happens quite rarely and they're willing to sacrifice just to get the ball moving forward and unblocking the team. So that's why I keep saying I'm going back to what company are you working for? What kind of teams are you working for? What sorts of complexities are you dealing with? It's not always a hard and fast answer. It's never a binary. It's very, very subjective. So in this particular example, uh, we had one project, we had three, four different time zones. It was impossible to align it. Even if it meant me waking up at 3am or M4am, we still wouldn't be able to bring the India team on board or the US team. And we had to make a sacrifice, but we made it intentional. We made sure that we did all the prep work before joining into the meeting. We tried to read and align as much on a word doc or via Slack or some other Async tool. And then we use that face to face meeting time to really kind of dig into the hard problems that cannot be solved on written or videographic, uh, or visual content. So I hope that kind of gave you some, some insights as to how I structure this problem.

Speaker D: Yeah, the key takeaway that I think is that, uh, or one of the key takeaways is that if you do have to meet when it's inconvenient for anyone, try and do as much as you can before or like Async. So when you're on that meeting, you're like, efficient.

Speaker A: Yes, absolutely. And again, it only matters if there is that particular chance. And I would tell you another thing, which is if you're working with those time zones, ask yourself, why is that happening? Who's behind it? Right. We, uh, have a rule in Atlassian. If you fall, uh, below or above six hours, you're not in the core team. You can't be in the core team. And I think that's fair. That's fair because the IC role for a PM is extremely collaborative and also very executionary. You can't get someone who's both collaborative and executionary and ask them to do willy nilly and do whatever that breaks the laws of physics. We are organic material in the end of the day. And unless Elon Musk speeds up his work with the neuralink, we can't upload our brains to the Internet. Until that happens. We have to grapple with the fact that humans need to sleep, need to eat, need to wake up at certain times, need to have some sense of work life boundaries and even work life balance. So ask yourself, why are you working? Why are you in this predicament where you have six different people dialing in as a core PM and an IC role, not an M role, not a management role where you have to execute and you need to collaborate with these people dialing in from all these places. Can you do something very painful and put in a rule that if you fall outside of these core working hours, maybe you can't be in that particular product team, maybe you should be in another adjacent product team.

Speaker B: The balance needs to be everywhere. Right? We are talking about work life balance. But the balance in the team also needs to happen. And if we have, let's say more junior people that need more time as the team, they need to be at least a few hours like co located.

Speaker D: Right.

Speaker B: Not maybe in the same location. But we shouldn't be talking about extreme time zone changes because it just, just makes challenges more and more impossible to me. Right? So it makes no sense. Why do we need to even make our life harder?

Speaker C: Yeah.

Speaker A: And, uh, there's a sweet spot, right? There's a sweet spot between that you can leverage or harness the power of remote async work and, you know, distributed teams without having to break yourselves. I like the fact that tech pushes through humans to really try and solve impossible or seemingly impossible problems. But I also think that there's a balance between being absolutely negligent of the fact that some things are hard facts and being very, very conservative and never wanting to tackle a very, very difficult and risky problem. Like we can send people on the moon, you know, we can do those difficult things, but we can't yet send people into Mars. That's another frontier. We have to really think about it. Till now it's really impossible. So. So, yeah, like, you know, it's good to be human. What can we do that would bring in that beauty and the magic of being distributed whilst also safeguarding our sanity? There is a good sweet spot and it depends on the team that you're working for and the product that you're building. And also your, your stake in the ground in your career, like where you're at, what level you're at. If you're building something that's back end heavy, PMs can take a step back. If you're building something that's super front end heavy or super product or consumer centric, maybe you have to be there quite heavily involved. If you're working with a large async design team and you need them to be with you 24 7, then perhaps it's not a great idea to organize teams very far apart from each other. But that being said, you can always say this role is only available for people who can work Sydney hours and find lots of nocturnal folks who just like to game all night or work all night and sleep during the day and that just works well for them. So I know one of my colleagues has issues with sleep and they sleep in the day and work at night and that just suits them. So they align with northern European time zone quite well.

Speaker D: All right, got two questions to bring us to the close. First one a bit more open. How do we think the role of the product manager is going to change over the next five to 10 years?

Speaker C: I think that uh, eventually product managers might become kind of advisors. Right. Because uh, I can see that there is the tendency of doing the work and separating the work on a more granular and granular level. So for example, like six years ago when I started this product manager, um, I started at a small startup, I was doing almost everything starting from working with the QA team development team, writing the documentation and so on and so forth. And um, now we are heading to the directions when on some project I do the high level strategic role, defining where we should move, uh, working with customers, stakeholders and stuff. So I Guess that the product management role will be a more granular, so you product managers will have smaller maybe areas of responsibility. And I guess at some point this might get to the consultancy, but that again depends on the products that we are building.

Speaker A: So that's, interestingly enough, we had Marty Kagan come into the office this week to talk about product management. So for those of you who don't know who Marty Kagan is, he's like the godfather of pm. He's worked in like literally everything, Ebay, Netscape, you name it. Someone asked him the same question. What do you think PMs are going to do in the next 15 years? He had a very interesting answer, which I think I actually quite genuinely agree with. He said he's been in the industry for 40 years and he hasn't seen PM work change at all. I agree with him because ask yourself, 400,000 years ago, humans came on Earth and wanted to eat. And it's 2022, it's almost 12 o' clock here and I feel hungry and I still want to eat. The nature of food may have changed or the type of food may have changed, but your core needs stays the same. So the products that we work on will evolve quite drastically. We might see ourselves finding ourselves do more VR stuff or AR stuff, or there's been a rise of blockchain and cryptocurrency industry over the last decade. We'll see more evolution in tech. Some of it will come because hardware will evolve and then PMs will have to catch up with that. Uh, some of it because just the actual computing and underlying processes will involve. But the core PM role, I don't see them changing a lot. I actually see it getting deeper and more polished. I have experienced that myself in the last eight years, uh, working across different software companies. I've been in four so far and I've done everything from B2C to B2B, platform growth and even like just plain browsers and newsfeed readers. You still have to write a prd. You still have to write some sort of user story in some shape or form, in whatever language for your team. You still have to help them prioritize. You still have to make sure that you can communicate what impact you've brought to the business and then tie it back to the revenue or whatever profit or big hairy, audacious goal you've set up for the company. So you're very much a, uh, gm. You're very much an artist. You're also very much a scientist, but perhaps you can Delegate some of those works more heavily and you can lean on a lot more excellent people in your team. So an excellent researcher, an excellent designer, an excellent engineering manager and so on. So there'll be a lot more hands on deck, but your role will become a lot more polished, a lot more deeper, and uh, a lot more critical for the business. A good PM can make or break what they're building.

Speaker D: And then final question. How do we think better product management will make the world a better place?

Speaker A: I found myself laughing because I was thinking of this a lot and I was posting on, um, Instagram. I'm very social. I was like, software is evil. We try to steal your data and recommend products to you and follow you. We even listen to you sometimes and go like, okay, you know, so and so said they're interested in a trip to Italy. Let me just splash, you know, airfare ads and like video ads of Italy all across different, you know, products that they use on their phone, uh, on their laptop. And you're seeing all these ads all the time. A lot of it is also misleading on purpose. Like the terms and conditions sheet, we make it infamously very large and long so that you immediately as a consumer go like, I don't want to read this, I will just sell you my kidney. Let me just go next and watch that, you know, sign up for TikTok and let me watch that TikTok video. So software in a nutshell is pretty evil, but so is a lot of stuff in life. If you don't have people with strong moral values and strong ethics behind these companies, behind these projects, thinking very carefully about what they're doing, what they're holding, the power that they yield in their hands, in their day to day life, then it can very easily go astray. A good example, and maybe also a really shitty example is I like this parable of uh, some soldier who was responsible for manning this crazy nuclear bomb. And although the commander had at that point, was it World War I or World War II, not even sure if this is anecdotal or if a real example, I'm going to go Google it after this podcast recording is done. But he was being asked to set the bomb off and literally kill an entire nation. And despite him knowing his role and his duty and what was being asked of him and the line of hierarchy, he stood his ground and said, that just doesn't stand with my, my belief system and my, my morals. I'm not going to play dirty. These are civilians. I'm m not going to nuke the Nation. And there's this parable that that was the reason why we didn't end up like blowing up the earth. So I strongly believe in the power that we yield in software. It's not just PMs, but the whole collective, you know, managers, GTM, product managers, devs and designers too, I think we can influence pretty quickly. You see that with Cambridge Analytica, uh, Facebook and so on. So know yourself, know what you really value and you care about, where your ethics and morals stand. And whenever you come across a decision that could possibly be, you know, morally ambiguous or negative, try to see if you could build with the right intention and save something, salvage something for the customer. I totally agree.

Speaker C: For this I would maybe add as far as product management is quite broad specific work and it's not often when you work on some very like short area of responsibilities in order to do a good product, in order to bring your product to the success, you have to read and you have synthesize a lot of the information. That is why I guess that uh, as far as the progress, moving on, uh, product managers learn and we use psychology in order to better understand our users. We use data analytics in order to understand on like mass mathematic level how it works. We try to learn more about the world, about how people work, how products work. And uh, in this way we can build better products, we can educate ourselves and we can think better and broader about the product we're bringing in.

Speaker B: And I think if uh, we always had like only good product managers, we would never see a service like okay, no names, but some really weird browser or search engine in the market or maybe some weird services where you cannot find what you're looking for after spending 10 minutes in the main page. Right. So people will be probably nicer, calmer, you know, sort of that thing having better products.

Speaker A: Having better products.

Speaker B: Exactly. So it's like getting users not irritated.

Speaker C: Mhm. So better product manager is going to do better products and better products will make people happier.

Speaker A: This is how it works and we

Speaker D: can end on that. So guys, I think we did a good job of creating a resource for product managers looking to deliver products, uh, multiple times. As we talked about tools, we talked about culture, we talked about alignment and we talked about the impact of this on how the world is going to become a better place. So I want to thank all of you for joining. Anita, thank you for joining as our guest. If anybody wants to get hold of you or wants to ask you any questions, should they just go to LinkedIn?

Speaker A: Yeah, LinkedIn or Gmail. Yeah, Instagram, if you can find me. If you can find me. But yeah, definitely. I'm pretty online.

Speaker D: Amazing. And Lisa Anastasia, where can people find you?

Speaker B: LinkedIn.

Speaker C: Yes, LinkedIn, Instagram. Um, we're all there.

Speaker D: Amazing. And all those links will be below on the episode blog post or in the show notes. Guy, thank you so much for coming on.

Speaker A: Thank you. Thanks for having us.

Speaker D: And thank you so much for listening to this episode of Shine, a podcast by Star. Uh, I'm very confident that we answered the question of how to create effective product delivery teams across the globe when you have individuals in multiple countries and time zones. So I want to thank Nida, Anastasia and Lisa for the expertise on this episode. If you have any feedback about the show, please leave a rating or review on Apple Podcasts. And of course, thanks to you for listening.