Nikita Zhitkevich lives in the world of partnerships. He leads partnerships and alliances for PartnerStack, which is a leading PRM and partner marketplace.
Nikita shared his insights on when you need a PRM, identifying your ideal partners, strategies to avoid channel conflict, and how he sees the partnership landscape evolving over the next 5 years.
Can you tell me about PartnerStack and what makes it different from other PRMs?
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:
First, working with agencies and resellers that are currently reselling SaaS vendors, bringing those vendors onto PartnerStack.
Secondly, working with agencies and resellers that are looking to shift their existing customers onto a modern partner management solution.
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.”
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.
Customers are demanding more integrations out-of-the-box in every vertical of SaaS. But offering a bad product integration is usually worse than no integration. User stories can help ensure integrations add real value to the customer.
Integrations can fail in three fundamental ways: 1) they are hard to set up, install, and manage 2) they do not sync data or return errors or 3) they do not accomplish what the user needs to do.
When any of these happen, customers will have a frustrating experience. They may respond like this (reviews left on SaaS product integrations):
So how do you prevent this from happening? Before you even start building (or approving) an integration, you should map out integration user stories.
To do this, you should gather input from sales, marketing, product, and customer success on how customers are using the product and what their other systems are. Beyond asking your customers, you can use data enrichment tools to find out what tech your target users are already using.
Once you have a good sense of your users' tech stack and workflow, ask your customers if your mapping is correct and if there are other ways they would like to connect systems.
What are User Stories?
The basic form of a user story is “As a [role], I need to [task] in order to accomplish [goal]” and there is no reason to deviate from this model for integrations.
Once this big picture is established, you will need to get more granular in how these integrations will be used. Remember that your customers might not always know how they would like to use systems together, and it is your job to figure out what business logic will best meet your users' objectives.
Sometimes these configurations will be quite simple. For example, a story might start, “As a marketer, I need my different lists from my CRM to sync with my audiences in my email marketing automation so I can track all my communications from my CRM.”
Flushing this out in more detail, you should specify that your marketing users want to be able to bi-directionally sync their different “lists” of contacts with “First Name, Last Name, Email” from your CRM with their different “audiences” with the same fields in their email marketing platform. This configuration is relatively simple.
In other cases, depending on your app and your partner’s app, what some of your customers want will be much more complicated.
The goal should be to identify the configurations your customers need so you can build a UI where your customers can self-serve AND your users can accomplish what they need to.
Construct Your User Personas
Depending on your app, you may have different users. For example, a CRM might have a marketing user, a sales user, a business dev user, and a developer user. An Applicant Tracking System might have a recruiter user, a HR executive user, a hiring manager user, and a benefits admin user.
It is important you identify all the major users of your product so you understand the different integrations and configurations that are needed.
Most likely, your product and marketing teams already have these user personas developed. You should also touch base with your tech partners to see if there is an additional user persona that they might bring to the table.
Writing out Each User's Story
Once you have all the user personas, write out the different ways each user would want to use the integrations and why. Just like before launching any new key product feature, you will have to talk to your product, sales, customer success, and product marketing people to try to establish these stories.
Most likely, they will evolve post-launch as you get more customer feedback.
First write out all the high level stories in the form of “As a [role], I need to [task] in order to accomplish [goal.]”
Once these higher level stories are established, you should write out “acceptance criteria” for each one. Acceptance criteria simply spell out what needs to happen to make sure the user can accomplish their goal.
Writing Acceptance Criteria
Let's say I spend most of time working inside my CRM, but I use an email marketing platform to send out special promotions to prospects and customers.
As a result, I have segments of contacts in my email marketing platform that I also have in grouped in my CRM. I want these lists to remain identical even as I add contacts to both systems.
I also want to be able to track performance of emails sent from the email marketing platform from inside my CRM as the CRM is where I track my results from all my email campaigns.
In this case, the acceptance criteria is the list of things that need to happen to make all that possible. For example, I need to be able to regularly sync contacts entered into either system and have them de-duped. I need my email marketing platform's audiences synced with my CRM lists, removing any duplicates.
I also need to have emails sent in the email marketing platform logged in the CRM, and their reporting metrics logged at the audience level in the CRM.
Writing out what needs to occur to meet a user's objectives will help inform the integration design.
Integrations are limited by the design of your API and your partners' APIs. You might not be able to deliver every item. But thoroughly understanding what users are looking to happen can ensure you have the best possible integration design.
Here are elements to look out for in drafting acceptance criteria:
Timing - when does the user need the data to be synced between systems? If someone is being notified in Slack, for example, of an important error or customer support ticket, they may need the information in real time for it to be effective. If a user is moving invoices from a billing to accounting software, daily syncs might suffice.
Data volume - how much data do users need to be synced? This can be an issue as APIs have limits in terms of how much data you can pull or push in a certain interval.
Field mapping - what are the fields in different systems and how do they relate? For example, one app might only have a 'name' field while another might have 'first name' and 'last name.' Or one might have 'groups' for people who enrolled in a class while others will have 'current class students' and 'all class students' for those currently enrolled and those who were ever enrolled (even those who dropped out). Users need to pass this information between systems in the most elegant and useful way possible.
User UX - how does your user set up, update, sync, view usage, troubleshoot, and disconnect the integration? All of this has to be accounted for in your integration design.
Once you have established your user personas, stories, and acceptance criteria, you should work closely with engineering to ensure that the integration design meets as many of the criteria as possible. If you want to see a sample integration user story and acceptance criteria, download a sample here.