 Right, thank you everyone for having us to speak to you all. Today I'm joined with two colleagues and we'll introduce ourselves in just a second. But today we're gonna speak about how business agility fuel development of Lucid Spark. And we'll give you a little bit of story behind Lucid Spark and really these principles more importantly about business agility. But first to kind of talk about who we are, my name is Jerem Chung. I'm a Senior Director of Product at Lucid. And overall I'm like over some product managers that support Lucid Spark and other Lucid initiatives around user engagement, things like that. I have a weird background. I used to be a scientist, turn product manager and I love to mountain bike to box, big pastries. But most importantly, that cute picture of me and my family, we are family adventurers. I am also joined with my good friend, Lindsey Martin who will introduce herself. Hi, I'm Lindsey, Director of User Experience with Lucid. I lead the team of designers who are conjuring magic for our visual collaboration suite. I have a background in design research and I have applied that across the range of industries. And I enjoy crossword solving and getting outside with my dogs who are also pictured here. So cute. And Andy. Yeah, I'm a Senior Director of Engineering at Lucid. I lead the Lucid Spark engineering team as well as some other groups across our organization. I have a degree in computer science and math that I received from Northwestern and Brigham Young University. I'm a father of two and I've captured all of my favorite things in Lego form in this photo here. So love Lego, love a bunch of other things associated with that and building things, video games, you know, all that stuff's fun. Love it, love it. So today we're gonna talk about business agility and specifically we're gonna go through the lens of how Lucid employed business agility strategies to launch our virtual whiteboard, Lucid Spark. But first we want to level set on how we're defining business agility. So what is it? So according to the Agile Business Consortium, they define business agility as agility in an organization's culture, leadership, strategy and governance that adds value to all stakeholders who operate in uncertain, complex and ambiguous environments. All those words basically mean to say is like there are frameworks and there's a culture behind an organization that leads to agility that we can navigate whatever may be thrown into your path whether it be a pandemic, a war, right changing markets whatever it may be, these frameworks that we hope to outline today around business agility will really help your business or your team or whoever it may be really be more agile to kind of make the decisions you need to make. So why should you implement business agility? We really want to quickly run through these core different ways. First, it improves cross-collaboration across your organization who doesn't want that. Second, it keeps products and future products really competitive, right? Cause you can be adaptable with it. Third, aligns all teams to a shared larger vision. You'll hear themes of that really resonate throughout the presentation of why that is so important to. And last, it helps teams bring features and products to market very quickly. So the framework that we're going to go over today is really bucketed to four main groups. First of all, customer centricity, why that's important to agility. Second, rapid decision-making. Third, active activity and flexibility. And fourth, continuous delivery. And these four business strategies really were employed throughout the process to make the development and launch of Lucid Spark highly successful. But first, let's kind of hear a little bit about the origins of Lucid Spark from our friend Lindsay. Yeah, so let's travel back in time. Summer 2020, the world changed pretty abruptly overnight. We answered a global pandemic. And one outcome of that was that a lot of people who were used to working together in offices on teams suddenly were trying to collaborate from their bedrooms and their kitchens and their dining rooms and their backyards and their closets. And we collectively had to adopt and adapt to a new way of working. And the way that that played out at Lucid was that there was an urgent market need, like a need surfaced for new technology solutions that could not only replicate, but improve in-person collaboration and creativity in a virtual setting. So we used to gather around whiteboards and we now needed a proxy for that to use from our closets and bedrooms and kitchens and dining rooms. So online whiteboarding solutions certainly existed two years ago. And in fact, we had a product called Lucid Chart that certainly existed two years ago. But we saw an opportunity to apply the strengths of our visual collaboration platform to build an innovative solution that could better enable distributed teams to brainstorm together than seamlessly move from ideation to planning. So go from really ambiguous to really concrete. And the teams at Lucid set an ambitious goal. So again, this was an abrupt market need, like everything changed overnight. We set an ambitious goal to build and launch Lucid Spark in less than six months. So while doing so, we were also adapting to a fully remote way of working. And that was really challenging in a lot of ways. And the agility strategies that we employed allowed us to build and launch product offering that met the unique challenges that our customers were facing while adapting to new ways of working ourselves. So fast forward to today. We picked up a lot of learnings along the way, both in terms of product development as well as our customers and our approach to design. But also how our teams work to remain extremely agile and flexible as we continue to grow the Lucid Visual Collaboration Suite. Awesome. It was so meta that we were building a solution for hybrid work when we were hybrid working and figuring it out ourselves. It was wild. At times we were even hybrid. It was full remote. That's what it was. Well, part of this, let's start, Lindsay, with customer centricity. You and your teams really dove into this and the importance of why how we create Lucid Spark was because of this. Yeah. I mean, customer centricity is at the heart of everything we do. Our UX designers, our product managers, our chief product officer, speak to a minimum of one customer per week. And oftentimes it's a lot more. And we were able to succeed in this incredibly ambitious timeline because we were customer centric, because we knew already how this product served our customers. We knew, and we knew already how our current offerings were not quite meeting their changing needs. So it was quite easy for us to make the pivot and quite easy to get the buy-in that we needed from the people who we were asking to make this change because they also are engaging with our customers every day, right? Or every week, and they also had heard these same pains and knew exactly what we needed to do to be successful. Specifically, customer centricity became really important during the development of Lucid Spark. We had a lot of constraints that we were working under, time being a huge one. But also it was a completely closed development process. So we were not speaking publicly about what we were doing. Everything had to remain very confidential. And so that made it difficult for us to do traditional user testing on our product. And so the foundational understanding that we had about customers and the way that they engage with our product and the context in which we work really was a boon to the design team as they had to make decisions very quickly without all of the data that they're used to gathering for each of those decisions. So customer centricity is a mindset that keeps our customers front and center. And it's something that we really embrace and believe in at Lucid. So the next strategy we wanna cover is rapid decision-making. Jerem, how did you see us employ this strategy during the development of Lucid Spark? Oh man, like with rapid decision-making, I mean, we had less than six months, we were making decisions quickly. Felt like literally every second sometimes, every meeting there was a new decision. And really when we think about rapid decision-making, it is this collaborative, iterative and transparent process to really make sure that these decisions are not only fast but also sustainable and are the right decisions. And really important to keep these teams moving against these really, really, really tight timelines. We didn't want any blockers, any, like whether they be what button color should this be or like how are we doing pricing and packaging, right? We didn't want any blockers. We had to go quickly and get that information and that data to really make those decisions. But overall, once again, we had these frameworks about empowering teams and using these frameworks, right? Likewise, to make these decisions quickly with these strategies that really helped propel us forward. So I'll give you some examples of some that we employed on this rapid decision-making. First is like the importance of just conveying and emphasizing this vision and these principles. I remember Lindsay and her team having design principles really salvaged early on, so that when we went down the line and had to be like, okay, do we do this, which is more clicks or this which is less? It's like, okay, what do the principles say? What's the why? What's what the customer needs, right? Or even thinking high level. When we think about, you know, Lindsay mentioned going from idea to planning as far as like how we think about Lucid Spark, this vision was really important that we make sure we can cover this customer journey. And if there's something outside of that customer journey, we should ask ourselves, why? Is this the most important thing we need to work on? Always, once again, going back again and again and again towards this vision really helped us make sure that we were focused. But more importantly also removing this noise, right? That when there are things that we decided that we're not part of our vision or part of that focus, we could actually kind of remove it out of the way, right? Put it in a parking lot, we could kind of talk about it later. But what was important too with this, with having a vision is actually sharing that vision. It was fine if I knew the vision, right? But it's better if everyone else knows it. We can make more decisions concurrently, independently and that alignment is a lot quicker too. So when we think about rapid decision making, really that foundation of the vision becomes by which we can, is a platform to make us go faster, right? But not only is it kind of our vision as directors or individuals as PMs, but even as a whole company, the CPO and the other executives were absolutely essential and crucial in this process. That we were communicating a lot with them in these working sessions together, right? In these executive alignment sessions together, not only to make sure that we were on the right path, but likewise that they saw that the path forward was what they were also hoping for. There's a lot of back and forth, but through that kind of really transparent conversations, communications, it really kind of helped us make sure that we were making decisions quickly. One other framework that we loved that happened pretty early on, it was actually Lindsey who was like, actually we needed to have a really simple framework to help teams know now, next or later. And that just became our adage, now, next or later. And it was funny because once I was a little meta, we were using one of our early prototypes for Lucid Spark, right? Helping our teams come together. And whenever there's a decision or just like something for our roadmap, we'd have to take a step back and say, okay, is this a now? We need it absolutely this sprint or this month, or is it next? Next month we can get to this. Or do we need this now because it affects the next, right? There's a dependency. Or is this later? Is this even after launch? Is this next year, right? When it comes to six month deadlines, you have to be very, very rigorous and almost cutthroat, it's not the best word, but make sure that you are trimming the fat too. Make sure you are doing the now when you have to do now and the later and the next can be in those buckets. But whenever we made those decisions, once again, we communicated about them, we aligned them to the vision and really just talked about the why of why we're cutting things down. But naturally as part of this, when we think about making these rapid decisions, what the downstream repercussions of that would of course be on the teams. How do they become adaptable and flexible? How do they actually think about these decisions and are bought in? So I'm gonna turn over to Andy to talk about this. Yeah, I know making sure the teams adapt, has that activity and flexibility is an important part of being able to respond to these kinds of changes. And really it's all about practicing on a regular basis. So Lucid, we follow agile practices specifically scrum methodology. And that gives everyone this opportunity on a regular cadence to, engineers are able to dive deep and along with everyone else on the team, get work done over a period of time and then kind of surface, come up for air and look around, see what has changed and then dive back in and work and focus for another couple of weeks. And so if you're following those kinds of practices then you're already designed around having flexibility as new priorities come up. And now these pivots come along but it doesn't happen too often. But when it does happen, you're ready for it and you can change. But sometimes with a huge pivot like this one was where we were completely changing what people were working on to build a whole new product. And especially on a distributed team it requires a lot of communication to make sure you have that alignment early on. And I still remember the meetings we were in early on trying to make sure we had that alignment. Those paid off huge dividends in the long run. Oh my gosh, they did. And when we think about the order, I mean, I think it's something that we started productionalizing too, Andy. We started thinking about what are the communication patterns we have to establish? Who needs to know what and when? And really when it was a, when we came back to the company, right? And said, hey, we're doing Lucid Spark and we're launching in six months. I mean, the company could easily be like, oh my gosh, what are we doing? Is this a right decision? Have we made the decision too quickly? And that's kind of where the alignment comes on. And it's important once again, kind of going back to that vision of letting everyone understand the why. Understand why we are pivoting, why it's happening, why it's important. And even some of the data that we had seen, right? Like, hey, we just had a pandemic. This is a great opportunity. And like, here's how we see work evolving in XYZ. And like, this is how we think it's not just a two-month type of remote work thing. This is why it might go on forever. And here's why the market is nice, right? Although sometimes to some of us, it feels like extra details. For those that are in the weeds, those extra details are actually really valuable. And what's the worst? They ignore some of it, right? And really what's more important is that they're bought in. It's like, okay, this is a thoughtful decision even if I don't understand everything. Or this is, yeah, these are similar questions that I would have myself. The next thing, of course, if you're on this team to be scared of, it's like, wait, six months, are we crazy? Well, we were a little bit crazy, but it was important and we did it. Everyone else was like, yeah, it was crazy. But really creating these clear expectations on effort and timing was so essential to make sure that no one felt like they were under water or over their head. That here's the expectations, but even then like our executive team, they weren't like holding us with a dagger, right? It was more like, hey, here's like what we think, can we do this? How can we do this? And anytime there was a pivot or something that we found out, communicating that back up about like, hey, executives, we had to be a little more adaptable and flexible on this aspect. Really created trust between the whole group, but also allowed us to make sure that there was breathing room and we could actually get this work done. This last one is when asking these people, it's important to make it asking and make it a choice and not necessarily fully tops down. A lot of engineers are like, oh yeah, I wanna do this. Like get me on this. I wanna like prove my career. I'm young and hungry, right? Where there's others where it wasn't the right time in their life to do that and that's okay, right? In order to be adaptable and flexible, you have to recognize the limitations and the capabilities of your team to move forward. So speaking of which, Andy, there was a good amount of engineers that were caught in this exact nexus of having to get the work done and realizing these expectations. How did you make sure that your engineers really got home the vision and the objective and made it way forward? Yeah, no, I think it's so easy for anyone on that team, but I think in particular engineers to get so caught up in the details of the work and the everyday things that they're taking care of and trying to crunch through, that they kind of forget about the why, what's the high level objective? And like in order to really understand that or like to make use of that, it's something you just have to repeat frequently and talk about on regular cadence like, okay, here's what we're doing and here's why we're doing it. This is what we're trying to get to. And like it's really important for engineers to understand that because a small change in requirements can actually have huge repercussions for what's actually in the product. So if an engineer doesn't understand why those changes are important or what's going on, you can get a lot of pushback and a lot of concerns, but it still understands it like, oh, okay, this is what we're thinking and this is what we learned and now this is why we're adjusting. It's a lot easier to accept that and move forward. Beyond that, if engineers really understand what the motivation is and what we're trying to accomplish, you can often see phenomenal solutions come from engineers that save just a ton of time and still meet customer needs really well. I know there were multiple times where this happened where designers presented a design that was great. It was amazing. And engineers said, well, if we just tweak it a little bit here, this will save us two weeks worth of effort to build out this whole new system. And that was an amazing thing to see. And you don't get that if engineers are so focused on the details of the everyday work that they don't surface and try and understand what they're accomplishing overall. So including engineering leads in those conversations early on can really create a lot of value, making sure they're aware and aligned. It all starts at the top. And with all this, like, if engineers know that you're testing something or just like experimenting, then that's an opportunity to save a lot of time. And, you know, cut corners, not build something fully production-ready but still get it out to customers and try out some new things without committing completely. Love it. And so, yeah, along those same lines, in terms of, like, just moving quickly, continuous delivery was huge for us. Continuous delivery is really just about removing all of the barriers to get solutions out to customers as quickly as possible. You know, in a sustainable way. That's a really important point here. So for Lucid, this was not a sudden thing. It took us about three years of pretty consistent effort to get to a point where our entire system, you know, today is continuously integrated and continuously deployed. And it wasn't like a big thing that we pushed out all at once. We took a very incremental approach and we built out infrastructure to be able to release things on a regular cadence. And the other important part was testing. But like, we just took a step-by-step approach and prioritized, okay, what are the big pieces that are impacting customers the most? Where can we see the biggest improvements and value? And then we worked through until we got to maybe some of the smaller systems that, you know, maybe they don't change as often. So it's not as critical that we have that continuous delivery piece. But like I said, testing was a huge part of the initiative. If you're not going to have any kind of manual checks ahead of deploying, you really have to make sure you're dialed in and things are working well. So without automated testing, there's just not a lot of hope of getting that really fast feedback loop that you need. So we organized a whole team effort. We had lots of testing in place already, but there are areas where there is manual testing still going on. And so to remove all those so we could go to continuous deployment, we created a giant list of all the tests we needed to create and then we assigned those out to teams. And by assigned out, I mean we kind of just threw the list out there and said, hey, everyone take a couple of these and we'll be able to get it all done. But we built this huge dashboard that had kind of where we were on the testing and we had these drawings that people could get entered into by completing extra tests. We even had a certain director dancing around with a big Ewok head on. I was really random and made it a ton of fun for people. So it was definitely an investment. We took a lot of time doing it, but we made it fun. And at the end of the day, I like really helped our customers because now we can get something out to customers often the same day that we, you know, emerge the code. It goes out to customers. We can even sometimes iterate multiple times, you know, in the same week on something to really get some details and clarity on what we need from customers. But really with all this, like it wouldn't have helped us had we not invested early. And that's really the critical thing here with all of these things. I think we've talked a lot about these different principles, right? Especially in the development of LucidSpark. A lot of it came from our investment early, like continuous delivery, three years of investment, but it was worthwhile. So we talked to these principles of customer centricity, rapid decision-making, adaptive, adaptivity and flexibility as well as continuous delivery. We talked about it very much kind of on a company level. Andy and Lindsay, as you kind of think about this for your own teams, how do you apply these business agility techniques in your domains? Yeah, I think the principle that we adhere to that we like learn through this process and have reflected on it since is that you are going to stay competitive if you have the agility to respond to changes in the market quickly. And a customer centric organization is an organization that can recognize when those shifts are happening and respond appropriately to them. Yeah, totally, totally. And I think like the other part is if you're gonna ask people to pivot quickly and to change their price, you really have to help them understand and rely on a why to really win their hearts and minds. It's critical to develop a strong shared vision that you can point to. It helps people feel like pivots are recalibrations and not wins. That's awesome. Well, I love those principles. And once again, kind of as reminder, business agility requires time. It requires an investment. And you can't just all of a sudden have it, right? It's a change of culture. So what we did when we launched this is we really leveraged a lot of what Lucid had done for years across the org or to really create this type of agility from decisions to how we think about customers all the way to even how we ship a code, for instance. But our greatest recommendation, so thanks for having us. Our recommendation to you all today is that you start now, start implementing these principles of business agility because the investment is well worth it for when you need it. Thank you so much. Cheers. Thank you.