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.
Heidi Williams co-founded tEQuitable, was the VP of Platform Engineering at Box, and managed strategic partnerships at Adobe. She shared her insights on building product integrations, the importance of in-app marketplaces, and best practices around APIs and the technical infrastructure that enables tech partnerships to be successful.
I was at Box for 4 years as VP of Platform Engineering. When I started, my team was working on our APIs, SDKs, embeddable widgets, and partner integrations.
We built our own integrations or did so in collaboration with partner companies like Netsuite, Salesforce, and Jive. But we also had APIs and SDKs that anyone could build with, whether to integrate with another SaaS app, integrate with internal systems, or to use Box capabilities to power new apps.
Everyone had to sign up for a Box developer account. Once you did, that would give you a Box instance. By signing up for an account, your app could access content in your own instance, but you would need permissions to access anyone else’s. This provided a high degree of security for our customers as they had to grant access to any third party apps and developers.
There was a process for publishing an app so that it would be available for Box customers to use. We looked into adding a more rigorous security certification of third party apps so we could highlight those apps to more users, but that required a great deal of resources.
I would advise them to think about the security model. At Box, we kept increasing our security posture in the API to make sure that we were not putting customers at risk.
In general, app developers building integrations fall into 3 categories. The first is larger customers who are building integrations for their own internal use. Imagine at a large company, they might have a number of developers building integrations to your product for their internal use.
The second is what I would call a third-party developer. This is someone you have never heard of, and have no relationship with, but they just built a cool integration with your API.
The third category is partner developers, where you have a relationship with them and their company.
There is a different level of trust for these tiers, and it is worth thinking through what capabilities and permissions you want to extend to each one. The most trust is, of course, when you are partners and building something together. But companies should think through the use cases, and decide what extra security measures or further hoops different categories of developers should go through to keep your customers’ data safe.
I always think about the risks with an API. An API is called by other software. For that reason, the scale that you can get to with an API is higher than when you just have human customers using your application. A human can’t perform a million actions in one minute, but software calling an API sure could!
So it is important to think through how you ensure that someone does not crash your site because someone has an infinite loop running or is maliciously trying to overload your system. It can certainly happen by accident, so you need to protect yourself from these kinds of cases.
You have to set rate limits, and implement security that prevents the system from being crashed. You have to assume the end developer is doing the worst, and then figure out how you control for that. And be prepared so the site won’t go down.
Another important practice is to expose the absolute minimum amount of capabilities through your API that you need to. It is hard to evolve the API over time, and if you need to make a breaking change, it takes a long time to get all the external developers to update their code. If you expose the least amount of features in the API in the beginning, you can always make additions over time, and to avoid breaking changes.
In order to keep it minimal and the footprint as small as possible, a company should think through what they truly need to expose. For example, maybe you can have APIs expose some objects that are common for integration use cases, but not expose others. Or maybe internally there are 20 fields for an object, and your API only needs to expose 5.
Customer research is the most important component, and you should conduct this with your partners. At Box, we would do customer research with our partners, and we would ask joint customers, “What capabilities would be useful to you?” This would give us granular insight into what was actually needed.
In my experience, a partnership manager isn’t often super technical. So I am always a believer in engineers participating in these customer research projects. At Box, the partner manager would set up the meeting, and then engineering and product management would go along to the meeting. This way, the engineers would be clear about what they are building.
Many companies are likely adding APIs to an existing codebase that doesn’t already use APIs to power their own web application UI. If that is the case, there is a danger that third parties using the API may get slightly different behavior than a user using your web application. This is because there are two different code paths (the web application UI and the API) which means there are opportunities for bugs to creep in and behaviors to diverge.
If possible, look into rewriting your web application UI to use the same APIs you offer to third parties. This will require that all engineers think about quality, consistency, backwards compatibility, and how to avoid disrupting developers who use the API as a first priority instead of an afterthought, because of the impact those things could have on their own web application.
It has become standard to build a REST API with a JSON response.
The authentication world has evolved, and has shifted to using OAuth and JSON web tokens. I would recommend going to Auth0, a company that provides authentication as a service, for great content on these changes and why they are important. Generally, these changes have improved security and given more granularity and control.
At Box, our own success shot us in the foot. There were thousands of apps that connected with Box, and we had never put in place a way to sort out which ones were good, and which ones were being used. And the admins for our customers had no easy way to discover apps they wanted employees to use or block apps they didn’t want employees to use. It was a big project to rebuild the marketplace with new capabilities for governance and discovery.
So you should think ahead about what happens when there are thousands of apps available, and how you categorize and vet them. That requires building a marketplace with those capabilities from the beginning.
In addition, you should think about co-marketing and payments. When you establish a partner program, you will want to do co-marketing, for example, and you have to think through the technical infrastructure for highlighting an integration or app within your app.
Building your own in-app marketplace from scratch will always compete with the priorities of building features that differentiate your app. While having an ecosystem is a differentiator, building out the specific features of an in-app marketplace is not a differentiator. So looking at options like Pandium makes a lot of sense, so your engineers can focus on product features that give you a competitive edge.
I think there is a huge value in building out a tech ecosystem. If you can find ways to do it, there is marketing value, you can tap into each other’s customer bases, and you can expand your footprint.
The ecosystem can be a moat for your company. Customers can’t take you out of their tech stack if you are intertwined with 40 other companies they are using. When you are inside an ecosystem, you become integrated into everyone’s daily life and how they use their software.