Zach Lloyd Led the Google Sheets Team; With Warp, He’s Answering Developers’ Need for Speed

The Founder and CEO on how his background helped him reinvent the command line terminal, the importance of app speed, and how the three ways to measure product growth.

Zach Lloyd Led the Google Sheets Team; With Warp, He’s Answering Developers’ Need for SpeedZach Lloyd Led the Google Sheets Team; With Warp, He’s Answering Developers’ Need for Speed

Zach Lloyd is a previous Principal Engineer at Google, Cofounder and CTO at SelfMade, and the Interim CTO at TIME. His past experiences led him to start Warp, a Rust-based terminal, in 2020. Warp’s goal is to recreate the command line to be more useable, humane, and powerful for everyone.

I spoke with Zach to talk about Warp, why it beats Google Sheets, and how the team continues to maintain upward growth and user engagement.

What is Warp?

Warp is a reinvention of the command line terminal. A terminal is one of the tools every developer uses every day. It's a text-based interface where developers run commands, build their code, interact with cloud systems, and run CLIs. It hasn't meaningfully changed as a product in the last 40 years, so what we're trying to do is look at it, look at how developers use it, and build something that is the best possible version of the product.

What that means from a product perspective is that we're focusing on improving the usability of the app and also focusing on making the app cloud native, collaborative, and usable for teams, not just individuals.

One of the things you talk about on your website is speed. Tell me why you started focusing on this.

This app needs to be fast. Developers can do things with the keyboard faster than they can do things with the mouse. So they're typing and they're very sensitive to any kind of latency. We experimented with building this as a web-based app and it was slow. There was noticeable latency.

So we ended up building it using Rust, which is a very fast-compiled language. You can compile this Rust code base to run in a browser, but it won't be running as JavaScript. In the end, it'll be more like a native app in the browser than your typical react-based, clunky web app.

Did your experience of running the Google Sheets team inform your thinking here or not at all?

Yeah. Close to the top of the list of complaints about Google Sheets from heavy spreadsheet users is that it's slow. And that's fair. If you were to compare it to Excel for building a financial model, the performance is noticeably worse. It can't do big spreadsheets. We had a hard time winning over accounting departments and finance-types. To this day, I think a lot of people who work on Wall Street won't use Google Sheets because of its perceived latency.

A lot of that latency just came from the fact that it was a web app. Technically, it's really difficult to build something at the same level of performance that works in the browser, just because JavaScript is a slower language. So when we started building Warp, I was like, "I really want to start with the fastest possible platform. I don't want to limit ourselves on speed out of the gate." So that was one of the reasons that we picked this architecture.

But you knew you wanted it to be collaborative in a way that the current status quo is not?

Correct, although to be clear, Warp has not yet achieved that. Today, Warp has some collaboration features, but we don't have the magic that you get in Google Sheets where, all of a sudden, there are two people in the same thing at the same time. We're going to build that.

I think we have an interesting opportunity to be more like Dropbox, where there's a great single-user use case for storing all your stuff in the cloud before you start sharing it. Then, once we have single users hooked, we’ll start to focus more on the teamwork and collaboration features.

So what makes Warp better today? Because if I'm using it on my desktop and it's fast and it's not yet collaborative, how is Warp getting people excited right now?

The big thing is that we've changed the structure of the terminal. When you think about what you do in the terminal, you spend time typing things in to execute them, and then you spend time dealing with outputs.

The input is very different in Warp. We also do a lot of things that make it a lot easier to do input. We have this menu, kind of like Google auto-suggest, where you can get help as you enter things, including documentation on what you're doing, which is nice. We can construct commands out of natural language.

Anything you do in Warp is shareable. And then any command that I run, I can add it to this library of team commands. So this is the first start of the collaboration features, and then, on top of that, it's all very fast, because it's built with this native architecture.

When and why did you start Warp?

We started in June 2020. I wanted to do something where there was a potentially big impact. This is a tool that is used by all developers. I was less interested in building a company around a domain-specific thing than I was in trying to build something that all developers could use. I was looking for a project that I could work on, honestly, for the rest of my life. So I thought that picking something big and hard with a lot of impact would be the most fun and challenging and had the highest potential for reward and longevity.

Also, it was a very good fit for me with my background working on Google Docs. It made me very comfortable with building this type of app. A good founder-product fit.

How is Warp doing today?

It's good. We're in a public beta. We went into public beta in April. We have tens of thousands of developers using Warp every week, which is cool. We have a great feedback loop—thousands of people are in our Discord. We seem to have people who like the product. If you look at it on Twitter, people really like it.

The biggest complaints that we have are around the fact that we ask people to log in to the terminal, which they're not used to, and that we're not yet open source. I do think it's in our best interest eventually to open source at least parts of the app, just to make people comfortable from a security and privacy standpoint.

We haven't got the team features working yet, and I think that's important if we're going to have a business around it. So I'd say it's still pretty high risk and early stage. But going from zero to a hundred users, I think, is hard. Going from a hundred to tens of thousands, I think, means we have something pretty good, but there's still a lot to figure out.

What do you do right now to stay close to the customer?

We have our mass feedback channels like GitHub Issues, Discord, and Typeform. We also have more focused things, where we do a regular user interview rotation and bring people in to do deep dives. We've done a bunch of UX studies in terms of Warp onboarding and feature use.

We’re about to do some design partnerships, where we see if we can get an entire team onto Warp. If we can prove that there's a whole team use case where Warp makes that team more productive, I think that's our strongest business proposition. So that's the next big product thing that we're trying to prove.

How do you think that you've been getting your product instincts right now?

I'm a heavy user of this thing and so is everyone on the team. We have a product deck of things that I, our founding designer, and some of our engineers have done, where it's a series of things that we could build. I'm constantly showing this to people, whether it's in recruiting contexts or a user-study context. So we build up signal around like, oh, people are excited about our notebooks feature, but no one seems to care about our template features.

For the innovative stuff, I think sometimes we just have to take a guess and get a feedback loop going as fast as possible. It's very hard to figure this stuff out without real usage of the thing.

How do you think about product-led growth? Do you feel like you guys are following a path of product-led growth?

The way that we're thinking about growth, in general, is in three parts. There's retention. We need to make sure that people are going to use the product and that if we're going to grow it, they're going to stick with it. We didn't even try to grow until our retention was pretty good. Going along with that is engagement. Are people using it every day? How much are they using it every day? Do we have evidence that it's their main terminal, or are they just trying it?

The second thing that we haven't done is viral loops from the app. And I think if we can unlock that, we're in an amazing spot. We have a little bit of that with our share-a-link feature, and we have a referral program within the app, but the referrals only drive 10%.

The third thing is top of funnel, and for us, that's content and communities. So it's content around launches and then it's content for developer-facing products. We have a couple of developer advocates who are on the content side and we're trying to do a little bit of kickoff and SEO projects. The big thing that I really would like us to unlock is some sort of team use case and viral looping app.

Tags: Success