Lucid's Platform Growth Strategy with Karl Sun, Lucid Software

This episode is brought to you by Intercom. In a digital world, customers demand more, especially from support. Intercom enables businesses to connect with their customers at exactly the right moment using powerful messaging and automation. Scale your customer service without additional investment while still providing efficient and personal customer experiences. Welcome to a whole new way to support your customers. Eligible startups get advanced Intercom features at a 95% discount. Visit intercom.com traction that's int e r c o m.com t r a c dash t I o n the platform.

Is really a coherent technology underpinning that can be easily and flexibly built upon and in particular it's something that we have built ourselves upon. We've built our own products upon our technology platform and it's something that others can build upon as well. Prove out that platform and then be very deliberate and intentional and bring your team along and I think you too can think about how even the scale you're at now, think about where you want to be 2 years, 5 years, 10 years down the road and, and you can be successful in building out a platform as well.

I need some traction. You need some traction. Let's get some traction.

Hey, what's up innovators, entrepreneurs, visionaries and disruptors. This is your Traction podcast host, Lloyd Lobo. We're a community of over 100,000 people just like yourself on a mission to help you get the methods, the money and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before like Shopify, Twilio, Asana and many more.

Hey, thank you so much. Thanks so much for having me here. As Lloyd mentioned, I'm Carl San, co founder at Lucid Software and just recently handed it over to my long term business partner, David Gross. Company's in much better hands now. So for our users out there, you should be happy about that. Thanks for having me here. I love the energy at Traction and conferences like this. As a company grows, you go to different kinds of conferences, you start to meet with more investors and they're good people and that's, that's fun. But I really enjoy the energy of being with so many entrepreneurs, people who at the phases of really in it all the time building something. And so I love being here. So thanks for having me and today I'm excited to talk to you about building the effective platform and how we think about that and how that has helped us over the last 12 years and why we've thought about building our products as a platform from the very beginning and what that mindset has allowed us to do and how it's gonna help set us up for success going forward. So I guess the first thing I should do is talk quickly about what is a platform and acknowledge that everyone wants to be a platform. It's a pretty loosely used term. And so for this morning, what I mean by a platform is really a coherent technology underpinning that can be easily and flexibly built upon. And in particular, it's something that we have built ourselves upon. We've built our own products upon our technology platform, and it's something that others can build upon as well. So a quick intro to our company for those who aren't familiar. Our mission is to help teams see and build the future. Now that's a pretty broad vision and in fact we talk about helping people at every phase of the process of building, from starting with ideas, bringing those ideas to life, all the way through to turning those ideas into reality. And so as we think about this big journey, there's so much work to do. And so you can see why a platform is really important to us because we want to extend what we're able to do and we want others to be able to do more and more things that we haven't thought about, things that we don't have time to do for them. We've been around for well over a decade. Our flagship product, Lucidchart, was launched in 2010 and we've since then launched a couple more products on top of our platform, in particular LucidSpark in 2020 and, and then LucidScale, which is a cloud visualization product in 2021. Have millions of users, lots of countries, support lots of languages, we're used by small startups, large companies and really everything in between. Got over a thousand employees at this point. Headquartered out of Utah, offices, also in North Carolina, in Amsterdam and in Melbourne, Australia. And to get to the topic today, I'd like to cover five rules that we followed throughout our 10 plus years as a company that allowed us to really create a platform that has helped us drive growth and that will really allow us to scale and adapt. So my story with Lucid starts back in late 2009, early 2010. I think our team likes to throw this picture in here just to embarrass me every time I talk. But this was literally our first office. I had spent seven years at Google and then after leaving there, met my co founder and our cto, now Ben Diltz, and he showed me an early working version of lucidchart and, and I'D come from Google. So we had been using the early version of Google Docs and Google Sheets and I really saw the potential here because while text based collaboration really existed in things like Google Docs, there was nothing that you could collaborate and understand and communicate visually in a collaborative way. And I actually wrote Ben an early check and the joke is that I didn't know him that well and I figured I should jump on board because I didn't know what he was going to do with the money, which is sort of a joke. Real story is also that I was super intrigued and impressed by the technology that Ben had built. And he and I were on the same page. We thought there was a big opportunity here. And the first thing we needed to do was to really give the product a much better and more scalable technical foundation. And so that brings me to my first rule, which is build what you need now, but recognize when it's time to scale your technology. This is a point about the technology and architecture that provides the foundation for your products or service, which can turn into products and services, plural, which can turn into a platform with broader implications. Now, honestly, when we started, we had no idea, we didn't know that we were gonna get to the scale that we are today. But nevertheless, from the beginning, we had a very engineering oriented mentality. And so things were not just hacked together. We cared about the technologies, we cared about the architectures, we cared about the user experience. In fact, potential investors and advisors that Ben had met before he and I got together had really urged him to start selling that early version of the product to really go to market. But Ben and I actually didn't agree, didn't agree with them, we agreed with each other, which is that we really needed a much better technical foundation for what we're doing. So the first thing we did was we shut the door and spent six months refining and rebuilding the LucidChart application. Now, at the same time, we were pragmatic, right? We weren't building a backend that would scale to tens of millions of users, because at the time we only had, I think, a few thousand users. But. And so Ben's time and energy was spent originally on providing great user value and on the front end, as it should have been. But we also always were looking ahead, far enough ahead to see where the problems would. And so over the last 10 plus years, we've re architected and adopted new technologies as they became available and as they made sense. So as an example, by 2012, so pretty early on, we recognized that A typical relational database wouldn't work long term for us, even though it might for a while. And by the way, I should segue and say I'm just going to get into some of the weeds here and I hope that's okay, and talk about exactly what we did with our products. I think it's necessary to tell the story, so I hope you bear with me if it gets a little boring. So we realized that this typical relational database wasn't going to work for us. And that's when we started seriously investigating different options that we could use, which took us well over a year, including going pretty far down a path that didn't work. And then we had to backtrack and do something else. But we did find a solution that scaled with us for the last eight, nine years and is going strong. But if we hadn't have started thinking about that problem and solving that problem early on, it would have gotten progressively more and more painful, more and more difficult as we've got more users, more documents, more invested there, and ultimately maybe even impossible. Change things and then you'd just be constantly bandaging or constantly firing up more servers for scale, scalability, et cetera, et cetera. Other examples that we've done LucidStart was PHP based in the beginning. It was really rapid development, but wasn't very flexible, wasn't very secure and it certainly wasn't scalable. So we moved away from that fairly early on. Very early on we moved from a monolithic application into an application services architecture. I'm sure many of you have are thinking about doing that or have done that already back in 2016 as part of a hackathon project and I'll talk about that. We actually converted the entire code base, which at the time was 700,000 lines of code from JavaScript to TypeScript for efficiency and quality. It was actually a dare that a team of six engineers took on over a three day hackathon project. They got 70% of the way there and then we shut the company development down for the next like three weeks and the entire company finished the rest. But the moral here is always be looking ahead and make sure that you never paint yourself into a corner. Now second, recognize your advantage, what it is that you do better than others and really lean into that and build around it. So for us that became data understanding data and how it related to visuals. Now why, why was this the case? We saw that our customers really wanted this and in particular we realized that oftentimes users wanted to have a diagram, but they didn't necessarily love like creating the diagram. And so anything that we could do to build the diagram for them or to help them would have a lot of value. And so we wanted to take data, do whatever transformations are necessary to understand the items in the data and the relationships between the data, and then turn that into a visual, into a diagram. Now actually this is a really hard problem to solve, but it is a consistent problem. And so we figured that we should be able to provide a solution. And it's gotten better over time. I wouldn't say we're all the way there because there's always new nuances that we're refining, but we decided to make a disproportionate investment in data as an area that we would always stand out above others. Now, even this focus on data had different phases, right? Like early on, we built a number of data features the normal way based on customer feedback. We prioritized the way that everyone does, which is the important customers want this and so, so you go do that. Things like ERD import and export or org chart import and automatic creation. And these were really well received features, product to product features. But what we realized was that the use cases were very disparate, they were not connected. And so essentially we were building a series of one off things. And so finally in 2017, we had a three day tech leadership off site to talk about the future of data at Lucid. And the big topic for that meeting was what have we learned from these series of one off experiments and features over the years? And it motivated us to make this very deliberate technical investment in building out the platform. And we thought about how can we broadly support all of the data features that we've done before, but do it in a more holistic way. And so it was in that meeting that we decided to do a complete redesign of how we handled our data features. And so instead of building these features independently, we could create so much more value by considering how to build up the underlying platform to support all of these features of data that we were doing already in all these different product product feature sets. Now it sounds easy to say that, but actually that was a huge decision and essentially it meant thousands of hours of rebuilding features that quite frankly worked just fine for the users, but we wanted to build them on top of a unified platform instead. And we believed that this investment would be key in differentiating our offering in this visual collaboration market. And that's proven to be the case. And so definitely glad that we did that and quite frankly wish we had done that. Earlier. And so then our attitude shifted into how can we leverage the strength of data throughout our entire platform. And so that takes me to rule number three, which is we thought about how we could build for an immediate need, but then also solve the need in a way that would allow us to solve other similar needs that we knew would come down the road later. And this was a true shift in the way we thought and ultimately it worked. But let me be really clear, this took a lot of time and it was hard to do. And the reason it was hard was because the teams had a lot of competing incentives. We knew that we wanted to and were building this platform that would ultimately in the end, help us develop faster and make our offering more powerful. But it also meant in the short term, as you were developing specific features, it was gonna be a lot slower, right, because you had to be thinking about building the platform and then building the thing on top of it. It would take double amount of time, even longer earlier on for those first few things. And as product teams, dev teams are always under pressure to deliver faster. And so there was always this trade off between when do we have to do it the right way, build the platform, build things on top, and when do we just need to like get this thing out there? And we got to have it out in three weeks or six weeks or a quarter or whatever it is. Realizing that when we chose the speed to get a certain feature to market and didn't focus on the platform, that meant that at some point we would have to go back and rebuild that on top of the platform and reinvest. And so, as you can tell, it was a lot of competing priorities. Um, and we also deliberately very thought about always building for at least two use cases so that we weren't fooling ourselves into thinking that we were building something generalizable, when in fact we were really building something that only worked one off. The other side of this mentality shift was really educating our team to understand why we were doing this and how this worked. And so we built a data focused team whose job was to work on the platform, but then also to evangelize to all the other teams how this mentality should affect their day to day operations and how they should conduct their sprints and reinforce the message over and over. And so let me give you one example of how this worked. So we knew a lot of teams, including our own DevOps teams, were using LucidChart to build out diagrams of their cloud architecture. We also knew that when you diagram our cloud architecture, it's very time consuming and because things are changing all the time, they're out of date by the time you create them. So back in 2016, before this focus on a data platform, we had built an AWS import that allowed teams to import from AWS and then lucidchart would automatically map out your AWS architecture. And so this is it, this was it. And as you can tell, it wasn't particularly pretty, especially for larger instances. But we understood the relationships well enough that lucidchart could create this diagram automatically. Now, fast forward to that 2017 meeting where we decided to make a heavy investment in data. So we realized if we rebuilt this import with the data platform in mind and we could make heavy investments in the platform that could be utilized in other areas, not only importing from other cloud providers like Azure or Google Cloud, but actually building a foundation so that anyone who could supply data in a certain schema could make it visualizable automatically. And so it was really doing it in this way move the technical foundation of the platform along the way, which increased our optionality and ability to really build quickly on the feature set later on. And so In February of 2020, this resulted in an add on within Lucidchart that we called Cloud Insights. And as you can see, this was a dramatic improvement from what we had built earlier. I think you can tell just from it looks much cleaner. You don't have all this spaghetti in there that you don't know what to do with. And it really allowed us to render graphs with tens of nodes and tens of thousands of vertices very quickly, efficiently in the browser, which is no small feat. And then what happened? A month later, the pandemic hit. All of a sudden, all of us as knowledge workers were working from home. The way we collaborated changed and we really heard from users and customers a demand and we saw an opportunity for yet a new product. Users really needed to recreate that ability to brainstorm together, to have meetings, to throw ideas up on the board. And while online whiteboarding existed and there were many applications out there to do that, we saw the opportunity to take the intelligent diagramming and that data platform, that data understanding that we had and take it and build a brainstorming and ideation solution that would allow teams to not only seamlessly throw up stickies and create ideas, but then move seamlessly between that idea generation and move into action planning. And so we call this product lucidspark. Our platform work actually made it possible for us to, from the first line of code to bring lucidspark to market in less than six months, and in the middle of a pandemic, no less, as we ourselves were moving to a remote working, which quite frankly was not our mode of working before, we were more of an in office, all sitting together kind of culture. And because we had this ability with the data in our platform, we were able to have capability that just didn't exist before. So using tagging functionality, we allow people to cluster ideas, to gather and sort these different stickies very automatically, which no one else can do. We're also able to quickly provide, for example, a bi directional sync with something like Jira so that you can provide a visual representation in lucidspark that makes it easy to plan around Jira tickets and then to sync any changes you make in lucidspark right back into jira. For example, what you're seeing here is people have thrown up sticky notes, ideas. We automatically turn those into JIRA issues and tasks. And then because our data platform syncs with Jira, we can automatically edit those cards within lucidspark and those changes automatically get pushed into jira. For example, you can then take these cards and drag them into what we call a dynamic matrix, where you can visualize and organize them along different axes. So, for example, on the Y axis might be priority, along the X axis might be owner. And then as you change the fields, if you change the data fields, it will automatically move to the right part of the matrix. And similarly, if you drag the card visually on the canvas and move it somewhere else, we flip the data. We know what that change meant in the data, and that gets synced right back into something like Jira. So these dynamic matrices are powered by the same foundations that were built to support that original Cloud Insights product, which we turned into a separate product that we now call Lucid Scale for cloud visualization. But it's really because we understood all those relationships between the data that we were able to do this quickly and easily and powerfully. So I've mentioned a lot of things that go into our platform being successful, but there is one thing that I haven't mentioned yet, and that's the culture of our team and building this culture of experimentation. We talked about how that early focus on data came from some experimentations with small data features that we wanted to add. And we also do this hackathon every year that encourages big thinking. This is three days, and it's everything from feature enhancements at some engineers really want to work on, to fun gamification things, to really big moonshot ideas that change the entire technical trajectory of our company, such as that big migration from JavaScript to TypeScript I mentioned earlier. And the effects of the hackathon last a long time beyond those three days that gets everybody's creative flowing. And year after year, it seems like we get more and more out of this, including this year, like a full visual programming language on top of our new data platform. So what's the next iteration for us? Lesson number five is build so users can also build. Right. We're now looking for ways to allow users to extend our core functionality for their specific needs. And so we're building on the extensibility of our platform. We started with simple things like formulas and conditional formatting and allowing users to introduce custom shapes, but now we're giving people the ability to write code and add new features on top of our core products. And while we're still early in the phases here, it's exciting to see how this is developing and it allows us to really have this bright future of what we want to do going forward. So as an extension, as an example, just during this past hackathon, an engineer built an import from Wikipedia where you can pull in a bunch of page relationships and then map those out in different way. You can map them out as a graph like this, or you can turn them into sort of a mind map. This is just like one small fun example of something that we did. All right, so in summary, prove out that platform and then be very deliberate and intentional and bring your team along. And I think you too can think about how even the scale you're at now, think about where you want to be 2 years, 5 years, 10 years down the road and you can be successful in building out a platform as well. Thank you very much for your time.

Thank you for listening and we hope you enjoyed this week's episode of the Traction podcast. If you enjoyed the show, please leave us a five star review and you.

Can find all the information mentioned in today's episode at tractioncough IO that's T R A C T I O N C O N F IO.

Focused on the tech stack, thinking it was brilliant. Now I know that it's no way for you to.