 Thank you so much for the introduction and welcome to ProductCon. I am very excited to be discussing building a high performance async product team and four hard lessons learned. I think before we even get into that, I'd love to introduce myself a little. My name is Anik Drumwright. I'm the COO of Lume. Lume is a video messaging platform for work. At a dinner party, how I would describe it is we're basically a TikTok for enterprise, right? So, as we all know, there's just been a huge growth in video in our everyday personalized, specifically async short form video. And so Lume is simply bringing that to your workplace through making it easy to record videos, screen share, grab a link, send it, be able to collaborate on it and really scale information and knowledge across your company and across customers. I joined Lume in 2020 as the VP of product. We're currently at, we have over 20 million users in 232 countries, so absolutely global. And I started as a VP of product and over the last year I have transitioned to be the COO overseeing product operations, marketing and data. And before that, I was at TripActions, which is now Navan and I joined as the first product manager to build out the product function and eventually became the global VP of product. And before that, I was at Uber and then my pathway into tech was a bit nontraditional starting with feature America. So if you're someone who's product curious, it absolutely, I feel like product is an unbelievable role for people from diverse backgrounds. And just a little bit about me, these are my furry friends, Ollie and Muddy. I love to travel. I'm so lucky to live next to my nephews and my niece. So I spend a lot of time enjoying them. And with that introduction, we will go get straight into it. So I've been thinking about kind of working on sharing some of my hard lessons learned for running an asynchronous product team and really a globally distributed one. I think the biggest mistake I made earlier on was not having a really clear framework as to what's synchronous versus asynchronous. And I think having that framework enables everyone on your team within your organization to be successful. And I think the golden rules that at Looneyville ultimately landed on is anything that's discussion oriented, that is synchronous. If it is nuance where you need to hear other's perspectives where you need to ask clarifying questions, lean into synchronous communication, schedule that meeting. If it is explanation-based context sharing, recommendation where a huge fan of pre-reads and pre-watches at Loom, that is all done asynchronously. And the reason why we've really landed on that is we think it creates a ton of transparency within the organization around, what is this project? How are we thinking about it? What was the recommendation? And even if you aren't in the meeting, you're able to access that knowledge. And it also creates a clarity of thought for the person that is presenting and also for the people that are joining that discussion that if you can take the time to share your ideas asynchronously, if the audience can take its time to digest, then everyone's entering that meeting with just a ton of context and clarity of thought around the topic. And the one that I would add that it's not in the diagram of how Loom thinks about is this a synchronous meeting? Is this an asynchronous meeting? It's just if there's something that has to do with a really complex execution or we need to create a lot of urgency around, I am still a really big fan of having a weekly standup or a bi-weekly, two or three days a week standup just because I think it creates momentum around any given project or spike. So my number one first rule for making a successful async product team is just to begin by outlining. What do you as the leader, as the product manager believe should be synchronous and what should be asynchronous? And we have this little diagram that we always use out Loom, which is if you need an immediate response, it's a quick answer, use Slack. If you're, can your message be communicated and understood in two sentences or less? If the answer is yes, then you can use Slack, but if you think it may be misinterpreted, just create a quick Loom and send it over. I definitely lean into that for feedback. And then it's talking real time the only way to achieve your objective given it's the most extensive type of meeting, make that a virtual meeting. If not, it can always just be a Loom. My second lesson is just really investing and leaning into tools that supports context, empathy and expression. I think a lot can get misunderstood in a remote global setup. And so being thoughtful about, yes, what you use for synchronous communication versus asynchronous communication, but also what tools you choose to use can be hugely beneficial. My funny path into discovering Loom was I was trying to give design feedback all within Slack and it was getting really, really misinterpreted. And so when I found Loom, I realized that I could really accurately express what I was trying to convey visually, but you could also hear the intent of my voice. And that really was hugely valuable from a collaboration perspective because all of my empathy was getting stored in the short form video and the real intent of my message wasn't getting lost. So on our product team, we use video messaging Loom for framing, complex explanation and feedback a ton. We also, so generally if I'm going into a product review, we have a Loom that is walking through a NotionDoc that gives the framing and then within the NotionDoc, right, you're still able to give feedback, ask questions and that's just really valuable because both layers are very collaborative. And then I think the next kind of piece of, making sure that the workflow is collaborative and empathetic is just being really proactive as the product manager, as the product leader on being proactive on sharing context. So on Mondays or every Friday, send out a Loom on what's top of mind for you? What were the progress plans and problems across the product organization, across your product team? So everyone can have insight into what's top of mind and how is the work going for the team? I also think it's a wonderful moment to highlight great work, right? It's a moment to build connection across your global team. And I think the next one, that's pretty simple in terms of just like leveraging really rich channels that you have is just leaning into public channels versus private channels. When everything is asynchronous, transparency becomes really, really important and being thoughtful as to when you have a private channel versus a public channel can really increase that sense of collaboration and ensuring that everyone has the tooling that they need. So the big three that we have at Loom are Loom, Notion, and FigJam. And we love all three because they are collaborative by design. It's fun to collaborate on them. I have all the emoticons I'd ever want. It is real time and it is by design collaborative. But all three of these tools are asynchronous meaning that anyone can go back to them and understand that clarity of thought and there is just a real transparency there, which I think is very much underlying to having a healthy asynchronous product organization. All right, and our third lesson is make async prep a prerequisite for data design and product reviews. I would say that this should happen whether you are at a remote company or a hybrid company or fully in office having really, really high quality looms and documentation going into a design data or product review I think is a game changer and I will never go back. So I think the reasons why I am so passionate about this is I'm sure many of us have been in a design review or in a product review where a few different things happen. Right, people jump in and ask questions and the designer wasn't even able to tell the entire story arc or tell the entire customer journey. And if people had just slowed down they would have realized that the designer or the PM was gonna get to it. I think another alleyway that we've probably all been in before is someone dying on a very specific part of the PRD or a very specific risk when the big meaty question that the product manager actually wanted to talk about was something much higher level and much more related to the total impact of the product. And I think what pre-reads and pre-watches specifically allow PM's designers analysts to do is tell the story of, hey, this is the entirety of the body of my work this is the entirety of the customer's journey. And during this review, I really need help on XYZ thing. And so I think if I am the product manager, the designer, the member of the data team I'm just getting much higher quality feedback. And on the flip side, if I'm the person reviewing I've now slowed myself down to get context for the review to prepare my thoughts, to organize my questions as to, hey, what do you actually believe is the riskiest piece? And I think this really comes down to that first lesson of knowing what is synchronous good for and what is asynchronous good for. And I think this is like the most important muscle for specifically a product team to build is to start doing pre-reads, pre-watches, ahead of reviews to make sure that you are using that really, really precious synchronous time for discussion rather than for context building. Here's an example of Jenny on our team kind of sending out where we're releasing a new desktop recorder in a couple of weeks and she's sending out a pre-watch loom on, hey, this is launch update. These are all the details. This is actually a really, really robust one, but it was so valuable to hear her voice over. So when we went into the review, we knew exactly what we were talking about and where we should be spending the meat of our time. And I told Jenny I was gonna put this in here and she was like, make sure you tell them that this absolutely should be used for an in-office setting and also an out-of-office and also a remote setting because I think all of us who are building products that loom right now probably would never go back to a product review that didn't have a pre-watch just because it gives the voice over of what you're trying to achieve and what you need to achieve as a PM. So succinctly and so effectively and it's great because she can now share this loom with everyone who's in the review, but also her team who may not be in the review. And so everyone's operating with that type of context. So my fourth lesson learned is probably no surprise, but I think when you're talking about building a product team that is largely async that is remote in nature, hiring PNs and EMs who see themselves as leaders and not just project managers, I think is even more important than it already is. And the reason for that is in a remote setting or in a hybrid setting, soft skills, communication and thoughtful routines to support that communication and to support that transparency is even more important and being able to adapt. In many ways, all of us who are working right now and have been in the office for the last three years we are rebuilding what it means to be a working person, right? And we're all pioneers of this new way of working and to need to really, really carefully hire to find people who are obsessed on building rituals that create transparency and urgency and ownership and collaboration, but also you need people who are flexible who are gonna say, we're gonna try these few things for the next couple of months but then in two weeks time it'll be time to update our system and we're gonna, in two months time we'll probably have outgrown that system and we're gonna reinvent what it looks like to be working asynchronously or synchronously in a remote context. And so I think it's so, so important that specifically the product manager and managers are really seeing themselves as the leaders of the team of the product area and not just project managers. I think in a remote context, right? That ability to influence, create urgency and invest others is just crucially, crucially important. And it's often, the interesting thing that I find is that it's like pretty easy to pass the buck in a more async environment, right? So you need an increased ownership mindset, right? There's something about being physically in a room together you can all look at one another and be like, oh yeah, yeah, yeah. Like I'm gonna go the extra mile for that person but I think in an async setting it can be at times, you know, a little easier to make the work less personal because you're not seeing that person face to face every day. And so you need someone, you need leaders who are leading the team from a product engineering design perspective that are always up leveling what it means to be a team to ensure that there is collective ownership. So summing it up, kind of my four top tips for an async remote product team is start by doing the really basic foundation setting of defining what's sync versus async for this communication for your product organization, for your product team invest in tooling that supports context and empathy. I think increasingly in an async remote environment this is so, so important to building a healthy high-velocity product team. The third, maybe my favorite simple one is just make async prep and pre-watches a prerequisite for data design and product reviews so that your team can get what they need and so you can be as thoughtful as a leader as you possibly can be. And then higher PMs and EMs who see themselves as leaders and not project managers because in, you know, a remote hybrid context what's required of us is evolving. And so you need people who want to lead through that change. And that is it. Let me know if you have any questions. Again, thank you so much for taking the time to come to my session. And I hope you have a wonderful time at ProductCon and please reach out if you have any questions.