Go back

Beyond Handshakes: How to Structure Partner Programs for Success

35m 13s

Beyond Handshakes: How to Structure Partner Programs for Success

In this podcast episode, Martin Sholes, a veteran with over 20 years in B2B partnerships, shares insights on defining and building valuable partnerships. He distinguishes between transactional deals and true collaborations, where two businesses align on a mutual goal to create shared value. Sholes advises against prioritizing large, inflexible customers for integration pilots, instead recommending a focus on the ideal customer profile and common use cases to ensure scalability. He also clarifies the difference between technical integrations (API connections) and strategic partnerships (people connections), reserving the term "strategic" for partnerships that directly impact a company’s bottom line. To succeed, he stresses engaging multiple teams within a partner organization—such as customer success and marketing—through structured QBRs, rather than relying solely on a partner manager. Sholes warns against the common "give first" mentality, advocating for a balanced 51/49 give-get ratio to avoid toxic, one-sided relationships. He notes that in partnerships between large companies, a power struggle often occurs, requiring patience and strategic alignment to move forward. Overall, Sholes encourages a collaborative, goal-oriented approach to partnerships, where both parties contribute equally and prioritize mutual success.

Transcription

6366 Words, 34512 Characters

English
Welcome to Between Product and Partnerships, a podcast focused on bringing together product, partnership and engineering leaders to discuss how to build, support and scale SaaS ecosystems. This podcast is presented by Pandium, an integration platform for building native integrations. Hello everyone and thank you for listening to our podcast between product and partnerships where we talk about all of the challenges and what it takes to build partnerships, and SaaS platforms. Today we are so excited to have Martin Sholes from C-E-G-Consult join the podcast. Good morning to us, good afternoon to you, Martin. Tell us a little bit about yourself in your background. Sure, thanks for having me. I'm excited to be here and cross the pod and across the time zones. As you can probably see on my little bit here, I'm not the youngest anymore, so I'm in partnerships for quite a long time. I always joke that I started partnerships with B2B partnerships about more than 20 years ago. The first years I didn't even know that I do that because back in the days, that role was called business development when that was still the not the tough job of trying to make a call in book and meeting for your E-E, but really developing new areas of business, which is entering new markets that are geographically industry-wise or customer segments. Very often, if you enter a new market, it's helpful if you don't do it on your own, but you have a partner who knows the market and can help you to find the good stuff. I'm doing this. When my 20 plus years I stumbled also then in the B2B SaaS industry when that was also fresh, especially in Germany, which was a little bit behind then. North America built partnerships, diverse partnership types, multinational internationally for three startups as an in-situ operator. Before then, I made this jump into being an advisor, taking so I say my 20 years of making mistakes, trying to help companies to avoid those. We can find new ones, and that's what I'm doing today, trying to help B2B SaaS companies making partnerships work. Awesome, thank you. I have not been in partnerships officially for 20 years. I'm on the integration side for 20 years, but even just 10 years ago, I feel like partnerships as a role was really reserved for really large companies, if it was technology partnerships, or it was like reseller or channel or affiliate, then there's influencer, all this other stuff. It's a really interesting role to watch. I feel like maybe right around COVID, it got this huge bump, and we saw like partnership leaders and these types of groups popping up and new PRM technology and stuff. It's been interesting to see that sort of explosion of the role that I really feel like sits in an interesting spot in an org. It's like business development, but also sometimes there's a technology part of it. Sometimes it's like much more marketing than sales. I'm sure seen it all over the last 20 years. So to start off, how do you define a real valuable partnership? That's a very good question. I think one of the things which is challenging for us is that we do not have standing definition where partnerships are. You probably also came across somebody calling themselves as a partnership, and actually they wanted to sell you stuff. What sponsorships being called partnerships, even though that's pretty transactional. I had the pleasure to do the various kind of partnerships. I think the common denominator for all of that is that two businesses team up to achieve a mutual goal, or they have like one mutual goal which both benefit from. Very often there's a mutual custom in the middle around that. I think that's critical. That's one of the main drivers. Sales is transactional, partnerships is collaborative. It changes a lot of dynamics, and a lot of people don't get that. Look at partnerships very transactional. You give me this, I give you that. It's usually not the way that it works. A true valuable partnership for me is that there is an alignment on a mutual goal and both parties have been. I don't like that too much, but it's literally this cheesy one plus one equates three things. That is a line. I have heard a lot in this space. I'm curious how in your experience, how companies should potentially identify who that shared kind of partner is, or not partner, sorry, the shared customer is. This comes from like, again, I work more on the technical partnership side of the house, and I think there's always an impulse if there's like a large customer to be like, "Oh, that's who we need to use," but I'm wondering if you how you think about that. In my experience, your largest, most high-touch, high-value customer might not be the one you want to be piloting stuff with all the time, but I'm curious how you feel about it, what you've seen. Yeah, I absolutely know where you're coming from. This is a couple of thoughts here. Number one, the big one huge customer is probably a big corporate, which is probably not very flexible, responsive, and agile. These are things you probably want to have if you think about what could a product integration look like. There might be too much hassle with the stakeholders, and at the same time, you might find yourself in a situation where they come with very specific, very custom requirements. So it might give you a description which absolutely fits their need, but it's not repeatable, not scalable for any of your other customers. Then basically, you build an integration which is not reusable. You don't have this idly, you want to, like, everything which should be scalable, so it should be scalable, repeatable, usable. Then you have this very, "Oh, this is tail-on-made for this huge big elephant, but my majority of the customer wouldn't work." So what I would probably look at is really discussing about who's your ICP, and very often this massive key account is not literally your ICP because it's like this super cool brand you have, but not the one where you have 20 or 30 or 50 or 80 clients of. So I would look at the ICP and the common use cases they share. I agree. I do also think there's some vibes-based stuff there. Who is your customer that is a big user of your product, but also a champion, like a good partner to you? There'll be a lot in my experience, more like number one, excited to be working on something with you as a design partner, and also, tolerant of the rough edges that can come out of this stuff. But that's uptails nicely into another question about the difference between a technical integration partner and a strategic partner. And I think sometimes those two things can get conflated, and one does not need to be the other, and they don't need to be both. How do you think about the differentiation between those things, and like, maybe when companies should look at one versus another? I have to quote a good friend of mine, Justin Zimmerman, who was a guy who I heard from, who said, "integrations on our partnership, integration is a connection of APIs, and partnerships are a connection of people." And I think that nails it quite a bit. So I can have wonderful technical integration with research companies, right? I can have an integration to Google API or HubSpot, or even, you know, go to the AWS marketplace or not. That doesn't make me necessarily a partner, even they probably call you this way. Basically, what you do is you pull a number, and you're probably start up 1,750 who's in the line of being integrated or connected to the APIs. And that doesn't mean that anybody at Google gives about you and what you're doing. So the partnership layer would be then that you literally manage having a business driven conversation. So I'm literally, I just yesterday I came, visited one of my clients where we had this journey where they had a marketplace of 200 something integrations, which are critical for their core product to function, and it does really increase the value of the thing. And they were focused on the technical quality of this integrations. But then we really, I said, like, why don't you have partnerships with them? Why don't you have a meaningful business combination with them? What to how to market that integration and the value you create for them? Last but not least, strategic. I don't, I dislike this term a lot because it's used inflationary. Oh, it's a strategic partnership, which is for me, this is a quality criteria. And I would reserve this. I did reserve this in my history of four audacity, reserve that for partnerships, which are so critical for your business success that you do see it in your PNL, in your revenue or top line or button line result, whether or not you would have this. So that's and whether or not this other partners large or small is not necessarily relevant. It's just like how biggest impact to your own business. What a lot of people call strategic partnership is they, as a small startup, try to partner with one of the big guns and then they call it strategic. Guess what? You, they this partnership might be strategic for you, but most likely you're not strategic for them. So it's a very unbalanced partnership. Yeah, I've spoken on this podcast a lot about the dangers as a small company of like hitching your wagon towards one big partner, strategic partner. And you know, on the strategic partner side, you could have a partner manager that is giving you a ton of attention, but that's their job, right? And they're doing that for hundreds of partners potentially. And I've just seen so many folks like, you know, really put a lot of time and energy like years worth of time and energy into that relationship. And it doesn't work out for one reason or another through nobody's fault. It just like the momentum dies. And that is like that line on your PNL, if it's like 100% of something, it's very scary, tied to one external company. You know, companies have made entire businesses around that, but I think it's it's a dangerous, it could be a dangerous game. It's a bad, right? If you place everything on one number in the wallet, then you may even or may lose everything, right? If you distribute it, you have more chances to succeed. But I totally hear you. I mean, one of the things is what I always try to teach my clients is, you know, it's nice that you have the relation with the partner manager, but this person, she or he is usually not the person which will execute the partnership. They are the persons who own the relation. But if you want to have a technical integration, you need to get through the product team. If you want to have, you know, promote this integration, you need to get through to the marketing folks or to the sales folks or the CS folks who can actually talk if you, you know, look at hopefully this integration will also generate some needs at one day. You know, the parliament will not give you leads because this person is not customer-facing. And that's where this whole or very often dies. Yes, there's a question. Like, if you're working with your partner manager, you're working with a partner manager at a really large company and you want to do that multi-pronged approach that you just described, like sales, marketing, product, maybe engineering, like who knows customer support. How do you do that? Like, what's a way to, and I think caveat, I'm not expecting like a handbook, because I think it's very different in every org. But like, what have you seen folks do to be successful in getting kind of those inroads into all these different teams? It depends a bit on the size of your own company and your own role. What I would, or I didn't, with my teams in the past was whenever I had people like who helped me and became like the parliamentors on my team, I'd always challenge them, ask them, and force them to, you know, if they do QBRs, or if that's Q quarterly business reviews, or same equality, whatever. But I said, look, the QBRs are not you and your partner manager. This are the months these weeklies. The QBR needs to have the strategic alignment component in there. So you need to make sure that you bring at least your plus one, like me, or maybe even our like next step, like this, the founder or C level, you know, especially if you're a smaller startup, you probably need to bring in your founder to get attention on the other side. But then also required from the other side, that's not just, not just respect to the person, but not just the parliament manager, but her or his boss. Or maybe, you know, as high up in the hierarchy as you can responsibly ask them to bring into the QBR. And for me, the QBR is not about reviewing the last three months. It's like, you know, it's maybe 15% 20% reviewing what he did in the past, but eight percent should like, oh, what we're doing the next three, six, nine, 12 months. And it should always start as are we still strategically aligned? Is this partnership still paying into your business goals, the partner? Because if the partnership with us is not paying into their business goals directly, they will not prioritize it. We can have all the one and done and we can all have the nice shit chats and we can all have this wonderful relation. But ultimately, if we don't contribute with our partnership into their goals, we will not be relevant for that. Yeah, I 100% agree. And I think the way that I've tried to approach this in my own career is always with like a give. Like, you know, I think if you can get some people in the QBR, that's incredible. Like, do it. But also like marketing as an example, like marketing teams, everyone's trying to make content all the time, do events, whatever. And to your point, I don't think like a dinner is enough. But to be like, Hey, like, we'd love to write a blog post for you. Like, what can we, like, what can we as a company do to help you human individual? Is sometimes an easier task than like, let's meet. Like, I don't want to meet with you. Why do I want to meet with you? But it's like, Hey, I have an idea of a thing that I'm going to give to you that you can then use to make yourself look better. That always helps. And I my own personal, like, soft spot is always for customer support. I feel like they see X teams like really no boots on the ground. Like, what's actually happening? And I'm always trying to like get our team to like align the CX people at our customers. If they are the ones that are supporting integrations, like, Hey, you know, the product manager, the head of product might say everything's great. But the real rumblings under the hood or that like, Oh, you know, this thing wasn't working or it doesn't do well. We need that whatever it is. Like, and those folks, I think oftentimes, and I hope this changes, but I always get a sense that CS is sort of like overlooked. It's like their job to get you that. So like, it's like, who cares? But I, you know, I feel like they don't get a lot of attention. So when you can be like, Hey, I actually care about like your experience and your customers experience. Like, how can we work together to make things better for you? That always is helpful and can give a lot of a lot of strategic insight that you might not get from like a business person, you know, absolutely. You know, I couldn't agree more. I wanted to double down on two things you said. Like number one, I always, you know, also recommend try not to don't try to connect with the sales people of the other company because, you know, they have a very narrow focus and everything you do, I'm just a distraction. So they are less likely to, usually less likely to, to respond surface between the beginning. So I always point the people to the CS team just for the same reasons you said. They know they have much more deeper relation with the public customers. They much more regularly here, the pains and the the wishes and the the challenges they are facing. They are much more positioned to even mention the integration. Like, Oh, if this is a problem, do you even know that we have this other partner who could help you fix this? Because now sales thread will do that on us. It will have them to close the deal in the first place. So 100% aligned here where I'm not 100% aligned is this gift thing. I think that's a bit toxic. You know, when I hear this from Kass of Rana folks, they we have the saying, right, it's you have to give to get. You have to give to get. And I was like, yeah, and I used that phrase a lot myself. And then I was like, wait, why? If we agree that there's a collaborative relationship, I know, both should be as hopefully equally committed and interested in this partnership. Actually, you know, you would need to want to give me first what I would try to give you first. It's like me and you and being in a restaurant and I say, I pick the building, they say, no, I pick the bullet. You know, this kind of thing. So this dynamic should happen. So what I see a lot of companies struggling with partnerships, they say, oh, we need to give first. Oh, we can't expect getting anything. We need to give them something. And then they end up giving giving giving and then you have something which is like 80 20, right? And then, you know, if you give 80% to get 20% back, you know, what you're in toxic relation. And what you do in a toxic relation, you walk away from it because it's toxic. And I can't remember the name, but there was a very experienced partnership leader. She said like VPSVP partnerships some years ago on the training, she said 51 49, 51 49 is enough. We give 51 to get 49 back if it's 80 20, walk away. So well, I feel like this is a very natural motion for us, partnership folks to think we need to give first. I would challenge everybody to think is it really needed? And if you give how much do you give to before you really expect getting something back? Totally fair. And I agree with you. I think it's a good like point of clarification. Like in my mind, what I think about, hey, we're going to like write a blog post for your blog. Like what you as a company get out of that is like a giant audience hopefully from being on the HubSpot blog or you know, whatever it is. I agree with you. I've definitely seen, I think it goes back to that like being the little fish and a strategic relationship. Like if you're just constantly chasing and like investing a ton of money and having a ton of meetings and like flying out and like all this stuff. And there's no reciprocity like that that can feel like it can feel like strategic momentum when it's not right? If you're not getting any skin in the game back from that. And I think there is like a natural power dynamic and almost every partnership that there is a larger company and they might not even be like more employees, but they have something that the other company wants, which is typically like a large customer base or access to data or something like that in a technology partnership. And it can be easy to your point to like be the 80% and not the and not be on the receiving end of that. I do think it's an interesting thing and I don't know if in your background you've experienced this when you have two large companies that are trying to like build these relationships. We work with some really large companies and like it's always fun to watch like if you've got two big fish like who's going to do the thing? Like who's going to cave but like who's going to you know in our world it's like who's going to build the integration who's going to support it? Who's going to pay for it? And like no one wants to do it. And some eventually somebody just says we just need to get like it's been three years. We just need to do it and like fight the bullet. But I don't actually have a good room for that. When it's like two publicly traded companies that are massive and they like, they know their strategic value, but like nobody wants to make the commitment. I don't know if you have a war story around that. I see it all the time. For me, it was always when Venna Venna came into, I mean, I never wrote for these huge companies, but Venna was a similar situation was, you know, basically scaling it down to when the other company was about the same size. I was not the clear bigger fish. Yeah. Yeah. And basically both said, like we think these, we agree it would be great to have that. And then everybody went, you know, in the earlier days, it was a question like who is an API and who's not? And then they said clearly the other one had to develop against the other ones API, but then it was times very evolving API as we can more standard to it. Service-based architecture or service-oriented architecture. So everybody could make things stuff available on API. So it was like, well, we have an API, you can develop again. Well, we have also an API, you can also. And it was like, okay, and the thing at one point which we solved, it was like, well, you know, one develops, the other pays 50% non-recurring engineering costs. So basically splitting the bill. That was then the pragmatic one. Well, you know, because it was also, you know, a resource constraint. And at one point of view, you didn't say, look, if you don't want to develop it and we can't, well, don't want it's like, you don't have the capacity on your engineering team or on the roadmap to develop it. And we don't have it. Well, you know, then we both put 5K in and we hire an external developer who's literally developing this for us and we shared the IP on it. And that was literally a solution we did not only once where we had this kind of, wasn't like not, it wasn't even that nobody wanted us literally the resource constraints on both ends. Yeah, we've seen folks be successful with that too, where it's like, hey, we're going to split the bill or, you know, this company is going to build it, but then this company is going to pay like a higher rev share. Like, there's all kinds of ways to do it. I think it is, when it's like two smaller companies and by smaller, I mean, like not publicly traded, not massive, right? Like there's, there's like, can human element to your point where it's like, all right, like, how can we figure this out? The big giant ones, it's always fun when you see like an Oracle and it's just, you know, and like from here at Pantheum selfishly, like we're looking at the tech side and we're always, I'm always like, it's, this is not a technical problem. Like the like the API is to your point, the API's exist these days. Like, there's ways to do this. It's like, what do you guys want to do as a, as a true partner and hopefully a long-term relationship? Because once those connections are made, especially if you're an enterprise product and your customer's stick with you for five plus years, like you're really in bed with them at that point with this other company, right? So it's like, you want to be, want to be a good partner, but also kind of play this dance. At the end of the day, the building of the integration is usually like such a small part of this whole bigger, this whole bigger sort of exercise. Great. So that's maybe, we'd like to talk about the power dynamics a little bit. Since you've been around the block, folks that listen to this love to hear again, sort of like the battle stories of what you've seen. So what do you think are the most common failure patterns that you see companies make when they are building their partnership program or trying to recruit new partners? What advice would you give and what do you see folks do poorly consistently? I mean, focusing on that. So I have to make this disclaimer, working on both sides on technology integration partnerships as well as the basically core channel, which is, you know, reseller for all that stuff. But one thing which is always the same is that people start partnerships or the order to start partnerships from the leadership team or someone from the leadership team, is either one, it comes from only like a small part of the leadership team. So somebody says, let's do this, but it's not aligned with the other teams. And then you kind of work in the silo and actually the company is not even aware. And the one thing about partnerships is always touches all teams sooner later. The second thing is even if it comes from a broader leadership, the why do we do this is totally unclear. On integration, sometimes it's, yeah, let's do this. And I've been in places like in 2020, when was it in 2024? I think I was in San Francisco to conference cloud software, cloud software association very much around technology integration partnerships. And I was like, oh, amazing. And then it was about the time when Silicon Valley bang went south. So a lot of partnership people at that point lost their jobs literally, but specifically also in these tech partnership space. And I spoke with some there and it's like, well, you know, I can't even imagine the use case. Why did you even build this? I mean, why did you as a startup even integrate into Salesforce or Adobe or whatnot? What is the use case? And they were like, oh, there's no one. I said, why did you build it if there's not in the use case behind it? And then I said, because the investor wanted it. It was like a brand logo on the investor slide tag. Like, you know, we integrated with ABC. I was like, you have learned the hard way that investors are not always the smartest people on the block. And don't know disrespect. I mean, they are smart in some areas. But too often, they doesn't seem to even bother to understand what the product is actually about. They just look at their KPIs, CLTV to cut ratio, payback period, these AR grows and compound grows blah, blah. And then they just invest, but they do not understand the product. And then they say, oh, why don't we integrate with Salesforce? I saw these other guys have integrated with Salesforce. Shouldn't we also? And then the bot goes like, oh, the fun is going like, oh, okay. So that was kind of this stuff, which I saw and which I think it's crazy. But this is built. Also, I've been on the other side, like, you know, when I was meeting on this conference, direct serial director, are responsible for more of a public least company. And he was like, oh, we have 161650 apps in our app store, or integration or app. So I was like, okay, how many of them are active? How many are actually used? And that was just a vanity number, right? I mean, he could brag about this and it looked good on their marketing side. But I want to like, how many of these 1600, probably 1400 have been wasting their time, effort and hopes on it. And I don't know if they expectation setting when these people, these 1400 companies decided to build this integration, that was even clear. And maybe a lot of them hope that they get business out of that. And I think they will be totally disappointed. Yeah, and it's wild to me also to your first anecdote there about like building the Salesforce integration. Like going into that blind is so much work. Like, building into these like larger companies is oftentimes like not a single thread type thing. Like, there's, you know, they have rigorous requirements for approval. And like, you should definitely do it if there's a need. But like, that just feels like such a huge amount of work for like, not any value. And to your point about the, you know, 1600 apps, I wonder if that person even knows how many of those are being used. Like a lot of times when these larger companies started, companies that are larger now, you know, when they started these apico systems 10 years ago or whatever, they didn't instrument around like tracking or visibility into any installs even. And like, sure, maybe you have an OAuth 2 apps, you hypothetically could figure out who's using it. But like, a lot of these larger companies have to do some very crazy database work to figure out like, is that app even being used by anybody today on their own side? And like, that is obviously a huge mess. Like, I would be curious. Some companies have done a great job of like, keeping up with it. But again, like, the integration stuff so often from the tech perspective is like the cast off. It's like, yeah, just build to our API. And then all of a sudden, you've got a thousand companies doing that. And it's like, oh, who's actually using it? And why? Like, what's happening? Or somebody is, you know, beating the heck out of your API for some reason? You're like, who is it? I have no idea. Yeah. That's crazy. I mean, but there's, I think comes back to the one thing I said when in the beginning that partnerships are often understood or measured like, because they, the partnership falls report into people who have more sales background. So they look at partnerships on a transactional one on sales, you know, closed deal of, a signed deal is the best one. But then in partnership, they say, probably the person have been measured on not active or used integration, just on sheer number of integration. So the more the merrier, right? Instead of making sure that these things are actually working or are meaningful and used by the clients, even, you know, with one of my clients I'm working with who, again, I also had this kind of things I said, like, well, have you, have we, do we have transparency on, you know, which apps or integrations are actually used? And so they didn't. And we started to try to dig deeper into it. And good news is by now they have it because they understood why they should care for it. And now that is even a core of their data warehouse so that can actually monitor which apps are growing, shrinking are actively used are tested and de-installed because there's a lot of, as you say, there's so much value and understanding. what is used by our customers, what is valued by our customers. And now with this, and I know that's also topic you've been vocal about with AI stuff coming up. There might be some of these, especially like add-on apps which might have been a great value in the past three years. But they might just be dying because they are literally replaced by some agente.ai coming up and I'm not a big fan of it, but there are use cases where agente.ai can easily replace what used to be a nice plugin. 100%. Especially when it's like these kind of discrete workflow related things like there's a ton of opportunity there for, you know, applications that are really features to be turned into something agente potentially. I think we're coming up on time. I could talk to you forever. But with that in mind, maybe in parting in this year of our Lord 2026 with the AI and the MCP and all the things, do you have any piece of advice for partner managers out there for the rest of this year and looking into next year? Wow, where's my crystal globe? Tell us about the future. I think I would absolutely double down what you said in the beginning as into that partnership, I've been growing and becoming more relevant and are keeping becoming more relevant. I think I personally believe there's a huge hype around especially on the tech side of things about MCP and all that stuff. I think people do underestimate the requirement of maintenance and, you know, when my bubble people say, oh, if you just wipe code stuff or I can't do this, I build my own stuff and, you know, I just connected this and blah, blah, blah. And that's all nice and fine when you are like me a sole partner and you do it for yourself. But assuming that even midsize companies would invest, invest that their limited resources in rebuilding stuff, which is, you know, even if they could do it, I mean, you know, they don't have the time to run it and maintain it and so on and so on. So I guess my long words mean don't panic about MCP cooling your jobs or whatnot. I think there is, there's a way where we as software companies can develop more efficiently. But that doesn't mean that, you know, everyone will become their own software developing solutions. So, don't panic. It's just a hype. It will die. It's already dying in my opinion on a couple of things. I'm not so deep into it on the tech side because I'm not a developer but on the product sales marketing side. You see AI re-audrage is dying because nobody wants to get type of personalized spam. You know, arguments that there was this time when everybody came that drop interviews will be done by Avatras or SDR drop will be done by Avatras. Come on. If you don't take the time to talk to me when I apply for a job, is a company, why would I care for your company if you don't even care for me? Same goes to outreach. I guess the best proof is if you see this, the job adds for an ontropic for SDRs and SDR leadership. Apparently the company is building that AI doesn't trust the AI to replace these jobs. So, yeah, I guess that's my very long answer. I feel like you and I could have a whole conversation about this. And you and I were old enough to remember when we were migrating everyone from homemade custom software to SaaS. We've seen this movie before when we were coming from on-prem stuff that everyone had built and there's still a ton of it. But there's a reason that the entire software and technology industry got away from all the homegrown stuff that's really specific to you. And now we're going back into that cycle. It took 20 years, but it'll be interesting to continue to watch. I agree with you. I think we are at time. This has been so fun. When you make it to New York, you have to let me know so that we can meet in person. I don't think I'm going to be out your way anytime soon. But if I am, I definitely will let you know. We really appreciate you taking the time to hang out with us. We'll drop your LinkedIn when we post this. And to our listeners, if you guys are interested in more content, even more content about APIs, integrations, partnerships, building SaaS platform, security, some AI stuff, some spicy stuff, check out our website, pinup.com. We've got blogs, we've got e-books, we've got all the things. We have all these episodes. And yeah, Martin, it's been absolutely great. I hope you enjoy the rest of your evening. And I'm sure we will see you out there. I'm looking forward to it. Thanks for having me. Have a great day for ahead of you. Thanks. Thanks for listening. If you enjoyed our content, subscribe to our channel and give us a thumbs up. For more content on tech partnerships, integrations and APIs, check out our articles, e-books and other resources in the description or visit Pandiam's website.

Podcast Summary

Key Points:

  1. Martin Sholes defines a valuable partnership as two businesses teaming up to achieve a mutual goal, emphasizing collaboration over transactionality, with a "one plus one equals three" effect.
  2. Identifying the right partner involves focusing on the ideal customer profile (ICP) and common use cases, rather than large, inflexible key accounts that may not be scalable or repeatable.
  3. Technical integration (connecting APIs) differs from strategic partnerships (connecting people); strategic partnerships should be reserved for those critical to business success, as seen in P&L impact, not just high-profile names.
  4. Building multi-pronged relationships within a partner’s organization requires engaging teams beyond the partner manager (e.g., product, marketing, CS), using quarterly business reviews (QBRs) to ensure strategic alignment.
  5. The "give first" approach can be toxic if unbalanced; healthy partnerships aim for a 51/49 give-get ratio, and if it becomes 80/20, it's better to walk away.

Summary:

In this podcast episode, Martin Sholes, a veteran with over 20 years in B2B partnerships, shares insights on defining and building valuable partnerships. He distinguishes between transactional deals and true collaborations, where two businesses align on a mutual goal to create shared value. Sholes advises against prioritizing large, inflexible customers for integration pilots, instead recommending a focus on the ideal customer profile and common use cases to ensure scalability.

He also clarifies the difference between technical integrations (API connections) and strategic partnerships (people connections), reserving the term "strategic" for partnerships that directly impact a company’s bottom line. To succeed, he stresses engaging multiple teams within a partner organization—such as customer success and marketing—through structured QBRs, rather than relying solely on a partner manager. Sholes warns against the common "give first" mentality, advocating for a balanced 51/49 give-get ratio to avoid toxic, one-sided relationships.

He notes that in partnerships between large companies, a power struggle often occurs, requiring patience and strategic alignment to move forward. Overall, Sholes encourages a collaborative, goal-oriented approach to partnerships, where both parties contribute equally and prioritize mutual success.

FAQs

A real valuable partnership is when two businesses team up to achieve a mutual goal that both benefit from, often centered around a mutual customer. It's collaborative, not transactional, and should create a 'one plus one equals three' effect.

A technical integration is a connection of APIs, while a partnership is a connection of people. A strategic partnership is reserved for those critical to your business success, directly impacting your P&L, regardless of the partner's size.

Focus on your ideal customer profile (ICP) and common use cases, not just large high-value customers. Large corporates may be inflexible and require custom solutions that aren't scalable or repeatable for your broader customer base.

Involve senior leadership in quarterly business reviews (QBRs) to ensure strategic alignment, and engage teams like customer support, which have deeper customer insights, rather than just sales. Offer value, such as content or support, to foster collaboration.

Putting all your efforts on one partner is dangerous because if the partnership fails, you could lose everything. It's better to distribute partnerships to increase chances of success.

Aim for a 51-49 balance in contributions; if it becomes 80-20, the relationship is toxic and you should walk away. Don't assume you always have to give first, as both parties should be equally committed.

Chat with AI

Loading...

Pro features

Go deeper with this episode

Unlock creator-grade tools that turn any transcript into show notes and subtitle files.