In the lobby of the old Crashlytics office at One Kendall Square sat a custom tree that I helped design, and it took the artist three months of literal blood, sweat, and tears to bring to reality. Branches and leaves were replaced by origami leaves that abstractly resembled the Crashlytics logo -- imagine thousands of hand-folded, vibrant, red gears as the first thing you saw every day coming in to work.
At about five feet tall, it was a constant reminder of how experience, product and design were at the core of our company and the culture we were building.
I can remember looking at this tree at 3am one night back in 2012, reflecting on how far we had come in the year since Jeff and I had founded the company. We had raised six million dollars, helped the top brands in the world use Crashlytics, and were on the path to being in every device on the planet.
With the moonlight hitting the paper leaves just right, the tree illuminated, filling the room in a reddish tint. I looked at my phone and saw three missed calls from Jeff, and six from my girlfriend at the time -- I wasn’t coming home anytime soon.
I walked back into the conference room I was working in, and took a sip of my Red Bull. It’s weird how chills can be amplified by the bitter taste of ginseng and taurine. I looked at the whiteboard that had little cut out images of our faces assigned to each task we were completing.
Smiling, I realized -- we were about to do something big, and no one knew it was coming.
Starting Crashlytics
I almost forgot my sport coat at the table. Walking back inside the restaurant, I glanced over at the half-consumed bottles of wine with scattered business cards beside them. At many tech dinners, this is usually the post-mortem scene. It was 2011, and I had just met Jeff Seibert for the first time at a DartBoston event. He was leading Box’s engineering team in Boston at the time.
DartBoston had built a community of entrepreneurs and professionals in the Boston area that came together for networking events and dinners. I wasn’t invited to the dinner where I met Jeff; I just happened to crash it because my friend was going and we had agreed to meet up right beforehand.
I just happened to grab a seat next to Jeff and we immediately clicked. After spending some time talking about side projects, but not entirely revealing what we were working on, we decided to meet up for coffee to talk more a few weeks later. When we sat down for coffee, I could feel the passion Jeff had for his small side project -- an SDK that would make it easier for app developers to uncover why their apps were crashing.
My first thought was that this problem should’ve already been solved, but the market hadn’t made developers lives any easier since they started building mobile apps. Considering nearly 10 percent of all app store reviews mentioned the word “crash”, I told Jeff that this didn’t sound like a side project -- this was a startup.
It was then that Crashlytics was born.
When Jeff and I started Crashlytics, we quickly discovered that data was a large part of the SDK. When developers installed Crashlytics, we were able to see data the way any other analytics system could at the time.
We automatically received most of the normal analytics data that other companies were gathering, but it was simply as a byproduct of crash reporting -- we weren’t in the mobile analytics business. At this early stage of the company, we had a decision we needed to make: did we want to do crash reporting and analytics? Or did we want to focus on one area and then gradually explore other options of growth as it became successful?
Over the years, I’ve learned that one of the most serious problems many startups run into is not being 100 percent focused on one thing and thus failing to do anything really well. We could’ve built an analytics solution then, but there were countless mobile analytics solutions out there already. Crash reporting was hard and analytics was easy. We wanted to dominate crash reporting and then enter the analytics space with a product that actually provided what our customers wanted. We wanted to learn and grow on a massive scale before diluting our focus.
So, we started setting goals, not quite sure what type of growth Crashlytics would have.
Each milestone was paired to a different bottle of Port -- I wasn’t a big wine drinker but Jeff, a big wino, had recently introduced me to port wine. It had the sweetness of brandy with the richness of wine. These milestones (100 devices, 100 organizations, 250 apps, 500,000 crashes) were on post-it notes stuck on port bottles.
After a lot of work, we were lucky to hit all of these milestones within just a few weeks of launching, and we realized we needed to think bigger -- it wasn’t because we didn’t like to imbibe (we did, and still do), but we knew that there were more impactful goals that deserved those celebrations.
And so, Crashlytics started to gain momentum.
In about six month’s time, thousands of organizations were using Crashlytics and the SDK was on hundreds of millions of devices. Developers loved the product. The Crashlytics SDK was so small, the file size of the app’s icon was usually bigger than our code.
This helped prevent developers from bloating their app or running up against size limits in the iOS or Android app stores, and it was giving them better quality reports than anything else in the market.
But other companies knew that we weren’t going to just do crash reporting forever, there was a bigger picture. Towards the end of 2012, Jeff and I went out to meet a handful of companies that were exploring how Crashlytics could be part of their bigger vision.
We needed to do what would best help us grow Crashlytics the fastest while supporting our vision to build tools developers would love using -- whichever way that was.
I looked at Jeff and smiled. I can remember him shaking his head, glancing over at the whiteboard with our original go-to-market strategy -- we were both in disbelief, we had just been acquired by Twitter. This was January 2013.
The Whiteboarding Session
Fast forward to the fall of 2013 -- we had been able to grow our team and continue to expand Crashlytics’ reach. It was everything we had envisioned doing from the start. After the acquisition, we continued to focus on crash reporting, smoothing the transition to Twitter.
Jeff and I got into the office early that morning, it was Hack Week. Our team had been heads down tackling some of the toughest issues that came with being really good at crash reporting, and it was time for a little break.
All the whiteboards were blank, and teams split up on their own projects. One of our engineers, Kevin Robinson, was on a corner whiteboard drawing charts and graphs with data points floating all around it. He was precise, and you could feel his excitement for what he was visualizing.
Kevin was doing what Jeff and I had talked about doing when we first built Crashlytics -- he was mocking up an analytics solution.
This kicked off our thinking.
Developers had been telling us that if we built a mobile analytics tool, they wouldn’t need to check other dashboards. We finished our wine and got a relatively early night’s sleep -- we wanted to start brainstorming in the morning.
We thought about the types of analytics tools that were currently available for app developers: fancy filters, tabs upon
But what we soon realized in talking to customers and other developers, was that they didn’t really care about the million different ways they could split the same set of data. They just wanted more users in their apps and minimal churn rates -- things that are tangible and drive real value.
Building that into our sketches, we knew that we wanted the dashboard to be opinionated. Of course you could dive into the data if you wanted to, but when you got to your dashboard, we wanted to present you with the six data points you cared about most: daily active users, daily new users, monthly active users, crash-free users, sessions, and session length.
Now came the big question: Could we build a mobile analytics platform that would scale to the size and impact Crashlytics had?
We thought about outsourcing the data we were getting from crash reports to a third party, or acquiring a firm to do it all for us. This internal conversation lasted weeks, which in startup world is an eternity. Then one day we heard, “this is dumb, let’s just build it ourselves.” Jeff and I looked at two of our engineers, Ed Solovey and Jamie Rothfeder. I can remember Jamie saying, “we have the expertise to do this in-house and let’s face it, we would move a lot faster ourselves if we didn’t have to rely on a third-party.”
We trusted them. With the Twitter leadership team’s signoff, that’s exactly what we did. It was a gamble, but it was a risk we were willing to take -- after all, it was that faith in our team that had gotten us this far.
Do You Want A Recipe or Do You Just Want Dinner?
I was hungry. Working late in the office sounds like fun, except when you have no food. I left to go for a walk and clear my head, needing to take a break from designing the analytics marketing page, and maybe find some food. Maybe.
A few days earlier, we had agreed to call the product, “Insights by Crashlytics”. This was intuitive since we were giving you insights into your app, insights into your users, all in real-time. Delivering on the experience of Insights, the graphics and page design needed to be well thought out. When you think of your favorite product or website, you feel something when you interact with it.
Many designers and marketers think about layout in terms of geometric shapes, colors, and depth. I believe that time is what brings out the most well-thought-out stories. Thinking about when a specific graphic should appear, how long it should stay there and how slow it should transition enhances the emotional resonance of the page. It’s all about the psychology of the reader and how they interact with what you’ve built.
I passed by the Charles River, which cuts between Cambridge and Boston, thinking about how we could use animations to help tell the story and go beyond space and colors -- and into “time.” Through animations, we could control the product experience to tell a more impactful and memorable story.
We wanted to convey the message that we were doing all the work for you, delivering to you what you need on a silver platter. On the product page, we did exactly that -- it had a silver platter that would then lift up, revealing a handwritten card underneath. The card, in beautiful calligraphy, had the word “Answers” on it. Below that was a tagline that said, “No Analysis Required.”
I kept thinking about why we needed a tagline to describe a product that should describe itself…..
And then it hit me. “Insights” wasn’t the right product name! “Answers” was.
The more I thought about it, the more I felt committed to it. Answers. Of course. I should have thought about this sooner. Well, it should be simple enough to get it changed. Except, there was a problem. The engineering and design teams were ready to launch “Insights by Crashlytics”... in 48 hours.
I picked up the phone, called Jeff and said, “We made a mistake. We need to fix this.” In typical Jeff fashion, he kind of laughed and asked what was going on.
I said, “If you’re really hungry do you want a recipe or do you just want dinner? Insights is the recipe, but we don't want to just give them the recipe, we want to give them dinner - so it needs to be Answers. It can’t be Insights.”
I’m sure Jeff thought I was crazy -- not only because of that analogy, but because we were 48 hours away from the launch of Insights. But he thought about it, and agreed.
“I’m on board. It’s brilliant.”, Jeff responded almost immediately. “Calling it Insights puts us right there with every other analytics tool that uses the word insights in some way too. There’s only one problem though. You need to convince Brian Swift. If we’re going to do this, Swift needs to be on board too.”
Brian was the Product Manager of the Insights product, and fairly new to the team, so this would definitely be a trial-by-fire moment.
I can remember being on a three-way call with Jeff and Brian, not knowing how he’d react. It was late, about 10 or 11pm and I knew Brian was still in the office, heads down getting ready to launch Insights: tweaking the charts in the UI, and the colors and sizes of the bars we displayed.
Put yourself in Brian’s shoes. It was his first major launch as a PM at Crashlytics. He’s prepping like crazy for it, and then one of the co-founders calls him asking him to change the name of the entire product. 48 hours before it was set to launch.
“Hey Brian”, I began, ”So, I was just talking with Jeff and we think we need to change the product name from Insights to Answers. I was thinking about the name while working on the product page and I realized that even with the silver platter and tagline, I felt that we were trying too hard to explain what the product did. We need to think about what we want this to look like a year from now, and what we can build from it. We’re not providing Insights, which is like every other analytics product out there. We’re providing them answers. The needle in the haystack. The diamond in the rough. Let’s call it Answers. Thoughts?”
Brian’s response was simple:
“Your rationale makes total sense Wayne, I trust you guys. Let’s do it.”
I knew he needed to float the idea by the engineering team, but the entire situation was a scary one to be in: we had written blog posts, product pages and had “Insights” everywhere - in code and in graphics. If we didn’t execute this right, it would affect our adoption rate and how our users perceived and used our products.
The Answers Experience
I found Brian sleeping on the couch when I came into the office -- this was six hours after he got engineering on board to help us change the name to Answers. We were pushing hard and pulling all-nighters to change the branding, messaging and content from “Insights” to “Answers.”
While we were working on that, we also needed to focus on the product experience itself. Answers had a really poor onboarding flow (there wasn’t one). Users would have to wait without any type of visual indication between the time they turned on Answers, registered an event on their mobile device and app, and then waited for their data to be sent to our servers. Then our servers had to analyze that data, and then our front end web app had to render the results.
I knew this would be a major friction point with our customers. No one likes to wait, especially without knowing how long the wait would be.
I wanted to create a user experience that would make the waiting process much more delightful. Something that would turn a painful experience into a pleasant one. Something that people would actually wait to see even more of.
So we came up with a UI that was very animated, and very personalized. When you onboarded Answers for the first time, you would see a small modal above a blurred out dashboard.
Little squares would start flying in, and then very quickly you’d see that it was building your app’s icon! Data would start flying with pulsating lights, text would float in and dissolve. All of this was engineered to make each second you were waiting for the data more enjoyable.
It turns out we had to add a next button to the final page of the model because our customers were enjoying our animations too much and were disappointed when it disappeared.
Mission accomplished :)
Launch!
The launch room was prepped with Red Bull and we were ready to unveil Answers as a standalone brand. Our screens showed both an active conversation of mentions about the product and all the data Answers was handling. The room was blaring EDM music for background noise. This helped keep everyone on the same, upbeat rhythm. Aside from the occasional “come up for air” drink, we were heads down through launch.
It was a success.
I looked over at Brian, who was trading anxious glances with the projector and his screen, making sure everything was in check. His eyes caught mine and he smiled as he took a sip of his coffee.
The next words he said were, “Next time, will you give me some more time before a launch?”
All that hard work paid off and we were seeing some great early traction with Answers. Developers just had to click “enable” within the Crashlytics dashboard and they could start seeing all the data they cared about flow in, in real-time, immediately.
As the product grew, we started to get feedback from developers on what they liked and didn’t like about Answers. When we first launched “Answers by Crashlytics”, developers told us they loved the fact that it was accessible all from one dashboard. Now, they were telling us that they didn’t think about Crashlytics as a brand for their mobile analytics, and wouldn’t necessarily check that dashboard for both crash reporting and analytics.
Answers needed to be it’s own brand, and the timing couldn’t have been worse.
It was February, just 6 months after we launched “Answers by Crashlytics”, and it was the weekend we usually went to Stowe, Vermont to ski and celebrate for our annual team offsite. The trip still happened, we just needed to separate Answers into its own brand instead of playing beer pong.
I sat on the living room couch of the house we rented, and glanced over into the fire. Launching a standalone brand was complex -- I needed to really think about what would resonate best with developers. We had done really well up until this point, propelling Answers into a product that was really resonating with developers. Now we needed to change it from “Answers by Crashlytics” to just “Answers”.
When you launch a standalone brand, not only do you have to think about product and process, but visuals -- and icons more importantly. What would be that thing that would resonate, that would stand strong on its own? The symbols for analytics were traditionally charts and graphs, but at the end of the day, what is it on that chart or graph that you really care about? It’s just the one datapoint that gives you the answer you’re looking for. That one data point was the inspiration of the Answers symbol, the needle in the haystack, the answer to the mountain of data.
We launched Answers as its own brand on top of a mountain three hours away from our office. We were still the same group of people that were recovering from lack of sleep lost in 2011 -- we had learned what it took to make Crashlytics successful, and applied the same disciplined, product approach and execution with Answers. With six or so people working on Answers, we started to gain traction. Brands like RunKeeper, Buzzfeed and Spotify were using Answers, loving it and telling everyone they knew.
5 Billion Sessions, A “Monster” in the Market
Jamie flew into the office one morning on his bicycle. With his fluorescent yellow helmet in hand, he rushed through the conference room door where Jeff and I were sitting.
“I just talked to Ed. Do you guys know how many sessions we’re processing a day now?”
We had just hit 50 billions sessions a month, which was huge. But given the fact that Jamie was still in his cycling gear, I knew it was important.
He pulled out his phone and showed us an email from our other engineer, Ed Solovey. The subject line was, “Boom.”
In the body of the email, Jeff and I saw what Jamie was panting over --
We were now handling over 5 BILLION sessions. Every. Single. Day.
We had set up our architecture in a way that we could handle tons data in real-time and developers raved about the fact that the Answers product was opinionated. We had only built about 80 percent of the traditional features most analytics products offered, because we believed those were the ones you cared about most. The energy we saved by not building the other 20%, we put into scaling. We were really excited to see how many developers were going to use the tools we were building -- after all, this was only seven months since our launch!
After taking a sip of coffee and setting my bag down next to my desk, I fired up my laptop. 20 tabs proceeded to unwind, like a dealer shuffling cards. Opening one of the tabs in my browser, I wasn't quite sure I was reading it right. My tab had SourceDNA open, one of the most comprehensive data sources for mobile developers, and it listed Answers above Flurry AND Google. We were number 1!
I mean, Flurry was acquired by Yahoo for hundreds of millions of dollars.
Here, it was saying that we had done in a few months what it took Flurry nearly 10 years to do -- and with just six people on our team.
SourceDNA was a trusted third party, so they couldn’t have been wrong, right? Just for kicks, I scrolled over to the performance tab and found Crashlytics to be number 1 also. Not only was it the top performance SDK, it had a higher score than the next five SDKs. Combined.
I couldn’t believe it. Coming from a small conference room at One Kendall Square, not knowing how successful we’d be at crash reporting, to dominating the performance SDK space and having Answers be called “A Monster” in the analytics market -- it was mind blowing.
The Future of Mobile Analytics
Every day we would come into the old Crashlytics office in Kendall square and walk by that custom art tree. We actually have it here in the Twitter Boston office now. Building Answers, that’s all we thought about -- the attention to detail, the quality, and the emotions we wanted to invoke. We’ve been learning ever since, always listening to our customers, always iterating.
I am extremely thankful to Jeff, Brian Swift and the entire Answers team for their ingenuity and tireless work in making Answers come to life. We're fortunate to be working with some of the most talented, brilliant minds in the space.
Together, we are building an experience that will impact how developers build apps all over the world.
And this is just the beginning.
