Krishanth Thangarajah is the Senior Director &  Head of EMEA and LATAM Partnerships at Yellow.ai working with Channel and Tech Partners. Before Yellow.ai, he spent 3 years at Freshworks where his team vetted use cases and added 600 integrations in his first year. Eventually becoming the Head of Partnerships, he worked with this team to decide what partners to prioritize and how they could add value to their long-tail of partners.

In this interview with Kelly Sarabyn, one of the Co-Founders of the SaaS Ecosystem Alliance, he shares advice on how product and partnership teams can scope use cases, measure tech partnership's impact on retention and upsells, refine their partner tiering and long-tail partner experience, and how smaller companies can convince larger companies to invest in partnerships.

‍

This conversation is transcribed from our latest episode of the Between Product and Partnerships Podcast, presented by our group The SaaS Ecosystem Alliance. If you're interested in watching or listening to this conversation, you can access the video here and listen on podcast platforms here.

Intro

Krishanth: Thank you for having me here. I’ve spent three years at Freshworks. My first year was focused on adding to the total number of apps and integrations in our marketplace. We added close to 600 apps the first year I was at Freshworks. I spent a lot of time talking to a whole lot of SaaS companies trying to convince them to build an integration and talking to SA companies trying to figure out what use cases can be built into paid apps. 

During my second year, the focus was primarily on adding revenues to the partners. We had a marketing engine that started to work on its own. The idea was to work with partners to exchange leads, work together on certain opportunities, and add revenues to the company. 

During my third year, I took over the entire team and I merged both teams together. I didn't want people to just add partners and create unrealistic promises only to have the second team figure out that those promises are long-tail and difficult to provide. It was more of a cleanup activity, where we were trying to look at how we can add value to long-tail partners as well, and then worked on partner tiering.

We had partner tiering at the beginning but we started to focus more on how we can spend our energies and our team's bandwidth across different tiers of partners. We created OKRs around churn, app adoption strategies, promotions, etc. apart from just adding pipeline leads. That was my role Freshworks, at yellow.ai, I work with channel partnerships. The idea is to work with partners to add pipeline, and, of course, I do work with a few SaaS partners as well.

Kelly: That's some great experience for our audience. One of the things that organizations really struggle with is the prioritization of both partners and integrations.  It sounds like you went through that process where you had a bunch of partners, and then you selected some of the software partners to have a deeper relationship with. I'd love to get your thoughts and advice on how organizations should frame that decision.

‍There are obviously a lot of variables, but how should they think about which partners are we going to choose to invest more in?

Krishanth: The first thing is, who is asking for these integrations? One of the first variables that I look at is the number of integration requests that come from customers. The second key element is understanding who are building these integrations. If it is going to be big giants, then, it's primarily going to be you, so you make sure that the solutions also solve a product gap. 

The second key aspect focuses on the type of partner and the product gap you are trying to solve.  What use case are they trying to solve? Do you have open API's? Is it going to be a native integration? Think about data flow, it could be one-way or two-way.

What frequency are you going to update information or push information? Will it be live, every 15 minutes, daily, weekly? From an engineering perspective, these are a few of the variables that we look at before focusing on what integrations to work on and what partners to work with. You can look at it from a GTM perspective. But again, at the end of the day, you'll have to end with the engineering team, because they're the ones who are gonna build it out. And of course, it has to make sense as a solution together.

Kelly: Yeah, that's a great point. I've heard some people say,  “Engineer time is often the most expensive time to spend for an organization.” They were arguing, bring this more to the front of the process where you're not pushing something forward, and then you find out it's going to take 100 hours to get even part of the integration going. 

I’d be curious, what’s your advice? How much of the partnership involves the product team investing in scoping out the use case? And also what's possible? Customers might be clamoring for this two-sided bi-directional Salesforce integration that does everything, but maybe your own API doesn't allow that. 

‍What's your advice for the partnerships and product teams? How deep should they scope use cases before they say, “Let's push this over to engineering.”?

Krishanth: First things first, we have to understand whether we have the engineering bandwidth. That's the most important thing, even before we commit to an integration or coming to a partner to indicate an integration can go forward. One step before that, we have to understand whether the integration will make sense.

You're going to look at the number of common customers that you have and ensure the integration makes sense validated with customers. If an integration makes sense, you need to have data to convince your product teams. Get proper data, work with your product team, and look at the solutions that you're solving for. The product team also gets convinced with the data that you have. And then look at engineering bandwidth at both ends.

There are a few integrations that will be more of updating your systems, which means you will have to integrate and pull data from there to integrate. If you have an SDK platform, and if you need a partner to integrate, you give UI guidelines for the partner to integrate. You'll have to figure out between both of you, or if both of you do not have engineering bandwidth, can you enroll a third-party to build an integration? If so, does the integration need a middleware?

If that's going to be the case, that middleware will have to be maintained by the SFR? Are there going to be your trusted side partner or should you actually take care of maintaining a middleware in house? As the integration scales, it could blow up. You need someone to monitor this and it's best that you own it in house, or maybe a preferred SI Partner handles it.

These are the parameters that you will have to initially decide, get in place, and take to the engineering team. Again, it's very important. I keep hearing this from different partner managers where they commit if they own integrations, they come in, it takes till September, sometimes it even comes to the end of the year.

Typically this happens, because we narrow down on all of this, but we stop following up. It's really important for us to follow up internally and look at where the product team is. Are they on track with what they have in mind? A few companies have integration PMs from the product side; you will have a spot for integrations, if so you're a little bit safe. If not, as a partner manager, it's going to  be a little harder because you have to work closely with them. 

There are going to be cases where you're going to work with PMs to support them with API requests. There'll be some product lead integrations that they focus on. Make sure every partner manager is talking with your product teams regularly. Make it a point that you get updates from them on what's happening on the engineering side. Is this being prioritized? Have things started? So you can keep updating your partner-side as well. If the partner also follows a similar cycle, then we at least know when an integration is going right and of course, even before that, is it even possible for us to build.

Kelly: The alignment between product and partnerships, when it comes to tech partnerships is just so key to success and something a lot of organizations struggle with. Moving to the flip side, once you've decided which partnerships, and you have a framework for investing, what's your advice? Organizations, especially big market organizations, are still struggling with how to get data and measure the business impact on retention and upsells. Once you get to a certain size ecosystem, it's very hard to do this for any individual integration. 

Do you have advice for demonstrating to leadership and to your partners the impact that integrations have on retention and upsells.?

Krishanth: Everybody knows more integrations means less churn but trying to track and put it in a pictorial way, as a data representation and having OKRs, is going to be difficult. Nevertheless, we did this at Freshworks, we started to monitor churn - customers with zero apps, customers with 1-2 apps, customers with 3-5 apps, 5 apps and above. We started with buckets of customers and we started to compare the numbers between 2019 to 2020, 2020 to 2021. We were able to see that customers with more apps tend to see churn go down. As the number of apps keep increasing, the churn goes down.

I would recommend the partners do that activity. That's clear proof, data talking to your management, that the number of integrations will have to go up. Your customers will be using multiple SaaS solutions, they'll have to integrate and use the solutions together. This data point is enough to convince your management or get your Chief Customer Success officer invested in partnerships, so that all your CSM talk about critical integrations that you have. That way you can get buy-in from the management and drive towards more integrations. 

If you are going to prioritize partners, there are high velocity integrations. You have a mechanism to get ratings, reviews, and testimonials from customers on those integrations, those are the ways you drive forward and convince the management with respect to number of apps directly correlating with lesser churn

I would take the number of installs as one key metric. What value are you going to bring to the table as a partner? What dollars are we sharing, when we are approaching a particular marketing activity? What leads is your partner able to generate for an activity that is either co-sponsored or any of your co-marketing activities? Try and measure all these from a co-marketing perspective and see how effective partners are.

From a co-sell perspective, you can look at two things. One you could get leads from their marketplace, try and track that using UTM links. Second, any lead introductions. Once you start working on joint RFPs, you just need that one deal, one success story to convince people across the organization that partnership works or a particular integration works. If you're able to take it slow, and start with partners one co-sale opportunity at a time.

You will have enough data around how many partners introduced you to opportunities and how many of them got converted. You can have a funnel of the leads that came from your partners. That's a clear projection for your management to understand that closures are happening much more quickly. When two partners are working together or when there is an introduction that comes from a partner, customers are more inclined towards using your solution as well because they trust the partner.

Kelly: That's great advice on something organizations are really struggling to implement. Ultimately that quantitative data really speaks to leadership and speaks to partners.

‍Do you think there's qualitative data that can supplement quantitative data? Are there other ways that you've seen you can accumulate qualitative data to add-on to show that correlation?

‍Whether it's somehow convincing customer support include something about integrations in their NPS surveys or using conversational intelligence in sales to see how often people are mentioning integration and how important it is.

Krishanth: It's very important to have reviews and ratings for your integrations. If you have a marketplace or if you have a page, it's very important that customers rate those integrations. Going back to more of an NPS or other proof that the integration works; work on testimonials. These are additional ways by which you can provide solid proof from a qualitative perspective that the integration is working. Is that what you're saying?

Kelly: Yes, some people could argue people who have integrated more systems are just super users anyway. They were going to be using your product all the time. I don’t think it’s a strong argument, but it’s nice to be able to supplement that with customers saying, “Hey, this Salesforce integration is critical to me, it's valuable, I'm getting a lot of use out of it”. If you can show people are using the integration, that's already backing up your point. Even since it's a correlation, rather than proving out causation, it's nice to supplement that with a testimonial. 

To your point about reviews, and having them as a component in your marketplace, for example, you can pull that out quite easily and say, “Hey, look, here's what our customers are saying”. I have heard some organizations putting it on their customer surveys in general, but you can't always get that as a partnership manager. That's a limitation, potentially, if the number of questions is an issue. I was just curious if you've seen any other ways to collect those testimonials, even if it's a case study or talking to your partners.

Krishanth: When CSMs talk to end customers about getting a case study for our own solutions, we also have some questions around integrations as well. In most of those interactions with customers, a partner manager would join, and then we'll get some clues and ideas of how our use case is better than the competition.

They prefer us for XYZ reasons. It's very important to talk to your customers, because they'll give you clues and ideas on how an integration can be better. When you're working on case studies, your CSMs are working with your customers day-in and day-out, trying to get feedback. It's important that the partner manager convince CSMs to share those questions around integration to enable us to have testimonials around integrations. 

Another way to solicit testimonials, particularly when dealing with the long-tail, of course is that we share this load with partners, when we are working together and when an integration goes live. If we work together on solving an issue for a particular customer, we can ask the new customer as to whether the integration solved the problem for them or not.

It's easy for you to ask things from a new customer. That's something that we have seen work well for us, and you can have a shared load between two partners. Can we talk to customers and ask one to three questions around integrations? “Hey, I'll take these customers, can you take these customers?” That's another way by which you can kind of share load between two partner managers, trade off to their internal teams, and start getting integration testimonials.

At Freshworks, at least towards the end of last year when we went public, the company became even more popular. We had a lot of long-tail partners who were willing to work with us. You can’t involve all of them. We asked them to have a minimum of 10 integrations and then have a minimum of two or three customer case studies to talk about the integration. These are other ways by which we make sure that almost every integration has customer feedback or testimony.

You never know, customers these days are asking for testimony, they want to talk to other customers who are using those integrations; you never know which customer is going to ask you when. It's always important that you keep this data handy.

Kelly: That moves into another topic I'd love to get your take on. Three to five years ago, both organizations and customers were a lot less savvy when it comes to integrations. The customers pre-purchase would just ask, “Do you integrate to Salesforce?” And the salesperson would say, “Yes, we do.” That would be enough and then maybe a year later or six months later, they'd find out it’s just a one-way integration that just moves contacts over and doesn't really meet the objectives.

‍My read is that customers have become more savvy in the last couple years when they're vetting integrations, realizing that just connecting is not enough. Do you see that as well?

Krishanth: If you look at not only mid-market or enterprise grade, but even small and midsize businesses these days want solutions to problems. They want one, integrated solution. They don't want to work with individual products. It's important to use solutions to drive product selling. What I've noticed is customers used to look briefly at a particular integration. As long as you have Salesforce on your website, they're happy, they know there's an integration and they can go ahead with you. But sooner or later, those kinds of customers are going to realize the integration is not up to the mark, and they're going to jump

It's important for every organization to make sure that we’re not just listing and talking about a logo, it is about talking about the solution that both these companies are putting together or talking about the exact use cases on your website. We see a lot of customers spending time looking into the marketplace, and then reaching out to a CSM or reaching out via support email to hear more about integrations. 

This has clearly increased over the last three years. I mean, from right from 2019, where I used to see more of enterprise clients asking for these integrations. Earlier, they would have used a systems integrator, building everything into it and with exactly what they want. Enterprise customers look for integrations, they make sure they hear the use case completely before they purchase. SMBs were okay with whatever you give to them. Over the last year or so, I can clearly see the number of queries around the integrations and the use cases that customers throw at us have gone through the roof.

Kelly: That's what we're seeing too. It's really important to talk about because a lot of early stage companies are short on engineering resources. They want to be able to say they have integrations and you hear people saying, “Oh, if you have integrations, you're going to increase your retention.” The reality is that customers are getting more savvy. It can actually cause the opposite effect. I've definitely heard people saying, “This HubSpot integration doesn't do enough, it doesn't meet my purposes and I'm going to look for another tool that is more deeply integrated.” 

I'd really like to hear your advice on the partner experience for long-tail partners, because I think when partner programs start, they usually have closer relationships. As you grow, you still have those strategic partners that you're meeting with regularly, but once you get to a certain point, it's just not feasible.

‍How do you really create trust and investment, get partners, and engage them when you can't have that high-touch relationship anymore?

Krishanth: Are you talking about the bigger partnerships that you want to get into?

‍Kelly: No, once you have an ecosystem that has more than 30 or 50 partners, you are big enough that you have people who are willing to build the integration and they want to be in your ecosystem. How do you create a nice experience for that long-tail so that they are not just building the integration, but they're continuing to maintain it, and they're supporting their customers? And to your point about case studies, they're investing in the go-to-market side, even if you can't have regular meetings with them.

Krishanth: You can do it in two ways, if you have an ecosystem, there are companies reaching out to you. And in a few companies, you have people reaching out to other companies. If it's the latter, you can definitely correct this, because folks are going to reach out to the right audience, and they're not going to think about a use case without validating and pushing partners to build integrations. That could be an initial strategy to get the numbers.

We did it that way. In 2019, when we started, we just looked at the numbers, we were looking at use cases, if it made sense for us, we just continued. For every integration, we didn't go with the data to back us up.

If you're looking at having a team to reach out to partners to build those integrations, then it's really important that they narrow down on those use cases. When there is data to talk to, even if it is going to be a long-tail partner, they know they're going to be short, we can help them with the use case. We tell them the right product gap that they're going to solve. That is trust initially.

Second, the other way around when partners reach out. Even in both cases, it is important for us to clearly tell the partner what they're going to expect out of listing the integration or being part of our ecosystem. They will be tier three or long-tail partners; we can include them everywhere. Xero and QuickBooks, they do it really well. The idea is you clearly define when a partner qualifies to be a tier two partner.

Assuming you tier partners into three tiers, you can clearly tell them when you will consider them or work with them in terms of co-selling and co-marketing, when you will invest some amount of NDFs, and what it takes for the partner to work towards you. If you're able to define that, partners will come to you and they'll be more aligned with whether it works well for them. 

Rather than us pushing partners, you have given the use case you'd like them to think through.  If partners are interested in building an integration with you, they have no clue what to expect. You dictate terms, you tell the partner they need to get a minimum 10 integrations to customer case studies, then I'll invest in you with respect to NDFs. I'll invest say, $2,000, or $5,000 with you or rather, it could be on a number of activities.

I'll have you on two activities in a year. Another thing to do is cluster four or five long-tail partners together, and stitch together a big story where these four or five partners are solving different use cases. You'll have a big story, it could be verticalized, or it could be a story that you're going to bring together. Your overall cost is going to come down because you're going to bring in four partners, all of them are going to share, it's going to be one activity where you're going to invest in those four partners. You're going to make four partners happy.

Initially those criteria partners will have to meet so that they do the heavy lifting. If customers are using it, there are customer testimonials as well. It is important to invest in them, because by the end of the year, if they aren't happy, and there are less customers, they may not take care of integration. 

In the long term, that is going to be a big problem for you. It's always important for you to check if the partner is invested, if not, you'll have to figure out if there are enough customers. Assuming you have 20 customers, it's important for you to maintain 20 customers, but the partner is not getting much from those 20 customers. If they want to walk out, you need to have a fallback mechanism on how you're going to maintain those integrations. I think it's important to check on them. Are they happy? What are their plans? If there is an emergency situation, how you can handle those?

Kelly: From a more tactical side, I'd be curious about your take on the mechanics of it. I would imagine that a company the size of Freshworks could have a partner portal that people would log into it. But when you get to more medium size or mid-market companies, there's this problem of having 1000 partner portals, everybody's partnering with each other, and people don't want to be regularly logging into 100 different portals.

Do you have any thoughts on when that's a realistic experience? How large do you need to be to offer that experience as the way that partners are communicating with you?

At what stage do you offer that portal experience? How do you make it better so that people who are on the fence of whether or not they want to regularly engage have an incentive to login and maintain the relationship?

Krishanth: You're right, there's a developer portal that Freshworks maintains, and then partners can sign in, submit the app, and enter the details. After the approval process, the app is going to get listed in the public marketplace. If you're going to look at Shopify, it’s a very similar approach to the Salesforce App Exchange, everybody knows about it. So if you look at these big companies, there's no way that you can offer one portal for everybody. These are giants and you have to follow their process. 

Of course, the the partner marketing manager will have to work together with the developers who will publish the app, or a partner manager, in terms of getting the listing through. One of the biggest challenges I noticed at Freshworks, is that the developers who are going to build and test the app get their credentials for the partner or developer portal in the beginning while most of the times the partner marketing people miss out. 

Many times at Freshworks we had to go back to enable the partner marketing manager right from the beginning all over again, so that they also get a login. Or we added them as an agent, so they can log into the developer portal. For Freshworks, it makes sense; this is something that they're going to maintain. But for a midsize company, portal management in itself is a challenge.

That's where Pandium solutions come in handy. At the end of the day, you have to showcase your integrations and manage your developer portal, and this is huge work. If you're in-house it just doesn't make sense for you to have an IT team to manage this, because except for the partner manager, marketing, and partner marketing team, nobody's going to be seriously invested in this portal.

It's really important that someone demos solutions that take over managing partner listing. I think the ideal world is kind of like Facebook. Everybody's on one platform, and you can kind of do whatever you want, everything is synchronized to look the same. 

It'll be difficult for two reasons. One, the big companies are going to have their own ways of doing it. Second, logging in. It's going to be more of a one time effort, and more of a Google Form where you enter your details, upload those screenshots, and it goes live. Each of them have figured out a way to manage this, but at the end of the day, unless we have enough partners at the same platform, it is going to be really hard because it's going to be more of a one-time activity. 

Imagine this, if I'm listing an integration today, I'm going to come back to it maybe in six months time, or maybe after a year I'm going to revisit the integration. If I'm going to add more use cases to an integration, that's when I'm going to revisit, that's when I'm going to come back to a portal. It's not going to be a daily activity; once you’ve listed you're done.

You're not going to work on more than five or ten integrations. I honestly believe it's still okay to have multiple portals. It isn't that big a pain point, but I'll put it this way, it's nice to have one platform kind of a view; but it's not a must-have.

Kelly: When you're listing on a marketplace, if you're not doing the constant co-marketing and co-selling, there's only so many times you need to log in. I think some of the more sophisticated portals obviously have the install data, the usage data, and those like AWS and Salesforce have demographic information, which can be valuable from a marketing perspective.

They also have APIs that enable people to pull data in. You have companies like Tackle who exist because internal teams don't have enough developers to work with APIs; they bridge that gap, so business users can access them.

That touched on another point, which is how companies can take different approaches to how rigorous they are in the beginning, in terms of approving and vetting integrations. I've seen a wide spectrum. The most open spectrum would be one where anybody can submit an integration to be listed in the marketplace and it’s just approved with an indication that it’s not “certified”.

On the other end, you have people who only allow people who they want to co-sell with or co-market with. In the middle, I've seen marketplaces say, “Okay, I want to vet your use case. Are you different enough from the current integrations in our space? Are you solving a problem that's at least somewhat distinct.”

What is your advice on how organizations should think about how open they should be for accepting new integrations and deciding how much they should let people build into them?

Krishanth: It depends on the different ecosystems that you as a company want to participate in. What we at Freshworks used to encourage is building on an SDK platform so that the app could be verified. There was a three step review process: code, QA, and content. There are external apps where if you want to just pull APIs and update information in your system, then you're free to use the open API documentation, you can again list those integrations in our marketplace, but those are not verified by Freshworks. Atlassian does that across security, and they have like six to seven parameters, and they kind of have a checkbox or a warning symbol if something is not provided by a partner who is listed in the particular integration; it's left to the customer's risk. 

The customer is well-informed if something is verified by Freshworks or Atlassian. Customers are definitely going to go for those apps. If it is just being listed, then they can clearly see that in the marketplace. It's up to the customers. Atlassian, I believe, had left it to the customers to kind of deal with it. At Freshworks, we have taken a very similar approach where verified by Freshworks yes, we do verify and we take care of support as well and of course, we loop in the creator of the integration. But if it is an external app we don’t support it.

At the end of the day, the idea is to not have thousands and thousands. The idea is about having those 50 or 100 that actually work for you. At the end of the day, it's going to be the 20% of the apps that are going to work for you. While we can have random people build an integration, who's going to maintain it? For example, we have had apps built by engineering students as part of a hackathon. Now we can appreciate them during the Hackathon, look at someone who can absorb the app, and list it in the market.

I know for a fact that after a year, when they get a job, they won't be maintaining the app. I can't allow those kinds of apps in our marketplace; customers will start losing trust. When that happens, your whole marketplace idea goes for a toss. Of course listings show the integrations that are there, but at the same time customers are going to check the use case, whether it works or not, and then go for it. If not, the marketplace will just be junk where people are just going to list everything. There's not going to be any trust.

It’s why you buy at Amazon; because you trust Amazon. Even though there are a lot of apps or other products, you don't go to any other random website and buy it because of the trust. We can have certain criteria where you tell customers that certain apps are important and certified. Maybe you have a hard process where you can have certified verification of everything, you have a dedicated team for that.

Again, that depends on the team bandwidth. If you have a dedicated team, I would recommend doing that. At the end of the day, what we're trying to achieve is to solve the customer's problem. We shouldn't start the other way around where it's the partner that you're going to integrate with trying to push it to a customer. That'll never work.

Kelly: I think we know as consumers. Amazon's a perfect example. They have third party sellers, we know they're third party sellers, but if we have a horrible experience or if the product is completely junk, we still blame Amazon. The same can be said for tech platforms. I know as a business user, I use HubSpot. If I installed an app and it was a horrible experience, I'm not just blaming that third-party vendor. I'm also going to blame HubSpot for servicing that to me.

That's something no matter how organizations set that up, they should keep in mind that even if you didn't build that integration, if you're servicing  it to your customers, even if you say, “Buyer beware”, it's going to impact their feelings about you at a minimum. From the Freshworks perspective, you were probably the "big fish" in most of your relationships.

‍Are there ways that you saw where people could persuade a larger company to have them be more invested in that relationship beyond where they are in the program?

Krishanth: From the Freshworks perspective, we have a revamped portal where people could sign up for partnerships with a series of questions. For example, “Have you already checked if there are other solutions in our marketplace similar to yours?” If the answer is no, we know for a fact that they haven't even invested five minutes of thought before building an integration. Second question would be something like, ”What is the use case that we are going to build?”

If they have not defined that, we know they haven't fully fleshed out the ideas they want to discuss with us, which means unless you have bandwidth, you can’t entertain those kinds of things. 

At least in Freshworks, what we can address when someone is going to sign up for partnerships. If someone writes to support, we redirect them to the portal. The portal has a series of questions for the potential partners. If they spent 10 minutes answering those 10 questions, we know that they are serious.. By going through those questions, step-by-step, we are actually guiding them to a marketplace, we are guiding them to our API documentation. 

After the use case, the third one is, “Have you checked our API documentation?” If not, here's the link. See if it's the use case they're thinking of is possible to build. Do we have it? API is exposed, etc. Before they come on a call and we discuss partnerships? Right. So it was important to ring-fence, from Freshworks point of view, where we go growing the ecosystem. We can have influence by initially asking the right set of questions so that before building an integration, or before we even get on a call, partners can realize where they are. 

And then of course, you'd have to filter even after that. But nevertheless, at least you can educate partners who want to work with us. Because Freshworks is big, people are excited about working at Freshworks, but they also need to understand that certain use cases will not work. That's what I would recommend for someone who is looking at building an ecosystem. 

For someone who's small, what I would recommend is, if you're looking at getting into a bigger ecosystem, it's really important for you to align with their goals. At the end of the day, you need to understand how they are working with other partners in the ecosystem. What does their partner page say? What are the different types? What are the kinds of roles that they have? How can I be more methodical, logical in terms of reaching out to these big giants? 

You may not get responses, you may not have a partner manager, or dedicated partner manager, but there'll be a partner support email. Just start writing to them. Talk about the use cases, talk about how many people are using the integrations. People are going to take notice of that. When you keep talking about integration publicly and on your website, and you have testimony, I'm sure the companies are going to take notice of you.

We've seen some really small companies become really big. The proof is just customers at the end of the day. So I would recommend that if you're small, if you're trying to grow into a bigger ecosystem, start looking at what is important for them. Work backwards so that you can nail it down then try to directly talk to someone from that ecosystem.

Kelly: Ultimately, you have to have somewhat of a relationship driven mentality and just reaching out making yourself as visible as possible and being comfortable doing that. Some people aren't going to respond, it's going to take time. We're all humans at the end of the day on both sides of the relationship. Making the effort can go a long way, because I think a lot of small companies just look at it as a monolithic and it's a black box, if you make the effort to reach out. Did you have any final advice you want to share to tech partnership leaders who are scaling their program?

Krishanth: Based on my experience and having spoken to a few other partner managers that I’ve worked with, one common question asked is, “What targets can we make for the teams?” It really depends on what stage you're at. I would not recommend tech partner ecosystems to jump in and make revenue targets. There are enough people focusing on revenue.

It's about what value you can bring to the customer. Think from that perspective, and start having OKRs around that instead of something around revenue. If you have a marketplace you can do it indirectly, but don't just focus on co-selling, because that's not a sustainable model for the long term

End

If you enjoyed this interview, check out our Youtube channel and subscribe for more content on all things technology partnerships, APIs, and integrations. 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 Krishanth at SaaSecosystemalliance.com.