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.

Intro

‍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. 

From your perspective, what role do you think product and project managers should be playing in deciding  which integrations should be built and owned? What should their role be in that 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. 

What does it mean for companies to take a user-centric approach to 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:

1. Understanding user pain points and their needs
2. Making sure we have early and active involvement of users early in the product definition and process 
3. Iterating the design and implementation as we go by continuously validating what we understand, what user needs are, and providing a continuous user feedback loop.

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. 

Do you have a specific approach for how you get that data? Do you collaborate with your partners, product team, and your partner’s product teams? Or do you suggest reaching out directly to the customers of the other product to understand their pain points with that 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.

Do you expand the scope of those conversations to include prospects on both systems if that is the case?

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. 

Do you have advice for product managers who are investing in building out an integration, but it's not going to be their full-time job?

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.

What are your thoughts on best practices around beta customers and the timeframe around that process?

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.

When you're going through the public beta process, do you try to become more hands off in terms of the user being able to onboard and discover their own experience?

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.

For people who have their own in-app marketplaces for their product integrations, do you feel like reviews are a good way to have one touch point for collecting feedback on that experience?

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.

Is there a good way for product teams to get specific feedback on integrations from the customer support team in a way that's more systemic versus anecdotal?

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.

Can you share processes or practices for making sure that someone in the organization is really on top of partner API and product changes?  

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.

Do you think that there's any tension between the user experience that you're trying to achieve and the developer experience of the API?

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.

Any last advice for product managers who want to implement a user-centric approach? Any common missteps or misunderstandings you see out there that that you would like to offer advice on?

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.

End

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.

‍