Andrew Ofstad: valuing collaboration over authorship

Featuring

Andrew Ofstad

Co-Founder and Chief Product Officer, Airtable

Andrew Ofstad is the co-founder and Chief Product Officer of Airtable. Previously, he lead the redesign of Google’s flagship Maps product, and before that was a product manager for Android. Andrew studied Electrical Engineering and Economics at Duke after a childhood in rural Montana.

Eli: Andrew Ofstad, co-founder and chief product officer at Airtable, welcome to Conversations on DesignBetter.Co.

Andrew: Thanks so much for having me.

Eli: It’s great to have you. Let’s dive right in to Airtable. Obviously by your Twitter feed, your users really seem to love it. Let me read a few tweets here, recent ones:

This is from Leslie Baris, July 23: Seriously in love with Airtable, it was all the things I’ve always wanted project management software to do.

Here’s one from Brandon Hall, July 26: Airtable has completely taken over every aspect of my life, my to-dos, calendar, ideas, projects, content planning. This is nuts, in a good way.

It’s pretty clear that you’ve got some user love there. What do you think it is about your product’s design that gets people to fall in love with it?

Andrew: Airtable combines the ease of a spreadsheet with the power of a database. We’ve always thought of it as a LEGO kit that people can use to build custom software workflows as a non-programmer, whether that be for something like a video production pipeline, organizing all your user research, or even cattle farming. Cattle ranchers will use Airtable to track their cattle.

I think one of the reasons people love it, is that it’s very empowering. Before, they didn’t really have the means to create their own software to do something very specific that matches their intent and the specific process they have in their head. Airtable gives them that means.

The other thing is, if you are somewhat technical, you understand what a database is on an abstract level, but Airtable’s this very visual means, so I think technical folks really appreciate how much we’ve taken this somewhat complicated concept that programmers understand and made it elegant and simple, so anybody can use it for their own means.

The third thing, is we really sweat the details and put a lot of effort into design and small interactions and just making it something people will use on a daily basis. We want to make it a product that is enjoyable, that people love to come back to, and is beautiful. I think people appreciate that aspect as well.

Eli: Thanks for that high-level overview. You have a background in computer science, and then you did some product management at Google for around three years. What do you think it looks like when the design team works effectively with the product and engineering team, and where can things go wrong?

Andrew: A lot of it is just about collaboration.

For example, it works well when the engineering team participates in design along with the product and design teams: The best teams take the best ideas from anybody, rather than being territorial and saying, “Oh, I’m a designer, I’m the person that owns this design.” Occasionally, authorship gets in the way of people taking the best ideas from wherever they surface.

At Airtable, a lot of our engineering team is very product-focused, so a lot of the problems we’re tackling are creating these building blocks that people can combine to create their own applications. The type of thinking you’d do for that is very similar to software engineering, so I think people who have this mindset—of taking these building blocks and really reducing complexity, and trying to make things simple and elegant, and thinking of different layers of abstraction—those are things that can transcend design engineering. Some of the best people to think through those problems often have an engineering mindset.

I think that cognitive aspect’s real important.

Eli: Other than designers or others on the team trying to take ownership of an idea, are there other places you see teams fall short in their collaboration? Or in your experience, and how can they rectify those problems?

Andrew: I think I alluded to this before, but a lot of times, the private authorship gets in the way of people coming to the best solution. Where it’s like, you really want your ideas to be recognized a lot of times, and I think that can get in the way of coming to the best solution. The best collaborators are able to not let their own ego and sense of wanting to be the person that came up with the brilliant idea, get in the way of coming to the best solution. So that’s one thing to watch out for and certainly is, I think, something that comes with experience.

Eli: You raised a Series B last spring. Congrats on that. I’m sure you’re doing a lot of hiring and scaling teams. Are you seeing anything as far as what’s working as the best ratio of designers to engineers, or anything else around team structuring?

Andrew: It depends a lot on the specific team, what they’re working on, and the mix of folks on the team. For example, we have a lot of small teams where we have engineers who are product engineers—a mix of product and engineering—and they’ll own the spec for the most part as well as actually build the feature, and in most cases, we don’t need as many pure designers on a team like that.

The way we like to think of it is: How are we going to build this? What’s the most elegant way to build this? And how will it work across different use cases? Whenever we have a team of people working on things. We like to think of those different hats that people wear. Sometimes one person will wear multiple hats, and other times we’ll have a different person for each of those different hats, if you will.

The mix of designers to engineers very much depends on the individuals in the team. And so we’re taking that approach and a lot of times, we’re giving design ownership to various folks who are very product design oriented, but that may not be their sole responsibility.

Eli: Back in 2008, according to my LinkedIn sleuthing, you worked at Accenture, and you designed and built prototypes that you pitched to your clients. What did that experience teach you about the value of rapid prototyping and feedback that relates to product design?

Andrew: Accenture may not be the best example because we built these prototypes, but we didn’t really have customers for them, so we weren’t getting a ton of feedback, it was more just internally, honestly. I guess the lesson there was that demos and live prototypes and interactive prototypes are a really powerful tool for pitching an idea and can help get you a long ways. Thinking a bit forward, at Google, my main project there was a complete redesign of the desktop Google Maps interface. As you know, Google’s a large company, there are a lot of engineers, and teams working on Google Maps, and really the hard part of that project was looping everybody in. You had to convince them to drop their existing roadmap and suddenly hop into this redesign and dedicate a lot of effort to that.

Really you have to pitch them on the project, and our first step in that project was hacking together a prototype and not really thinking about the backend that much, or performance obviously—just doing whatever we could to realize this vision we had for a redesigned Google Maps. So the prototype was super hacky, but it was really cool, and it used WebGL and it had all these cool animations, and was pretty well executed, and we just added some polish and created that amazing demo. And after that, the project sold itself, worked for executives, as well as other teams.

That’s one lesson: Demos are a very useful way to get feedback from customers, but they’re also an incredibly effective tool for pitching a product concept, and at Airtable, we did the same thing. In the very early days, we just built this really amazing demo. The difference is, we spent a ton of time doing user studies, iterating, and really the intent was more to create this really useful database, rather than just pitching it. But we obviously used it for pitching as well, and raising our seed round, and everything else.

So, main lessons are: Demos are an amazing pitch tool, but they have to include user feedback and the ablility to iterate quickly without building out the full complexity of the real product.

Eli: Last question before we wrap up: Are there any books or blogs or other resources that are helping you now, or in the past with your work at Airtable?

Andrew: In the early days, we were really into a lot of the books and researching papers from some of the early computing pioneers, like Bill Atkinson, who built Hypercard, or Alan Kay, who was at Xerox PARC and played a big role in inventing the graphical user interface. We found those really interesting because there was this really creative and broad vision of what computing could be. And it was very much that anybody could have the means to not only use these tools on computers, but also to be able to, I guess in Alan Kay’s words, “open the hood and tweak them and customize them for their specific need.” That was obviously huge inspiration for Airtable.

I’ve also been really into architecture books—like Peter Zumthor’s Thinking Architecture or Cesar Pelli’s Observations for Young Architects—and found a lot of similarities between building software products and architecture, where it’s a balance of beauty and form and functionality. I appreciate reading those for inspiration more than anything, but also, there’s a lot of overlap I think between building products and architecture.

Eli: Andrew, it’s been great having you on, thank you so much for being on Conversations and best of luck with Airtable.

Andrew: Thanks a lot, Eli, and thanks for having me.

designbetter conversations

November 2, 2018