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.
Between Product and Partnerships is a podcast brought to you by our group the SaaS Ecosystem Alliance, and it’s focused on bringing together product, partnerships and engineering leaders to discuss how to build support and scale SaaS ecosystems. If you're interested in watching or listening in on this conversation, you can access the video here and a link to listen on podcast platforms here.
Our former Director of Marketing, Kelly Sarabyn, interviewed Priya Sukumar, the Director of Product Management at RingCentral. Priya defines a user-centric approach to building integrations and shares processes she has used to implement this mindset in her day to day. She also provides tactical advice for collecting user data, leveraging CS teams for user research, and keeping up to date with changes that can effect integrations.
Priya: I am Priya, and I am the director here at RingCentral, mainly focusing on product integrations. I have more than 10-plus years of experience in the SaaS world, as well as in the collaboration space. I am very passionate about user experience and I believe in user-centric design and design-thinking. Im looking forward to this session.
Kelly: Amazing. Just to take a little bit of a step back before we dive too deep into it. Product integrations for SaaS companies are very cross-functional, they usually have a tech partnerships manager involved in the process, and you might also have CS involved in the process.
Priya: For me, I feel that product managers pretty much lead and influence what needs to be built next. I'd say to always start with a purpose in mind as a product manager. Having a purpose in mind helps us to attain which goal we want to achieve through this product. Most successful product teams give importance to clear objectives, and a deep understanding of user needs, which frames why they are prioritizing what to build next.
This way, big decisions are not taken by impulse, or just out of intuition. Key attributes to look for while determining what needs to be built is to understand and deep dive into which segment would benefit from this product. What's the scale of impact? And does it solve a user pain point and bring value to the customers we are offering this product to?
And I have found a really good framework, which is called the RICE framework. RICE stands for Reach, Impact, Confidence and Effort, which has been very useful while I'm prioritizing and figuring out what it means to the audience that I'm building for.
Kelly: Yeah, that makes a lot of sense. We can get into that a little bit later on, on how products should be working with those different stakeholders to execute on that framework. One of the reasons I have reached out to you is because I read an article that you wrote on a user-centric approach to product integrations.
I would love to hear from your side, what exactly does that mean? Almost all SaaS companies now are building product integrations, from small to very large, almost every company owns product integrations.
Priya: Let's first start with what's unique about product integrations, right? Product integration is unique in a sense that, especially for a product manager, you need to be an expert, not just your product that you're building, but also the partner system or the external system that you're building on top of. So that's one of the reasons why it's so important to be more user-centric in terms of designing those product integrations. There's always this misconception that integration just mean a data sync and data mapping. It's way beyond that.
It's about how users can seamlessly get their workflow done. A user-centric approach simply means establishing the user voice, right from the beginning, when you're ideating a product. This simply means listening deeply to user needs, and developing empathy to their pain to help define requirements and design. We need to account for and support some of the users existing beliefs, values, and habits that they have incorporated in the years of experience that the user might have using certain products. I believe in three major principles as we think about user centric approach:
Kelly: Yeah, I think people sometimes forget that a product integration can essentially be its own app, its own system. It doesn't have to be a one-way data flow where you're just sending contacts to a different system; it usually gets much more robust than that. One of the really core challenges of product integrations is you do have this other system, which is unlike a product feature where you own that whole process.
You have your current customer base, but when it comes to working with that other system, and designing that experience, you really have to understand potentially another audience's pain points with another system.
Priya: There's quite a few things that we need to do. The first thing I would like to map is my first principle that I just stated, understanding the user needs. We basically do this through user discovery activities. That's the beginning stage. It actually comes in handy when we want to empathize more with the user perspective, and understand how they use the two different systems. What I've incorporated into some of our integrations as well, as I'm building and leading the team, is user interviews. Honestly, nothing beats having a user interview and actually talking to those users, especially when building enterprise product integrations.
It's important to keep a note that buyer personas could be different from the actual user persona. You need to account for both because buyers are generally more interested in cost, configuration, and onboarding vs an actual user that may be more interested in ease of use and how they'll get things done. What has benefited me when it comes to gathering data is shadowing users and experiencing a day in the life of a user. We'll look at how they go about performing tasks, the workarounds they perform each day, and what's their emotional state is as they go about doing all this.
What has helped me a lot is mapping the entire user journey right from the start with onboarding. How do they onboard? How do they discover this product integration? How do they engage? How do they plan to use this product? How do they exit? How do they finish their job and move on with their life?
So that has been really important. I feel like as product managers it’s something that we need to do, and continue to do. Make sure that you ask a series of questions to understand their current behavior and possible workarounds. It's definitely worth your time to understand the user persona and limitations.
And sometimes during the sessions, we do get suggestions on what can be improved for a product to be even better than our competitors. So those are a few things I would think about as a product managers. Aim to better understand from the user perspective and not just from the system perspective. Of course, these are two different systems, but it comes back to that whole user centric approach of how the users thinks about these two systems and how it needs to work seamlessly.
Kelly: When you're doing that process, are you most often focusing on your current customers? With product integrations, in particular, because it can be a partnership, they're looking at it as sort of a market expansion.
So even before the product integration is built, you might be looking at it as a way to attract new customers from this other system, because you see a use case that may be valuable.
Priya: Exactly. Yeah, you're spot on, Kelly. So again, it goes back to what I said, understanding the purpose and understanding the goal. If the goal is growth and adding or expanding your user segment, then making sure you understand those personas with user interviews. As a product manager, it's impossible to be an expert for all systems.
I wish that was the scenario, but it’s not. Sometimes you have to work in a vertical related domains, like a virtual classroom with an educational domain or something in Telehealth, which is a completely different kind of an integration. As a product manager you gain those insights about user behavior through user interviews and also by understanding the segment you're targeting. During these interviews you get to know what other systems they use. For example, I was working on a Telehealth integration. I had zero clue on what this meant, what the doctors did, what the patients needed, and the role that nurses played in all of this.
It was so insightful to actually shadow some of the nurses and the administrative officers in the clinic to understand how they actually use the healthcare system. They had notes that they took and signed. Then they used Outlook. There were three to four different systems they used and all of them had workarounds that they did to address their needs. That's where, as a product manager, you need to be creative to see how you can simplify their life.
I would go back to that whole user-centric approach in defining if it's growth or if it's retention. Each is a little different. How do you penetrate the current account? How do you retain those customers? How do you keep them engaged in the product? How do you get them to come back? In the first 30 days, 60 days, 90 days, we need to have a plan in place.
The engagement goal is a little different. It's just more about how engaged you can keep the user within the product. The more simple and effective the workflow gets, the more they're going to come and use it. So those are things that we need to consider as we're thinking about our roadmap, as well as, building the products.
Kelly: That's an interesting point about having this other system and learning, to your point, new knowledge about the user journey. There may be some strategic integrations that have a product person who solely owns one integration and they stay with it their whole job, but when you get integrations of mid-level importance, you might not have someone who maintains it as their full time job. At that point, the product manager has to face this dilemma.
They have to decide how much time they should invest in learning this other system. Also, we know there's going to be technical limitations. In this case, you can understand the user's journey, and what their pain points are, but you have your own limitations on your own system. The other systems may not have webhooks, they might not have a bulk endpoint. They may have really restrictive rate limits. They'll be different in every case, but there's going to be restrictions.
How familiar should they be with those technical limitations and how deep should they go in investing and learning those technical limitations in order to correlate what the user wants and actual technical feasibility?
Priya: Absolutely. As we determine the best user experience the product manager should be considering technical limitations in the very early stages of building the product. It's more about how deep you want to go and how much time do you want to spend on it.
We need to spend enough time that you get a foundational understanding of what's between the two systems and what the limitations and gaps are. Gaps could be from UI design styles. It might be that the API and the mapping are so different that you need to figure out the gap between these two systems.
The two systems could be architecturally so different that it needs more engineering involvement to go even deeper to vet out the details. I feel as a product manager at least a high-level understanding of technical limitations is going to be immensely helpful even while designing the product, which is very early in the process. Sometimes we come to a point where the development starts, we are all excited, and then boom, it doesn't work. Now we have to go back to the drawing table.
There's a lot of chaos and confusion when we start thinking about technical limitations in the late stages. That's one of the reasons why I always recommend product managers start understanding the design limitations, understanding the guidelines, and showcasing the brand limitations as well. Sometimes the UI limitations or third-party platforms might not be very evident, upfront, especially when you're attempting to integrate with really big names, which are more strategic. They have very strict branding and style guidelines. Sometimes we have to accept these limitations.
I have found it super helpful to know these limitations, find workarounds, and move on. There's not a perfect kind of application out there. So we have to be creative and find those alternatives. What has helped me is supplementing with video tutorials, detailed user guides, FAQs to address those limitations and ease some of the user onboarding, and help improve adoption. Those are few of the techniques that I've adopted to mitigate some of these limitations as we move along towards the end of building that product.
Kelly: How do you decide what to budget out for that in terms of timing and resources? Also, if you are using beta customers, how can you make sure they're representative of your frame for choosing them.
Priya: What is very beneficial about the user interviews I mentioned before is that, as product managers during the process, you can build relationships with customers. That's important for the success of the product. When you build a relationship, that creates partnership - more than just customer and company.
We build a closer relationship, they are invested in the product that we are planning to offer. What I have found really helpful is to start with private betas. This is because given it's such a new kind of integration, putting it out there for general usage might actually bite us in the behind. I've experienced that myself. The support call volumes go up.
The first thing that comes to our product managers is the usage doesn't take off, or the goal doesn't work out. What we forget is the secondary impact or the ripple effect of support cases going up, and the sales and account managers pinging you and trying to resolve these fires. I have always found it very useful to have a more organized way of rolling out releases.
I normally start with private beta, since we have built those relationships through user interviews. Given that we are all in an agile kind of a way, it's such an iterative approach to things. So, during the private beta, we get a lot of input from users.
We then take their feedback, make improvements to the product, and go in for public beta next. That's through signups, and so it is more of a restricted public beta. Then we go full on in terms of GA. That has worked for me. Going for a brand new kind of integration that we think would create an impact, but taking it slow.
Kelly: That's more scalable, versus, I would assume in the private beta, it's a little bit more close-touch?
Priya: Exactly. So private beta is more hand holding, staying very close. That also means, as product managers, we’re very invested in the product at that point. But, as you said, as it goes to multiple hands of the users, it's close to impossible to handle every single user. So self-service onboarding is very important. That's very key, but also, I’ve found it very helpful to make sure we have a feedback loop set up. That could be within the product itself. One example would be prompting users to rate the product and give feedback in the app.
Then, as a product manager, look into that feedback and use the right kind of tools. There are some word analytics tools to determine the most common pain points that customers are having. In fact, we use Pendo as one of the tools to get feedback. Those are some of the things that have been immensely helpful to get more qualitative and quantitative data.
Priya: Absolutely. Especially when it comes to a marketplace, it is very important to track those ratings and reviews. In my experience, however, customers or users provide feedback in those marketplaces only when they are really frustrated. So, even though that's one perspective, we address whatever the pain points are.
It's also important to get the complete feedback loop, meaning that if there are ideas about improving the product, those things might not always be captured in the marketplace feedback. That's one of the reasons why I suggest supplementing the marketplace ratings and reviews by making sure you reduce the friction for users to provide any feedback you're looking for.
Priya: Yes. What I have found really helpful is implementing monthly sync ups with the support team to understand the volume of support tickets we receive, and categorizing those support tickets to understand where exactly to start focusing on. We also collect support ticket data and translate it in terms of product investment.
Meaning, which areas do we want to invest in to elevate some of the issues and customer pain points. Those are things that we look at as part of defining the roadmap. We also make sure we have constant sync ups with the support lead or the support team to get their input as well.
Kelly: I think one of the other common challenges that I see in this space is that even if you have a really strong product integration that users are happy with, nothing is static. Your product is changing, and your partner's product is changing as well. Their API might be changing. I think there can be breaking changes, which are pretty easy to be up-to-date on, but I think the more subtle things, like the API having new functionality, or their product changes in a way where the integration should probably change from the user experience perspective, becomes a challenge.
Kelly: Ideally, companies won't only realize something has changed when enough users are complaining that an integration has ceased to be useful.
Priya: I'm smiling because I can very well relate to this problem. So the big question here are: What can a product manager do? And also, how do PMs partner with the engineering team to stay up-to-date? In the case of a product manager, it's a good practice to make sure you have an ongoing partnership conversation with the app marketplace and whoever you're integrating with on a regular basis.
It could be monthly, if you're so invested in that particular app integration, or it could be on a quarterly basis just to sync up and discuss where they are heading, where your roadmap is heading, and if there are things that would have an influence on either roadmap.
There are two elements. One element is the people who have influence over a product roadmap, and definitely the partner conversations that we have do have influence over these roadmaps. So making sure we understand those, as we have conversations with them. I also suggest working closely with the engineering team to understand if there are any API changes coming in. Also sign up for newsletters. Many of the developer platforms and developer portals now have updates on what's happening to ensure that you are up to speed on what's going on.
It is true that sometimes you will be caught off guard, because not only do we have integrations that we are working on, we have other work that we do. In this case, it's more about how well you react to these changes, and how, as a team, you can immediately jump in and be flexible.
One of the things we've always done on my product team is to buffer out at least 5% or 10% of our product roadmap for these kinds of updates. It commonly happens that platforms do get updated. By ensuring that we buffer certain engineering bandwidth, we make sure that this is taken care of.
Kelly: Everybody wants the end user to have a good experience, but, for example, you probably have people building into you, and you have developer partners using your API.
When you think about the API there's things as a product manager, you want it to be able to do so you can meet the end users needs, but then you also have to think about the experience for the developers who are actually working with a code. I'm just curious if that’s a tension that comes up?
Priya: I honestly feel it complements, which I think is an interesting perspective. The reason being is that when you're trying to address some of the use cases for the key users, that becomes a great input to how you define those APIs for developers. For developers are also trying to build for users. It's the same targeted users.
It's important to make sure we have certain developer guidelines and we provide enough examples to those developers on how it can ease some of the user pain points. I feel it complements more than conflicts the way we define those APIs, the number of API calls, or the way the APIs are structured. We make sure if it's with webhooks versus the number of APIs that you need to ping.
All of that architecturally is defined because of the input that we get from the users. In fact, it will be immensely helpful for developers as they are taking these APIs and integrating to provide that same seamless experience to our users.
Kelly: I can definitely see what you're saying. If things are designed well across the board, they can be in alignment for all the different users.
Priya: One thing I want say is that many times organizations are just tasked to build ecosystems and marketplaces. In the earlier days, building those marketplaces was a tricky time. Even though the success of building those ecosystems or building that app is defined by the number of apps in that marketplace, it's important as an organization to stay on high-value and strategic integration.
So bottom line, what I'm recommending is to go deeper in building a best interest integration instead of going broader in terms of number of apps, which might be subpar in terms of the integration quality. Most organizations do not give importance to user research. I feel it's very, very important, especially user research, competitive analysis, and understanding the market segment and which users you actually are targeting. Having that research early in the product life cycle helps make sure we don't waste time, money or resources in the later stages.
Most of the time, I feel that organizations run on assumptions. That's a huge, huge problem. When product managers run on these assumptions, they will get into a place where they're frustrated and wont understand why their product isn't being adopted. Why are the competitors going ahead of us? It's because simply, they need to lay the foundational work of making sure they think about user research and design-thinking. Then, they can build a quality product that addresses the user needs and their pain point.
Kelly: Amazing. I think that's such great advice. Especially when it comes to integrations, you often have people saying let's just grow. We need a marketplace. We need to grow quickly. If you do that, and don't put the upfront work, it gets super messy and you've involved all these other organizations. You can get a lot of tech debt that's hard to get out of.
I love that advice to put in the user work upfront, focus on those strategic ones. Then once you have that down, start to scale it out successfully. We will link to your article in the show notes but is there anywhere else people can reach you. Are you on LinkedIn?
Priya: Yes, I'm pretty active on LinkedIn. You can just look me up as Priya Sukumar. I'm happy to provide any advice or guidance based on my experience. I'm really passionate about user experience and design thinking so I'm happy to contribute to the community.
If you enjoyed this interview, check out our Youtube channel and subscribe for more content on all things APIs, integrations, and technology partnerships. If you're someone who is working on building and scaling SaaS product partnerships, we invite you to apply to be a member of our community and network with other leaders like Priya working on this at SaaSecosystemalliance.com.