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.
Max Katz has led Developer Relations teams at Okta, IBM, and Appery. He shares his advice on developer relations KPIs, collaborating with other departments internally, building a community, and how earlier stage companies should allocate their resources.
I don’t know if there is such a thing as the best KPI. I believe every company will have a different KPI they measure and for them it will be their best. I believe it’s important to measure something whether it’s clicks on a blog, active developers, or applications deployed.
If you are a startup that just launched, your KPI and what you measure is probably going to be different than what IBM measures.
Now, people also say there are vanity metrics (which perhaps are not good to measure) but if you want to measure them, that’s fine, as long as you understand what you measure and it helps achieve your overall company goals.
I published a blog post where I suggest a 3-part framework on measuring success in Developer Relations: Measuring success in Developer Relations, a 3-part framework. I published another blog post on this topic: How to measure Developer Relations – DevRel meetup recap. This was an in-person meetup (when we could still do that) where Amir Shevat talked about measuring success.
I’d say hire folks who love creating and publishing educational content and enjoy helping other people. If you believe you will be running a significant number of (online) events, you might also want to hire a Programs person. You should also look into hiring folks who are comfortable being on (live) video.
As for which department, I don’t think it’s that important as long as the Developer Relations organization has clear goals which are also tied to overall company goals. And there is a strong buy-in and sponsorship from other parts of a company. I talk about it more in the questions below.
My opinion, it should be its own department (not reporting into Product, Marketing or Engineering).
Sit down with leaders from Product, Marketing, Sales, Engineering, Support and any other organization and ask them how a Developer Relations practice will help them achieve (some) of their goals. Once they see how it will help them, I believe you will have a stronger and more effective collaboration.
I think the biggest one is probably what value does Developer Relations bring to our company. I believe it’s important for the Developer Relations leader to show the value of this practice to the company.
I think it still comes down to what value does Developer Relations bring to the company. My advice is this. First, ensure that the Developer Relations team has very clear goals. It’s important that every Developer Advocate knows that what they are doing will get them closer to the goal. Now, that goal (or goals) need to align with the broader company goals.
Second, ensure that the Developer Relations practice brings value and helps other company organizations. This will ensure buy-in and closer collaboration. In general, Marketing, Product, Sales and other organizations always work together. I believe Developer Relations shouldn't be any different.
An existing community could be in a number of places. Dev.to is a popular developer community. Another one is Hashnode. You can also check Stack Overflow. You might also find people talking about your product in a Slack channel.
It’s not necessarily “bad” that a built-in community might not exist. It’s absolutely fine to start, build and scale a new community. It’s important you talk with Product, Marketing, Sales and determine how a community will help them achieve their goals. I believe it’s important there is a buy-in from these organizations as you will also need their help to build the community. For example, if you decide to launch a blog, you would want to work closely with the Product team on producing content on new features for example.
My advice is to focus on things that scale such as educational content (tutorials, blogs posts, how-to’s and tips), videos and online events. Such content can be consumed by developers any time, from anywhere.
This perhaps is not specific to early stage companies. It’s important that the Developer Relations team has very specific goals they are trying to achieve. This goal also has to be tied to overall company goals. The one or two people on the team need to know that whatever they are doing - gets them closer to that goal.
One more thing I will say. It will also help if the Developer Relations function provides value to other company organizations such as Product, Sales, Support and Marketing. For example, ask the Product how the Developer Relations practice can help them achieve their goals. This will ensure there is a buy-in from all company organizations.
The overall strategy should be very similar. How do we help these developers? How do we make them successful? As for tactics, you might have some differences on the type of content you create, companies you partner with and the type of events you host.
I believe it helps if you have an engineering background, especially for more technical products or tools but it’s not required. I’m a believer that the more you know about a product or a tool, the easier it will be to educate people on how it works and how it can help them solve problems.
Also, many companies are building low-code and no-code tools. As these tools target technical folks (but not necessarily engineers), advocacy people don’t need to have an engineering background.
Whether it’s documentation, support, educational materials, or online events - I believe everyone at the company needs to always think: how do we make our customers, partners, and developers successful?