Why Every SaaS Needs a Good Developer Experience — And How to Provide It
Most SaaS companies do not invest much in their developer experience. But with the increasing importance of product integrations, a strong developer experience is no longer just the purview of developer and enterprise software.
The 1000 fastest growing SaaS companies have a median of 15 product integrations, while the top 15 come out at 347 integrations. With even earlier stage companies needing to provide their customers with integrations out-of-the-box to close deals, companies are working through how they can offer more quality integrations to their customers faster.
Scaling integration offerings requires relying on partner and third party developers to build, maintain, and support integrations.
By providing these partner developers with an exceptional experience, a company can build a thriving ecosystem around their app without having to pay for and support every integration themselves.
But SaaS companies whose primary users are not developers likely have not put much thought into marketing to or supporting developers.
Even at early stages, every SaaS company can provide partner developers with a good experience if they are attentive to their journey and point of view.
There are 6 stages of the third party developer journey that companies should consider when building out the developer experience for their ecosystem.
Awareness
Developers do not want to be “marketed at” in the traditional way. Instead, driving awareness to developers should revolve around events, hackathons, and informative content that benefits the developer in their professional life.
Engaging the developer community in your ecosystem by speaking at events, writing articles on ecosystem-related topics, engaging in communities like Reddit, Discord, Quora, and DEV, or showing off cool things you can do with your API can help generate awareness with third party developers.
Exploration
For ecosystem developers, exploration will focus on your product and API documentation. Unless you have a compelling reason not to, your API documentation should be public. Developers don’t want to spend time digging through your site or request a log in just to see docs.
Your documentation should also be thorough, updated, and clear.
Third party developers are not experts in your product or even your product category so be sure to explain not only the technical components of your API, but also give a high level explanation of what the product and API does for the end user so they can understand the use cases.
For early stage companies, following OpenAPI specifications can streamline the documentation process. Tools like Swagger or Readme can auto-generate interactive documentation, which can save time and ensure that the documentation stays up to date.
Many companies follow a docs-as-code process for maintaining their docs, which follows the basic coding process of version control, code reviews, and testing.
More mature companies offer SDKs and more examples, which make APIs even easier to use.
Consideration
When developers are considering whether to build an integration to your app, they will look a bit more deeply into your API and the use cases it enables.
Remember partner orgs will often be choosing between building an integration to your product or one of your competitors, and a key part of that decision is how easy your API is to work with.
You should offer developers a free sandbox account, as this helps them to gain a greater understanding of your product and APIs in a hands-on way. Ideally, developers only need to enter their name and email to gain access.
Sandboxes should be clearly documented in terms of how they differ from a regular account. Make them as similar as possible to regular accounts, and include data for a wide variety of use cases.
API call limitations should be the same as a regular account, even if the timeouts are much quicker. This enables developers to ensure their integration works within the real limitations.
Your API design plays a big role in the assessment of whether it is worth building an integration to your product.
Most SaaS companies offer a REST API with a JSON response; GraphQL is increasingly common. Most developers are familiar with these styles and frameworks so deviate only if you have good reason to.
OAuth 2 is the standard for authentication and authorization. Again, only deviate from this if you have a strong business reason to do so.
In terms of the resources, endpoints and the call limitations for your API, make sure that you are using generic language as possible and have considered different use cases.
Survey different types of customers to understand what they would be looking for when moving data amongst other systems. If you’re in an established product category, look at what competitors’ APIs offer.
If your customers require some real time information from their systems, then consider offering webooks or streaming APIs so partners can efficiently design product integrations that get their customers data in real time.
Develop and Test
Thorough API documentation and robust sandboxes play a big role in providing a good experience developing and testing an integration.
Allowing developers to add team members to their account, providing collections in testing and design tools like Postman, and enabling beta apps can also improve the testing experience.
Technical support is vital at this stage. As a smaller company, providing one-on-one support can give you invaluable feedback on your API design and use cases.
How to contact support and what to expect from support should be made clear in the developer portal or, if there isn’t one, on the API documentation. Giving timelines and being realistic about availability helps to avoid increased frustration.
If you can’t provide one-on-one technical support, even by email, pay close attention to support inquiries so you can update your knowledge base or even your API. You can also consider trying to identify developers in your ecosystem who might be able to help their peers.
Publish and Maintenance
Once developers are done testing with beta customers, they will want to publish it in your marketplace (if you have one) or get it in front of your customers. Provide clear documentation around how to publish an app in your marketplace and what is required technically and for any marketing materials.
If publishing in your marketplace requires dev work (like for payment processing), make this as straightforward and well-documented as possible. Ideally, provide a portal where developers can submit and receive feedback on their app.
Showing developers app and marketplace analytics inside a developer portal also makes it easier for them to support customers and improve their app.
Engagement and Advocacy
Engaged developers will do a better job of supporting and expanding their integration. They will also recommend your ecosystem to other developers and their coworkers in product and partnerships.
Rewards and recognition for developers who build cool things or contribute to your community can lead to more engagement. Rewards and recognition can include prizes, a blog profile, speaking at your events, or being put in touch with your product and engineering team.
Soliciting feedback and forming a Developer Advisory Panel can also help to engage developers and turn them into advocates. Facilitating local meetups with a designated third party developer host can lead to increased investment and community.
Once you have set up resources for each stage of the developer journey, you will want to track metrics to make sure that developers are responding positively to the experience.
Implementing developer surveys at every stage can complement the statistics. Put a “Request a Feature” button on your docs and in your developer portal, for example.
Much like the traditional revenue funnel, your goal is to make sure developers are moving forward in sufficient numbers.
You should be tracking the number of developers who: 1) visited your developer-specific pages and API docs 2) register for your developer portal and sandbox 3) use the sandbox frequently 4) launch an app 5) submit an app for publication in your marketplace 6) maintain and support their app 7) grow a satisfied customer base 8) deprecate their app and 9) become engaged members of the community.
Other than the deprecation of apps (which you don’t want to encourage), serious drop off at any stage can alert you to problems in the developer journey and signal where you need to invest more resources.
Most likely, your initial goal will be around getting more developers to launch a supported app and grow a satisfied customer base. More mature organizations can expend more resources on the whole funnel, including growing awareness and advocacy.
Developer experience is no longer something only developer and enterprise products have to care about. By investing in a compelling developer journey, any SaaS company can increase the number of high quality integrations they are offering customers. These integrations, in turn, will help close more deals and increase retention, which is becoming increasingly important for successful growth.
