05 December, 2017

10 mins

API Partners with Adam Duvander of Zapier

Be willing to serve your community and understand that some of your work is a down payment for the relationship.

For our latest “What I’ve Learned…” interview at OpenChannel, we spoke with Adam DuVander. A self proclaimed lover of APIs and the people behind them, he leads developer marketing at Zapier, helping Zapier’s API partners integrate with its automation platform to empower their shared customers. Previously he led developer relations for database API Orchestrate (acquired by CenturyLink Cloud) and developer communications at SendGrid. He spent four years as a writer, editor, and analyst for ProgrammableWeb, the journal of the API economy. Way back he also wrote the book on mapping APIs, Map Scripting 101, and covered developer topics for Wired. He’s been living APIs and developer content for over 10 years and spent some time with us to share what he’s learned along the way…

When building an ecosystem of developers and API partners, how important are live events, conferences, and meet ups?

Adam Duvander: I just attended APIStrat and it was fun to have it in my city (Portland). They do a great job of getting the industry’s best at the event, both speakers and attendees. From the very first one, it’s been a must attend.

In general, events are helpful for finding people to collaborate with and less so for finding customers and leads. That may be possible but being able to meet people and then work together on projects are what I look for in an event.

You have to know your audience. At Zapier, our platform helps you connect APIs for a SaaS application to our platform. It is an integration platform so It makes sense to be in a place where people are talking about APIs. Your readers audience is going to be different.

If you can find really pinpointed events, those are worth going to. If I was evangelizing a specific API today, I would choose small meet ups regionally over large live events. At least early on you’ll see a lot more value out of those.

With large events, I’m not sure that’s the right fit for evangelism at any scale, though it may make sense at some point.

OC: You call yourself an “accidental marketer” and talk about sharing knowledge instead of features. We’ve heard people say “developers hate marketing” but how do you think about developer marketing?

Adam: One of the reasons I registered was to have a timeless version of my thoughts on that. Saying developers hate marketing isn’t very helpful. One of the reasons is that everyone hates marketing when it’s overt marketing.

Everyone would rather have their problem solved and be inspired to do something. In this case it just comes from the marketing department. With developers there’s an additional radar for anything that smells of marketing.

That’s why we need evangelism groups within companies. Meeting developers where they are, listening to them and understanding their problems is the first step. Then you can echo that back to them while mentioning your product in an authentic way. You also have to be willing to have things that don’t always mention your product.

Be willing to serve your community and understand that some of your work is a down payment for the relationship. If developers see that your company cares about the community then they’ll pay more attention because you’re both part of the same community.

OC: What are the most successful strategies or tactics for growing an ecosystem of developers and API partners?

Adam: I have a content background so gravitate towards content and tutorials. They’re a great way to show someone what’s possible and teach them in a scalable way. You can’t be at every single meet up, every single night. Find the things people want to do with your product and show them how to do it.

I joined SendGrid after meeting their evangelists at events and being really impressed. I felt like I could scale their effort through content. The focus was not only to write content myself but to help them share the interesting things they were doing at hackathons and meetups on a larger scale.

If you’re choosing topics that people care about, they will find it either via search or other people linking to it. Those have been the most successful things.

When I went to Orchestrate we built a developer relations team that was content first. We did events but content was the foundation. That was good. It works.

For tactics, look at what tools your audience is already using and how your API can be integrated with those tools. If an authentication library needs to store the user details in some database, we said it may as well be Orchestrate. If a company needs to send a confirmation email, it may as well be sent through SendGrid.

OC: What are the most important metrics a platform should track when doing developer content?

Adam: At the top level, and coming from ProgrammableWeb, it’s pageviews. That’s still the top level metric of API partners that we’ve impacted. Ideally you also want to track what specific pages are driving signups.

Once you have a signup, you can start sending email drip campaigns to help them with next steps. The faster you can get developers to actually creating something the better, and you want to track how often that is happening

An example from Orchestrate. We had post sign up page where there was a button for “Create An App” and a button for “Read The Docs”. We wanted more people to create an app so we said, “Let’s see what happens if we take away Read The Docs.” We didn’t take the docs away completely, but the number of developers creating an app increased.

At Orchestrate we had six different language SDKs so all of our documentation spoke a developer’s language of choice. The next step was deciding what we wanted to see happen and tracking that. At Orchestrate we wanted to see API calls go through.

OC: You started at ProgrammableWeb in 2009 which was early days for web APIs. What has been the biggest change in APIs?

Adam: When I joined we were talking about mashups, especially driven by mapping APIs. For context, I should say I wrote a book on mapping APIs, so I love them.

John Musser (ProgrammableWeb founder) found me via a post on WIRED saying, “Mashups are dead but the web is alive.” Basically, I was making the argument that we should stop talking about APIs because they were already in everything. That was actually less the case then. Now it’s even more so.

I remember the first mainstream outcry around APIs. During Instagram’s signup flow you were able to find people you follow on Twitter (enabled via Twitter’s API). Twitter shut down access to their API and people got mad at Instagram. Now, not everyone said “You took away API access” but what they were complaining about was really API deprecation, which is a thing that usually only developers care about.

You had companies opening up their APIs without understanding how it benefited their business. If you look at Google Maps, 12 years ago it was freely available with no path to payment. Now Google Maps has a path to payment. That’s the biggest change I would say now is that you see APIs crafted in a way that acknowledges how they make sense for their business. Companies realize they need to align an API with the interest of their business and API partners.

That is why I love SaaS and infrastructure APIs, it’s clear how they benefit businesses. Evernote has talked about how people who use integrations are more likely to upgrade to premium and FreshBooks users that have an integration are 3 times as likely to convert to paid. Companies have seen the value in API partners, thats for sure.

I keep waiting for us to stop talking about APIs because it really is just now how we build software. Moving forward everyone will understand the the value of being able to connect via APIs. I think they’ll design things differently when they know they will have to share it.

In the same way that “User Experience (UX)” as a field barely existed 10 years ago, developers will start thinking about the way that the data flows via APIs as well.

We need to think about what things people want to accomplish and what use cases that they need to support. That has not been a big part of APIs so far. We’ve been too focused just on the needs of the company that is producing the API and not the API partners or end users

OC: When evaluating an API, people often have a “Build vs Buy” decision. Is there a framework you use for making that decision with APIs?

Adam: A developer is naturally going to think about building something. That’s the default response. Show them that there’s more to it. Get them to an “Aha” moment, where they realize that there’s a whole bunch they don’t have to do because of your solution.

Help them see how your solution gets them further and lets them focus on more important things once they’re supported by your software. It’s still the inspiring and teaching I mentioned, but with an added “here’s how hard it really is.”

OC: How can a platform instill trust in their developers?

Adam: Nothing helps like time. The biggest fear for any developer is that a platform will go away. Time helps.

With Orchestrate, the database is a big part of someone’s application. That’s good because you’re integral to what they’re building. The downside is that no one’s going to rip out their existing database and replace it unless they have a really good reason.

Find people who are working on something new, maybe something smaller. Whether that means a startup or a new project that may be related to a major product or company.

It’s being able to find a use case where you can win. For email like SendGrid, it could be a specific use case like confirmation emails. They’re important for a product and everyone wants that email to go through.

OC: In a post on ProgrammableWeb you found the most successful APIs had an App Gallery or Marketplace for API partners. Why is that and what are the best ways to showcase developer success?

Adam: Wade, the CEO of Zapier, has talked about how an integration strategy might not be successful because you aren’t telling anyone about it. It’s the same idea here. You have to tell someone that developers are using what you have.

The biggest reason goes back to inspiration and showing what’s possible. The important part is when early developers built something you have to promoted the heck out of it. Twilio used to have a whole campaign around doers.

It wasn’t about what they built with Twilio, it was about the person and the cool things they are doing.

In that ProgrammableWeb article we were able to see across thousands of APIs and what worked. Then it’s easy to see what the best APIs have in common.

OC: What’s something you love to do or are really good at that most people don’t know?

Adam: I wouldn’t say that I’m good at it but I really enjoy playing piano. Specifically 1980s TV theme songs on the piano. I play a mean “Cheers” theme song. Cheers would be my go to. Everyone knows the song. Everyone knows the name.

Grow Your API Partners!

Thanks to Adam for sharing his insights. If you want to learn more you can follow him on Twitter and connect with him on Linkedin and check out

Want more from platform leaders at Shopify, Intuit and Box? Check out the “What I’ve Learned…” series.

Related posts

How to Build Great APIs with Mike Amundsen of Mulesoft
Community Interviews

How to Build Great APIs with Mike Amundsen of...

Now you’re creating a set of tools to solve a problem that nobody knows about, for people you haven’t met....

From Industry to Ecosystem with Michael Jacobides of London Business School
Community Interviews

From Industry to Ecosystem with Michael Jacob...

We have a bad habit of saying “take a look at what Google or Facebook are doing” and trying to...

App Marketplace Strategy with Alan Glickenhouse of IBM
Community Interviews

App Marketplace Strategy with Alan Glickenhou...

Table of ContentsIt’s a matter of getting businesses to understand that’s where the real money is, and it’s definitely not...