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.
Over at the SaaS Ecosystem Alliance, we hosted a discussion with product and platform design leaders about best practices for building a platform UX that partners, partner developers, and customers will love.
Our CEO Cristina Flaschen talked with Richard Fortune (Product Manager for Platform Experience at Xero), Courtney George (Head of Design for Data at Amplitude), Kirby Montgomery (Vice President of Product Leadership at C2FO), and Ashwini Sriram (Group Product Manager at Twilio).
Courtney suggested developing a deep understanding of all the personas involved in the experience, keeping in mind that developers will not always be the only personas involved in your platform.
“Keep in mind all the consumers of your platform. It’s not just developers that are involved in this ecosystem, there are also decision-makers and marketers for example. You have to think about how everyone is going to work together and interact with your platform.” - Courtney Maya George, Head of Design for Data at Amplitude
After identifying the different personas that will be involved on a platform, and the different functions they will likely need to perform, she suggested focusing on designing for scale.
She recounted her time at Adobe, where there were a wide variety of use cases they had to think through the UX for. They decided on creating a flexible framework where they were more opinionated on the information architecture and navigation of their platform and less opinionated on the specific nuances of each step of the workflows.
Kirby added that all of the tools of UX designers should be applied when building out the customer journey of a platform. When thinking of platform developer experience, for example, there should be personas and a journey map.
He recounted bringing in the engineering team at his company and gaining valuable insights from going through this process with them.
“We would have them imagine that they were integrating with our API, and we asked them to share what would make that experience delightful, and what would frustrate them,” he recollected. “We would have Product Managers and Product Designers there to hear from that persona, and then we’d use this intel to think about how we could create great documentation, how we were going to administer API keys, and what tools we could build to turn our integrators into super users.”
If companies are thinking about what they should create for their API, he suggested that they look at notable examples in their sector for help with determining a mental model for the industry. He remembered, in particular, looking through Xero’s documentation during his time working in B2B fintech.
Richard urged platform UX designers not to see developers as a special case, but instead as humans working on a team with a job to be done and measures of success.
“Have a deep understanding of the integration lifecycle and where personas are in the journey. Then after laying down a uniform infrastructure, work on enhancing common touchpoints where experiences and users overlap to make them as delightful and accessible as possible.” - Richard Fortune, Product Manager for Platform Experience at Xero
Building on an earlier point made about personas, Ashwini warned against slotting users into rigid personas. She pointed to the fact that in some cases, for instance, a product manager may wear a hat as a developer when it comes to low-code or no-code tools. In this case, having a strict developer persona may not work.
Courtney co-signed with Ashwini’s point stating that someone using Amplitude to clean up data might be a data scientist, data governor, or a product manager with some technical knowledge. For this reason, it is a good idea to create personas based on functions as opposed to job titles.
To this point, Richard shared that Xero is currently re-evaluating what it means to be a partner or a developer using their platform. He pointed out that the domain for their platform users is called developer.xero.com; however, this isn’t just meant to support developers, but everyone who has a platform relationship with Xero.
As part of this reevaluation, they have a community that does developer experience analysis externally, with the intent to understand the motivations behind decisions other companies are making when creating their APIs. They even look at organizations outside of their business sector, like Miro and Notion, to determine what they can learn from their approach.
Kirby first shared that creating personas based on functions should help inform companies of how and where people do their work. They can then use this to define how access on their platform should work. He pointed to how the developer portal for Xero not only has a space for engineers to build integrations but includes space for customer support functions like resetting passwords.
He added a caveat to be mindful of having a persona where they don’t need to be or where there may be cognitive overload for them that makes it difficult to navigate and complete their function.
Courtney shared that this has been a common discussion in her roles because the variety of use cases they have makes this a complex task. In some circumstances, her teams saw that the same persona was performing functions relevant to both the developer and GTM portal, and it made sense to blend them. In other cases, this was the opposite.
She stated that there is no one right answer and that the separation depends on the problems a company is trying to solve.
Whether organizations choose to create separate portals or not, she encouraged all organizations to think about what the end-to-end workflow is across their user’s teams in order to accomplish creating integration and putting it on the market. This is to ensure that even with separate portals, there is a seamless link between the portals and the different experiences.
Adding to this, Ashwini shared that instead of instinctively thinking about the separation of portals for GTM and developers, to lead with a goal-orientated design.
“We’ve learned that the separation between developers and GTM teams is starting to break down, and it’s more beneficial to have a goal-orientated platform interface design rather than leading with separation.” - Ashwini Sriram, Group Product Manager at Twilio
She shared that a goal-oriented design that focuses on different jobs such as “I’m trying to create an invoice for a customer” has helped her team at Twilio to think about the design and the success of the design. They always ask whether a design is enabling people to accomplish their tasks with minimal friction.
Kirby shouted out Codat.io, which helps companies offer their small business customers integrations with their accounting, banking, eCommerce, POS, and payment software.
He stated that they not only do a great job at providing a nice combination of tools but also do great storytelling to demonstrate how users of their platform can implement their tools.
Kirby explained that they do this by providing use cases involving real users of their product, which helps to show potential platform users why they should be inspired to use and build with their product. He added that he never felt like there were any artificial barriers between him and the next steps of working with their platform, as he was quickly able to access a sandbox and provide access to his developer team.
He used this example as a way to remind platform builders and designers that developers and product managers want to be inspired too and that they should be mindful of creating artificial barriers for those looking to work with their platform.
“In B2B, many companies are trying to create large ecosystems, but you will see terrible decisions being made with platform design,” Kirby explained. “Passwords on API docs, or tickets for API keys that take two weeks to process. These are all things that make people less likely to want to work with them, because people want to work with someone who wants to give them their product.”
Courtney looked back at her time at Adobe where this had been an intense discussion across teams. She explained that how open they were with certain components of their API was dependent on a persona and their level of motivation to build with them. Even though there were some cases where there was push back internally, they ended up opening up certain components of their API because companies wanted to build integrations with them.
They then realized where they needed to be the most open and public was with their documentation. She explained that this allowed her team to show platform users why they should work with their technology and the capabilities, outcomes, and ROI that it could bring before determining whether to allow self-serve access to other components of their API.
Richard, Kirby, and Ashwini then shared their perspective on arguments for and against organizations being more open with their API, considerations to make before providing more self-serve access to them, and advice for companies building a partner experience. They also shared their thoughts on what is commonly overlooked in partner developer UX when companies are transitioning from a product to a platform.
If you're interested in hearing the full discussion, join the SaaS Ecosystem Alliance to gain access to members-only resources and a recording of this event.
You can also register for more upcoming roundtables on interdisciplinary topics relevant to those working in technology partnerships.