Lessons learned launching and marketing 800+ integrations (Wade Foster, Zapier)

So as Cody said, I'm one of the founders, CEO at Zapier. If you don't know what Zapier is, we're a workflow automation tool. We hook into over 800 apps, so ultimately the end users of your all's tools can set up integrations between any of the stuff we support. So we have a developer platform that empowers all of this, so folks will build integrations into Zapier and automatically you get integrations with everything else. So that's a little bit about how it works. It wasn't always 800 apps though. It's taken us a while to get to this. So you can actually see kind of our progression over the years getting new apps on Zapier. And so at the very beginning, it was actually really, really difficult to build integrations. We were building them ourselves. And then as we've kind of grown, it's been a little bit easier to add new integrations. We have better tooling. The dev platform helps a ton, things like that. So I'm gonna talk a little bit today about some of the lessons we've learned launching these 800+ apps, things that if I had have gone back 5 years would have really helped us out and helped us scale a little bit better. So one of the interesting stories I like to talk about is in the early days, it kind of illustrates how challenging this is. We built— we were approached by a really big company, one that you all undoubtedly know of, and they asked us, "Hey Zapier, you know, we love your all's product. Can you build an integration to our product? And, you know, big company, big user base, so we get really excited. We're like, oh my gosh, this big company wants us to build this integration with them. I'm sure if we build it, it's gonna turn out fantastic, right? So we pop open the API, we start playing around. It's a little bit old school, like, well, documentation's not so great, but like, ah, we're smart, like, we'll figure this out, right? You know, we'll get in there and figure out the intricacies of it. Anyway, it takes us a little longer than we thought, but we kind of got to a place where like, hey, it's working locally. This seems like it's going to be good. We tested it out with a person. It's like, OK, I think we're going to go ahead and launch this. So we launch this thing. The partner's like, hey, it looks good, but then doesn't really help us talk about it at all. And then over about a couple weeks, we had about 400 people try it. And of the 400 people that tried it, only 4 were successful. And so we're like, ugh. Like just heartbreak, right? We poured, I think ultimately it was over 100 engineering hours into this integration with this big company, and it just totally flopped. And we're like, oh, that's just so painful. Like, we do not want to waste all of our time and efforts on things that aren't going to work, right? None of us likes doing that. You counter that to, for example, with our integration with Typeform, another forms company out of Barcelona. So with them, we worked with them up front, and they were like, hey, let's do something cool, a cool integration that's going on. And we're like, hey, how can we make a good experience for your users? How can it be a good experience for our users? We talked a little about what that might look with. We kept it small in scope, and ultimately came up with this experience where as you build out a Typeform, you'll, you know, you set up your form, and then kinda part 2 is this configuration stage where part of this is integrations, and right inside of Typeform you can set up integrations through Zapier. So we kinda designed this really nice experience. It took us not very long to ship it. And it worked out great for both of us. So like we get dozens of new customers from this every day. Typeform actually gets about, users churn at about half the rate when they're using Zapier versus when they're not. So it works out great for both of us. You know, big success. So, we wanna do more integrations that are like Typeform and less of the stuff that we did earlier, right? Like that's the kind of things that are great partnerships when both of us kind of win together. So, how can we do that? I've got about 9 different things that I've observed over the last 5 and a half years running Zapier that I think can help you all out. So the very first one, start small. If you're product-focused like I am, probably your intuition is like, how can we build this like, beautifully crafted integration? Something that's really simple for our users to build. We're gonna like, nail this payments piece, the sign-in piece. It's gonna be like, super slick. The user's never gonna know kind of what happened. It's just gonna be magical, right? That's kind of like our default. However, oftentimes that adds a lot of complexity to the integration up front, and you may never get to a point where you ship something. So we found it's often a lot better to find like the simplest piece of functionality that's gonna make a customer really, really happy, and start there. And then once you've launched that, you can start hearing the feedback from your customers and see, Where are the places to iterate? This is like classic MVP sort of stuff. Works the same with integrations and partnerships. And the other nice thing about when you do small integrations is they don't have to be huge wins, right? Like, you can settle for some singles if you're not putting as much effort into it. But if you're trying to spend all this time on them, you have to have home runs every single time. So keeping things small and lean is really helpful, and you are able to get a lot more speed small wins out of that. Number 2, know your use cases. So integration is a really loaded term. Depending on who you talk to, integration can mean various different things. So some users might think this means like a web UI widget. Others might think this is like pushing data from one app to another. Others might think this is a, a two-way sync. So just know when you're talking to partners and when you're talking to users, you gotta know what the use cases are for your user base. Talk to your users, figure out where your holes in your product are, and understand how maybe an integration or an ecosystem partner can help make your product better. That way, this helps you in a couple ways. One, it makes sure that when you go to look at your product roadmap, you're gonna be building the right types of things. It also helps when partners approach you for potential partnerships. When they approach you and say, "Hey, I wanna build," 'X' with you all. Well, if 'X' is totally different than what you're hearing from your customers, you can say like, "Hey, that's great. That actually doesn't match up what we think our users need." And you can politely decline. Versus if they say, "Hey, we wanna do 'Y' and your customers are all about 'Y'," you might have a really good partnership there. So if you have these kind of use cases known up front, it really helps you make sure you're kind of building the right types of partnerships that are gonna help your users out. And it also helps you build an API that's ultimately gonna be most beneficial for your developers, 'cause they're gonna be able to build the types of experiences that you know that your users are gonna want. Uh, 3, make sure to define what success looks like for you. So depending on what types of integrations and partnerships you might be after, you might have different goals. You might be trying to retain your customers better, get more users out of a certain feature. You might be trying to drive distribution, so you want to get a bunch of signups. And it's really good to do some back of the envelope math to know what success might look like for any given partnership. So for example, we have up here, imagine you have like a partner that comes to you and says, "Hey, let's do an integration. I'm willing to promote this. We'll send an email to 100,000. We have 100,000 customers. We're gonna help you promote this." Well, without any other information, you can start to do kind of some back of the envelope math about what the outcome of that situation. So you can say like, "Hey, 10% might open the email, so that's gonna be about 10,000 people that see that." Maybe 30% click to a landing page, so we'll have 3,000 on the page. Maybe 20% convert to a trial, so now we're down to 600. And then maybe 20% then convert to paid, and so now we're down to 120 new customers. Now depending on the size of your org, that might be a really exciting outcome, or it might be something that's really disappointing. But if you don't go through this exercise, you won't be as sure if that's gonna be a good outcome or not. So it's really helpful. You don't need a ton of information. Usually just 1 or 2 things can give you some insights into whether this feels like a good opportunity or not. Number 4, quality over quantity. I think all of us in the early days wanna have a big ecosystem. We wanna have as many apps as possible, and it's really hard not to chase that. I know we've made the same mistakes. Like, "Hey, let's get as many apps as we possibly can." It doesn't matter if they're great, but they're awesome logos, so it'll be fantastic. Trust me when I tell you though, it's way better to have 5 stars than, what is this, like 24 poops? So way better to have that. And the way you can make sure to do this is you can start to track, if you're tracking things like NPS, you can segment based on users that are using different integrations versus if they're not. So you can try and get a sense of, the quality of an integration and how they're impacting your users and decide how you want to progress with those partners and if you want to do that. And it's gonna be way better to keep that quality bar high too. The other thing you can do is make sure to set standards. So define upfront, this is what a quality app looks like for us. This is what a quality integration is gonna be. As a result then, you can have this kind of style guide that you give devs and they'll know, they'll have a checklist. If I do these things, that's probably going to lead to to success when partnering with you and you partnering with them. The other thing this really helps with is it helps you make faster decisions. So if you've already had this pre-baked style guide, you can make decisions based on this quality standard rather than at the last minute being like, "Oh, well this is like a hot startup," or "This is like a really cool logo. Maybe we should let it slide," right? Instead, you're like, "No, we've got this quality standard. This is what we need it to be." and you can make sure that that's the deciding factor rather than something a little more fuzzy. Uh, 5, make sure to bake in discovery for integrations on both sides of the platform. This is probably the saddest thing I see a lot is, you know, a bunch of engin— smart engineers spend a couple weeks or a couple months building a great integration, but then no one on either side thought like, how are we gonna even talk about this? So you build it, nobody comes, right? Any of the users are gonna be like needle in a haystack style situation trying to find the integration. So it's really important even before you think about building the integration to talk to your potential customer and say, hey, how might users discover this? What are the ways that people are gonna know that this exists? Intuit just had a great example with Fuse about how they talked about right when the user has a failed invoice, Fuse is presented right there. So discovery's kind of built into that integration so it makes it easier for folks to find it. To find that. So it's really good to think about those types of things up front. In my experience, you often get a little more leads from things like high-profile app directories, showcasing your integrations in like onboarding emails, or in customer-facing help docs. Things like press, tweets, blog posts, those are all nice and help with kind of a broader trend, but they don't always drive a ton of new users or customers to you. It might be different, you know, sometimes it works, sometimes it doesn't, but. In my experience. Number 6, commit to support. So, an integration is really, it really is a two-way partnership, right? So make sure that you commit to supporting your side, whether it's your API or whether you maintain the integration. Make sure you commit to doing that, and then also make sure your partner has the same standards that you do, and they're gonna also commit to supporting and maintaining your integration as well. This is really important because is if something goes wrong, your users are gonna need help. And they're gonna need to know how to work with your support team or your partner's support team to figure out how this could get better. And it's really a big bummer to the end user if you or your partner basically just spaces out and says like, "Hey, that's not my problem. The other guy is the one you need to talk to." It should really be a joint relationship with your partners to help support both users, right? So make sure you commit to that and realize that that is an ongoing thing that you're gonna have to do with an integration. You can't just spin an integration or an app up and expect everything will be gravy from there. 7, make sure to prioritize your options. We're all strapped for resources and you only get so much ammo. So when you look at all the potential partnerships you can do, there's a lot, right? There's a ton of people in this room alone And that doesn't include the thousands of other apps and companies that aren't even represented here. So it's really important to think, where are the best places I can spend my partnership time? And do that up front because that way when folks come to you and say, hey, let's partner, you can see, hey, how does this opportunity stack up in the list of other opportunities? And you don't commit to something on your roadmap and then later think, ooh, I really wish we would have not committed to that one and we'd have done this other one instead. There's a really great— let's see if I can get this thing working over here. There's a really good book. Gabriel Weinberg wrote this book called "Traction" where he talks about marketing channels. This is a really good book just to learn general marketing things, but there's one thing in here in particular that I really like. He's got this exercise for testing channels to figure out which marketing channels are gonna work great for your company. You can actually apply the same concept though to integrations. Run a little bit of a checklist against your potential integrations that could exist for your company to figure out which ones are gonna have the biggest potential output for you. The way this might look is you set up like a little table over here and you have different inputs on the left, things like, hey, do they have an app directory? Are they gonna talk about us in app or their help docs? Are they gonna send a couple customer emails? Is there a bunch of dev time involved? What user types do they have? Are they enterprise? Are they SMB? Do they match up with our user base? You can have a set of things that you think make a good integration for you and your company, and then have a whole bunch of options and say, "Hey, do these things meet those criteria, yes or no?" And at the bottom you can say like, "Hey, this is gonna be big, medium, small, whatever," right? To figure out what's gonna be a good opportunity for you to maybe go after. In this way, you make sure to spend your resources in the place that are gonna get you the best bang for your buck. As you start to grow, a really good thing is to start to transition to a platform. So when we were younger, we had to do all the work building all these integrations ourselves. Over time, more and more people were asking to build on Zapier, and we thought, hey, if we build a developer platform, we're gonna be able to empower this. So we actually have a developer platform. We've had one since 2012. We actually launched a new version of it just yesterday. So if you have an app on Zapier or don't have an app on Zapier, you should check out the new CLI stuff. Which is really cool. But the thing that platforms make it a lot easier for is scale up and get a lot of new integrations into the platform, which is great. But remember all the other stuff needs to apply here, right? Just because you have a platform now, that means you're probably gonna have to commit even more to support because you're gonna have a lot of people building on your side as well. So there's also things that go into building a platform that matter too. A good example of this as well is we launched our Zap Templates API as well yesterday. And if you remember the Typeform example we gave, we defined this nice little experience inside of— we've got a little dealio up there. Let's get rid of that. Ah, screw it. So Typeform, we built this nice custom experience, but we didn't have any way to replicate that across any other partners. Didn't make it very easy for them, even though we knew this would be a good way to work on it. So we actually built a Zap Templates API, which allows people to showcase Zaps or potential integrations inside their app using their own styles. So they can style it to make it look a little more native, feel a little more at home inside that company's app. So you actually see here, this is a screenshot of Unbounce. They've started using this already. And so it's something that any of you all can take advantage of. And this kind of stuff allows you to kind of scale the types of use cases that you want to see, and you'll potentially be able to do more integrations that you could on your own. Lastly, you want to make sure that you have a win-win for your partners. So when you're smaller, you're gonna get approached by a lot of companies to build integrations against them, 'cause that's what they do. They try and get you to build as many— they'll reach out to as many companies and just hope that some of them are gonna convert into potential integrations. As a small company, though, you need to realize You have only so many bets you can take. Make sure to go through this exercise and make sure that it's gonna be a win-win for you. A lot of times big companies will say, "Hey, this is a strategic partnership." Things like that often mean, "Let's do a bunch of speculative work and maybe it'll work out." But when you're small, that's not super— that doesn't make you feel good. You need things to work out when you're really small. So make sure to go through these exercises to know what is going to be a win situation for you. And then as you grow and you are going to be able to come bigger, you'll find that you have more leverage over partners. And this is usually generally a pretty good thing to be able to kind of dictate a little bit better things for yourself. But however, you need to realize that you have that power and not put your smaller partners in a position that they might make bad decisions because you do have that influence over them. So if you're asking them to do things like discount their prices or give away really long trials and things like that, you can totally make the ask, but realize that that may not be in their best long-term interest. So you don't want to influence a young company who may not have the experience to do something that's not in their best interest that leads to them really, really struggling. The best partnerships are one where you and your partner get a really, really good outcome and customers are taken care of. So work to find that, and if you can't find that, That's OK. There's many, many other partnership opportunities that you can go find. So just to wrap it up real quick. 1, make sure you start small. 2, make sure you know your use cases. 3, define that success up front. 4, quality over quantity. We want good apps. Bake in discovery. Make sure people can find your apps. Make sure to commit to support to know that folks are going to be well taken care of. Make sure to prioritize the different integrations you can work on. Make sure as you grow you can build a platform and scale this up even more. And then really look for win-win opportunities for your partners. So thanks everybody. Really appreciate you taking the time to come out. Happy to field questions.

OK guys. Hello. Hey. Thank you for your presentation. Quick question is, when you come across integrations that are subpar, that just suck, how do you handle those? Do you just— stress it to the partner that they need to do a better job, and if they don't, you kick them out? How would you do that?

[Speaker:SETH GREEN] So generally, you try and have those quality standards up front. So hopefully you don't push something onto your platform that does suck, that generally does suck. But every now and then, it does happen. Something gets through for whatever reason. Or maybe a partner is going through a really tough time, and they're not able to commit resources to something, and it just atrophies. Maybe they got bought and now the resources weren't there that was there before. And I've really found it's just best to have a candid conversation with them. Say like, "Hey folks," don't shut them off, be mean and shut them off right away, but say, "Hey, we've seen these numbers. Here's some customer tickets that are popping up. It's really affecting the quality of experience your customers are getting. It's really affecting the quality of ours. And it's hurting the reputation of our company as well. So here are some options we have." We can work with you to help get better, or we can take it off and then maybe revisit this at a later date. Either one, but we can't keep it how it is because this isn't gonna work. I think it's usually just best to have that professional conversation with folks and try and figure out a way forward that's gonna be in the best interest of customers.

Hey Wade. Hey. How many integrations did y'all have to build before you got critical mass and then it flipped and people started building for you?

We built probably probably about 30 to 40 integrations ourself out the gate, and then started hearing from various different people things like, it started happening a few different ways. People would phrase it in a few ways. They'd say, "Hey, how do I get my app on Zapier?" Or they would say, "Hey, why isn't our app on Zapier?" Or things like that that would indicate they want a way to make this happen. Then usually when we were at that stage, we would flip the question on them and say, "Hey, if we had a platform that allowed you to build this, do you think you would spend the time? Would you commit an engineer for a week or two weeks to work with us on building this integration?" A lot of times we would hear yes. Not always, but a good amount of the time we did. That indicated to us, "Hey, if we build this, people are going to actually use this." I think we did that, and then we were able in 2012 to launch our integration platform. We got 13 people To all build on it, we kind of— in the early days, it's kind of like a joint thing. You're building some stuff, they're building some stuff, and then you do a big launch around it. And that kind of gets the momentum behind it. So we had 13 folks highlighted by HubSpot. So we had a big one that kind of looked really nice for other folks. And that kind of got the ball moving and snowballed from there. [SPEAKING SPANISH] [Speaker:AUDIENCE] Sorry.

Follow-up question on that. Are there any segmentation dynamics around the type of developers that are more likely to build on the platform quicker? I.e., Salesforce's roadmap isn't going to move, but smaller guys or gals move faster. Is there?

There's not a lot of rhyme or reason to it, I found. I found big companies that can move really fast, and I found small companies that can be super slow. One of the interesting things we did early on was our developer platform was through a web UI. You went to zapier.com/developer and you actually built it right there. And we did that for a reason because we thought, hey, if we make this like point and click to build your integration, we're gonna get folks who are maybe not as technical that can still get the integration built. So we found in the early days we had a lot of like product managers who were like semi-technical that were building integrations for Zapier. which was really good for helping us get things going. It also has some unintended side effects that product managers also maybe don't build the highest quality integrations. But, like, we were able to work around that. And so now we, in fact, one of the big reasons we launched CLI now is because it actually bakes into, like, more people who are, like, a little bit bigger and have maybe more professional roadmaps. And it's like, this is a real more, this is like a real way to build integration. Like, you'll hear that comment from from time to time, and so it has the tools that they expect like version control and pull requests and all this good stuff to work with. So we kind of have both sides now where it's like no matter the type of partner you are, you can kind of build an app on Zapier, but we optimized in the early days to just focus on those who are gonna get it done fast.

[Speaker] How about, so what about the integrations that you did in the early days and maybe turning those over to partners, or how have you, or maybe not develop— or improving those integrations. Can you talk a little bit about that strategy and how that's changed over the years?

[Speaker:Wade Foster] Yeah, so we do have about 50 of these integrations that we built originally. And we started with the biggest integrations, so they were the ones that we thought were the most popular. So we looked at Google and Salesforce and QuickBooks and apps that were like, we know if we build these, there's gonna be a market for this stuff. Over time as we've grown, there's been asks improve these integrations. Like, hey, how can we make these integrations better? And so one of the things we've wanted to try and do is empower more people to make improvements to these. So with the launch of CLI yesterday, we can now kind of share ownership of an app. So whether it's Zapier building these improvements or the third— our partners building those, both of us can contribute to this. We can both do pull requests against an integration. And allows improvements to happen in tangents. So whoever has the resources available at a given time can take a stab at making those improvements. So it lets you and your partner be a little bit more agile versus kind of having this siloed fence of saying like, this is my integration, I own this, you all are the platform, right? So you kind of, it's nice to try to build the partnerships as close together as you possibly can where it can really truly be like a joint venture to make a nice thing for your users, your joint users.