4 lessons from building Lucidspark

March 12, 2020 was a dramatic day at Lucid. A huge change was announced by our CEO, Karl Sun. Due to rising concern over COVID-19, all employees would begin working from home immediately. The announcement was both surprising and appreciated. However, that was not the only big shift for Lucid in the spring of 2020. One month later, Karl challenged the product development team to build and launch a fully-featured, virtual whiteboarding application in less than five months.

Lucid had considered building a product focused on ideation and virtual whiteboards for teams in the past, but the timing was never right. With the acceleration of remote and hybrid work environments that COVID-19 brought on, the decision was made to build Lucidspark to complement Lucidchart with a platform for visualizing ideas, brainstorming, big room planning, and collaboration. 

Ryan Stringham, Lucid’s chief architect, committed the first line of code for Lucidspark on May 26, 2020. Less than five months later, Lucidspark publicly launched on October 5th. Since that launch, we’ve been continually amazed to see how much our customers value Lucidspark. 

Below are four lessons I learned from the experience of building a product in less than five months which, less than a year later, is being used by more than a million customers.

Lesson one: It pays to maintain a high-quality, robust codebase. 

This obviously isn’t a new insight. However, the experience of building Lucidspark was another validation for me of what we all know but sometimes forget when under pressure. It’s not always obvious to everyone that it will pay off to implement the well-designed solution rather than the kludgy hack, to refactor that troublesome area of the code that is no longer effectively handling current requirements, or to pay down the technical debt that may have accumulated over time. 

For Lucid, there is no question that the many conscious decisions we’ve made over the years to keep a well-architected, maintainable codebase paid off in 2020. We were in a position to build and launch Lucidspark in less than five months only because we had a robust codebase in Lucidchart to leverage.

Lesson two: When there is a need for a team to go the extra mile, communicate that clearly. 

When it was time to staff teams to build Lucidspark, I knew individuals on the team would be under heavy pressure. The project would require more effort, time, and focus than is typically asked. I had a conversation with each individual who might join the Lucidspark team to explain that the project would not be business as usual for a few months. I understood that not every individual was in a position to provide that extra effort based on life circumstances or other work responsibilities. I also reassured everyone that there would be no retaliation if an individual decided to opt out of the team because they weren’t in a position to tackle a demanding project at that time. 

Clearly communicating expectations, showing understanding of life circumstances, and allowing individuals to be part of the decision to join the Lucidspark team was appreciated by those involved and ensured we had the right team for the project.

Lesson three: A tech lead and product manager who support each other, listen to understand, and focus on the best overall outcome can do amazing things together. 

In the past, I’ve seen an incredibly capable tech lead work with an incredibly capable product manager but make little to no progress because they could not reach a mutual understanding. It can be a downward spiral of productivity, even when both the tech lead and product manager are brilliant individually. 

In contrast, I observed an amazing upward spiral of increased productivity in the less than five months Lucidspark was built as the tech lead and product manager of the project mutually supported and learned from each other. There was disagreement at times, but there was also always mutual respect and an ability to listen with the intent to understand. When challenges arose that could have blown up the timeline, the product manager and tech lead did an amazing job of putting their heads together to find solutions rather than throwing up their hands and suggesting the launch be pushed out. If the product manager and tech lead had not listened to each other, understood each other's points of view, and found solutions together, Lucidspark would not have launched on time.

Lesson four: Delivering a hard project can do wonders for morale. 

Because I went into the Lucidspark project knowing that it would require more than the usual amount of time, effort, and focus from the team, I was worried about burnout. After an intense project, we often talk about needing to “recharge the batteries.” However,  my experience was that “recharging the batteries” was not a good analogy for this situation. Why? Because morale was already through the roof! 

That isn’t to say that the team wasn’t a little tired and in need of a break. We found a variety of ways to thank those involved and help them take a breather. I was thrilled to see the continued energy and excitement from the team, even after the launch. In the end, the team was proud of what they accomplished and pumped to see what they could do next.

In software product development, it can sometimes seem daunting to do what it takes to capitalize on an opportunity that arises. However, those can be some of the best and most memorable experiences in anyone’s career. Take those opportunities, learn from them, and go do great things!