%20(1).jpg)
As a graduate of Y-Combinator, PartnerStack has been rooted in helping some of the world’s fastest growing SaaS companies scale. Companies like Asana, Monday.com, Unbounce, Intercom, and Intuit all use PartnerStack to manage and scale their partner programs, and onboard thousands of partners into our platform.
There are a few unique aspects to PartnerStack, which has led us to becoming the #1 platform on G2.
PartnerStack is the only solution that has both the PRM and a B2B focused marketplace that connects vendors with partners. On average, our marketplace drives a 30%+ lift in revenue for customers.
We are extremely focused on partner experience, which is a big distinction for us. Most PRMs are focused solely on the vendor experience. But if both sides of this equation are not having a good experience, then it becomes a problem.
And with PartnerStack, all of your channels can be managed from a single platform - affiliate, referral, reseller and ambassador. We see a lot of companies, agencies, and resellers choosing our platform to help them consolidate their channels into a single view.
How is your partnership team structured at PartnerStack?
Our team is still relatively young, as we launched it in April. The majority of this year has been building relationships and working with both agencies and resellers.
I lead the team, and we have an incredible Account Manager that works closely with our partners, as well as a partner marketing manager that works on any co-marketing efforts we run with partners.
Our partnership team is currently focused on two core areas:
We often work with sales when one of their SaaS prospects wants to launch PartnerStack right away but doesn’t have the internal bandwidth. In those cases, we connect them with an agency partner who we know can do it right away and do it well.
Technology partnerships are also on our radar. We have recently built a number of integrations. One of our goals in 2021 and going into 2022 will be to further build out our technology partner program and our own integration marketplace.
We also plan to enter the app marketplaces of other SaaS vendors, especially CRMs like SugarCRM or Hubspot. CRMs are good partners for us because, with the exception of Salesforce, no CRM has a PRM as part of their product offering. So our software is complementary rather than competitive. And it benefits our customers to have those systems integrated.
“If you’re planning to scale your partnerships at all, you need the infrastructure in place to do this.”
<center>- Nikita Zhitkevich<center></center></center>
What advice would you give for organizations trying to think through who their ideal partners are?
Ultimately, everything has to come down to revenue. Whether you’re pursuing referral, reseller, or technology partnerships, you have to tie them back to driving revenue.
Especially since you need the support of other departments in your organization, whether it is collaboration with the sales team or the product team to help build integrations, the benefit to the business needs to be very clear.
For agency and reseller partners, I would advise looking to see if they power similar products to yours. I’d also think about whether the partner will continue to evolve over time in the direction you are going and whether they truly understand your product and space.
API documentation explains to API users and developers what is possible with your API and how to use it. API documentation generally includes descriptions of your API functionality, references, instructions for implementation, and use case examples.
At the minimum your API documentation should answer two questions:
API documentation is where API users and developers go to learn about your API and how it works. Thorough and easy-to-follow API documentation leads to higher adoption and a better developer experience (DX).
Companies understand the importance of design thinking around user experience, and how it can contribute to customer loyalty and retention. DX is equally important to API adoption and a well-thought-out DX will similarly increase customer and partner loyalty.
API documentation is key to the developer experience. Developers usually prefer to self-serve and excellent API documentation enables them to efficiently plan and build their integrations, without having to reach out for support.
It also prevents hidden surprises halfway through the build process where developers discover your API doesn’t enable a use case they need or has limits that need to be worked around.
SmartBear, who built Swagger, surveyed developers and users of APIs in 2020. When asked what are the top three most important characteristics they need in an API, accurate and detailed documentation beat out responsiveness/performance.
Poor API documentation will impact implementation speed, increase costs, and make development teams unhappy. With more organizations offering digital services, API consumers have more options to choose from. If your API is for customer or partner use, a poor DX can damage your brand reputation and push customers and partners towards products that are more developer-friendly.
Your audience can range from developers and CTOs to product managers and non-technical customer support or business teams. Being clear on who your audience is enables you to make more informed decisions about how to make your documentation accessible, the kind of sections you should include, what language to use, and how to structure your documentation.
For example, your API may be for partner use only, or for internal use only. Other times, it might be only for enterprise customers. Whoever your audience, you should ensure there is a clear path for them to locate documentation and that proper access is granted.
Some API providers like Google include a blurb at the top of their API documentation that describes the audience it is targeted to, including what technical knowledge they will need and links for further research.
Not all API documentation is designed only for developers. Some documentation can be understood by product managers and even business users looking to see what is possible to accomplish with a particular API.
Like Google, it is helpful to provide the information upfront on who a particular set of documentation is for and what knowledge is required to understand it.
SmartBear, who built Swagger, surveyed developers and users of APIs in 2019. They asked what features and sections developers look for in API documentation.
The responses illuminate what categories you should be investing in documenting first, and what categories you should aim to include as your documentation becomes more mature.
Let’s take a look at some of the most important sections to include in your documentation.
While this section wasn’t a part of the SmartBear survey, this section is key to ensuring the right people are reading your documentation and that they have the right expectations.
Use an “API Overview” section to give your audience clarity and hook their attention into reading the rest of your documentation. Remember, especially when an API is being considered by a customer and a partner, you want to encourage adoption and keep people from dropping off. Third-party developers may have no idea what capabilities your API offers, and you want them to excite them enough that they take a more serious look.
Here is an example from Facebook describing how their Instagram API can be used, for example. Google also has a page that lists the most common use cases for their Google Maps API and includes links to documentation for APIs that best suit those needs.
This was the number one section that API users look for when reading API documentation. Remember many users will be completely unfamiliar with your API, and examples are the quickest way to illuminate what is possible.
Providing snippets of code that developers can easily copy and paste, with examples in context, can allow for easy adoption, limited questions, and less troubleshooting on your end. Twilio, for example, details example error responses and what might trigger them.
Some APIs, like the Deezer API, go beyond laying out examples and even allow developers to test endpoints with interactive demos.
Developers need to know what errors they might get and what each error means. List any errors that can be returned by your API with readable descriptions.
Many companies’ API documentation has a page specifically dedicated to error messages. Some companies also include error messages and descriptions under endpoints where they tend to happen the most, which is useful when building an integration.
They can also be included as part of a troubleshooting section at the end of a quick-start guide.
Since authentication is one of the first challenges of getting started with an API, your documentation should clearly outline how authentication is handled for your API.
For example, if your API requires the developer to get an API key to authenticate, you should specify how one can get an API key, how the key works for making requests, and how to restrict API keys.
Whatever your authentication scheme (what is required for the authentication process for your API) ensure that you clearly document and list out steps for how users need to authenticate before gaining access to your API.
Slack, for example, uses OAuth 2.0 authentication to allow end-users to download API consumer apps from slack workspaces. See here for an example of their authentication documentation.
HTTP is a protocol for requests sent to a server. It identifies what actions (known as methods) that can be taken through your API and on which endpoints. In your documentation, you should clearly lay out all the available methods and their endpoints.
Two of the most common HTTP methods are GET and POST. GET requests are used for receiving specific data fields, while POST requests are used to update or create new data fields in your system.
Specify the type of requests you are enabling, and what fields the request can apply to, to improve your developer experience. See an example of how Hubspot organizes this information this below.
APIs change faster than ever, and outdated API documentation is one of the major ways developers and users end up having a bad experience.
Put in place an internal process for ensuring that API docs are updated whenever changes are made. This can be folded into your product update process, or even assigned to someone who will be notified whenever changes are made.
If your documentation is extensive, one way to ensure you’re updating the most important parts of your documentation is to use tracking analytics to determine what endpoints are used most often so that you can prioritize updating those first.
Some of the most popular tools for API documentation include Slate and Swagger. Swagger in particular offers many solutions for creating and maintaining your documentation so that it stays up to date. They also provide resources geared towards improving developer experiences like Swagger Editor and SwaggerHub that provide a YAML editor with a visualization panel. This allows developers to work in and see how your API will look and behave before they actually implement it
Slate is an open-sourced, free tool that allows you to create a clean and intuitive design. It allows you to create a three-panel webpage, one panel for navigation, another for documentation, and one for code samples. See more examples of documentation created using Slate in their repository.
In addition to updating your API documentation, ensure developers are notified and made aware of these changes. Most companies have a developer email list that they send notifications of changes to as well as a developer-focused webpage where upcoming and current changes are noted.
Invest in understanding the audiences for your API and how the audiences intend to use it. Creating API documentation that enables an exceptional user experience will increase adoption, limit delays and problems, and ultimately improve your brand reputation and customer retention. Lastly, treat API documentation as part of your API. Ensure it is thorough, accessible, and up to date so that your API users are able to have the best possible experience.
