“You’re going to have to shut off your computer. We’re about to take off,” said the flight attendant. Sergio, an iOS engineer for Mixpanel, needed one more minute. He was about to push his code and solve a problem in the app that had been bugging the team for weeks.
Getting this update over to the team before a major product review felt just as urgent as the plane taking off on time. Mixpanel was about to launch our app and there was no time to waste.
Our users can relate to that feeling on a daily basis. Building an app, especially under a deadline, is a high-pressure job. And to be completely honest? We should’ve known this already.
At Mixpanel, we do analytics to help mobile developers learn from their data so they can do their job well and build something great. But here’s the kicker. We have been helping app builders do their jobs without doing it ourselves – until now.
Before we launched our app, you had to go on your laptop to look up your stats. Now that we’ve gone through the experience of having finally built one, we’ve learned that, in the end, it wasn’t really about the app unto itself. The app was another channel to help our users learn from their data. It was also an opportunity for us to see our technology from a whole new vantage point.
The industry often touts, “Think from the user’s perspective.” We learned that advice didn’t take us far enough. Instead, we became our own customer.
As we built the app on top of our SDK, we suddenly saw all the ways in which our platform could be improved. To the team, it felt a lot like piloting a jet and making repairs at the same time. It wasn’t until we became our own customer did we become empathetic toward the work mobile developers and product managers do every day. Plus, we discovered new coordinates for our Product Roadmap.
Straight from the Mixpanel offices, with Sam Green and Sergio Alonso, our engineers who worked on our mobile dashboards, this is how we built our analytics app (now used by thousands of customers). This is what we learned. This is how we weathered the unexpected turbulence and came out with not just a great app, but also deeper insight on our core products. Fasten your seat belts.
First, why on earth was Sergio risking the wrath of flight attendants and air marshals to get out a few code updates? It started with a quick Slack message from Sam as Sergio was returning to the Bay after being home in Madrid for the holidays.
“The product team isn’t happy with the table view,” he wrote to Sergio. Sam was referencing a specific UX flow they had built – how a user scrolls through a dashboard of metrics. “The team wants to see something else in the next product review. Fuck. We’ve been working on this for the past two weeks.”
Sergio and Sam couldn’t seem to figure out the right design animation for this table. They had reached a point where they wanted the product team to agree that 95% was as far as they could take it. However, they knew that wasn’t going to fly.
After getting the news, Sergio immediately jumped on his laptop to try to figure out another way as he waited at the gate for his connecting flight to London. Why? The meeting was in two hours.
As many coders know from experience, inspiration often strikes when the pressure is on. It didn’t matter that he was en route to another country. He had to code.
“I had an idea and I just thought – maybe this will work,” Sergio remembered. “I pushed the code at the last moment I had WiFi. Then, I closed my laptop and hoped for the best.”
It turned out that the design animation for the table view wasn’t an obvious choice. It was inspired by a random conversation Sergio had with Mason Yarnell, Mixpanel’s Creative Lead, who introduced both engineers to the National Geographic app. What they learned from this other app was how to navigate a narrow screen when a phone was vertical. They modeled the Mixpanel app after this design in order to navigate the full view of the table vertically, so a user wouldn’t have to flip their phone into landscape mode. With this new animation, Sergio made it so the screen followed every user’s touch and scroll of the table.
Considering that they were down to the wire before a product review, it was a clutch move to remember and source inspiration from a buried conversation.
“It’s perfect,” Sam wrote back to Sergio, once he landed and found a Hotspot. Figuring this UX interaction out was mission critical and such a relief for both engineers and the product team.
As any developer may relate, it’s easy to become vulnerable to creative exhaustion. Over Slack, Sam admitted, “I couldn’t have gotten through this project without Sergio. He joined us just as I was losing steam.”
There was a lot that happened before Sergio joined Mixpanel though. In particular, Sam had the challenge of creating the runway and ensuring a majority of the development went off without a hitch.
From the beginning, the product team knew there were three goals this app needed to accomplish. One, the app had to summarize a user’s information well. Two, it had to include a user’s most important metrics. And three, it had to be as accessible as possible for the user. This criteria ultimately lead the product team to build a mobile dashboard.
On his first day as the engineer for iOS, Sam started work with full designs of the app already developed. Having all these decisions made was a very unusual starting point, but it forced Sam to build a framework around his process and go above and beyond the typical developer’s role.
“As an engineer, you need to be conscious of why you’re doing what you’re doing. Blindly implementing what the designer has given you is not good enough,” said Sam.
Sam went on to explain his personal philosophy on development:
“I relate my work and life as an iOS engineer to flying an airplane.
When you’re on the ground, you’re focused: hook up this text field to this login, and get this thing done, right? Then, you go up to 10,000 feet, and you think , ‘Why am I hooking up this text box? Oh, so I can make the login feature ready.’ Then, we go up to 20,000 feet: ‘Why do I need the login feature ready?’ That’s a ship criterion for this project,” said Sam.
Being able to answer these questions is what ultimately builds the best experience of an app for the user, and it helps your product team understand why certain decisions are made, he said.
“My first priority with any app – and with this one, in particular – was to get the UI in place,” said Sam, “I don’t care about data, I don’t care about the API. I don’t care about any of that. I care about getting the UI to about 50-60% complete. That way, a user can navigate through every screen on the app. Navigation impacts user experience immensely, so getting that right is baseline.”
According to Sam, the most important thing to remember about these “elevation points” is the value of answering questions for yourself in order to explain it to others on your team.
With this approach, the developer is able to think of the app’s progress as series of levels one could step up or down from.
“Engineers are really good at having many things in their head all at once. So, depending on if I need more context during a product review, I can go up. If I need clarity on what actually needs to be done, I can step down,” he continued.
But there’s a caveat to app development, with or without following this philosophy:
Nothing is totally sacred, or permanent. A developer can always go back and change something.
As we saw with the UX design of the table view, the best ideas often arrive after a couple of iterations. This type of wisdom – being able to access many different elevation points – comes with hard-won experience.
“Sometimes you have to make a decision that may or may not be right, but you need to make it in order to move forward. Knowing this, you have to accept that you’ll probably have to go back and change a decision,” said Sam. However, when you think in a series of elevation points, you can identify the necessary tactics, the context for a choice, and the greater logic behind what you’re building.
This also keeps the developer honest. Sam remembered telling himself often, “You just went cowboy on this decision. People need to have context for why you picked what you picked.”
Keeping it first class
When building a mobile app for an audience of mostly mobile app developers and product managers – our most informed and toughest critics – the iOS team knew they needed to surpass expectations. For our engineering team, that meant going above and beyond the typical developer role.
“Many of the decisions we made from the very beginning had the user as the primary focus,” remembered Sergio. “When you’re solving a problem, though, you have to ask, ‘What are the resources that I have? How much time do I have? Will the user benefit from this change if we invest in it? Will it impact the app’s user engagement, retention?’ Almost all of the decisions were based on what’s the best user experience.”
“For example, remember that UX design pattern it took two weeks for us to figure out?” Sam recalled to when Sergio pushed code as the plane was taxiing. “That’s so intrinsic to how a user would interact with a table of metrics. Sure, we could’ve told the user to turn the phone horizontally in order to see all the metrics, but we realized that was a lazy alternative to what we ultimately gave them.”
“We knew the benefit of making the design pattern just right was incredibly valuable, despite having no data to back that choice up,” Sam continued.
“Prioritizing the user experience was always worth the investment, so we followed our gut.”
In order to keep the experience first class, Sam and Sergio had to inhabit the user’s point of view and ask themselves how they would want to use mobile dashboards. But this was only one way in which our team became a Mixpanel customer.
In the passenger’s seat
This is where it gets really meta.
Sam is in charge of the Mixpanel’s iOS SDK. The SDK is how Mixpanel helps its customers collect data. Sam integrated the Mixpanel SDK into the Mixpanel app.
As if the captain of the plane became the passenger, Sam experienced what it was like to be a developer integrating with Mixpanel.
“I spent four months maintaining the SDK before we ever started on the app. That gives you context to how well I understand the SDK. I know how to use it well and how to use it poorly,” Sam said. “However, I didn’t know what was important to collect, and how a company should collect that data.”
“Having built our mobile app, and then implementing our mobile SDK into the mobile app, has given me an immeasurable amount of empathy for our developers. It’s highlighted how important a good integration is for a strong analytics framework, which is the bedrock to a successful app.”
From this newfound perspective, Sam saw ways that Mixpanel’s SDK could be improved.
“After going through our documentation, I was able to see where our integration was non-intuitive. So when making improvements to our SDK with feature updates, I addressed those non-intuitive points directly so it would be easier for our developers to work with us,” said Sam.
Developers know how imperative a good integration process is, especially when the App Store is the primary distribution channel. Even the smallest tweak to an app requires a company to re-submit it to the App Store, prolonging the dev cycle. This is time companies can’t waste.
Going through the same journey as our customers helped Mixpanel’s engineering team understand the intricacies of app building, which we weren’t originally privy to. Plus, it heavily influenced what our company prioritized in our product roadmap. It was also a good reminder for us (and any company) to “eat your own dogfood” – to use your own product as a strategy to discover where it could be improved.
“I constantly say this when we’re shipping SDK features: I will work 4-5 hours if it will save our developers five minutes. That’s the truth,” says Sam, holding his vape pen up to the Google Hangouts screen, like Scout’s Honor.
“It’s the same thing with the app. If it takes you two taps to do something and you’re going to do all the time, I want to work to cut it down to one tap,” he continued.
When the app launched, Sam and Sergio joined forces with our Support team so they could better serve users who downloaded the app, as well as spot product improvements at the source.
“Every time someone would tweet or write a comment in the Apple Store, we would pull it up and send the user an email if they were having a problem – crashes, bugginess, etc. We did this especially for the people who wrote one-star reviews,” Sergio said. “Within two days, we had fixed the problem. All those one-star reviews turned into five-star reviews: ‘Not only the app is amazing, but also the support is great. I got a fix right away.’”
At this stage, we realized “going mobile” meant more for us than our original intent.
We didn’t just build an app on top of our API, siloing our iOS engineers off from the rest of the company. Going mobile connected our teams even more, providing a channel for continuous product improvements. It was also intrinsic to our greater mission. Going mobile meant every team broadened its horizons on how and where we help people learn from their data.
Buy the ticket, take the ride
Stepping out of the office one night, I asked our founder and CEO, Suhail Doshi, what originally inspired him to build the Mixpanel mobile app.
“When it came to creating a set of dashboards, we debated on whether it should be on desktop or mobile,” Suhail said to me.“However, I knew going mobile with our dashboards was better for our customer, and for us, than keeping it all on the desktop.”
In the span of a short elevator ride, Suhail told me, “I remember being out to coffee with the CMO of Salesforce. When she referenced something, she simply took out her phone and showed it to me on her mobile app. That’s when I knew doing a mobile dashboard mattered more for us than desktop dashboards. No one brings out her laptop during these types of conversations. We’re all on our phones, so we needed to figure out how Mixpanel could be there, too.”
Building a mobile app was the surest way to fit the lifestyle of the people who use our analytics, giving them the insight they need at a moment’s notice, no matter if they were in a stand-up, at a happy hour, or out networking with a colleague or investor.
But it wasn’t until we were able to look back on the process of building the app did we learn that “going mobile” not only meant serving our customers on a different platform but also making a 180 to become one of our mobile customers, too.
When we challenged ourselves to go beyond the browser, we became critically aware of what it was like to use our technology. Sure, we had a lot to celebrate, but our greatest gains came from grappling with our limitations. That’s what innovation is all about.