All right, welcome to another webinar. Today. We have our good friend Mark Demeny talking to us about vendors are from Mars and buyers are from Venus. So Mark, take it away. Thanks. Yeah, this was a presentation I did a couple times for Yanis boys, CMS groups, CMS connected Montreal, and also the one in in Denmark last year. I'm not going to go through the whole presentation. I think it's more fun to sort of pick a few key concepts and then, you know, you and I can talk about those in detail. So kind of skip to those. If anybody is watching this and wants a copy of this, let me know, and I can send them that. But you know real quick about me, and it'll be very quick. I've, I've been in CMS for a very, very long time. You know, obviously worked with the Konabos folks during my time at Site core, but I've, been at a number of other different vendors. Contentful, Optimizely, uniform, currently doing work for the mock Alliance. And this is me and my dog. He just turned six. So this is right down the street from my house.

So I think the reason why I made this presentation was CMS software is surprisingly hard to evaluate and acquire, and this is something that I hear all the time. And I've been on all three sides. I was at the client side implementing CMS software. I've been at the, you know, vendor side as well, you know, building software. And, you know, a little bit on the services side, too. And so, you know, this is really a recurring theme. And, you know, I think the presentation kind of came from a need to do some therapy and really sort of explain why things are the way they are. Because once you dig into it and sort of understand it, there is sort of a logic to it, even if it is frustrating to everybody. So that's really where it came from. And I think the first thing is, you know, again, why is it so hard to acquire? And the first reality check is enterprise, CMS vendors do not sell software. And really, what I mean is they sell a set of capabilities that someone assembles into software. And that is, you know, either the vendor themselves, if they have their own services group, or, you know, NSI like Konabos, or, you know, clients may be implementing the software themselves, but you know, but really what they're digging, you know, what they're doing is, you know, taking some of those core capabilities and mixing them and matching them in different ways. And so, you know, I think this is, this is sort of one of the, one of the key concepts. And really, you know, the majority of the total cost of ownership is related to the implementation and not the software itself. So I think that's really, you know, kind of one of the key, the key things for people to understand. And I think once you start to understand that, then, you know, some of the other reasons why things are the way they are become a little bit clearer. You know, this was a show of hands that we did in the room, and it was sort of rhetorical question about, you know, has anything changed in the last 14 years? And this was, you know, tweet from 2011 you know, choosing the CMS is only 20% about the system, 30% chemistry and 50% integration competencies from the partner side. And I absolutely agree.

You know, one of the interesting things, though, I think is worth noting, is that 30% chemistry, I would call philosophy. And you know, really, what I mean by that is sometimes vendors have different ways of handling and tackling the same problem, and so some of its chemistry with, you know, do you enjoy the buying team? Did you like their documentation? But some of it is also like, hey, how do certain vendors handles, you know, certain common problems? So I think that's a real key to that as well. Oh, and actually, you just disappeared, just as I was going to sort of pull you into the conversation. So, so I was, I was gonna say, you know, it's, does this ring true? You know, thoughts, agree disagree, yeah, no, it's here. Sometimes I don't know if the customer is ready for it, right? They think they're buying a software. And I remember in the good old days, like, What do you mean? The implementation cost more than the actual software. And you're like, Yeah, you got the capabilities of what the CMS or the dxp can do, but in order for it to fit your need, there have to be customizations, and you have to build it for you. And the interesting part is, yeah, you can see the commonality at like.

To 10,000 20,000 foot level amongst all customers, right? Yeah, you have to build a site, yeah. You might need this, yeah. But when you get down to the 100 foot level, it is different, even though, like the there was commonality up above. So it is quite a bit about that. And yeah, most of the thing goes into the SI or whoever's building it. The system is only part of it, so I totally agree with that part chemistry, yeah, again, chemistry depends on its between what and who and the different systems. But I totally agree with that, that it's they're selling you a set of capabilities, and you're hoping that the capabilities in now and in the future will align with your business growth as well. Yeah, I think one of the things that's changed since 2011 is a lot more vendors allow you to evaluate sort of chemistry and the non functional things a lot more yourself. You know, in 2011 if you wanted an enterprise, CMS software, you know, you went to the website and did whatever, and a sales guy contacted you, and you went through this long process, and it was demos and whatnot. And I think now a lot of vendors, you can go get a trial account, start to play yourself and look at the documentation yourself. And I think this is one of the big changes, is you really should be looking at, you know, less of an RFP approach to, you know, evaluating software, and much more of a POC type thing. So, you know, take a look, play with things yourself. And I think that's also much more useful for teasing the philosophical differences between things as well, right? Yeah, really. CMS is a really wide space. And like some, some platforms are better for internal and corporate comms. Some platforms are better for building applications. Some platforms are better for building pages. Some platforms are better for, you know, deep governance and, you know, retention and these things are really hard to evaluate in an RFP sense, you know, partially because, with a little bit of work, all of them can do all of these things. Like, yeah, every CMS can be used for blogging. Like, okay, well, you know, our you know, there's a lot of intangible features that make one better than the other, so seeing that for yourself is really one of the big changes these days. Also on because we're talking about being able to check your own capabilities, right? Doing a proof of concept or proof of value, I would strongly suggest people to do more of a proof of value. It's a tiny bit different than proof of concept, because you're doing it for yourself, but pull the prospective vendors in, let them have a skin in the game. And this is where I'm getting at is you're also figuring out the chemistry of how well they support you. So a good example I can give is one of the vendors we were working with on paper, publicly documented APIs. Looks great. We did a proof of concept, oh yeah. Everything worked fine. When the push came to shower. Oh, wait, we want to be able to do a, followed by B, followed by C. Oh, well, we don't have an API for that, but let us help you get there. We can build something or give you a different direction on how you can achieve the same thing. So they were able to work with us to help us get to where we need to get to. But some don't. Some are like, well, that's the API. We'll put it on the roadmap. It might come in six months or a year. So you're also trying to work out that chemistry as to see how, well, not just from a sales perspective, but from a technical perspective, they're willing to help you out.

Yeah, no, that's, that's a really interesting point as well. And I think, you know, I noted this later on in the slides, and maybe I'll skip to that. Sometimes you want a vendor that's a little bit smaller and a bit more responsive, and sometimes you want a vendor that is not responsive. And what I mean by that is, they'll build the API, and they're building that, and they're supporting that for 1000s of customers. And you know, there's a stability there that there may not be for a smaller vendor, but you know that stability and that performance comes at a cost, right? And so, you know, I agree, I think it's really useful for you to point out, like, what are you looking for as a vendor? Do you want that? Do you want that stability and you're okay with the fact that the API is what it is, and, you know, the roadmap is what it is, and you will build the rest. Or, you know, do you want a smaller vendor that's a little bit more, you know, flexible in that way? And that's, that's a really. Important note as well, and that's actually why there's a lot of, you know, smaller CMS vendors. It's not necessarily that they're providing a product that's different than larger vendors, but they're providing an overall partnership that is different. Yeah, sure. I totally agree with that point. Cool. So yeah, that's, I think that's one of the really key things. And yes, there has been some changes in the last 14 years. So, you know, that was an interesting point of discussion as well.

You know, really other interesting point that we were talking about as well is because there's so many vendors, and this really dovetails off what we just said. Sometimes you're buying products, sometimes you're buying features, sometimes you're buying enabling capabilities. Sometimes you're buying into a community or ecosystem. And you know, it's really clear for you as a buyer to know which of these things you're prioritizing, because some people just want a product. They don't care about the other things, they don't care about a community or ecosystem. They have their own team, you know. But in other cases, you are buying into community or ecosystem, you know? I'll give you like, two examples on this end of the spectrum, you know, if you're looking at something like Drupal or Wordpress, you're absolutely buying into the community or ecosystem. If you're looking at something like Contentful, you're, you know, buying into the product and what they offer, and, you know, API performance and all that sort of fun stuff. And there really is a spectrum here. So, you know, one of the things that I did is, yeah, dig in a little bit further into this and sort of compared Sitecore like you're buying components, ease of assembly and a final product. So, you know, there's lots of components, different content, repositories, workflow, three visual editors, CDP, damn, etc., etc. You know, ease of assembly is pretty hard. You need to, you know, have a lot of experience to be a Sitecore developer. You need, you know, developer environments, typically you needed, you know, tools like unicorn or TDs in the past. And then, you know, something like Contentful, you get some bits and pieces and components, but these of assembly is amazing. So, you know, these are two very different philosophies about what a CMS is. So, you know, again, you need to understand that as buyer. So that was interesting as well.

Let's see here, pricing and packaging. I'm going to really quick, quickly jump through it that pricing and packaging, often larger vendors won't give you a price, and this is probably very frustrating for buyers. You know, sometimes you'll get a price at, you know, different tiers. So like Contentful, for example, has a free tier, they have a basic tier. But anything beyond the basic tier as well is, you know, custom price. The reason for that is that, you know, often the value a client gets from a solution may have really very little relation to what costs the vendor. And interesting things like consumption is really easily understood, but it doesn't provide cost certainty. So if your traffic goes up, your consumption goes up, all of a sudden, your bill might be higher one month or another. The flip side is, you know, feature based selling provides cost certainty, but often there's a disconnect between cost and value. And so pricing is really, really hard, you know, I'll frame that this way. The other reason it's really, really hard is that, you know, sometimes a client wants to push a whole bunch of risk onto the vendor like, hey, I want you to build this in your roadmap. I want to see this capability. I want to see that capability. You know, I was in involved in one sale that was in negotiation for like, a year. 139 attachments in CRM, 24 employees on the vendor side involved, account executives, legal services, product management, corporate leadership, hundreds of legal document red lines, ongoing demos, product roadmaps, product updates, etc, etc. But you as a vendor can't say, Hey, here's what it cost us to go through all that procurement hassle. And so you know that that time and effort in order to build that partnership and that certainty and that risk mitigation from the buyer side that has to be recouped somehow. And that's really why vendors, especially at the enterprise level, are very opaque with their pricing, because often they're having to do, you know, choices about investments that they want to make in the roadmap. Often they're having to do a lot of time and effort on their side, from the legal side, etc. And so these, you know, kind of need to be covered one way or the other. And this is also why there's some vendors back to the previous conversation that just say, No, the product is what the product is. The API is what the API is. And per. Procurement is what procurement is. And if you don't like it, go elsewhere. And, you know, they do that because that's a model for them that they don't want to be spending time in, you know, legal and other cycles. They just want to focus on product. So again, it's a philosophical thing as well, but it, I think this, this more than most, really explains. You know why? Often enterprise pricing is hard, so you do? You think I know often wondered this as human beings, right? If you're evaluating two or three vendors at a similar level, enterprise level, right, one of them is far too lower on the cost, as opposed to the other. From a product perspective, being human beings, do you almost think that you're getting something less or subpar like do you think that plays into pricing as well? Yeah, you're trying to always make sure you're competitive and not too low or not too high than your prospective competitors who are pitching to the same customer. Absolutely, absolutely. And it's, you know, it applies in every, every domain. But certainly there's even more variability in software, because, you know, generally speaking, the cost to deliver a lot of stuff is fairly fixed. And so, you know, depending upon what the scale of people that you sell to, you could be selling fairly low and making a profit. And so, yeah, Stella Artois, the beer used to have an ad, and I think the tagline was reassuringly expensive. And it's, it's quite funny, because in North America, they were targeting sort of like, oh, it's Belgium. It's imported. It's expensive, you know, meanwhile, in England, it's, it's the drink of choice of hooligans, right? And it's, and it's not expensive. So, you know, there just goes to show that, you know, yes, branding is part of it, and marketing is part of it, and pricing strategy is part of that as well.

You know, I think the one, the one thing that is probably worth noting, like you do want your relationship with your vendor to be sustainable. You know, I think that buying market share is not a good approach. You know, you have to sort of pay for that some way at some time. So I think, you know, you want to be sustainable on both sides. You know, if you're hammering your vendor and it's a small vendor and they're not making any money, you may need to find a new vendor at a certain point, if they, you know, go under, you know. So, so, yeah, there's, there's an element of that, you know, I think what else was, was key to note in this, because pricing is so variable, like, yes, you should be pushing for discounts, but you know, understand that there is a trade off to that. You know, usually the trade off is longer lock in term, or, you know, something like that. You know, they can use your name in customer case studies. And so, you know, some companies have the ability to, you know, do that on the buyer side. Some don't as well. So if you don't, then don't expect your vendor to be that flexible either, right? So, you know, again, it's, it's a give and take between the two sides, another naive question for the master. So as my company climbs as a vendor through the quadrants for Gartner or Forrester, have you traditionally seen the pricing also increase with that climb in the quadrant? Yeah, absolutely. And I think they would argue, you know, not without good reason, the product has gotten better. And if the product's getting better, and you know they're, they're competing at a higher level, then, you know, they, they expect to, you know, gain that in terms of cost, you know, I think it's, it's interesting, and based upon experience, you have to be careful with that as well. You know, I think a really good example is if the product has changed substantially over the years, the value proposition of the product may be very different as well. And so, you know, companies that bought your product when it was sort of smaller and mid market may not need all of those new capabilities. You know, now that you've gone enterprise and added a customer data platform, and, you know, all of these other things as well. And so, you know, I think vendors need to be.

Aware of that sensitivity, if the customer has needs have evolved along with the product capabilities, then, you know, great, you're probably both in lockstep there, and you can be raising the price and the customer would be okay with it, because they're getting more capability. If you're developing a bunch of features that the customer doesn't need because they're, you know, staying relatively the same in terms of their needs, you know, then, then there's a real source for frustration. And I, I don't want to call out certain vendors, but I think there's, there's enough vendors, especially those that have grown inorganically, and they've acquired a lot of those capabilities, if they can, you know, continue to serve with service those existing customers in a composable way, and they're not charging, you know, a ton of money because the customer's needs have not changed, then, you know, they'll retain them. But if, if every vendor has this expectation that every client is, you know, is going to need everything, and then is pushing that price upwards, you know, then that's absolutely a recipe for churn. One last thing I'll say about pricing, which I think is interesting. I want to see your take on it, is, if the leadership stands. So what I mean by that is huge fortune, 500 company, the leadership, who made the decision to buy the vendor software, still is in existence, maybe at a higher level than they were before. They were probably a director. Now they're a VP or C speed, right? I feel like, what if, what I feel my personal opinion, is, if they've invested the price was substantial, they're more hesitant to change it, because they feel like their credibility is kind of attached to that. Yeah, three, four years from now, they're like, Oh, we spent a million dollars on this. We can't change it. I would rather pour in $100,000 every month, every year, and leave it the way it is, then, then change it. Have you seen that mark? Absolutely, it's a very uncomfortable conversation, and there's sort of two parts to it right there. You know? The first is, yeah, and vendors should be aware of this, like the buyers are betting their careers on that platform. And that's, that's absolutely correct. And, you know, yeah, that that does, that does provide a bit of a moat, because if they're, you know, now, at a point that things aren't working. And you know, they should be looking at other vendors. They need to go back to the business and say, kind of like, yeah, I fucked up. And we need to look at something else. And you know, not everybody is comfortable enough in their position to be able to say that.

So, you know, there is an element of that for sure. And I think, I think one thing that buyers can do to mitigate that is really point to the fact that, you know, we've gone through, at least, you know, since I've been in CMS for 20 years, we've gone through a few major evolutions and what CMS is. And every time that there's a major evolution, you need to ask yourself, is the organization going to benefit from the major evolution and CMS changes? So, you know, if we really quickly dive into the history, like back when it was interwoven team, site and vignette, you know, you were, man, it was really software that cost millions of dollars. You're managing this stuff to sort of in a decoupled way. And then that was replaced by sort of, you know, live access of content being served off of databases like the site core and Optimizely and am generation. And then it was the headless generation, Contentful, content stack, content at AI. And you know, now we're starting to lead into vendors doing a lot more capabilities with, you know, agents driving a lot of things like governance and, you know, content creation and things like that. So each one of these things had, you know, some benefits and trade offs the you know, the biggest one I'll say, is moving from systems like site core, and am who are very good at managing things like pages, and, you know, would manage the whole site and the whole stack of the site, to something like headless, which is, was not managing pages, was not managing The site. You need to do a whole lot of your, you know, functions there as well. That was a huge change in philosophy and technology. And some clients said, you know, yeah, the existing thing is working for us, and that's fine. And other clients and organizations and individuals had to say.

Say this new approach makes a lot more sense for us. It didn't exist at the time that I made the previous decision on the previous vendor. And so, you know, don't, don't crucify me for, you know, the fact that that stuff didn't exist. But we need to make that change. And so I think you know, if you go along with that model, to say, here's why we want to take advantage of this new technological shift, it's a little easier to deflect blame, because, you know, that shift didn't exist. You didn't make the choice because those vendors were didn't exist, or were new or nascent, or whatever. And so you know, it really does come down to what you know, what makes sense for the situation there, I think related to that, on the topic of making it hard to shift, I think there's a lot of marketing organizations, especially now that the marketing stack has gotten so big, you need to know so many tools that just the lift of, hey, you need to know this, you know, older tool, and start to learn this newer tool, and transition and be doing both at the same time. Some organizations really struggle with that, especially if their turnover in the marketing teams is, you know, once every two years, they have to train somebody new, and then it takes them whatever to get up to speed on the existing tools, let alone the new tools. And it's just this treadmill.

I think the way I've seen some organizations adapt to that is separate out, sort of core people who are sort of focused on the marketing outcomes from the people who are doing deliverables. And so they can say, right here are the people who are focused on the outcomes, and they have the KPIs, and that is technology agnostic. And then we're going to have contractors, si whoever, build the website. And if it's, you know, site core today and it's Contentful tomorrow, that's fine. And if the you know, team can do that, great. But if not, then I just, you know, stop working with that contractor and work with a different contractor that can do that. And so they'll, you know, use contractors for the you know, flexibility of the technology side. Because, you know, usually the contractors are sort of in that cycle of deciding what their bench is going to be, you know, going forward, and what the technologies are going to be going forward. So I have seen organizations sort of split out that risk to say, Okay, we're not worrying about training our own folks. Our own folks are going to be focusing on the KPIs and focusing on the outcomes and sort of managing things, and, you know, understanding how to manage and how to deliver, but the actual implementation will rely on contractors and then we can be very, sort of ruthless around, okay, this is the technology. Can the contractor do that? Yes, no, okay, if not, find another contractor that can, and then that way they, they separate out the risk there and get them off that treadmill. Makes sense. Yeah? So, yeah, that's, that's an interesting one as well. This was other, another, you know, fun, fun discussion around procurement, I think, you know, back to the earlier discussion. I think, you know, we were discussing, you know, talking about, it was always like build versus buy. And if you were buying, you went through that RFP process. And I think, you know, nowadays it's, you know, a build and buy discussion. You're going to be buying some capabilities that are sort of commoditized, and you're going to be building other capabilities that are differentiated. And I think this is really the key distinction for an organization, is, yeah, buy anything that's commodity, build anything that's differentiated, and if nothing that you do is differentiated, then you can probably get away with buying, you know, absolutely everything. You know, there's a reason why WordPress is pretty popular. There's a reason why Shopify is pretty popular. Because, you know, if it can do 80% of the stuff for 80% of the people, then, you know, great. Do that. You know, where we see a lot of the building, especially in composable, is where you want to have a differentiated customer experience. And that's, you know, differentiated in terms of, like, Oh, we're going to deliver through apps instead of a website. Or we're going to deliver through, you know, Omni channel means. Or we're going to deliver through, you know, people doing click and collect and, you know, all these different or we're going to deliver through marketplaces like, you know, whatever that is for differentiated customer experience, that's usually where you're doing a heck of a lot of building and integration.

So, yeah, that was another, another really interesting point. You. Know, another really interesting thing that is sort of differs from enterprise buying and really enterprise product management is, you know, more often than not, the team doing the evaluation is not the team using the software. You know, you do have buyer personas and user personas, and I think this is one of the biggest sources of frustration for, you know, people implementing content management software. You know, vendor is going to be working with the buyer team. They're going to be addressing their needs, but then the user team may be much larger, and, you know, stuck using the software, but the vendor is not responsive to them. And here's sort of the economics of that. So again, you see, like procurement, IT leadership, you know, development, etc, and the user personas will be content authors and casual contributors. You know, the numbers that you'll see. Here's an interesting example. You know, let's say you're selling to a team of publishing managers, and there's four of them. And you know, their tasks in the platform are managing sites, user provisioning, template configuration, content modeling, governance, permissions, etc, etc. They're in the platform eight hours a day, 250 days a year, and there's four of them. That's 8000 person hours. Meanwhile, that team of four might be supporting 5000 casual contributors. They may be financial advisors, faculty doctors, whatever they're going to be using the CMS three hours a year. You know, they might come in update their bio, or, you know, a couple pages of their research, or whatever. That's, you know, 5000 people at three hours, and that's 15,000 person hours. But you know, the CMS vendor is going to be catering everything to that team of four. You know, more varied tasks. They're the buyers. They're the ones that, because they're using it eight hours a day, as opposed to three hours a year. Are going to be calling up, having support tickets, etc, etc, and so, you know this, this really, you know, kind of explains. And this isn't just CMS. You'll see this in HR software, ERP, etc, etc, you know, why? Why vendors are, you know, really catering to one set of users rather than the other even if the other is larger in terms of, you know, actual footprint and use in the system. Yeah, totally, totally agree with you. Like, even if it's an RFP process or even a regular sales process, it's the people who don't even use the system. Like, at least in this case, yeah, you're including people who kind of use the system.

Basically, you're making decisions for something you don't even you control it. You take care of the people who do support it. But it's, it's a shame. But to your other point, nowadays, because of the being able to try things, I feel like people do have a voice. I don't know if the casual contributors might have a voice, because they can actually go with like, you know. Well, yeah. So this is, this is interesting in that in the sales cycle, that buyer persona absolutely runs the sales cycle. The user persona runs retention. So if 5000 people, over time, get pissed off enough and are calling that team of four and telling them, Hey, I can't create content well enough, eventually that team of four will like relent and start to look at other platforms. And so, you know, this is the other nuance to that. Is like selling to the buyer persona is absolutely the initial sale. But then for retention, you absolutely need to cater to the user persona. Otherwise it comes back and it bites you over time, you know. And it's really insidious in that it's it, it happens in the background, right? You know, the first little bit like those, those people are like, well, it didn't quite work the way we wanted to. And, you know, we'll get used to it, and we'll figure it out. And, you know, over time, it sort of accumulates. And I've, I've been involved in CMS selections processes where, you know, I'm working with that team of buyer personas, and it's like, well, you know, why? Why not look at the latest version of X platform, and they're like our users F and hate it. And we, you know, if we stuck with that, they would, they would quit or run us out of the, you know, the company and so that that absolutely, you know, affects retention as well. And so you know vendors, and it happens silently and in the background, and it only sort of by the time it gets up to that team and to the vendor, it's too late. And so vendors really do need to be proactive with those casual contributors and organizations do. As well, in order to, you know, prevent that from happening. Yeah, maybe, maybe a good, good thing for the vendors to push for speaking with the end users of it, the market. Authors, Oh, for sure. I mean, right? I think right now, vendors, you know, kind of look at the world in there's or CMS vendors look at the world as like, Oh, we're catering to developers, or we're catering to marketers. And I, in my mind, there's always three personas, there's developers and marketers, and then there's practitioners. And practitioners are those who understand content modeling, you know, understand template configuration. You know they're not. They don't necessarily have the market or KPI for like, hey, the performance on this landing page, but they certainly do think about content management as a practice. And you know, those, those practitioners, I think, are often ignored by vendors. And, you know, I think the practitioners are really sort of the glue between, you know, marketer goals and the developer goals. And you know, they're sort of responsible for making that stuff work at scale. And so I think that it's really important to realize that there's really those three practitioners, certainly for larger organizations, for smaller organizations. CMS is pretty simple, but you do need to think about it that way.

We do have a question about monolithic versus composable in the future from LinkedIn, that's a very vague question. I mean, I could, we could take that and run with it in in different directions? Tony Byrne, Real Story Group, someone who I really respect very, very into the weeds of different CMSs and very, shall we say, accurately cynical about the state of these things. I think he would like this conversation and the frankness of it. But he recently wrote a blog post saying, composable, essentially one because either you have the composable vendors who have started acquiring other bits and making them work in a composable fashion. You know, content stack was a good example of this. Started with CMS analytics For CDP, you know, other functions for personalization, etc, etc.

You know, site core also went in this direction. You know, they had this monolith, and they've been breaking out parts of it, you know, particularly things like personalization and XDB. You know, they acquired another vendor for that, and, you know, they're now using that capability as well. And so, I think, you know, there's, that's, that's his perspective, is that, you know, from a technology architecture point of view, the trade off for composable has always been, you know, do these things play nicely together? And, you know, is it, does it make sense to, you know, acquire these things in one vendor, or be, you know, more open in that respect. And I think there's different aspects of composability. One is this, you know, are things open through API's great. The second is, can these things actually work standalone and be supported by the business standalone? So, you know, good example of acquisitions content stack, acquiring Linux. You know, can you have Linux as a standalone CDP and use another CMS, like, yes or no? And if you can't, then it's composable in the technological sense, but not in the business sense. And you know that that does happen a lot with acquisition. Acquisitions in, you know, gets it pulled in. It's like, great. It's composable. You can choose whether or not to turn it on or off, but, you know, you can't necessarily use it on a larger composable stack. And so, you know, that's sort of that second level. You know, there's an element of partnerships within that as well. You know, do they still actively maintain partnerships with other vendors out there. But, you know, from a technological perspective, you know, Tony's perspective is it's, it's definitely one, and even a lot of the composable, or, sorry, the monolithic vendors have started to break up their monoliths as well. You know, in some cases, it's clients doing it themselves. In other cases, it's the vendors doing that. One of the biggest, I think, drawbacks, and, you know, actually jump in here as well. But I think that a lot of the older, sort of monolithic approaches were.net based, Java based, you. You know, you would do your front end development in the same language as your back end development. You kind of had to, because it was running sort of within the context of that app. I think that's pretty much gone everybody now is you can run, you know, JS front ends. Adobe has JS front ends site, course, JS front ends. Or, you know, Adobe has HTML templating that they built like that's already more composable than it was. You know, similarly, how you can serve up the application, you know, site core, partnering with, I think, you know, Netlify and Vercel and, you know, Optimizely did as well. You're now separating out and composing that delivery tier as well. So that's already more composable. So I think there's very few like, you know, truly monolithic applications left, you know, Wordpress, but I think, you know, in those cases, for where, for what WordPress is for, and who they were targeting, that's probably Fine. You know, composable does add a lot of complexity and overhead to the processes, and if you don't, you know, benefit from that in some way, then it's, then it's a hindrance. So I don't know that every vendor in the world and every use case needs to be composable, but I think more are, and I think it has become easier and, you know, a more standardized way of doing things. Yeah. And I think one of the positives of all of this, like you said, is all the monoliths are turning to be more composable. All the composable ones are adding more capabilities to become more of a dxp than just a CMS from a headless perspective. The one thing which is interesting that you just mentioned is they all are finding that they could implement it the way they want, so the front end to separate that do it in React or any other JS framework, or even.net but for them to have that ability and want to, hey, we'll just take care of this. And that itself provides a lot more avenues for growth, fast, you know, faster implementations and stuff. It's not as tied down as it was before. So I think the whole composable movement had really good positive effects on the entire industry. Yeah, for sure, yeah. I mean, again, it goes back to us being people who have been around for a long time. That used to be one of the main buying criteria was like, What's your organizational skill set? If it's Java, then you're looking at, you know, Adobe and hippo and Magnolia and you know, if it's PHP, then you know it's Drupal and WordPress. If it.net's it was, you know, site core and epi server, and, you know, those guys, Ektron. So you know that that used to be one of the main criteria, and now it's to your point. I don't think it's really a criteria at all anymore, or it shouldn't be, you know, I think there's still some of the case of back end development, if you're, if you're doing on prem, you know, I think there's, there's a whole other discussion. One of the, one of the things that I find interesting is, you know, vendors, Adobe site, core, Optimizely, are starting to try to transition to a more cloud based model and a more, you know, more of a SaaS like model. And, you know, one of the trade offs of that is less ability to do that back end development.

I think a lot of their existing customers are struggling with that move, right? You know, they're looking at it as, okay, I'm going to have to completely rebuild front end stuff. I'm going to have to completely refactor back end stuff, because I can't do the customizations in the way that I did anymore. And so I think for a lot of them, the choice is, okay, we move to headless entirely, and look at new vendors, or we just stick with what we have on prem because that halfway solution, I'm going to have to do all that refactoring anyways, of moving to something new, and the headless stuff is priced differently. And, you know, I may have the on prem thing as a capital asset or whatever, and, you know, or those were my investments in the hardware and the infrastructure and the processes and to, you know, shift all of that to cloud and sort of throw out all that investment in order to be, you know, it's like a car that you've owned for 10 years, but you're, you've maintained it really, really well, you want to throw that out the window entirely to go to leasing, like, even if the new car is, you know, slightly nicer.

You know, all of that investment is now worthless. And so, you know, I've, I've been hearing pretty regularly that that that that real big push from Adobe to, you know, am as cloud service, and from site court XM cloud hasn't really been as successful as they want, because that, again, the value proposition of that buyer has changed in. And so the old buyers want the old value proposition. And so they've had to kind of say, yeah, we'll support that model for a lot longer than I think they would have liked. Sorry, I got an earthquake drill message. Fair excuse. If we see things start moving, then, yeah, yeah, no, no, totally get the whole pricing as well as the mentality from a buyer's perspective, and then just drilling into just a tiny bit, not that we need to go into that. But there's also occasions where they can't do all cloud because of the industry they're in, regulations and stuff. So there's still going to be a market where on prem is a thing just because they need to control the place that it's hosted on, or the data center needs to be theirs and not not all vendors let you have your software to install it wherever you want. So that'll still be in a good niche of the market, for sure. Yeah, well, that goes back to, I'm going to go back to a slide like part of that procurement hassle often happens in regulated industries. You know, the buyers really have a lot of interpretation of legalities, as far as, like, you know, financial buyers, healthcare buyers, government dealing with accessibility, etc, and they need to validate upfront, and so they push that to the vendor, and that that ends up like codifying this into a waterfall process. So, yeah, regulated industries, you know, big procurement challenges. You know, to your point, still have a preference for on prem that is changing a little bit. You know, some FedRAMP stuff is, you know, moving towards cloud. And you know, some other countries are starting to certify that a little bit better, although, you know, there is a big question about data sovereignty, which is now starting to rear it's had a lot more there too, as well. So, you know, yeah, that's, that's certainly part of it for sure.

Let's see here. So I'm going to skip to couple. Oh yeah, these were, this was a fun part. This was, this was, you know, ranting some, you know, poor patterns and procurement. So we've, we've talked a lot about vendors and you know what they can and should do this. This one, this one's, this is funny, because this is a shared delusion between buyers and vendors, like, oh, the new CMS will solve everything. The new brand will solve everything. Personalization will solve everything. Headless will solve everything. I call this a shared delusion, because it, you know, it benefits both the buyers and the vendors to be lying to themselves, right? The buyers are like, Hey, we don't have to think about underlying process, governance, whatever. We're just going to solve it by throwing some software at it. And that prevents them from, you know, really getting to the roots of what their issues are, you know, preventing whatever it is they're trying to achieve. And it suits vendors as well, because they're like, Yeah, of course, we're going to sell you a new CMS, and that'll solve everything. And so, you know, this, this is one of the biggest shared delusions, and I think this is one of the biggest problems, is shared delusions, right? And, you know, that's, that's, that'll always be a thing. I think, you know, I think there's a whole other conversation about what organizations, you know, need to do to get out of the shared, you know, the delusional thinking. But that's maybe another webinar. Now there one that we discussed, and we've, we've talked about it already, is really the tyranny of the RFP, you know, I have the Oscar Wilde quote, you know, this is, this is a man who knows the price of everything, the value of nothing. I think RFPs, you know, ideally should go away. I think there's, there's a handful of exceptions that really go down to regulated industries and buyers that, you know, as I said, they're having to validate a bunch of stuff up front. If you're a government buyer doing that for procurement, you kind of have to go through an RFP for everybody else you should be, you know, looking at POCs, you know, because it's there's, you know, vendors will often answer yes to everything because, like, yeah, I can do it. We can turn any CMS into something that can blog, you know, we can turn any CMS to something that has a headless API, so the answers are not useful to evaluate what you're trying to actually evaluate in answering those questions.

You know, things that they do here, they minimize non functional criteria. So we were talking about that, you know, 20% or whatever that was, you know, good relationship. And I was saying it's philosophy, but this is all of these things, how is the onboarding? How is the Partner Network? Work. How's your geographical footprint, how's the community, how's the documentation, you know, how's your reputation among other buyers like, you know, these things, and again, every organization cares about these things differently. Often, these are hard to evaluate in an RFP, they're easier to evaluate through, you know, your own means, including POCs. You know, we actually, yeah, we undertook some research at the mock Alliance, you know, when we saw the same sort of thing, you know, Legacy processes, sales tactic, mismatches, etc. I don't, I'm not going to go through all these slides, because we have this on the website. And maybe, you know, actually, we can share this. But you know, there was, there was a lot that we were seeing from the mock Alliance perspective as well. So I'm just going to skip to the end, because I think there's a few interesting points here, you know, and we've talked about some of them already. As a buyer, be really clear about what your tasks are. Prioritize appropriately in the process.

You know, this is also useful for signaling to vendors what's important to you as a vendor. You know, work to understand all those stakeholders. And I mentioned like, yeah, long term retention absolutely depends on, you know, keeping those 5000 people happy whether or not you're selling to them or not in the initial sale. So, yeah, you know, more stakeholders, more points in the process do POCs instead of our RFPs. And you know, again, be clear about your goals. This is a really interesting one, because I saw this a lot in you know, previous lives where you know, a buyer will have a clear set of goals and sort of go into the demos, and then the demos will completely wow them with stuff that they didn't know that they wanted. And like, Oh, I really want personalization now, or I really want this or that. Like, Well, do you really, like, you know, Don't be swayed by shiny features. Like, be really clear about what your needs are up front. Shiny features being pushed by vendors. Do a few things they you know, one, stack the deck in their favor, right? Like, if you're being, if everybody's being ranked off that sort of clear criteria, and a vendor blows, you know, your socks off with something shiny, then they're going to be the front runner, because they push the criteria in a direction that suited them. And so, you know, be really clear what your requirements are, because, you know, often you may be chasing the shiny thing at the detriment of, you know, what your actual needs are, you know. And then, you know, the flip side of this is from the vendor side, like, you know, really, they should be understanding what buyer success criteria are a lot more as well. Because it goes back to that conversation the way at the beginning, which is, you know if, if you're selling and you're mismatching, and the team of the vendor, and you know implementation, and you know the buyer, and you know whatever that team looks like, if they're not happy and successful, then you know you're not going to get that case study. You're not going to have that retention, etc, etc. And so, you know, understanding what that criteria is up front is also very helpful as well. So that was, that was pretty much all of this in a nutshell, and we've got a few minutes left. Yeah, no. Talk about anything else, but, yeah, that's almost, I haven't I think we're good on time. I don't see any more questions again. This is, I know you can get into a lot of these conversations, and each deserves its own own webinar by itself, but thank you so much for your time Mark. This was really fun. Yeah, no problem. And Yeah, happy to talk about these in greater detail, you know, I'll follow up on LinkedIn, if anybody wants the slides, you know, D connect, DM me. I'll send you the slides, and then, yeah, happy to have these conversations and also post the mock Alliance research about procurement as well. Because I think that's really fascinating. That was, that was a very interesting bit of effort that was undertaken by them, you know, on the subject of composable and you know where, where there still are challenges, and what we've been doing to address that, that's awesome. Thank you so much. Mike, great. You.