Startup Field Guide Episode 18

In this episode of the Startup Field Guide podcast, Sandhya Hegde chats with Amplitude's co-founder and CTO, Curtis Liu. Amplitude started out as a mobile analytics tool, and eventually expanded to include all digital analytics, experimentation, and personalization. The company now serves over 1900 customers.

‍

Be sure to check out more Startup Field Guide Podcast episodes on Spotify, Apple, and Youtube. Hosted by Unusual Ventures General Partner Sandhya Hegde (former EVP at Amplitude), the SFG podcast uncovers how the top unicorn founders of today really found product-market fit.

‍

If you are interested in learning more about some of the themes and ideas in this episode, please check out the Unusual Ventures Field Guides on customer validation, CEO/founder prioritization, and iterating to MVP with design partners.

‍

TL;DR

• Curtis and his co-founder Spenser’s initial idea was for a consumer product, but the idea didn’t have wide adoption since it was too early. They pivoted to mobile analytics after coming up with several different product ideas.
• Their prototyping process included doing interviews and showing mockups to customers. They eventually instrumented an SDK for user testing to validate their assumptions. 
• As a founder, Curtis learned by doing, and by leveraging online resources and open-source tools. He prefers a combination of self-directed research and talking to experts. At Amplitude, he also learned by repeatedly testing the company’s software with customers.
• While Curtis was initially focused on product-building, as the company scaled he changed his mindset — he realized he was building a company, not just a product. He thinks of himself as a founder first and CTO second.  Curtis learned about company-building by stepping into key functions, including recruiting and finance.
• Curtis’s advice to founders: Look for problems to solve by talking to lots of people in the problem space you are exploring, really understand their pain, and if there is a solution, then ask why it has not been implemented yet.

‍

‍

Episode transcript

‍

Sandhya Hegde:

Welcome to the Startup Field Guide, where we learned from the successful founders of unicorn startups how their companies truly found product market fit. I'm your host, Sandhya Hegde, and today we'll be diving into the story of Amplitude, the number one product analytics company in the world. And we are joined by its Co-Founder and CTO, Curtis Liu. Curtis, say hello.

Curtis Liu:

 Hi. Good to meet everyone. Nice talking to you Sandhya.

Sandhya Hegde:

You too. It is so nice to have you here. So I want to go back all the way to 2012 and you and Spenser first decided you wanted to start something. And I think you had applied to YC twice and eventually got admitted with the idea for a consumer app, which is not really Amplitude at all, yet. So can you tell us more about how that happened? How did you pick your first startup idea?

Curtis Liu:

Yeah, so Spenser and I, we go way back. We knew each other in college and all throughout, even before we started Sonalight, we had worked on projects together. Both of us had a pretty entrepreneurial mindset in terms of wanting to build things, wanting to use technology to create things. And leading up to Y Combinator, we actually, as you said, went through a number of different ideas. We thought about building a website for our alumni network, building a website for connecting people with photographers, building a website that was kind of like a fiverr, TaskRabbit competitor. And all of that--we went through a first round of interviewing with YC, with that TaskRabbit idea, didn't get in, reflected, and decided, "Okay, what is something that we truly want to see happen in the world?"

‍

And we recognized that everybody was using their mobile devices, mobile growth was huge at the time, it was back in 2011. And we thought the phone was such a powerful potential tool and thought, "Wouldn't it be cool if we could interact with our phones handsfree? Just talk to it and it would do things?" And that's where Sonalight started and when we applied to Y Combinator with that particular idea, we got in. And that's what we went into Y Combinator with Winter '12.

Sandhya Hegde:

Got it. Turns out great idea, probably too early.

Curtis Liu:

A little too early, as we would find out later. Really, the mode of interaction was exciting and I think forward-thinking at the time. But in our time at Y Combinator, we launched the product, we tried to grow the product, we did a lot of analysis on how people were using the product and learned over the course of that period of time that maybe we were five years too early.

Sandhya Hegde:

Right. And when you thought about kind of pivoting, or actually not even pivoting, but when you first decided, "Okay, we are too early, there isn't enough adoption of this Sonalight idea," How did you two think about that? Obviously, didn't just shut down, but what did it feel like as founders to say, "Okay, idea number one, not working, what do we do next?"

Curtis Liu:

Yeah, definitely, I think it was a bit of a... We weren't afraid of it, but it was a little bit nerve wracking to think that this idea that we had gone through Y Combinator with, we had gone through Demo Day with, had a really awesome presentation. People loved the demo that we presented. Had investors actually already ready, they invested in us on that idea, it was a little bit scary to think, "Oh, this isn't going to be a long-term company that we can stick through.” And maybe it helps to back into the reason we came to that conclusion, and I'll do that a bit.

‍

But I think having come to that conclusion that we needed to pivot after all of the Demo Day and fundraising and seed fundraising was definitely scary. I think the amount of conviction we had behind it though kind of pushed us. And what else was encouraging was the investors that invested in us under that idea, actually, they were very amenable to us pivoting. I think they had experience with other companies pivoting, I think they believed in us as founders, and I think ultimately, they were investing in us, not just the product, but more so the team. And that helped a lot.

Sandhya Hegde:

Right. Make sense.

Curtis Liu:

Yeah. I think once we told everybody, "Okay, we're going to do this pivot," And that kind of freed us and we were like, "Okay, let's go head-first into this next idea."

Sandhya Hegde:

How did you explore options to pivot into? I'm sure it wasn't just next day you started building Amplitude. You probably explored a few options first. What were those options? Why did you pick them?

Curtis Liu:

Yeah. So I didn't actually get into it, but the reason we decided not to do Sonalight anymore after we launched was because ultimately, we had built up an infrastructure for understanding how our users were using the product, we got a lot of feedback from those users saying, "This is an awesome product." But we weren't growing as a company in terms of usage. And the data was showing us that retention was poor, people would stop using the product. So when we pivoted, we were coming up with, "Okay, well what should we pivot to?" And one of the first things that we noticed was other batchmates in our Y Combinator class saw the kind of dashboards and analytics that we were tracking in Sonalight.

‍

And that was kind of actually the first thing we thought about, was "Maybe there's an opportunity here." But we weren't fully convinced about that and we wanted to explore if we were going to pivot, like "Let's actually explore some more areas." And so there were a few other areas that we actually thought about. We thought about a better Bloomberg terminal. Spenser had come from the trading world and he thought the Bloomberg terminal was not a very good interface, not a very good tool. We thought about a way of aggregating and summarizing financial news for companies that needed to summarize and make decisions off of financial news.

‍

And we did a lot of just, I guess, interviewing of people in the space, people that had used Bloomberg terminals, people that cared about news aggregation and as well a lot of mobile companies that were looking for analytics and how they used their analytics. And ultimately, between the three, without doing any kind of coding, without doing any kind of product-building, we decided that there was the biggest opportunity and best opportunity in the mobile analytics space. And then from there, quite honestly, once we decided that, it wasn't like we decided mobile analytics, there was still a lot of ideas that we tried once we decided on mobile analytics, just by nature of working with companies and working with our customers on what they were looking for.

Sandhya Hegde:

Right. How did you approach prototyping? So, I assume you and Spenser carved out some kind of roles and responsibilities. And even though if you're both developing, you were kind of the primary developer on the team. How did you approach prototyping and building just enough to figure out, "Okay, is this the right thing to keep building?"

Curtis Liu:

Yeah, that's a great question. Prototyping can come in many different forms, and ultimately, I think what you're trying... The ultimate goal of prototyping is getting something in front of customers as soon as possible so that you can learn from it. And as I mentioned before, there's still a lot of signal you can get without even building anything, just by doing interviews, by showing mocks. And so I think when we started Amplitude, there were, I guess I'll give two examples. One time of when we did actually build stuff to prototype and test, and one time where we used mocks, actually the mocks example came a little bit later, but once we had a couple of customers, we realized that there was a big use case around comparing segments of users, really focusing on segmentation and comparing users.

‍

And our initial product had been modeled off of another analytics product called Flurry and GA. What we really wanted to was do was change the interface and focus of our product to be comparing groups of users. And so before we actually did a redesign of the product, we built these design mocks, worked with a designer, built these mocks, brought it in front of our customers, and just said, "Hey, what do you think of this interaction? Does this work with the workflows that you're trying to analyze?" And that took a couple of weeks of just revisions, but we got feedback way faster doing that than if we had gone off and built it. And then once we finalized around the interaction design, we took the next month or two to actually fully build it out.

‍

I think the other side of it is, there are some times when people won't believe what you're building and the vision of what you're trying to do without actually having something to play with. And so, one of the things that we really just built as quickly as possible was the instrumentation SDK. And the goal for us in building that was, "How quickly could you go from wanting analytics to analyzing an event and in a workflow in Amplitude? How easy was it to just stick our SDK into your app and build it?" And I think that we built over the course of a couple of days. We sat down in front of Harj Taggar and said, "Hey, you got a little app, can you try our SDK and tell us is this easy to use or not?" And in that 30- minute meeting with Harj instrumented, and we were pretty happy with that result.

Sandhya Hegde:

Right. That's fascinating. So I think what I'm hearing you say is that there's some things everyone promises, where you know that if it works, people will love it. There's no question, if it works, they're going to love it. So it's almost like proof is in the pudding. "If you can actually show me it's working, only then will I believe you can do it. Because guess what, everyone promises me this." And there you just need to build the prototype and have something people can actually use. As opposed to if you're trying to decide is this valuable? You're not sure, you definitely want to not start with prototypes. And it sounds like that for you, that initial prototyping of user comparison became kind of the foundation of how Amplitude became different from the status quo and all analytics at the time, right?

Curtis Liu:

Yeah, absolutely. I think that initial set of design feedback loop really set the tone for how our interface worked, how people thought about using analytics and analyzing and understanding customer behavior at that time.

Sandhya Hegde:

Make sense.

Curtis Liu:

I have another little... I guess, it reminds me, just like this question about prototyping reminds me about when you and I were working on an experiment together, and in that particular case, there was already a status quo that people had established. And the thing that we were trying to understand was, could people start to actually target and use cohorts, like use more complex sets of users in their experiment — an interesting idea on paper, but people want to see it actually happen. And so I think when we set out to work on the experiment, it was very, very much the, "Let's get something as quickly as possible in people's hands that works."

Sandhya Hegde:

Yeah, because we already have conviction that the issue isn't whether it's valuable, it's whether we can make it easy to implement.

Curtis Liu:

Exactly.

Sandhya Hegde:

One thing that I always wanted to ask you Curtis, and all these years, and I have never asked is, you were so young when you and Spenser started Amplitude and an analytics company is a very challenging company to build, just from a technical infrastructure perspective, there's decades of history around databases and pipelines and there's just so much that you need to know because often you're making long-term decisions that will affect the company and what products you can build for the next five, 10 years. Going all the way back to almost a decade ago, how did you teach yourself how to approach building Amplitude as the technical leader in the company? What was your process of learning? And I'm curious how your process of learning new things has evolved since then.

Curtis Liu:

Yes. That's a great question. I'm a learn-by-doing kind of person. And I think the internet is awesome and has a lot of resources and I think there are so many resources, tools, open-source tools that help you get started and try things out and see what works and see what doesn't work. So we weren't starting completely from scratch, I think my experience at Google definitely helped me understand a little bit some of the practices and best practices for running infrastructure, some of the tools for what you look for in analytics, and the importance of uptime and how to keep it monitored.

‍

AWS was tremendously helpful in not having to deal with infrastructure, and so we could leverage their infrastructure very easily, spin ups and down instances. And then in terms of the deep technical things related to analytics, one, I think there's just understanding the principles behind it. And I think at the time Columnar storage was this emerging idea and it was showing up in a lot of warehouses and databases. And I think we were early enough and understood the principles behind Columnar storage enough that it was very clear that it would be super valuable and super helpful for scaling analytics. And the other thing I guess is, I mentioned learning by doing, some of the things we did as a company really tested our software. So let me give an example of that. In 2013 we worked with a mobile app SDK provider that helped companies provide a framework for their customers to quickly build cross-platform mobile apps.

‍

And so we actually worked with them to provide their customers with analytics. And thought this kind of partnership would be beneficial to both of us. This was around the time that when we started on mobile analytics, we actually just started with a Postgres database and did all the queries on top of a Postgres database for our customers. Now, this company that we were working with had 10,000 customers, and each of those customers was their own table in our Postgres database for us to query on. And very quickly we learned Postgres does not do well with lots and lots of tables, large tables to say the least, for analytics. And upon seeing that, very quickly, we realized that we need to uplevel our infrastructure. Did a lot of research on massively parallel--I think MPP was the hot term at the time, Massively Parallel Processing.

‍

And think we looked at things like Cassandra, we looked at things like another Y Combinator company that was building kind of a distributed database on Postgres and just evaluating a lot of different options. And all throughout this time in 2013, 2014, I think we tried and rewrote our backend three or four different times on different types of infrastructure to figure out what worked best.

‍

And ultimately, we continue to evolve our back ends to make processing more scalable and more cost-effective and more efficient. I guess, the one thing I would say is, in all that time, I never lost confidence that we could figure out what was needed to be done and took problems as they came. We didn't try to prematurely optimize. And what ultimately ended up... The reality is we ended up hiring a bunch of experts and smart people that help us scale out of the problems that we might have created in the beginning.

Sandhya Hegde:

Right. Makes sense. But you were solving for the clear problems you already had rather than trying to be cute and try to really foresee what might happen in three years down the line.

Curtis Liu:

And I think the other aspect was just leveraging technology where we felt like it was easy to leverage, like AWS and...

Sandhya Hegde:

Right. So you talked a lot about evaluating different options, doing research on new frameworks that were coming up at the time. What's your approach to doing that research? Is it more what you talked about, you're reading on your own and learning by shipping, or are you also reaching out to specific people to understand, "Okay, what are other people trying that's working?" And what would be your advice to especially CTOs and technical co-founders in the world today when they are starting out? Because it feels like the frameworks available to them, whether they're abstracted and easy to use or not, it's just evolving so quickly. Especially in the world of AI-native software right now, it feels like what is possible changes every few months, if not weeks. So yeah, what was your approach on getting smart really fast and doing that research really fast?

Curtis Liu:

Yeah, I mean, I err heavily on reading and exploring on my own. I think YouTube's a great resource. I get a lot of information from Hacker News. I get a lot of information from blog posts and links and Stack Overflow and all of those resources. I probably err a little bit too much on the side of not going outside of the walls. But I will also say during those early days, there were a couple of folks that were helpful. I actually got a chance to talk to one of the contributors to Cassandra and understand from their perspective, was this a good fit? Was this not a good fit? How might we fine-tune Cassandra if we wanted to use it? We also talked to the founders of CIS DB to get their perspective on how to use CIS DB potentially. And so I think ultimately the ideal is a combination of the two.

‍

One of the things that self-exploration can help you do is, you can independently formulate your model of the world. And that provides powder and understanding that you can then take into conversations with experts. And quite honestly, where experts can help is when you have... Well I guess, they can help in two ways. One is when you have absolutely no idea and they can provide a guide, but then when you want to go deep into something, they're very helpful there too. And so even getting connected to people through people you already know is very helpful.

Sandhya Hegde:

One of the things that I have always really admired and appreciated about you is, while your favorite way to spend time is with code and still just writing code, your role at Amplitude has evolved so much over time and you've worn so many different hats over the last 10 years. So I'm curious if you could walk us through how would you describe all the different hats you have worn at Amplitude and how it felt as a technical co-founder to do that? What was your philosophy of, "What is my role as a founder? How do I approach it?"

Curtis Liu:

So I think there's kind of three eras, I guess, maybe actually four eras in my time at Amplitude. So we started Amplitude in 2012. At that time it was just Spenser and me and we had a Seed round and we hired a few folks once we got the product going. But at the time it was just building product and getting feedback from customers and building product and getting feedback from customers. And even throughout, we launched in early 2014, we had closed our Seed round around the same time, we started hiring engineers and I effectively led the product and engineering team at that time, but I was still coding and getting feedback from customers and coding and getting feedback from customers. And then, I'd say probably around, they were 10 people or so, and we started really having a sizable engineering team. I say sizable, it's five people.

‍

And that's when you start to put on your manager hat and where you start to exercise, what is the company's strategy, how do you lead a team, how do you get the team to follow, walk in the same step to be focused on the same things. And I'd say around this time, 2015, 2016, actually right after we raised our series B in early 2016, that's when a switch flipped for me where I realized I was no longer building a product, I was building a company. And a big part of that is because a big reason why I started a company was because I wanted to build a product that people used. And so going into working on Amplitude and all throughout those years, I had the attitude of, "I am building a product. I am leading a team that is building a product." But once we raised our Series D, we were probably 25 people, we were establishing our culture and our values at the company and we were hiring a lot, we had targets to hit.

‍

That's when you realize, what you're really building is an organization that can build good products that people will use. And so at that point, I had to pull myself out of the day-to-day of prioritization, coding, management of individuals, and start really thinking strategically about, "How do I set up the organization in a way that gets them to do the right things." That was a lot of learning along the way. I think I also learned along the way that there are much better people for managing the company from a people management perspective. And so we brought on senior leaders, we brought on our VP of product, now Chief Product Officer, Justin. We brought on leaders on the engineering side as well.

‍

And at the same time I was still part of the leadership team and still forging the direction and decision-making at the high level of where we needed to be as a company. I'd say the next era though, is when I was really put to the test of building a company, which is we went through a number of phases where we had a senior leader leave. And so I think first we had a gap in recruiting, and so I had to lead recruiting and then operations overall. And then we had a gap in financial leadership, so I served as interim CFO in late 2018. And then a maybe a year and a half later, we had a gap in the people function. So I led the people team in HR. And every time that happened, the reason for me doing that was because I've always viewed myself as founder first, CTO second.

‍

And so at the end of the day, you're an owner of the business and where there's a gap, you need to fill it or you need to find somebody to fill it. And I think for me it was also a very big learning experience for how those functions worked and how to make those functions... What I should expect and how to make those functions perform better. So just a couple of examples. When I was leading recruiting, you realize that recruiting is very much a sales process and the more you can create and measure and evaluate the recruiting funnel of how many people are applying or how many candidates do we have sourced, how many people take the first interview, how many people clear to the onsite, et cetera? And what those metrics look like and having some stability there and holding the team accountable to those metrics, helps to really narrow down the areas, the problem areas that you want to focus on and gets everybody focused in on the same page.

‍

Another learning I had in my time as CFO, and this was a big one, is in order for your business to scale, you want your revenue to grow according to your spend. And if you don't have your revenue growing according to your spend, you probably need to check if something's broken and you need to fix it before you continue spending more. Super fundamental, super obvious lesson, but it wasn't until I dove into the CFO function and understood projections and created a little financial model for myself that I really internalized that, what the relationship should be between revenue and spend.

Sandhya Hegde:

Right. Yeah, I mean, sure, it sounds obvious, but let's be honest, most startups get it wrong, right? So it's one of those fundamental things that you only really appreciate when you are in the spot of having to put the data together and make decisions based on it. So yeah, I think having had the privilege of watching you do all this, I have a couple of comments. One, I think, and I've seen a lot of engineering cultures now, and Amplitude's was still by far the best one I have ever been a part of. So you and Jeffrey did such an amazing job of not just hiring people who would be a good fit for the culture, but also just really walking the talk. It's very easy to have a poster on the wall that says "Ship Fast." Everybody does that. I think the way you worked within the team really set the tone for what it meant and how important it was and how to think about it.

‍

And it's not just about shipping code frequently and fast, it's about approaching your work with a sense of urgency and appreciation for the customer. You did such an amazing job of scaling that culture, even as the team got larger and you were also very careful about headcount. You never hired just to fill seats. And I think those are things that even very experienced engineering leaders get wrong all the time when they start a company. So I mean, in hindsight, I appreciated that a lot when I was there at Amplitude, but I think now I appreciate it even more just having seen how often people get it wrong. I think you and Jeffrey did an amazing job. Kudos to you! And when you were taking on these other roles, when you were stepping into fill temporary gaps and finance or recruiting, I think, A, I just absolutely loved your ability to go learn something from first principles so quickly.

‍

It almost felt like it was sped-up, like you're watching a video at 5X, which is great to watch. But again, it reinforced this ownership value, which is that if you think about the company and what your role in a company is, there is no such thing as, "This is not my job." It's about putting the needs of the team ahead of what you think you want to do or will enjoy or not. And also, the realization that every experience has something you can learn from if you have the humility to approach it like that. So I think what you did reinforced the culture that we wanted to scale in the company as leaders so beautifully, even though at the moment it might feel awkward or suboptimal. I think it played an amazing role for culture overall.

Curtis Liu:

Yeah, I think for those that don't know, one of Amplitude's core values is ownership. Ownership, humility and growth mindset are our cultural values, something that we established very, very early on. We ran through an exercise in an offsite to write those down and codify them. And like you said, it's one thing to codify them, hang it on the wall, put them on your website, and it's another thing to really live them and show them, and you have to do that as a founder. It's your company and you set the tone for how everybody else feels.

Sandhya Hegde:

Yeah, and it sounds like you have now stepped away from all your interim roles and you're focused on the core architecture and the future of Amplitude stack again. How are you thinking about the modern data stack, and how plus all of the impact coming in from advances in AI and foundation models as well? It feels like there's going to be a lot of change going forward. And how people want to store their data, analyze their data, what type of data they want to analyze. How are you approaching Amplitude's future tech stack?

Curtis Liu:

Yeah, so I think like you said, Amplitude started in mobile analytics and then web analytics and product analytics, and now we're digital analytics. And what we're seeing is more and more companies have more and more data sets that they want to combine and analyze together. And so at Amplitude, we're really trying to provide and expand our product suite to really support different types of data sets, different types of... And it's not to say that we're fundamentally changing our architecture to do so, but we're really trying to educate customers on how they might be able to leverage Amplitude in more than just a mobile app and app behavior. There's so many different ways to bring data into Amplitude, and we're continuing to expand on how we integrate with where all these data sets come from, so that people can effectively do their analysis and understand their users, not just for the data that they instrument, but also data that might be coming from their servers, their backend, their data warehouse, et cetera.

‍

With the modern data stack as well, there's this big focus on efficiencies and, definitely in the macro environment, a big focus on costs. And so that's another area that Amplitude and we're thinking about heavily. I mentioned this before, it's like we're constantly trying to drive down costs, drive up efficiencies for our customers. And then I think the last thing is, our approach to innovation at Amplitude has largely been the same, like you mentioned this ship fast, get feedback fast, and we hold internally still hackathons on a regular basis to spur innovation and bring forward ideas.

‍

We're constantly releasing whether in beta form or in general releases, we're constantly releasing features and seeing like, "Okay, do these stick? Do these resonate with people? Where can we lean into?" One of the more interesting ones was the release of data tables, which was surprisingly... Well, I mean, I guess not surprisingly, but it was super well-received in that there are lots and lots of different ways to look at data and sometimes Excel-like table is just the most effective.

Sandhya Hegde:

Makes sense. Given how crowded the data ecosystem is. I don't know what the latest big data market map looks like, but it's probably got 2000 companies on it now. What would be your advice for new founders entering the data ecosystem? How do you make sense of what are the right problems to focus on given that no matter which problem you pick, there'll be some customer who says, "Yes, I still have this problem," not because it hasn't ever been solved, but just because they haven't implemented a solution yet. What would be your advice to new founders in the big data analytics ecosystem to just figure out, "How do I pick the right problem?"

Curtis Liu:

Yeah, I think any problem you pick, I guarantee you somebody else is also looking at it. I don't think you're going to find a problem that is completely greenfield. That's just the nature of data, it attracts talented individuals and it's a hot space right now. I think at the end of the day, what you're looking for is solving for customer pain. And you can get very far by talking to lots and lots and lots of different people in the problem space that you're exploring and seeing.

‍

Maybe they haven't instrumented something and there is a solution for it, but why haven't they instrumented it yet? Is it difficult to instrument? Maybe there's an opportunity there. For us, when we started Amplitude, we talked to 50 different companies before we actually wrote any piece of code. Two-thirds of them were not happy with or did not have a mobile analytics solution. So we started mobile analytics. And I think the thinking is, you start somewhere and you get a group of people that are so passionate about what you're doing that they help to evangelize what you're working on. And if you can find that, that's a really good starting point.

Sandhya Hegde:

Awesome. Well, thank you so much for joining us today, Curtis. This was lovely.

‍