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. Ooh, 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 US, but welcome back. And again, the goal of Workshop Wednesday is that every Wednesday at 10 AM 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 SaaStr 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 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, um, 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 focused 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, uh, 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. We've been working on a couple of 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 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 a social media marketing campaign or creating, you know, or like creating a blog post blast, launching a new feature. And there's like the same kind of task 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 a specific Specifically being able to link multiple record templates together so you can just label something as like Tier 1 marketing campaign, add all the possible tasks, deliverable templates, etc. 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've used Airtable, it's, you know, one of the top 3 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, 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 him 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 the 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 like 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 and powering 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 previously to this, I've been building platforms at a couple of other companies, primarily developer platforms, but at Slack, Twitter, and at Microsoft. So I've 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? So do you really need a platform? And when is the right time to start thinking about platformizing? 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, um, 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 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 businesses 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 Tenet Square here— but platforms can either be something that solves 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 if you— 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 sort of 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, you like, as your customer base grows, and as you see a more variety of different industries in your customer base, you might start to 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 AppExchange. 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 4 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, OK, 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, a company that I was at before Airtable, that was out for like 5 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, right, 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. 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. So 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 sort of 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 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 to ask your customers is, would they build on top of your platform themselves, or 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 2 boxes of like built-by-customer integrations, either in a no-code way or with an API? Or are they more interested in, like, 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, say, 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 gonna 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. 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? Like, would you hire developer advocates if you really wanted to support this? And so I think this is a really important part 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. Where 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 worked at Slack and through my 5 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-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 leveraged Zapier 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 worth 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 SimplePoll or Polly, 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 incentivized 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 it— 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, you know, 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 like 2x2 matrix of all the sort of core different types of platform features. But you can see that the journey really, you know, 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, you start by understanding your users, of course. And these users are your builders' customers. 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, what take— 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 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 and 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, etc. 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 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 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 difficulties with, you know, integrations not maybe being available or those types of things. We're trying to use it 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 thinking about a lot right now at Airtable because honestly, I think our— like, we really value people who are using Airtable for project management or for product management. And we don't want this Lego block-like experience, right? We know that you're coming to Airtable to solve a specific problem and you're not here to figure figure out how to use Airtable for the 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 preconfigure it in a way that makes sense for a use case like project management. And so when you're coming in, you can just start— you can kind of like, um, what's a good analogy for this? It's like if Airtable were Legos, instead of you coming in and us giving you 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 specifically too.

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 a 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 guy at ExxonMobil, the third-party gadfly consultant, and also maybe a third-party ISV that wants to develop a quasi-product? I just 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, um, I think you mentioned a couple of different things. You mentioned consultants, um, 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, um, 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 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 developer 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, 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. Right. And so our consultants are a really important part of that community. And if you go to our Airtable forums, 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 under— 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, or I assume that, you know, larger companies would have more retention than the SMEs, but do you do anything specific to about retention in the product? Like, for example, publishing templates, or do you have any segments that you focus on to improve retention?

Uh, so I think, um, at a high level, like, of course we do care about retention, we care about customer return. And I think, um, so going back to, uh, what I was talking about earlier, the best way to sort of 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 switch to another project management 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 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 your team starts using this feature that the builder has built out, Does it make their Airtable sticky usage more sticky?

Great. 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 loco 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 serve, that like you share common goals. An example of this is I've recently been talking to our notifications team about like workflows, right? And we've been talking about, hey, you know, notifications are 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 would like me to do so.

I can ask, Caitlin. Thanks for the information, Helen. Just exploring a table in the context of small businesses or small to medium businesses in an enterprise context, where some of the businesses cannot afford the analytics and some of the data requirements and insights. So in that context, is Airtable working in the direction of where the, 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 Airtable can be leveraged to provide a quick and easy solution to get to the SMB needs?

Um, 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 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 it 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. Yeah.

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 week we will be at Saastr Scale, so please join us there. Um, sign up if you have not done so already. It is a fully virtual event. We would love to see you there. Um, but if we do or we don't, we still will see you 2 weeks from today, um, at 10 AM Pacific, and it— 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.