Former Zapier partner on Zapier's commoditization of SaaS

They expected integrators to build to them. And they expect them to go through the approval process because that’s what connects that app into the marketplace, and that's where the value is. The app providers, the people that are going to be creating the triggers or the actions, are looking for ways to access that, because it makes their app a little more sticky, right? If you have these other actions and I can offer that stuff as additional functionality in my app, then people will build those workflows and it feels like once you've built those workflows, you're not as likely to switch off of either Zapier or whatever that platform is that's integrated with Zapier because you can't just transfer that to a different trigger. That was the reason why we wanted to do it, was because we just wanted to create more engagement.

I don't think we did that much work to really figure out why this was better. We just felt like it was a cool thing to give to our users. But it wasn't cool enough that we wanted to deal with a whole lot of demands from the Zapier side. 

We weren't willing to really put the widget onto our site. They wanted to put it someplace pretty native inside our app experience, and we were really just not sure what that would do. Like for one, we didn't want to put JavaScript code running in our context that we didn't have control over.

One thing I'm curious about is how over time your understanding has changed in regards to thinking that integrating with Zapier is is a value add big value, add for, the users of of one of the tools connected to Zapier.

Guest: So in my current experience, everybody says that their app connects with every other app. Across our competitors, all of them say that they do all of these integrations, and then when you get to the site and you actually start clicking around, you'll find that most of them are just doing Zapier integrations. And that's I think a big part of the benefit of being partners: you get that connectivity to the no-code ecosystem, if you want to call it that, without having to actually build a bunch of integrations yourself. 

What you give up there is the product experience, which has two parts to it. One is that it's not your product. They have to leave your product in order to go there. They have to create an account on Zapier. They basically adding an entirely new step, a new integration, a new configuration and thought process, everything, to your apps. And now they're managing this configuration across two totally different application experiences. 

And your app is always going to have specific goals. There's specific, simple things that we know our users are gonna want to do. We can intelligently figure out what context to pull into integrations. Once you get into Zapier, it's like, “Okay, you've got this generic blob of data, please connect whichever part of this generic blob of data should go to this other generic blog of the data that we're getting from MailChimp or whatever.”

Zapier doesn't know—it's necessarily generic because it's trying to be like an alternative to writing integration code. So you have to switch mindsets now into this “builder mode” where you're setting up workflows and doing all this wiring. You go from being like a marketer to an electrician or coder or maker or whatever that persona is. And I think that you lose out on that experience we had with walled gardens where everything's thought-through and designed for you and your personas carry through different threads of the UX and so you can expect things are gonna be designed for you. Now, you’re the person designing it, you're the person creating the workflows. You're now out into your own kind of a little bit scary world where you might wire the things up wrong, maybe it's not going to work when it gets over into MailChimp or whatever your other integration is.

Or maybe something changes. There's more points where things can fail. Things can not be set up correctly and you can have to go back and manage that. So I think it's actually a terrible user experience. I think for people who are trying to build something specific where we know and understand their workflow, asking them to go wire it up in Zapier takes them like way down into a rabbit hole they don't need to go. 

There are some people who that's their mentality, right? They're like, “This is my identity. I'm a no code marketing person, or I'm a builder slash whatever the thing is that they're trying to actually build.” And they don't mind that experience. 

So I think for Zapier people, you know that they've gotten into that and they're ready to take on that burden and they're comfortable because they've done it before. Or they see this as a tool in their tool belt. It's I'm not, I'm a developer, but what makes development useful is the application domain.

Do you see companies moving to a model with a ‘whitelabeled’ Zapier that helps companies create these native integrations more easily?

Guest: I've seen that a few times. There's Tray.io, and something called Paragon that’s more developer-centric, and both are basically trying to build at the developer level and integration layer so you can deliver more integrations faster and they manage them.

These services can be very expensive. So I think their idea is to work with bigger partners, to work with an Airtable-like company and help them get to a hundred integrations faster.

There will be people that are interested in using Zapier because they love the Zapier way, but I think that's going to be more of the thing where you’ve got a universe of tools like Zapier, Bubble, Integromat, and Airtable and they’re all gonna have their own philosophy on what it means to do this, like no code stuff, right?

Airtable is really focused on data. If your thing is, “I'm collecting data, and what can I do with that data? How can I modify it, link it together, or trigger different behaviors?” If that's the way you think about the problem, Airtable is going to be more appealing to you than Zapier, which is all about control flow.

Zapier is like somebody who's more of an imperative programmer who says, “I want to do this step, then this step and this step, and I want to set up these sequences of actions.” That kind of thought model. 

So I think this is going to come down to some core experience on each of these different platforms that attracts a certain type of problem solving and a certain type of user and people will gather around whichever one sort of fits their mental model.

And then from there it's not going to be easy to have a territorial fight in this space, because the pitch is all about the user having control, you own your data and being able to move it around. The whole idea with no code was that you have the control that a developer has.

You're empowered to be a builder, which means to be able to break out of those limitations that silos provide. Introducing new barriers and new walled gardens into that environment, I think, I can't imagine how it would work. I can't imagine how somebody would really start to build moats or defend their territory and keep their users.

I think they have to create more gravity, more experience that's close at hand so that users don't stray as far. But I think everyone's going to be playing that game. And I think that people like Zapier naturally have a disadvantage in this environment. If you look at the set of Zapier users versus the set of all users that are trying to do something a little bit outside of the context that's typically offered by their platform, obviously, Zapier is a smaller community. 

Zapier is not going to be able to be better than the apps themselves at providing integrations. There’s going to be some people who say, “Oh, I wish this was in my world in Zapier,” but most people are just going want the app they’re using to integrate directly, like, “I wish my spreadsheet could also send an email.”

Something that I'm just not as sure about is what percentage of people out there really want that kind of added flexibility and control. I think there's a lot of people that just don't want to think about it that much and just are happy to use whatever works, but there's definitely a big, long tail of people that are just like, “Ah, I wish I could just do this a little bit differently.”

The ethic of no code is to have data be portable, but Zapier, even though it's a no-code company, is based on this idea of silos that don't talk to one another.

Guest: Yeah, the problem they started solving was the problem of data locked in silos and they provided a path out of that. They basically created the proprietary standard that would allow all of these different silos to inter-operate. I think the world that we're in now is where every company has to implement each different services API. And that's why there's a pain there. The API for MailChimp's not the same as the API for MailerLite. If you had a standard approach to that, you might be able to consolidate and make it easier to connect to any of those. But it's not really in those company's best interests to be API compatible with their competitors.

That's where Zapier steps in and does it, but that creates a dynamic that we're concerned and sensitive to. Do we want when somebody goes into Zapier for them to see “Here's some alternative apps you could set up?”—like these other ones could be your inputs? And then you look at other tools, and maybe you think the price is cheaper and you don't need these other features? I don't know. We just don't necessarily want to be commoditized that way.

And I think Zapier as a service does create a kind of commodification, almost like fungibility in terms of all the different competitors within a certain class. And I think that's one of the reasons why people are trying to pull out of that and offer their own ecosystems because then we can give you all of the actions without necessarily being compared with all of these other triggers.

And when we want to expand, yeah, we may also want to provide a plugin that does more than we can do for some money, because that's cool and it gives more flexibility to users. So we're willing to send people off to become someone else’s customers when they hit a certain need, but we still want to retain the value and the flexible experience of not having to go to a third party for services that we think are kind of part of our offering.

So in those cases, we want to be able to correctly market the alternatives. And I think that's the big control thing that you give up—you give up your ability to do product marketing when you outsource integrations. And that is a two-way street. That's both how you present alternative packages and also what you know about how people are using those, right? We use our own spam tools, but we also give people the option to click a button and set up Akismet. But we want to know how many people are using each and what kind of features in Akismet are being used and whether we could easily add those to ours. And then we could keep people from having to go set up an Akismet account. So this is I think the counter to no code. And I think there’s tension between the two because as platforms build more integrations, they're still going to be looking to keep people as close as they can.

And so I think, again, you want to offer integrations, so that people don't leave your platform or start going outside of it, but you also want to maintain your own gravity.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.