Live: SaaStr Workshop Wednesday: Creating Enterprise Platforms | Airtable PM Helen Zeng

While you are waiting, please type into the chat where you are logging in from. Love seeing how global this community is. I am tuning in from San Francisco. Great. Love to see that in the chat. Keep it coming Again, we will start in just a moment. Oh Barcelona. Saster was there last year. So much fun. All right. Okay everyone, thank you for joining us and welcome. I know we took off last week due to the holiday in the U.S. but welcome back. And again, the goal of Workshop Wednesday is that Every Wednesday at 10am Pacific we will be here rain or shine sharing detailed, interactive and hands on workshops. We'll bring along an expert in the SAS community. Today we have a really exciting one I am happy to share and they will walk us through a few slides, their topic and then it is an interactive discussion. So please get your questions ready and come on camera if possible. We love to see the community interacting. Take use of this 30 minutes or so to interact with the speaker, us and your fellow Saster community. All right, so today we have Helen Zhang, product manager at Airtable. She will be discussing building for builders, creating enterprise platforms with airtable. Again, get your questions ready. This is going to be a great session and we want you to to make the most of it. All right, well Helen, it is so great to have you. Thank you for joining us.

Yeah, thank you for having me.

Of course. All right, so a few warm up questions just to get to know you a little better. So what does a product manager at Airtable do? Tell us just a little bit of what you're responsible for. Give us a bit of background.

Yeah, of course. So as is true at any company, there's different types of product managers here and we're all segmented broadly on audiences, different audiences and different Personas. So there's folks obviously focus on activation which is on the customer acquisition side, enterprise which is like admins, it scaling and then I'm on the core product side. So there are folks here who are focused both on the end user experience as well as on the builder experience. And you know, judging by the topic here, obviously I'm focused on that builder side. So for me it's when we say builder we really mean the people who are setting up airtable for the rest of their organization to use. Right. Typically if you're an Airtable user, like someone set that up for you, you go into the tool, all the tables are set up, the interfaces are set up and you're just using it like it's software. And I'm really thinking day to day about the people who are actually doing that work. So understanding what features they need, helping them understand their end users and overall just like thinking through how we can help them essentially do no code development.

Great. Well I am an Airtable user so thank you for your work. Our second question is what project are you working on today that you are most excited about?

Yeah, but we've been working on a couple exciting things. But the focus for me right now is really helping out builders with in terms of scaling their workflows in airtable. So what that means is there's just like a lot of repetitive work, especially in project management as I'm sure we're all well aware of. So you know, there's things that like there's types of projects that you might do all the time. So if you're in marketing, you might be doing something like a social media marketing campaign or creating you know, or like creating a like blog post blast, launching a new feature and there's like the same kind of tasks that you do all the time. Right. And if you're tracking that in airtable, what's an easy way for you to scale that work? So we're creating something that sounds pretty simple but I think is really, really useful for this. Just around record templates and specifically being able to link multiple record templates together so you can just label something as like T1 marketing campaign, add all the possible tasks, deliverable templates, et cetera within it and then whenever you're ready to spin one of those things up, you can just like use that template and sort of scale up that whole project.

Very cool. Well again, excited to put that into use. In the last 12 months, what's been the hardest thing you've worked on?

This is. Yeah, hardest thing. I think it's interesting because it's less of a specific feature or product and more of like sort of shifting strategy in the company. So just to give a little bit of context, I joined Airtable about a year and a half ago and half a year ago we like I was really thinking or I started off managing our Automations product which if you use Airtable it's you know, one of the top three tabs. It's how you build workflows essentially and that's sort of really come into product maturity. It, it works, it supports a lot of high ceiling features and what I really want to do is to think more holistically about how to help builders like build out logic and build out workflows in Airtable that extend outside of Automations. So the work here has really Been messaging internally about like, how do we rebrand the team to think more about low code creation generally or like no code creation generally and then helping as well. Think about like, how do we do this not just in the context of automations, but instead, how do we extend the tendrils of all the things that we do, extend the tendrils of logic throughout the whole product and of course like sort of telling this story, doing a roadshow to everyone else who's within the company.

I'm sure that's relatable to a lot of people tuning in. So thank you for sharing. I will now hand it over to you again. Everyone get your questions ready. After Helen presents, we'll have an interactive discussion.

Okay. Awesome. Yeah. Thank you all for tuning in. So today we're going to be talking about building for builders and how to create enterprise platforms. So specifically I want to talk about how do you build a compelling platform on top of your core product that really empowers users to customize your enterprise product to all the different needs that they specifically have and to really then build out a moat for your product? Because if it's, you know, if it's acting in exactly the way that they want to, empowering the workflows in exactly the way that they want, it really makes your product much stickier and it makes your customers of course, much happier as well because there's better product fit. And so a little bit about me. I'm focused on low code creator products at Airtable and I'm a product manager here. But previous tips this. I've been building platforms at a couple of other companies, primarily developer platforms, but at Slack, Twitter and at Microsoft. So been doing this for a really long time. Truly have been doing platforms my whole career, which feels like forever. Yeah. And today we'll be covering a couple of different topics. The first is just helping you understand like do you really need a product? Sorry, do you really need a platform? And when is the right time to start thinking about platform monetizing? We'll also talk about different types of platforms that are out there and what kind of platform product makes sense for you or makes sense for your product right now. And as a part of that, understanding your user motivations and how they can help you make that decision. And lastly, talking through an example product journey in terms of building out that platform from end to end. Because I think essentially customers just don't want to settle for one size fits all enterprise software anymore. They want solutions that just work for exactly what they need. And yeah, being able to provide that is a really significant competitive advantage. So let's get started. I think the first is to really think about, okay, does your product really need a platform? And I know this is very whatever, silly meme, but it's honestly it happens all the time. Because I think a lot of times people start thinking about platforms as sort of a way to bandage all the different sort of gaps in their core product. Of like, okay, if we have an API for this, then you know, we can kind of hold off on building this feature and that feature because if a customer really wanted it, they can just use our API and kind of bridge that gap for themselves. Which is true to a point. Right. That's a part of customization that comes with having a platform. But I think the key there is you cannot solve glaring product needs by doing that. An API is not this cure all and especially not if your typical users are not in technical. Also, platforms are just really hard to build and maintain and sort of do well. So you should only start on the road to this investment if it suits your business needs. Right now, like Every, I think SaaS business wants to be a platform. You're like, okay, people can build on top of us, we'll create this ecosystem. But yeah, think about whether or not it's the right way to address your long tail needs and whether your customers right now are at the point where they want to start customizing your software at all. So a platform comes first of all in a lot of different forms. There are, and I kind of have this like tenant square here, but platforms can either be something that solve a couple of core use cases or something that helps you address like a huge long tail of use cases. And so as your product is starting out, especially when you have a smaller user base or your software is doing something quite targeted, you might already know from your customers that there's just a couple of different integrations that they're all asking for. Right. And so like a lot of your customers might all be using Google Calendar or Salesforce and Jira and they kind of just want something that do do those things. Or I think at Airtable, a huge need that we hear from our builders all the time is we just want to be able to do notifications well, we want to be able to generate reports well, and I think that's something where you can start to think of as these are your core needs. And sort of on the other side, as your customer base grows and as you see a more variety of different industries in your customer base, you might sort of see a lot more long tail use cases. And this starts to get really specific into a way that that company operates. So they might start to think about, okay, I have this internal tool I want to integrate with you. I have these specific needs. And that's where something like a developer API starts to make a lot of sense. Or as your company and platform starts to really grow and you start to generate a lot of community interest as well as a lot of sort of longer tail needs, something like an app marketplace might make total sense. And that's where you see something like the Slack App Marketplace come to play or the Salesforce App Exchange. That's kind of like, like the ultimate apex of having a really, really powerful platform. But I think the thing to note here with these four boxes is that these are all things that you can sort of build out iteratively. You do not need all these pieces of a platform at once. And so I think it really behooves everyone to think about, okay, what type of platform can I start off by building? And I will go through this a little bit later. In terms of the journey, that Slack, that was at Fourier Table, that was out for like five years, really started to think about this whole journey, where we started off from and how it really helped us scale. Okay. And the way to start thinking about where you want to start off in terms of building your platform is, of course, by starting off with your users and really talking to them, talking to your potential builders and figuring out what their needs are. And when we talk about builders, we're talking again about the people who are, in a lot of ways, setting up this enterprise software to be used by the rest of the organization. So what you really want to talk to these builders about is like, what do their end users want out of using Airtable, out of using Slack, out of using whatever software, and essentially like, understanding your customers. Customers. So you can start off with questions like, hey, are they interested in enriching their experience with your app? Or are they interested in exporting that data elsewhere? An example of this at airtable is that obviously airtable stores a lot of pretty rich data, like important business data for customers. And one way that people want to integrate is like, hey, I want to take some Airtable data and I want to bring it into my data warehouse or my analysis tool to really start understanding our trends over time. And so that's like one potential type of integration. Whereas another type of integration like you might see at Slack is, okay, I see a lot of my users on Slack that's where people are and I just want to give them different ways to interact with that. And so that's where you see like simple but pretty powerful apps. Like I want to integrate Google Drive in so that when I'm sharing a link it asks me if I want to share the document also with everyone else in the channel. It's like what kind of integrations do people want to build? And I think you can also think about this as are people interested in you as the surface that people are interacting on or are they interested in your product as data that is useful elsewhere? Another interesting question, are just like digging into the common integrations that your customers are asking for and that they're using. So like what is the most common software that people are using today? I think as I mentioned before for us at Airtable, Gmail, Outlook, Slack, some of the most common things. And that's not a surprise, right? They're the pretty like they're common productivity software that's out there. But I think what's interesting to us at Airtable is that this shows that notification type integrations are especially powerful. We own the data, but people want to be able to see that data elsewhere. And I think the last sort of set of questions that's really interesting ask your customers is would they build on top of your platform themselves? Are they more interested in off the shelf solutions? And I think this really gets to this part of it where it's like do they want to build things themselves in this sort of top two boxes of like built by customer integrations either in a no code way or with an API? Or are they more interested in you having a rich set of integrations that they can sort of plug and play with. In which case instead of helping them build, you kind of want to court a set of third party ecosystem developers to start creating integrations that your customers can then start using. And a core part of that is, okay, are your customers then open to paying for consultants or open to paying for these off the shelf integrations? Because if they are, then that's value prop that you can bring to developers to say like hey, you should be building apps for airtable because if you build for apps, if you build apps for Airtable, our airtable customers are going to pay you for these extensions and that really helps them of course, but also helps your customers like bridge that last gap. And I think you need to remember that you're building an ecosystem. So figuring out which builders you want to target is really, really important. So if you're thinking about, hey, I want to support these partners. So you're building strategic integrations for us or I want to find community developers that are building these integrations that our customers can plug into and pay for. Make sure you're telling that story to the this ecosystem. Well, like tell them why they should invest on your platform. For instance, I think at Slack a really interesting thing was since it was a Surface, a lot of other SaaS players said okay, if I build a Slack integration then because that's where people are spending a lot of their time, they're going to get eyeballs on my software and it's really going to help my business sort of expand and grow within existing customers. So that's a value prop that you can then go and tell and your BD team can take to potential partners because it helps grow that existing user base and it's a way to help them make money. And then the next part of that is do partners, do developers see a long term future with you, which is like, do they feel seen and supported and heard by your team and is there a sense of community? Because once you start telling people that they can build a business on top of your platform, they're like dependent on you for their livelihood. Right. And so they want to know that this is sustainable. They want to know that you're not going to build a feature that cannibalizes their business business. They want to know that if there are feature requests that they have that you'll be responsive. So is that investment something that you're willing to make? Would you hire developer advocates if you really wanted to support this? And so I think this is a really important part in talk in thinking about are you ready to support a more off the shelf kind of ecosystem.

Cool.

And so I think you can really summarize this in terms of like which kind of platform you want to start off by building depends on what you want to like prioritize and what makes sense for you and your builders. So a no code builder platform might make a lot of sense if a lot of your builders are non technical, but you want this to be truly a core part of your product experience. And so that's something that we do a lot at airtable. Right. Because airtable is meant to be this like no code software solution. So of course we're investing a lot in these like no code builder tools and that's the way that we're approaching our whole business. Whereas something like a developer API makes a lot more sense if you know that your customers either have technical resources that they can lean on from their IT team or your customers themselves are quite technical. So this is how I think a company like Retool, for example, thinks about their user base. And actually at Slack, since a lot of, since a lot of Slack customers start off with engineering and product teams as like their first foray into a company end up being quite technical as well. And then when you're thinking about strategic integrations, it's like, do you have a clear idea of the use cases and of the clear sort of partners that you want to start approaching? And lastly with an app marketplace, like I said before, this is sort of like the apex of support here. But like, what do app builders get out of it? And are you able to sort of make a clear value prop for why people might want to be part of your ecosystem? Okay, so having said all of that, yeah, let's go through how all of this work at Slack. In my five years of being there, that platform journey actually really started off with just a couple of strategic integrations to prove out the ecosystem. It went on to thinking about launching APIs for targeted simple use cases and then thinking about leveraging an app directory to support longer tail use cases and finally ending with that no kill code builder experience. So starting off with the strategic integrations, which is that sort of bottom left box from before, meant at Slack, we've really built out the first few dozen of integrations internally. We leverage sapier to get off the ground with these use cases, but we've literally built the first, I think 80 integrations internally with the, with the software that we knew that our customers were using, like mailchimp and Google and Google Drive as obvious ones for instance. And that really helps our users see, okay, like I can use an integration with Google Docs, maybe this platform is something we're trying. It's worth thinking about what other integrations I could do and really help their creative juices start like getting going. And then it's when they started thinking about okay, how else can I extend Slack that we started launching APIs for really simple use cases. So there were things like slash commands for instance, which I think we probably all use in Slack at some point of like, I want to use a quick command, I want to start a zoom meeting, how can I integrate that? And this really paved the way to allow customers to start building integrations themselves, even if they had pretty limited technical resources. This then once we got a lot of these use cases starting to get going and we got signal that people really wanted to build on this platform both Sort of as third party developers or for themselves. We started building out this idea of an app directory. This was until years in, in terms of promoting and supporting more use cases and really making it much easier then for customers to go to a place, get an off the shelf solution that they're interested in, like for something like polling with like simple poll or poly if you use that to be able to solve their issue, to be able to solve their use cases. And also by having a directory like this, it told third party developers this is something that we're investing in in the long term. So then in turn incentivize a lot of third party developers to build because they knew there was a way for them to get exposure for the things that they actually built out and sort of very lastly, only in the last couple of years did Slack sort of start scaling with a no code workflow builder. And this is like one of the last things I helped work on before I came to Airtable. And this really helped to remove that technical barrier to customization and allowed less technical folks to start building tools like the ones that we've seen before, even if they had no coding experience. And I think that really helped. Overall Slack complete that two by two matrix of all the core different types of platform features. But you can see that the journey really took time and we invest pretty strategically in each one. So overall, yeah, don't expect your platform to solve your core product problems. Your platform is supposed to sort of build on top of your core product and really help extend that. And in order to figure out which features you want to build, start by understanding your users of course, and these users are your builder's customer. So talk to your builders. And lastly, I think it's just important to think about building your platform one step at a time and not hurrying. So yeah, that's the end of my presentation. Thank you so much. And I am ready to take questions if you have them.

Great, thank you so much, that was super helpful. First question, you talked a lot about customer research or talking to your customer or your customer's customer. What type of research are you doing in those circumstances to find out the use use cases that are needed, etc.

Yeah, really great question. And I think at Airtable we're so fortunate in having a really, really strong CE team in our and we're really, really close to sort of our customer support teams. So they give us a lot of early signals. Our account teams will come and say hey, like Netflix is interested in this feature, et cetera. And so I think that becomes an early start. We run these things with our CE teams called CE Rodeos. Very cheesy term, but they'll come to us quarterly and say, hey, these are the top 10 requests that we're hearing from enterprise customers or that we're hearing from sort of self serve customers. And it gives us a starting point and pulse check on what we need. And then each team has, including mine, has a dedicated sort of user research team. So we'll go and we'll talk to customers both on the enterprise side, which is where we source through our account teams and just in general like by sort of sending out surveys and sending out screeners to talk to our customers so that when we were thinking about a potential problem, we can really validate that problem with customers. First to see, hey, is this a pain point that you're really experiencing? How do you think about that? And as a builder, is this something that you're really prioritizing and asking questions like I talked about before, like if we built a feature to solve this, it's interesting to you, but would you start using it like today, would you start using it next week?

Got it. Thank you for the insight. I believe John, or John Mark has a question in the chat he would like to ask.

Thank you. One of the things we struggle with using airtable is how to apply it to solve a specific business problem. You know, we're kind of looking for guidance around best practices on how to have the right optimal, you know, and efficient outcome. And this feels often like a bunch of Lego blocks that you're just throwing on the table and you got to figure out yourself how to put this together, which is probably partly what you're going for, is to be very agnostic. So people can use this in a variety of different ways. But that can also have a downside to it where it creates, you know, actually creates friction, process friction and, and difficulties with, you know, integrations not maybe being available or those types of things. We're trying to use it to, to automate a product management lifecycle and there's a lot of different constituents cross functionally and you know, it's not entirely clear what's the best way to use airtable to get the best out of that. And we're not exactly sure where to go with that.

Yeah, I think you're hitting on something that's really important and really true and something that we're, we're thinking about a lot right now at airtable because honestly I think our, like we're, we really value people who are using airtable for project manager or for product management. And we, we, we don't want this Lego block like experience. Right. We know that you're, you're coming to Airtable for to solve a specific problem and you're not here to figure out how to use airtable for the first fun of it. And so we're actually hard at work on a couple of different ways to think about how to sort of prepackage Airtable and pre configure it in a way that makes sense for use case like project management. And so when you're coming in you can just start, you can kind of like what's a good analogy for this? It's like if airtable were Legos instead of you coming in and us giving a block of Legos and being like okay, well you can build out a spaceship like this. You come to Airtable, we're like we built out a spaceship out of these Legos but you can add to it if you want to. Right. And that's really the approach that we're trying to take. And so you'll see releases from us like pretty soon actually on how this will work. And John, if you contact me after this I can, I can point you to some of those specific things that we're working on and some of the betas that we're running for this. So yeah, really excited to hear from you actually. And some of the things that I'm working on like record templates, go towards solving needs like this specific will do great.

You're becoming customer research and connecting with my question. John Casey, I believe you have a question in the chat.

Yeah, first of all thanks for great presentation, kind of thought provoking. I went through that journey with Slack and I'm starting to go through kind of that journey with Airtable and my question was like within in the product management discipline and how you're scoped your role at airtable. Do you have an all encompassing view of builders where builders includes like the internal guide Exxon Mobile, the third party gadfly consultant and also maybe a third party ISV that wants to develop a quasi product. I just would was interested in your thoughts as a PM about how you, how you sub segment if you do the builder community.

Yeah, I think it's so important to sub segment that builder community. So I think you mentioned a couple of different things. You mentioned consultants, third party independent software developers and then I think there's also sort of those internal builders that I've been talking about that are like more no code and So I think consultants, that's something that, or actually let me start off with like sort of like third party app developers. We have a team that's dedicated like to those folks right now internally that's a part of our API and our platform team that handles our app marketplace. So, so I think we think about those audiences pretty specifically. Right. Because third party app developers, this is about to get kind of cerebral. But whereas I said builders think about what their internal end users do, a third party app developers thinks about what builders want and what those builders and their end users want. And so they're kind of like one step away and they need to build for a lot of common use cases. So we deserve to think about them a little bit sort of differently. And they also have different needs, like wanting to monetize, wanting exposure. And so yeah, we treat that community sort of differently. For that reason we want to make sure we cater to their needs. I think consultants is also something that's really interesting to us because a lot of customers are interested in airtable and to John Mark's point earlier, they come to airtable, they have a problem, they want to set up airtable to solve their needs, but they might not be experts themselves. And so our consultants are a really important part of that community. And if you go to our airtable forms, actually we're starting to build out a community for our consultants so that as folks so that we can refer customers to relevant consultants if they're thinking about using airtable but might have specific questions, I think, but they tend to be power users already and, and like power builders. So they're honestly, I think less of like we need to teach them how to use airtable and more like we want to be able to connect them to folks that keep them invested in being a part of the community.

Great. Our next question comes from Manny.

Hi Helen. This question, are you able to hear me?

Yes.

Okay, great. So this question is about retention. I understand that, I assume that larger companies would have more retention than the smart piece, but do you do anything specific about retention in the product, like for example publishing templates or do you have any segments that you focus on to improve retention?

So I think at a high level, like of course we do care about retention, we care about customer churn. And I think sort of going back to what I was talking about earlier, that's way to maintain retention is to make that make sure that your product is sticky. And I think it actually by having really great platform and really allowing users to customize your software, that's the best way of sort of building retention. Because in a more fickle way, it's like the switching costs that are higher. Right. If you put in all this work into managing your projects through airtable, it's hard for you to like switch to another project manager software. And you do want to, because airtable is ideally taking care of all your needs there. And so I think for me, the way that I think about sort of retention is actually like anytime we're building a builder product, so something like the Record Templates project that we're working on now, one of our key sort of metrics that we monitor is does this help customer retention overall? So first of all, like, do builders actually get to the end of using this and sort of applying it to their team's use cases? And also once their team starts using this feature that the builder has built out, does it make their like airtable sticky usage more sticky?

Great. If we're just over time. So if you do have any last minute questions, please type them in the chat. Want to make sure they get answered. How do you communicate your product strategy internally?

Yeah, great question. And I think that's something that I talked about before at the very top for those who might have joined a little bit later. I think communicating your or that one of the things that I worked on is actually just communicating our product strategy and the way that we're expanding our sort of team's charter and purview from just sort of Automations, which the local creation side initially started off with, into thinking about how to sort of scale workflows overall and how to embed logic in more parts of airtable. And so I think a lot of that is just like helping other teams understand how you can work together and actually like helping them understand that you can help sort that like you share common goals. An example of this is I recently been talking to our notifications team about like workflows, right? And we've been talking about, hey, you know, notifications are a core way of what Automations is being used for today. And obviously we know that notifications team is thinking about this. So like, how can we work together? And in particular we're talking about like, hey, how can, how can we build our foundation so that your notifications can work on top of our Automations infrastructure? For example.

We have another. Thank you for answering. We do have another question. Ravi, let me know if you would like to ask it or if you'd like me to do so.

I can ask Kaitlyn, thanks for the information, Helen. Just exploring a Table in the context of small businesses or small to medium businesses in a enterprise context where some of the businesses cannot afford the analytics and some of the data requirements and insights. So in that context is a table working in the direction of where the SMBs for their data needs and kind of connecting with the cloud ERPs or cloud solutions. There is so many are going evolving. So any insight on how the a table can be leveraged to provide a quick and easy solution to get to the SMB needs?

Yeah, thank you for that question. And so I think that this is actually an area where we're relying more on our platform and our ecosystem to help meet this demand from SMBs. Airtable is obviously a place where people store a lot of their critical business data, but we're not in the business of being an analytics tool. Right. We don't want to be doing too much. However, since this is where a lot of that data lives. We know that by partnering with other with other companies. So for instance we have a really great partnership with fivetran and with a couple of other data insights tools that like you know, a customer who is interested in analyzing their airtable data can actually export their data out to these tools and analyze it there. I think we are, we know what our strengths are and we don't want to sort of dilute all the things that we do by also getting by competing with these partners and doing a lot of that like sort of insights ourselves. Although I will say we are pretty interested in helping admins in general understand stand and get insights on how airtable is being used in their company. But I think that's a little bit different from what you're asking.

Thank you.

All right, I know we are over time as per usual so thank you everyone for joining us and a big thank you to Helen. This is great, really insightful and we really appreciate you joining us. I keep saying at the top we will be here every week and again to you I have lied to you. Next week we will be at Saster scale so please join us there. Sign up if you have not done so already. It is a fully virtual event. We would love to see you there but if we do or we don't, we still will see you two weeks from today at 10:00am Pacific and we will be looking into building a sales engine, navigating the transition from founder led sales and this will be with the CEO and co founder of Unit 21. So looking forward to seeing you all soon and thank you again Helen.

Thank you.