Welcome back to our three-part series with Allan Adler of Digital Bridge Partners! Allan re-joins Avanish for another great episode on making sense of monetizing tech partner ecosystems.
In Part Two, Avanish and Allan discuss:
Guest: Allan Adler, Managing Partner, Digital Bridge Partners
Allan Adler is a world-class advisor, consultant, and change agent. As Managing Partner at Digital Bridge Partners, he helps individuals, managers, and executives understand and leverage partnership best practices in business and society. He is the creator of the GoToEcosystem Framework and has worked with a wide range of organizations to unlock their full ecosystem potential. Allan is Chair of the Ecosystem Counsel at PartnerHacker and an Executive Member of Partnership Leaders. Previously, Allan founded and ran MSI Consulting Group; a 100-person sales and marketing strategy firm focused on the tech industry and worked as a consultant with The Boston Consulting Group. He received his MBA from Harvard Graduate School of Business, where he was honored as a Baker Scholar. Allan is a CPA and serves on several for-profit and not-for-profit boards.
Host: Avanish Sahai
Avanish Sahai is a Tidemark Fellow and has served as a Board Member of Hubspot since April 2018 and of Birdie.ai since April 2022. Previously, Avanish served as the vice president, ISV and Apps partner ecosystem of Google from 2019 until 2021. From 2016 to 2019, he served as the global vice president, ISV and Technology alliances at ServiceNow. From 2014 to 2015, he was the senior vice president and chief product officer at Demandbase. Prior to Demandbase, Avanish built and led the Appexchange platform ecosystem team at Salesforce, and was an executive at Oracle and McKinsey & Company, as well as various early-to-mid stage startups in Silicon Valley.
About Tidemark
Tidemark is a venture capital firm, foundation, and community built to serve category-leading technology companies as they scale. Tidemark was founded in 2021 by David Yuan, who has been investing, advising, and building technology companies for over 20 years. Learn more at www.tidemarkcap.com.
Links
Avanish. Hello, everyone. Welcome to another edition of The Platform Journey. I’m delighted to once again be joined by my friend Allan Adler, managing partner of Digital Bridge. Part one was about contextualizing a series of three episodes all about how you monetize tech partner ecosystems. That episode shared some pretty important insights about the strategic imperative, some of the challenges, etc., mainly focusing on the “why” of tech partner ecosystems, particularly the monetization aspect.
Today, Allan, we’re going to talk a bit more about the “what”. What does it actually mean? What are some models to make some money off the technology partners? Welcome back.
Allan: Yes. Super excited to be with you, Avanish. Thanks again.
Avanish: First off, what have you seen? You’ve been working with a variety of clients and engagements. What do you see as some of the models that are out there to monetize tech partners? Once you’re done, I’ll add some of my thoughts as well, since I’ve also been living in that world for a little bit.
Allan: Absolutely. I think maybe we’ll do a little context setting, because that’s what we’re good at, right? Explaining the big picture. One point of context is that, when you think about a technology program, you could think about it as a program for a vertical market—as if this is a program designed to help the finance vertical market, or the insurance vertical market, or the retail vertical market. Or you could think of it in terms of horizontal programs based on functionality, like ecommerce, sales tech, or mar-tech. Or you could even have it be a program designed around a geography.
Before we get into what’s worked and where it’s worked, we have to start by saying that different go-to-markets are going to have different focus areas. You have to first start by asking, “What are the segments of the market we’re trying to go after?” and “How are we going to go after them?” Then the tech partner program sits on top of that to give you access to the partners in that network.
Avanish: I think that’s a critical point, and well stated. Something that most of us who lived it realize that (1) you cannot peanut butter it, as we say—make it all the same. And (2) frankly, you do have to focus on certain areas where there’s better opportunity and more likelihood of success. Great context setting. Now let’s take it to the next level: what are some best practices or ideas that you’ve seen out there?
Allan: Well, I was thinking about it in terms of models. One model is the taxation model. Say you’re Salesforce. You have a whole bunch of customers, and you’ve got people that have built on your platform. You’re going to say, “I’ll set up a marketplace, and I’ll charge a tax.” That’s what SAP does—they’ll take 20% of your ARR. In exchange for you giving me access to your customer base, you’re going to set up a marketplace and take a percentage of my ARR. Let’s call that the tax model. You see the tax model a lot with SaaS companies.
Another model is the reciprocal model. That says that I’ll give you some of my customer leads if you give me some of yours, so we have something called the reciprocity flywheel, which is all about how to stimulate those outbound and inbound referral processes.
A third model is the mutuality model, like what Snowflake or Databricks does. They say, “If we can get you to consume some data on our platform, we will have our sales reps bring you into our customers.” I might not take a tax [directly], but I will essentially, based on a consumption model that drives sales reps to relieve quota based on consumption. This is what the hyperscalers do. They also have a marketplace where mutuality comes in. In some instances, in the hyperscalers’ tech partner program, a customer can offset 25% of their total spend with hyperscalers, on the ISV solutions that are sold through them.
Those are just three different models: the tax model, the referral model, and the mutuality model. These are different ways of working that in some instances function really well. In some instances, however, they don’t work very well—it all depends on how you execute them.
Avanish: Yeah. Again, I completely agree. I would say, though, those of us in the industry would prefer calling that tax model the revenue-share model. I think there are some negative implications to taxation. And, you know, tongue in cheek aside, there are a lot of questions right now on what the value is of that rev share, and how it can truly be aligned with the value that’s being delivered or not.
You mentioned access. Obviously, access is one thing that large companies, like Salesforce, offer. But with that are those numbers. You know, whatever the number is, 12%, 15%, 20%. That’s a pretty substantial number.
Allan: It is. But it’s also interesting to see, too, that some folks who start with a rev share model abandon it. The hyperscalers, for a while, followed the same script as Salesforce and others by charging the 20%. They eventually figured out that, wait a minute, if I can get that ISV to drive consumption of my pipe, I don’t want to charge a rev share. I want to actually give them all the money back. They keep something like a 3% administrative fee, but they give 97% back to the tech partner, because the tech partner is driving a lot of consumption. And that drives their NRR, the net retained revenue.
All these different commercial models are about figuring out how to add value to the customer and how to grow the pie.
Avanish: Yep. It also has to do with the core economic model of who that platform provider is. Let’s again use Salesforce or even ServiceNow as an example, where they’re usually selling by user. It’s different than someone who’s selling infrastructure and selling by capacity or consumption. I think understanding the root framework or model is pretty critical to understanding how to engage, right?
Allan: Yeah. In fact, I would even go to the next level of saying that most technology companies in the SaaS environment, whether they’re the infrastructure as a service or software as a service, typically have some variation of ARR and NRR. The ARR drives the net new revenue. The NRR is net retained revenue. But those two variables typically drive almost all their business models.
But to your point, the monetization model is quite different in some instances. In some cases it’s based on number of users. In other cases, it’s based on data or CPU capacity. At the end of the day, the CRO and the CFO are trying to find the magic multiplier, the variable that drives the business model. Then tech partners—this is the magic—can make that multiplier significantly bigger or better by rewarding the tech partners and the system for participating in the dance. That’s really what monetization of tech partnerships is all about.
Avanish: A hundred percent. By the way, to that point, on the NRR element, stickiness is the root of success in the SaaS business. For example, at Salesforce, we could show very clearly, through the data, that the minute customers added an additional one or two or three integration partners, or built on force.com partners, their retention went up. Even if they didn’t have seats. They were evolving from just using Salesforce Automation (SFA), to adding to it contract management, or electronic digital signatures, or compensation tracking. Things that were natural complements but that Salesforce didn’t do itself. The retention went up because now you’ve become part of a more complex business process, and therefore much more difficult to replace. I think you’re spot on on that.
Allan: On that in particular, I think that there’s no better financial justification for attempting to monetize tech partnerships than exactly what you mentioned, which is the stickiness factor. In fact, the data we see is consistently doubling and tripling retention rates when the number of integration partners goes north of three, four, five. It’s every single program. And of course, that makes sense, because as soon as the customer has connected four or five technologies to your technology, you’re now an embedded stack. You’re not dispensable anymore. To rip you out means screwing up five or six different data flows, five or six different work processes. That just isn’t going to happen.
The other data point, which is really interesting, is that ProfitWell did a study a couple years back showing that not only do you get more stickiness, but you actually get growth in NRR. Because the integrations produce a need for greater utilization of your product, additional features, more consumption, more users, whatever variable it is. You get not only this magic of lowering churn, you also get the magic of growing NRR. You put those two together? Oh my god, that’s a moment for the CFO to go, “How come we’re not doing that at scale?”
Avanish: Yep. That turning point is a bit magical. Particularly CFOs are very, very resistant to it in the beginning, because they see it as a long-term investment. It’s a lot of cost, and so on. Then when it starts happening, the switch flips. “Why are we not doing more?” Which is cool.
Allan, you’ve studied this space, obviously, and you’ve brought up some examples already. But which ones would you consider successful models? Or maybe not-so-successful models. And give us a bit of that context from your point of view.
Allan: Yeah. To generalize on universal principles of success, we talked last time about prerequisites. These include things like integrations in place, your product team understanding APIs, and published APIs. You’ve committed resources. You’ve got better-together stories. You’ve got use cases. You’ve got customer references.
Once you have those things in place, what you find is that there are some universal success models. One success model that’s fairly universal is that it’s much easier to drive success when either you or the partner has a customer. Let’s take a couple of data points. I mentioned Snowflake and Databricks, just as an example—two companies that are on the consumption side of the market. Just like the hyperscalers are on the CPU, they’re on the data side. When an ISV with whom they’ve integrated drives additional consumption, they see tremendous growth in NRR and net new ARR. But the NRR data points are really phenomenal. Like you take both of these companies, they have an average NRR of about 165%. One has 165, one has 170. Those are really good NRRs.
Avanish: Those are pretty good NRRs.
Allan: And what we’ve learned in studying them is that fully a third of it comes from the ISVs.
Avanish: Really? That I did not know. Wow.
Allan: It’s amazing, if you think about it.
The other thing that you find that’s really interesting is that, as they move from just infrastructure-type ISV relationships to where the ISV embeds their technology inside their stack… that’s where the real magic comes. Then you see all these magical network effects popping up around that embedded experience.
So one ISV decides to build their data stack on Databricks, and then a bunch of other ISVs want access to that data, and now that produces these incredibly expanding consumption windows and envelopes around that original ISV. That’s the kind of stuff where this gets very, very exciting. It’s really the only way to go to market, if you think about it from the standpoint of vertical markets.
I mentioned that’s one of the segments. That’s where it’s really right. I’d say another place where it’s really right is with the hyperscalers. If you look at the growth of their marketplaces, and the growth of the ISVs that have integrated with them – I’m talking Google, Microsoft, AWS. You’re seeing tremendous growth year over year in those marketplaces. Why? Same reason. It’s those ISVs driving consumption of the CPU and causing the annual consumption that the customer has with the hyperscalers to go up and up and up as more of those ISVs are running on the same platform.
You get the stickiness you mentioned before. You get the consumption. And when these events start to happen, they start to be company-making events. These are no longer like, “It’s nice to add this,” because it’s important. These can change the trajectory of an entire company, once you get them right.
But those are relatively mature examples. Many of our clients are only just starting to get the basics right. For example, getting 5 referrals from partners. Then soon five becomes 20, and 20 becomes 50. The examples I gave earlier are companies that are well down the maturity scale, but it’s always good to see a North Star so that you can point to it.
Avanish: To the hyperscalers point, obviously, I was at Google Cloud, and we were going through the beginning of that journey. And I’ll be honest, in the beginning, there was not a lot of belief that this would actually work. Some of us were maybe bigger proponents of it than others.
The reality of it is, what it’s really doing—I think you implied this, and I’ll just call it out—it makes it easy for the customer. I always think you have to start with the customer. They make these mega-commits—a billion dollars over 10 years. Well, now they’ve got to go find a hundred million a year in consumption. That they have to run on that platform. The ISVs are an easy way to do that, and many of them already have. Some of them may be part of their app modernization strategy and stack. But if they’re aligned with the hyperscaler, they can retire all that commit. They can burn that commit down.
Allan: Yeah, absolutely.
Avanish: It’s a beautiful thing. Because once it’s in the marketplace, the transaction is easier, the deployment is easier, the tracking is easier. That is always one of the things that I advocate: you’ve got to make it easy for the customer. If the customer starts seeing that there’s three entities here, I need five agreements between them and among them… That is not fun.
Allan: And make it easy for the sales rep.
Avanish: Of course.
Allan: The reason the hyperscaler thing really works is because of that little IP co-sell thing that Microsoft has. Or private offers that—didn’t you have AWS…
Avanish: AWS and GCP both, yeah.
Allan: The sophistication of those commercial envelopes… Last time we talked about commercial structures. The sophistication of the IP co-sell model and the sophistication of the private offers in these marketplaces is really off the charts. It’s the best example of how to crush it with tech partners. Insofar as being able to figure out how a customer can simply go, I would like that ISV. I press a button, and boom. Done. Not another contract. Not having to go through all this due diligence. Of course, there’s due diligence on it still, but it’s not costing me anything.
Now, reality is that you paid millions of dollars for that contract.
Avanish: But now you’ve kind of made a commitment. And you’re on the hook to consume it.
Allan: …get 97% of their first year ARR on those deals.
Avanish: That’s correct.
Allan: I’ve got the AWS sales rep retiring quota. I’m there all day long. That is a go-to-market full on.
Avanish: If it’s done right and managed right, and if the right incentives are in place, it can be magical. I think some of the analysts—our friend Jay McBain from Canalys and Frank Della Rosa from IDC and others—they’ve been calling out for a little while that this could be huge, that the marketplace would be a major consumption model. This is where that floodgate is going to open up. This is where it starts.
Allan: Absolutely. You see people like Tackle.io, who are doing a really nice job creating some of the infrastructure to support the ISVs working with the hyperscalers. I think today it’s probably around 10%; 10% of the total B2B SaaS ISV business is going through the hyperscalers. It’s not insignificant, but, guess what, 90% still are not.
Avanish: That’s right.
Allan: We’d better be turning our attention to how to get the other 90% to work. Okay, let’s say that 10%, that’s going well. Invariably, it’s probably never going to be 40%. For the majority of your go-to-market, if you’re an ISV and you want to go through tech partners, you’d better find some other models than just the hyperscaler marketplace. Because that’s only going to get you a way into the dance.
Avanish: Allan, I’m going to put you on the spot and ask you a question which is something that I think about, and I don’t know that I have a perfect answer. In a case like that, from an organizational perspective… We talked about the incentive alignment with the hyperscaler sales teams. What does the ISV do for its own sales team? How do they organize, how do they operate differently? How do they need to think about it?
Allan: Are you speaking in regard to, like, the hyperscaler motion?
Avanish: Yeah. If it can be successful, if you use that as a scale mechanism, how does a CRO of an ISV in one of those ecosystems need to operate?
Allan: First and foremost, the way I look at ecosystems and partner ecosystems is that they exist in multiple ecosystem segments. People’s tendency is to think, I’m in the AWS ecosystem, or the Google ecosystem. And that may be true, but the reality is that there’s a bunch of other ecosystems that are overlapping with those.
Let’s take an example. Let’s say that Informatica wants to retire a whole bunch of data stuff on AWS. Well, they’re going to go through this motion of driving demand and then find as many ways as possible to align those back to the hyperscalers, so that when the customer is ready, they can flip on the procurement machine, and all that complexity goes away.
But if you think about it from a top-of-funnel, bottom-of-funnel perspective, you’ve still got a lot of top-of-funnel work to do. You have to create demand, because if you don’t do that, the AWS rep will never hear about it. The customer won't ask for it, and there are crickets. I think that the go-to-market or go-to-eco motion has to be multi-threaded. Through the hyperscaler, yes. But guess what’s also going on? There are other ISVs around you, competing, yes, but also creating a wealth of opportunity. I would argue down the line what you’ll start to see are bundles going through the hyperscalers. Not individuals, bundles. The work that we recommend our clients do is align to other ISVs in the tech partner monetization scheme so it can be connected to the hyperscalers. The more work you do at that bundle level, creating better-together stories—the more noise you make, the more value you create, and the more the AWS rep goes, “I want all three of those ISVs.” Not just one. It’s not single-threaded.
Avanish: Yeah. That makes a lot of sense. There is one thing I will say, and I think it reaffirms your point. There is a perception sometimes, from ISVs, and particularly startups, that if they put up their offering on marketplaces A, B, or C (or A, B, and C), that they’re done. Now they’ve built it, and the customers will come. You and I have talked about this. This is one of the biggest fallacies in this business.
You have to create demand. You have to define your value prop, your differentiation, your engagement model, etc., and that, I find, is one of the bigger frustrations a lot of folks have. “I put it up there. Nothing’s happening!” Well, how do you stand out? How do you engage? How do you tell the story? All the things we talked about as prerequisites—that does not go away. Everything gets reinforced.
Allan: Yeah. If we went into a supermarket marketplace selling cereal, and we go to the Kroger’s to put our cereal on the shelf, guess where our cereal would be if we didn’t do what you’re talking about? We’d be on the bottom corner with one little cereal box, and then Kellogg’s is like all of the eye-level stuff, three feet wide, two feet tall.
Avanish: And the endcaps. [Laughs]
Allan: Yeah. [They] ain’t going to buy your cereal, because you didn’t do your job. In any kind of marketplace, that is a prerequisite that won't even buy you a cup of coffee if you don’t do the other stuff you’re talking about.
Avanish: That’s exactly right.
We talked about some challenges. You and I both know there are some other operational challenges that come with this too. There’s other elements of organizational processes, systems. Talk a bit about what you’ve seen from that front. How do people figure out how to work around that? Or with that?
Allan: Absolutely. Yeah, so we’re talking about making products, right? I like to look at the journey of go-to-eco very similarly to the journey of making a product. If you’re going to make a product, the first thing you’re going to do is the market requirements. You’re going to do total available market assessments. You’re going to do justifications and business cases so you can say to your CPO, “We should add this feature.”
If you don’t come with your act together, and you’re a product manager competing with another product manager for resources, you get nothing. The whole front-end piece is, be an entrepreneur. Look at the opportunity set: how big is it? With which partners? Doing what? What customer experience are we solving? What offering are we going to have? How are we going to create a flywheel of value for us, the partner, and the customer?
If you don’t have your business case right, if you haven’t felt like an entrepreneur, if you haven’t done your homework, you’re probably not going to get the resources that you need.To my mind, that’s the starting point. I think a lot of partner people don’t put themselves through that rigor of treating themselves like a true product manager. To get the resources they need, you’ve got to get your act together and you have to have your story right. You’ve got to prove that you warrant an investment.
I’m sure you’ve seen that many times, where people come together with their little PowerPoint and it’s like, this is garbage. There’s no use case here. I’m not going to invest in this.
Avanish: [Laughs] Yeah. I think that the product angle, and being technical enough about it, is always critical but often lacking. And internally, you cannot do anything without that.
Allan: Yeah. That corresponds also to the mindset that the requirement is with the CPO at the very beginning of the process. You can come with your business case, and you can come with your story, but if your CPO didn’t have space in his or her road map for this thing you’re doing, with resourcing to allow for the proper technology infrastructure, the APIs, published documentation, and a willingness to invest against that business case, then you’re going to be shooting blanks. Because your business case is really good, but the organization is not prepared to execute on it.
Those, to me, are really important starting points. Do you have a business case? Do you have a CPO? I always like to start with the CPO, because we’re making products. Where do you start when you’re making products? Not with marketing. You’re going to start with the CRO, the CPO.
This is the next level of dysfunction when the organizational alignment is poor: the classic case of the tech partner program reporting to the CRO, who wants quarter-to-quarter results, when we both know that making product is a multi-year event. Even in a technology with a partner, you’re still going to need a certain amount of time to build the right use case and the right road map, to show the value and the results, before you can turn on the revenue machine. The second piece there is alignment.
The third piece is the one which I think is most relevant in 2023: we’ve got to assume that we’ve got the right goods. We’ve built the product, we’ve got the business case, we’ve got the alignment, the CPO is on board, it’s marketing, sales—now we have to programmatize. This is where we find most of the gap in skills and gap in process, because we don’t understand how to programmatize. We get insights from automated account mapping, or Nearbound now reveals calling the process of determining who you should work with, how much you could get if you work with them. But the insight doesn’t necessarily mean that you have the skills or the process to actually turn that into outcomes.
The programmatization of the product is really like the next frontier, if you will. How to create a true commercial program and do it at scale. Because guess what doesn’t work? You make all these promises, and then it turns out you have a bunch of random acts of partnering going on, and nothing is repeatable. And guess what else won't get funded?
That’s why we’re really big… Monetizing tech partnerships is about having a program that works at scale. It’s efficient, predictable, scalable, and it’s sustainable. You can't do that with this BD orientation. That has slowed down the partner progression significantly.
Avanish: Yeah. I one hundred percent agree, and I think the one thing I would add is, in addition to the program, I have found that systems are so often one of the challenges. There’s obviously technologies like Reveal or Crossbeam and others helping do the mapping, but then, how do you deal with it? How do you make sure that it’s being appropriately tagged, tracked, executed upon? The times that that breaks down, and that you end up having to throw people at it to fix it, or to track it, it’s mind-blowing.
Allan: That is one hundred percent right.
Avanish: Right? I hate situations where you see the opportunity, you have the core of the product, but then the execution is limited because IT is not going to get to whatever you need for three quarters, four quarters, five quarters, whatever it might be. That just blows me away. Unfortunately, I’ve seen that firsthand; I’ve seen that secondhand. It’s a sad state of affairs. You and I talk about the need for better technology in this space. Some of those are coming but boy, that is a limitation that’s unfortunate.
Allan: One hundred percent true. There are steps that, if you follow them, you will win, and if you don’t, you’ll lose. Step number one: align with rev ops. If it won't align with rev ops, you’ve got nothing, because the CRO is looking to rev ops to show them what the data says. And if rev ops doesn’t (a) believe you add value, (b) work with you and take your data, or (c) support you with the resources that are necessary, you’re kind of on the tent waving again.
Avanish: On the outside.
Allan: Exactly. That rev ops alignment is super key. Then it’s really incumbent on partner leaders to recognize that partner operations is not a “nice to have,” it’s a must-have. Rev ops can give you the resources, but down the line, someone is going to have to say, I will be responsible for the hands-on keyboard to make sure that the data flows and the work processes. You need data, you need a workflow.
Avanish: Yep, that’s right.
Allan: …are instantiated in rev ops, so that when the dashboard says “Sourced revenue contribution 20%,” someone goes, I don't buy that number. That’s bullshit. Show me the data behind that. Then you’ll say, we did a bunch of tagging and flagging in CRM to get the AE to say that the deal happened, and they go, that partner stuff is bullshit. I don’t buy that stuff at all. I’m not putting any money into that. These are the unfortunate realities that most of our peers face, that we’re trying to solve with better process.
Avanish: Yeah. That’s exactly right.
Allan: Better process.
Avanish: Yep. Processes and systems.
Well, Allan, as always, time flies when you’re having a fun conversation. We are at time for this episode. But fret not, we’ll have one more, and we’ll come back and get deeper into the how, and what that means, and some guidance for folks who want to really think about this in a strategic element.
Allan: It’s great to be here.
Avanish: Allan, it’s always a pleasure.