Beyond Handshakes: How to Structure Partner Programs for Success
Between Product and Partnerships · 2026-05-28 · 35 min
Substance score
44 / 100
Five dimensions, 20 points each
What our scoring noted
Our reviewer’s read on each dimension, with quotes from the episode.
Insight Density
The episode contains a handful of genuinely useful operational points - the 80/20 QBR structure, the 51/49 toxicity threshold, and the vanity-metrics trap in app stores - but these are surrounded by extended agreement loops, anecdote wind-ups, and generic platitudes that significantly dilute the insight-per-minute ratio.
the QBR is not about reviewing the last three months. It's like, you know, it's maybe 15%, 20% reviewing what you did in the past, but 80% should like, oh, what we're doing the next three, six, nine, 12 months
sales, is transactional. Partnerships is collaborative, uh, which changes a lot of dynamics and a lot of people don't get that
Originality
The pushback on 'give to get' culture and the 51/49 threshold are mildly contrarian and worth noting, but most of the core frameworks - mutual goals, ICP alignment, don't over-index on one large partner - are well-worn partnership orthodoxy recycled without meaningful fresh framing.
51, 49, 5149 is enough. We give 51 to get 49 back. If it's 8020, walk away
integrations are not partnership. Integration is a connection of APIs and partnerships is a connection of people
Guest Caliber
Martin Scholz has genuine 20-plus-year practitioner credentials across multiple in-seat operator roles before becoming an advisor, and his anecdotes feel grounded in real experience; however, he is now a consultant rather than a current operator at scale, and CEG Consult carries no name recognition that signals exceptional access or track record.
I started B2B partnerships about more than 20 years ago
I'm literally just yesterday I come visited one of my clients where we had this journey where they had um, they had a marketplace of 200 something integrations
Specificity & Evidence
A few concrete data points appear - 1,650 apps in an app store, splitting a 5k engineering cost, the SVB collapse as a timeline anchor - but the most illustrative client stories deliberately omit company names, no revenue or pipeline figures are cited, and named examples (Salesforce, HubSpot, AWS) are used only as generic reference points rather than as evidence of outcomes.
we have 1,650 apps in our app store or integration in our app Store
one develops the other partner pays 50% non recurring engineering cost. So basically splitting the bill
Conversational Craft
The host lands one genuinely productive push - drawing out Martin's contrarian take on 'give to get' - but too often spends question time sharing their own extended opinions rather than probing the guest, and the conversation repeatedly collapses into mutual validation rather than productive challenge or follow-up depth.
I a hundred percent agree. And I think the way that I've tried to approach this in my own career
I could talk to you forever
Conversation analysis
Computed from the transcript - who did the talking, and the verbal tics along the way.
Share of words spoken
- Speaker A60%
- Speaker B40%
Filler words
Episode notes
In this episode of Between Product and Partnerships , Cristina Flaschen talks with Martin Scholz , founder of CEG Consult , about why most partnership initiatives miss the mark, and what actually separates transactional deals from true, strategic relationships. Drawing on more than 20 years of partnership experience across startups, scale-ups, and enterprises, Martin cuts through the noise to explain why partnerships fail when they lack clear alignment, why "giving to get" can create toxic dynamics, and how to identify which partners actually deserve your resources. For more insights on partnerships, ecosystems, and integrations, visit
Full transcript
35 minTranscribed and scored by The B2B Podcast Index.
Speaker A: 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.
Speaker B: 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, integrations and SaaS platforms. Uh, today we are, we are so excited to have Martin Scholz from CEG Consult join the podcast. Good morning to us. Good afternoon to you Martin. Uh, tell us a little bit about yourself and your background.
Speaker A: Sure. Um, thanks for having me. Um, I'm excited to be here and uh, across the pod and across the time zones. Um, yeah, as you can probably see on my little beard here, I'm not the youngest anymore, so I'm in Parashes for quite a long time. I always joke that I started 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 um, business development when that was still not the tough job of trying to make a call and book a meeting for your ae, but really developing new areas of business which is entering new markets, whether geographically industry wise or um, customer segments. And 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. And um, I'm doing this, um, in 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 uh, North America, um, built partnerships, diverse partnership types, um, multinationally, internationally for three startups as an in seat operator before then I made this jump into being an advisor taking. So I always say my 20 years of making mistakes, trying to help companies to avoid those we can find new ones. And um, that's what I'm doing today, trying to help B2B SaaS companies making um, partnerships work.
Speaker B: Awesome. Thank you. And 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, um, 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, uh, 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. Um, and you've, I'm sure, seen it all over the last 20 years. Um, so to start off, like, how do you define a real valuable partnership?
Speaker A: Um, that's a very good question. Um, I think one of the things which um, is challenging for us is that we do not have standing definition of what partnerships are. And um, you probably also came across somebody, you know, calling themselves, let's do a partnership and actually they wanted to sell you stuff, um, and. Or sponsorships being called partnerships, even though that's pretty uh, transactional. Um, and I've had the pleasure to do the various kind of partnerships. I think the common denominator for all of that is that um, two businesses um, team up to achieve a mutual goal or they have like one mutual goal which both benefit from. And very often there's um, a mutual customer in the middle around that. I think that's critical. That's one of the main drivers is sales, is transactional. Partnerships is collaborative, uh, which changes a lot of dynamics and a lot of people don't get that and look at partnerships very transactional. You give me this, I give you that. Uh, it's usually not the way that it works. So a true valuable, um, partnership for me is that there is an alignment on a mutual goal and both parties win. And I don't like that too much. But it's literally this cheesy one plus one equals three thing.
Speaker B: That is a line I have heard a lot in this space. Um, I'm curious how in your experience, how companies should potentially identify who that shared kind of partner is. Or, uh, not partner, sorry, the shared customer is. Um, and 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, ah, that's who we need to use. But I'm wondering if you how you think about that, because that in my experience, your largest, most like high touch, high value customer might not be the one you want to be piloting stuff with all the time. But I'm just curious how you feel about it, what you've seen.
Speaker A: Um, yeah, I absolutely know where you're coming from. Um, this is a couple of thoughts here. Number one, um, the big one huge customer is probably a big corporate which is probably not very flexible, responsive and agile. And these are things you probably want to have. If you think about what could a product integration look like, um, there might be too much hassle with the um, stakeholders and at the same time you might find yourself in a situation where they come with big, very specific, very custom requirements. So it might fit um, they might give you um, a description which absolutely fits um, their need but it's not repeatable, not scalable for any of your um, other customers. And then basically you build an integration which is not reusable and you don't have this idle, you want to anything which should be scalable. So it should be scalable, repeatable, usable and then you have this very, oh, this is tailor made for this huge, big elephant. But my majority of the customer wouldn't work. So who I would probably look at is you know, really discussing about who's your icp. And M, very often this, this massive key account is not literally your ICP because it's like this super cool ah, brand you have but not the one where you have 20 or 30 or 50 or 80 um, clients of. So I would look at the ICP and the common use cases they share.
Speaker B: I agree. Um, I do also think there's some vibes based stuff there like who is your customer that is a big user of your product but also a champion, a good partner to you. Um, they'll be a lot in my experience, more number one, excited to be working on something with you as a design partner and also tolerant of the sort of rough edges that can come out of this stuff. Uh, but that dovetails 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 maybe when companies should look at one versus another?
Speaker A: That's a very good question. Um, I have to quote a good friend of mine, Justin Zimmerman, who was uh, a guy who I heard from who said integrations are not partnership. Integration is a connection of APIs and partnerships is a connection of people. And I think that nails it quite a bit. So I can have wonderful technical integration with um, huge companies. Right? I can have an integration to Google API or HubSpot or even go to the AWS marketplace whatnot. Um, 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 startup 1715 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 uh, what you're doing. So um, the partnership layer would be then that you literally m manage having a business driven conversation. So I'm literally just yesterday I come visited one of my clients where we had this journey where they had um, they had a marketplace of 200 something integrations which are critical uh, for their core product to function and it's does really increase the value of the thing. Uh, and they were focused on the technical quality of these integrations. Um, but then I said why don't you have partnerships with them? Why don't you have a meaningful business conversation uh, with them, how to market um, that integration and the value you create for them. Um, last but not least, strategic. I dislike this term a lot because it's used inflationary. Um, oh it's a strategic partnership, um, which is for me, um, this is a quality criteria. Um, and I would reserve this or I did reserve resolve that's in my history for or does resolve that for partnerships which are so critical for your business success that you do see it in your P and L, in your revenue or ah, top line or bottom line result. Whether or not you would have this. So that's. And whether or not this other partner is large or small is not necessarily relevant. It's just like how big is the 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? This partnership might be strategic for you but most likely you're uh, not strategic for them. So it's a very unbalanced partnership.
Speaker B: Yeah, I've spoken on this podcast a lot about the dangers as a small company of like hitching your wagon to one big partner, strategic partner. And you know, uh, 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 P and L, if it's like 100% of something is very scary tied to one external company. Um, you know, companies have made entire businesses around that. But I think it's a dangerous, it could be a dangerous game.
Speaker A: It's a bet, right? If you place everything on one number in roulette, then you may win or may lose everything, right? If you distribute it, you have more chances um, to succeed. But I totally hear you. I mean one of the things is, what I always try to teach my clients is it's nice that you have the relation of 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 um, 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 look at, hopefully this integration will also generate some leads at one day. Um, the parliamentary will not give you leads because this person is not customer facing. And um, that's where this whole very often. Diesel.
Speaker B: Yeah. So there's a question like if you're working with, you're a partner manager or 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?
Speaker A: Um, it depends a bit um, on the size of your own company and your own role. What I would or uh, did with my teams in the past was whenever I had people like who helped me and became like the partner managers on my team, I'd always challenged them, asked them and force them to, you know, if they do QBRs or whether that's quarterly business reviews or semi quarterly, whatever. But I said look, the QBR is not you and your partner manager. These are ah, 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 level 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 require from the other side. That's not just no disrespect to the person, but not just the partner manager, but her or his boss or maybe you know, as 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 you did in the past, but 80% 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, dear 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 wine and dine and we can all have the nice chitchats 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.
Speaker B: Yeah, I a hundred percent agree. And I think the way that I've tried to approach this in my own career is always with like a give. Like it, uh, you know, I think if you can get some people on 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. To help you? Human individual is sometimes an easier task than like, let's meet. Like, it was 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. Um, that always helps. And I. My own personal like soft spot is always for customer support. Um, I feel like they CX 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 or 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 what we need, 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 yelled at. So like, it's like, who cares? But I, you know, I feel like they don't get a lot of attention. So when, 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 um, a lot of strategic insight that you might not get from like a biz dev person, you know.
Speaker A: Absolutely. No, I couldn't agree more. I, I want to double down on two things you said. Like number one, I always, um, you know, also recommend, try not to, don't try to connect with the salespeople of the other company because you know, they have a very narrow focus and everything you do ask them is distraction. So they are less likely to, usually less likely to responsive, especially in 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 customers. They much more uh, regularly here the pains and um, the wishes and um, 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? Uh, because no sales rep will do that unless it will help them to close the deal in the first place. Um, so 100% aligned here, where I'm not 100% aligned is this gift thing. Um, I think that's a bit toxic. Um, when I hear this from partner folks, we have the saying, 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 it's a collaborative relationship, both should be as hopefully equally committed and interested in this partnership. Actually, you would need to want to give me first, while I would try to give you first. It's like me and you and being in a restaurant and I say, I picked the bill and you say, no, I picked the boy. This kind of thing. So this dynamic should happen. So what I see a lot of companies, um, 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. Um, and then 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, um, I can't remember the name, but there was a, uh, very experienced partnership leader. She said, like, VPSVP partnerships, um, some years ago in the training, she said, 51, 49, 5149 is enough. We give 51 to get 49 back. If it's 8020, walk away. Um, so while 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, um, if you give, how much do you give to before you really expect getting something back?
Speaker B: Totally fair. Um, and I agree with you. I think it's a good point of clarification in my mind when I think about, hey, we're gonna, like, write a blog post for your blog. 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 in 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 in almost every partnership that there is a, um, 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. Um, 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. Um, 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 and, like, who's going to cave? 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 bite the bullet. But I don't actually have a good rubric 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. Uh, I don't know if you have a war story around that. I see it all the time.
Speaker A: Um, uh, for me it was always when, when, when I came into, I mean I never worked for these huge companies but when I was a similar situation was basically scaling it down to um, when the other company was about the same size, there was not the clear bigger fish. Right. And basically both said like 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 has an API and who's not? And then the other one had to develop against the other one's API. But then was times very evolving APIs became more standard. You had um, service based architecture, um, or service architecture. So everybody could make things, stuff available on APIs. So it wasn't like well we have an API you can develop again. Well we have also an API you can also. And I was like okay. And the thing uh, at one point which we solved it was like well you know, um, one develops the other partner pays 50% non recurring engineering cost. So basically splitting the bill. Um, uh, that was then the pragmatic one. Well you know, if, because it was also you know, a resource constraint. And at one point we even said 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 share the IP on it. And that was literally a solution. We did um, not only once, uh, where we had this kind of. It wasn't like, not, not, it wasn't even that nobody wanted was literally the resource constraints on both ends.
Speaker B: Yeah, we've seen folks be successful with that too. Where it's like hey, we're gonna split the bill or you know, this company's gonna build it. But then this company's gonna pay like a higher rev share or 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 a, there's like inhuman 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.
Speaker A: It's a political company.
Speaker B: Yeah, yeah, yeah, yeah. It's just, it's you know, and like from here at Pan dm, 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 that. Like the APIs, to your point, the APIs 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 customers 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're going to be, want to be a good partner but also kind of play this dance, um, at like the, at the end of the day, the building of the integration is usually like such a small part of this whole bigger, this uh, whole bigger sort of exercise.
Speaker A: Agreed.
Speaker B: So let's maybe we talked about the power dynamics a little bit. Um, 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? Um, do poorly consistently.
Speaker A: I mean, focusing on that. Um, so I have to make this disclaimer. I'm working on both sides on technology integration, partnerships, um, as well as what you basically call channel, which is reseller, referral and all that stuff. Um, but one thing which is always the same is that people start partners or the order to start partnerships from the leadership team or someone from the leadership. 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 a silo and actually the company's not even aware. And um, the one thing about partnerships is it always touches all teams sooner or later. Um, the second thing is, even if it comes from a broader leadership, uh, the why do we do this? Is totally unclear. Um, on integration, sometimes it's yeah, let's do this. And um, I've been in places like in 2020, what was it, 2024, I think I was in San Francisco to a conference, Cloud Software association, very much around, um, technology integration partnerships. And I was like, oh, amazing. And then it was about the time when Silicon Valley bank 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 someone 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, uh, 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 an a use case behind it? And then also because the investor wanted it. It was a, like an um, a brand, a logo on the investor slide deck. 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. Geez, um, AR growth and compound growth, blah 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, um, the funnels go like, um, okay. So that was kind of this stuff which I saw and um, which I think it's crazy, um, that this is built. Um, I also have on the other side, like um, when I was meeting um, on this conference, direct, uh, senior director are responsible for a lot more of a public company. And he was like, oh, we have 1,650 apps in our app store or integration in our app Store. And 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 wondered 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 expectations 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 uh, I think they will be terribly disappointed.
Speaker B: 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, 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 uh, when these larger companies started, companies that are larger now, you know, when they started these app ecosystems 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 uh, 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 uh, 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.
Speaker A: That's crazy, isn't it? I mean but that I think comes back to the one thing I said in the beginning that uh, partnerships are often understood or measured like uh, because the partnership faults report into people who have more sales background. So they look at partnerships on a transactional one on sales, you know, closed deal or signed deal is the best one. But then in partnership they say probably there the person has 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, uh, and used by the clients even you know, with one of my clients I'm working with who also had this kind of um, things I said like well have you, have you, do we have transparency on you know, which apps or integrations are actually used? And um, 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 um, data warehouse. So they can actually monitor which um, apps are growing, uh, shrinking, are actively used, are tested and deinstalled because there's a lot of as you say, there's so much value in understanding what is used by your customers, what is valued by your customers. And now with this, and I know that's also a topic you've been vocal about with AI stuff coming up, um, there might be some of these um, 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, by some um, agentic AI coming up. And I'm not a big fan of it, but there are use cases where agentic AI can easily replace what used to be a nice plugin 100%.
Speaker B: Um, especially when it's like these kind of discrete workflow related things. There's a ton of opportunity there for um, applications that are really features to be turned into something agentic potentially. I, um, think we're coming up on time. I could talk to you forever. But with that in mind, maybe in parting um, 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?
Speaker A: Wow, where's my crystal globe? Um, tell us about the future, come on. Um, I think um, I would absolutely double down what you said in the beginning as intro, that partnerships have been growing and becoming more relevant and ah, are keeping um, 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 um, you know in my bubble people say oh, if you just wipe code stuff or I cancel this, I built my own stuff and you know, I just connected this and blah blah blah and that's all nice and uh, fine when you are like me, a solopreneur and you do it for yourself. But um, assuming that even mid sized companies would waste or invest Waste that their limited resources in rebuilding stuff, which is, uh, you know, if they could do it, I mean, you know, then 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 killing your jobs or whatnot. I think there is, um, there's a way where we as software companies can um, develop more efficiently. But that doesn't mean that, you know, everyone will become their own software developing solutions. So, um, don't panic. It's just a hype. It will die. It's already dying in my opinion on a couple of things. Um, I'm not so deep into it on the tech side because I'm not a developer. But on the product, um, sales marketing side, you see, AI re outreach is dying because nobody wants to get hyper personalized spam. Um, you know, arguments that, um, there was this time when everybody claimed that job interviews will be done by avatars or SDR job will be done by avatars. 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 outreach. Um, I guess the best proof is if you see this, um, the job ads for anthropic for uh, SDRs and SDR leadership. Apparently the company's building that AI doesn't trust the AI to replace these jobs. So, um, yeah, I guess that's my very long answer.
Speaker B: I feel like you and I could have a whole conversation about this. Um, and you know, you and I, we're old enough to remember when we were migrating everyone from homemade custom software to SaaS, right. Like we've seen this movie before when we were, you know, when it was coming from on prem stuff that everyone had built. And there's still a ton of it, right? But like, 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 like going back into that cycle. It took 20 years, but, um, it'll be interesting to continue to watch. I agree with everything you said. Um, cool. I think we are at time. This has been so fun. Um, 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, um, I definitely will let you know. Uh, we really appreciate you taking the time to hang out with us. We'll drop your LinkedIn when we um, 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, platforms to get security, some AI stuff, some spicy stuff, check um, out our website, pandub.com, we've got blogs, we've got ebooks, we 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.
Speaker A: I'm looking forward to it. Thanks for having me. Have a great day ahead of you.
Speaker B: Thanks.
Speaker A: 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, ebooks and other resources in the description or visit Pandium's website.
More from Between Product and Partnerships
All episodes →- The Vibe Coding Phenomenon: What Happens When Everyone Becomes a Developer?64 / 100
- Why Partnerships Fail (and How to Fix Them): Insights from Jenn Steele, SoundGTM69 / 100
- Why AI Doesn’t Replace Product Thinking: Insights from Stephanie Neill, Stripe
- How to Build Integrations with Platforms Bigger Than You Without Getting Stuck at the Bottom of the Queue
- No-Code vs Code First: Why Visual Builders Often Lead to Integration Dead Ends