Creating a Developer Community Around your API: Interview with Marshall Johnston

Marshall Johnston is a Product Manager at NinjaCat responsible for their APIs and Integrations. He shares best practices for PMs building integrations for the first time, as well as how SaaS companies can support third-party developers and create a developer community around their API.

‍What does NinjaCat.io look like today? What value does it provide to its customers (digital marketers)? ‍

NinjaCat is a scalable digital marketing analytics platform. What makes it unique is that we have a data model that allows enterprise agencies and brands to track their advertising data across all of their channels. 

For example, if you are an agency and you have plenty of advertisers and plenty of sources in which you’re advertising, we have the ability to aggregate, clean, and transform this data, and then let you report on it all within our product. 

‍

What we notice is that previously many of our current customers were going into each of their individual advertising reports and creating a Google Sheet to aggregate, analyze, and update this information. You can only imagine how long this would take if you had thousands of advertisers you’re managing.

It’s really unbelievable seeing how much time we actually save our customers, because we do all of that for them, while also saving them time by creating visually appealing reports and presentations they can share with stakeholders. 

Any advice to or best practices for product managers who are charged with building SaaS product integrations for the first time? 

Definitely understanding the goals of growth and the company’s strategy. There are integrations that you can build specifically to reduce churn, to acquire new customers, to grow accounts, or to improve NPS scores for example, and all are very likely different integrations. 

I think it's always seen as most impressive to build new integrations, but in my experience, it matters more to focus on gold-plating the integrations that you do have to ensure that the use case for your customers is actually satisfied. 

The impact of building a new integration will forever increase the size and cost of your team. The cost of every new integration that you're building is ever-increasing due to support, maintenance, and updates, and the benefit of each individual integration that you're creating is ever diminishing. That’s why gold-plating existing integrations often provides the best ROI. 

PMs should understand that the first integrations they build to their app are going to be key. 

When looking at the long tail of all your integrations, think about if there are better ways to solve the problems that a new integration would solve. For example, if a commonality amongst all your integrations is that they’re consuming CSV files for large amounts of data, think about creating a smart connector for a CSV processor that will process those files for you. 

All in all, they should really think about ways to gold plate their core group of integrations and think of creative long-tail solutions for the ones that are not really going to benefit many of your customers in the long run. 

Related Content: App Marketplace Benefits and Managing the Long-Tail Partner Experience

‍

Can you share some of the biggest challenges you have faced as a product manager in getting SaaS product integrations built?

I would say, generally speaking, the biggest challenge with building integrations is that you are 100% responsible for only 50% of your product, right? 50% of that integration is the API contract which you sign into when you build with that third party. 

If that integration goes down, and it's your third party’s fault, your customer is still going to be frustrated with you regardless of who is to blame. 

And so, especially as an integrations PM or an integrations team, you really need to do a good job of setting proper expectations with your customers and internal stakeholders. I've seen this done in a bunch of different ways. For example, doing proper error logging and handling, and letting customers know that there is an issue proactively. 

Having frontline support is also a huge differentiator. At NinjaCat and FreshBooks, one of the things that got us through the toughest times of building an integration at the beginning was our customer support teams being empathic and understanding towards why we need to solve a problem for our customers. 

Customer facing teams are communicating with both internal teams and external stakeholders, and so, if you can create internal systems that make it easier for them to understand what's going on so they can translate that information to the customer, that's super helpful.

Customer expectation setting is also huge! I'm a big believer that much of a product’s general issues can be solved by just communicating better with your end user. 

It’s a problem if customers are coming to you about an issue with an integration, and you already know about it. That creates tension in the relationship, and so, be upfront and open with your customers, even if it's frustrating for them at the beginning.

At NinjaCat for example, if we’re dealing with hundreds of millions of rows of data, and we have 40 rows that are off for one reason or another, that impacts our customers. And so, even though it's a very small difference on our end, it can have a huge business impact on them. Communicating that with them is key so that they can set the stage for their stakeholders. 

Related Content: Building a Support Strategy for Your B2B SaaS Integrations: Key Considerations for Product and Technology Partner Managers

What advice would you give companies on how to support third-party developers? 

Definitely, documentation. In my mind, so many poor design decisions and pitfalls created in your API can be solved by really well-documented APIs. 

Back to our previous point about expectation setting, documentation is an excellent way of setting expectations with the user of your API. Letting them know the limitations of your product before they find out for themselves. 

Developers are problem solvers, and if you give them a foundation of where to start, they will take it from there. Giving them the rules for how your API works best will benefit your third-party developers in the long run.

At FreshBooks, when we were creating our developer relationship program, one of the biggest frustrations was that customers didn't know that there was the ability to do a bunch of things that existed on our software. 

We had to go and individually show each person how to do certain things or describe to them the workaround for specific instances. Workarounds exist everywhere, and so, document your workarounds. We created an informal Postman collection that allowed us to share these details without having to formalize it in our public documentation, it allowed us to quickly interact with our developer community while getting fast cycles of feedback to update our API. 

Related Content: The Pros and Cons of Offering Your SaaS Customers Native Integrations vs Third Party Integrations

What advice do you have for creating a developer community around an API? 

Developers usually build on your platform for one of 3 reasons, and they're all really important to maintain and embrace as a PM. 

1. API consumers that are looking to solve business problems, and they have the technical skills to do so. 
   

These will be the first people that you want to reach out to.  These are the API consumers that will explore your system, push it to its limits, and all the while they’re doing it for themselves. This kind of consumer will likely see a pitfall in your product that isn’t bad enough to leave, and will want to work to try to solve on top of it. 

These types of consumers invest in your product with more than just money. These are the customers you want to reach out to and develop a relationship with. Create a mailing list, inform them of the developer-centric updates, and make it easier for them to scale their solutions. 

By developing the relationship in this way, you may even get to a point where you can offer up their product or service to a bunch of other customers, or even maybe potentially allow them to monetize.

2. API consumers that are interested in something new. 
   

Giving your product cool, new features makes your ecosystem a lot more friendly to work with and many developers are willing to provide feedback on these types of innovations. 

Years ago when I was on the FreshBooks team, we were just toying with the idea of adding GraphQL to the FreshBooks API. It was still relatively novel at the time, and our developer community was chomping at the bit saying they wanted to try this out and see how it works. 

They got really excited, gave great feedback, and it raised a lot of attention, which led to more internal support for third-party developers and that entire community. 

3. API consumers looking to make money off of your product. 
   

This happens most when you’re a platform, and ideally, that’s where you want to be. When you’re a platform, you no longer are responsible for solving the long tail and all of these problems that you can never even think about solving -- your partners are solving them for you.  

They identify the problem, come up with a solution, and are incentivized to update them. Generally speaking, the best integration is one built by a third-party developer when it benefits them. 

There are so many added benefits that you both get from that long tail solution that they're providing, which allows you to focus on innovating on your core offerings!

A perfect example of that is the Shopify experience. They just focus on making an excellent e-commerce product and developer platform. They know what they do really well, and they continued to focus on that and didn't toy with anything else. 

To this day I don’t believe they toy with accounting, and they don’t really deal with inventory or invoicing. They support an entire developer ecosystem to build solutions and make money off of their excellent e-commerce product. Everybody wins!

How do you prioritize integrations to build? Can you speak to an example where you had to think through this type of prioritization? 

This goes back to what your business goals are. The first question to ask yourself is: does it make sense to build another integration at all? 

You may have a lot of customers asking for it, but would building it solve their problem or your underlying business problem? 

For example, a company can have a goal to increase revenue by 3 percent this year. If they reduced X percent of their churn, and their sales team did the equal amount of work they did last year, would they still hit their goal better than if they were to continue or grow their churn, and their sales team did a much better job this year? 

This is a very valuable statistic to start to look at because there may be an easier way to reduce churn in the integration world than creating new customers and keeping them on board.

If the major reason that your customers are leaving you is that your integrations don't work or they're having data consistency errors, prioritize that and go back to gold plating those existing integrations. 

However, your customers might be leaving you because you just don't have enough integrations or the ones that they’re looking for. Then you may have to build more. Be sure, though, that this is actually the reason they are leaving. 

This can sometimes be an easy excuse for customers to tell a salesperson as to why they are leaving, so having your sales team know this and be sure they are digging into the root cause during these conversations.  

Generally speaking, how I would prioritize new integrations is listening to your customers, and try and find a way to get a feedback loop. When it comes to your app page, if you have a search bar, put in a tool that allows you to figure out what your customers are searching for. 

Then, you can start looking at what you may need to work on. Talk to your customer success teams and sales teams, then collaborate and figure out what the biggest benefit might be. After, perform an analysis to determine what is a top priority, high value with the lowest technical lift. That’s what you want to prioritize first.