Hello, everybody.

Welcome to, five of our part six series on selling MDM to leadership. This whole, series around, selling MDM to leadership has been not around the technology of MDM, but around to get it adopted quite often someone in IT has an insight as to something that MDM could solve, but getting the justification over the line and getting it set up, in a on a path for success, can be a challenge. So that’s really what this has been all about.

The Let me just put this right here. The previous sessions have covered organizational readiness.

You know, are you ready? Is your organization ready for master management? How would you know one way or the other?

Defining your the prioritization and the rightsizing, the scoping of it for, you know, why should we do this? Looking at the total cost of ownership calculations, what, might be part of that. What might you have overlooked that you didn’t think of? Yesterday, we looked at, the program scope. How do you scope for quick wins We all know that, in enterprise software planning for quick wins, and then growing from there is is a good way to, build what we call the momentum or the enthusiasm flywheel.

We talked quite a bit about where to focus in quite a lot about implementation style, some of the details around that, because sometimes we get, implementations can get tripped up when there’s misunderstanding or expectations around that. Today, we’re gonna talk about evaluation pitfalls. We’ll talk about that a more in a second. Then tomorrow, the lesson in the series is, talking about how to get beyond the first use case we have found, and this is very consistent. The customers, most of our customers deploy a second use case within the first year.

And then quite a few of them go on for several more beyond that, and they’re the ones that get the most value. That you start to get exponential returns when you start to do that kind of thing. So that’s what tomorrow is is all about.

Today, though, is all around the evaluation pitfalls and, it should be an I’m looking forward to this. It should be an interesting session.

We often we see evaluations, of course, from the other side. We see people doing evaluations, and it’s usually fairly clear to us early on whether, someone is building evaluation that will produce a great result, meaning pick the best possible software solution and, you know, scope and and, you know, if if their head is on straight in terms of, how they’re going about it, or if they’re not. And so, we’ll, bring down some of our, collective expertise around what we’ve seen that works well and what doesn’t. And hopefully, that will be helpful for you.

I should mention that, all of these, sessions have been recorded or will be recorded and they will all be available on the, proxy website. And if you’re, if you register for this series, then you’ll get a summary of all of that at the, and once all the recordings are available. The other thing I’ll say is, you know, we’re not here to be sales y at all around prophecy, but, the people that you’re about to meet are available for, future conversation. If you’re, if you are someone who’s interested in MDM, getting into an evaluation or whatsoever, we’re all fairly, passionate about this topic. So if you are too, then we’re happy to, to, to follow-up and connect.

These are our speakers today. I’ll introduce them. I won’t ask them to do it themselves, because this is the fifth time. And for those of you that have come back, several times, this is getting tedious. So Bill O’ Caine is, regarding our analyst, and, VP of mark, of MDM.

At, a prophecy here, Bill managed the, magic quadrant for master management for eight years. And has a huge depth of experience, in the topic. We’re very happy to have him, with prophecy and, happy to have him on the on the call here. Christopher Dwight also has, many years of experience in master data management and data quality and things data related He is a VP of customer success at prophecy.

Harvard Bernard is, our value management consultant. He owns the VIR or business impact road map program here at uh-uh prophecy and and broadly speaking, that’s helping customers figure out, where they’re going to find turn on investment from their MDM investment, and that, it gives them a broad understanding of where they should start.

I’m, Martin Boyd, VP product marketing prophecy, and I’m gonna be, moderating this, session. So hopefully that’s enough to get us all started.

And, the the one thing that I I’ve, you know, when you’re when you’re thinking about, to evaluate, you know, if if you don’t know where you’re going, any road will get you there. It’s one of my favorite quotes from Lewis Carroll in Wonderland, and and that’s true for almost any endeavor. It’s very true for master data management because there are so many things that MDM could potentially do for you. We kinda think of it sometimes like a Swiss army knife. It’s got so many different things that it can do. If you’re not clear on what you’re gonna try and do, then, you know, you could look at the swiss army and I can go, yeah, it looks like it does a lot of things, but you’re not really clear on what it’s gonna do for you situationally.

And that’s, that’s what we’re gonna talk about here. Okay. So evaluating evaluation pitfalls first topic that we wanted to to to bring up was looking at business outcomes, not capabilities.

The graph here, I think, are are indicating, you know, these are not the MDM requirements you’re looking for.

So hopefully that’ll give you just a little bit of something to look at while we’re talking. So, Bill, let’s have you talk first of all about, business outcomes, not capabilities, and some of the advice you’ve given to, MDM teams over time on on how to to best think this through.

Sure. Thank you, Martin. So we’ll start off. I just wanna tie back a little bit to to the previous four sessions.

There is a running theme here. If you if you haven’t, noticed it, you will today and tomorrow.

You you you’re again back to business outcomes. So in prophecy’s case of business impact road map, if you have an ROI model that you use internally, that’s fine too. As long as it is delivers a set of use cases, that can be sequenced and signed off on in that type of thing. So, not just financial justification, but operational prescription, if you will. So, this is no exception. You know, looking at looking at evaluations and and what can go wrong is, again, that my set of, how versus the why. So again, it’s possible to to be to behave yourself and and pursue best practices all the way up to this point with, in terms of why and business outcomes, and then get tripped up during the evaluation.

You’ll hear from a little from Christopher a little bit more about this in the in section number two, but, you know, it it’s it’s possible to do all the right things and then get here and pull up somebody’s RFP template and go crazy.

And I speak as someone who who built the first version of the Gartner, MDM RFP template, which I think is is still in use. I don’t watch that get abused, and we’ll talk in the next section again about how that happens and why. But it pays to remember, to piggyback on Martin there that, you’re looking at a platform.

It’s a specialized platform, but it’s got a broad set of capabilities, really focusing on on all of them or even one particular section of them as a first stance, is again gonna lead you astray, potentially, if not, almost certainly, cause you to make the wrong selection.

Based on things that you either won’t need or aren’t as important or that could have been done another way by a vendor, that’s more suited to your industry or your use cases. Again at the end of the day. So again, remember that it’s not an app. You don’t run it through its paces to to make sure that it does does everything in a certain way. And, comes out with a certain outcome, a set of records that it always comes out with, and there’s no flexibility, prophecy and, and, some other MDM tools are pretty flexible when it comes to data model, in fact, a hundred percent flexible. So, again, you’re gonna be able to we get this all the time during evaluations.

Can we can we do this to this data? Yes. Whatever, you know, whatever you like. As long as it’s master data, the sky’s really the limit. It’s it’s the business’s creativity. Again, you wanna indulge that creativity even at this point in the process.

So again, capability driven evaluations can be misleading for a bunch of reasons that I think we’re gonna dig into a lot more. And I’ll just sort of reiterate the the incoming position of don’t don’t fall for the how.

You know, we often hear, I I want to rate a three sixty degree view of my customer. Okay.

You know, we we we thought we got everybody out of this habit, but, okay, what does that mean? Because I can’t translate that to what I wanna see from a vendor during an evaluation, whether it’s a demo or a POC, or something even more detailed parallel POCs, things like that. And again, we’re gonna talk about this later. If you do a proper POC or even just an evaluation without one, you’re gonna dedicate some time it. So there is an expense to doing these things on the buyer side.

And we what we’re really trying to do here is get the most out of that set of resources and time and expense that we’re going to incur and get the right outcome not just for, the first internal release of whatever this is, but, you know, subsequent years, subsequent releases, subsequent business cases, domains, etcetera.

So, I’ll throw it out to the the group here from there.

I’ll I’ll I’ll jump in on this. You know, you’re talking about how important it is to make sure you understand, you know, your your business outcomes and don’t focus just on capabilities I’ll I’ll kind of bring it back to yesterday when we’re talking about program skills. When you’re thinking about how to scope a data management program, we said, probably several times not all data is of equal value across the organization. Some data, some use cases are gonna have much higher impact than others.

The reality is true when you’re looking at technology, right, not all capabilities are of equal priority or or value to your use case. And that’s why it comes back to use case because all the vendors can spout off the myriad capabilities that they have, a lot of very proud of our solutions, and all the things they can do.

But not all of those capabilities are gonna be important for you. And the way you figure out which ones are important is by tying that to use So it’s it’s super critical that you do look at your business outcomes and use that to figure out what are the capabilities that are important. You’ll need to do that, not just for your initial use case. That’s when we talk about a program and a road map.

You need to be thinking about, hey, show after we show success, you know, going beyond to use case number two and three, what are the capabilities we’re gonna need there? In fact, if you think about, yesterday, we spent a good bit of time with implementation styles. You might start with high volume consumer data and do consolidation, but your next use case might be vendor onboarding or chart of accounts management that’ll be centralized. So you need to be thinking about what are the criteria for capabilities that are gonna be important for those two different use cases.

So Make sure you’re aware that not all capabilities will be of equal importance to you, which is the risk of using those standardized templates. Or if you just grab an RFP template from Gartner, or the myriad of other ones that are out there that you can find on the internet. You know, that’s the ones in our website.

Yeah. It that’s a generic set of capability measures. Right? You need to go through and really vet that.

Right. The intent of those is not to use them as they are. The intent of those use in the starting point and curate them down and weight things appropriately in some capabilities may not even be relevant to your envision of use cases in one, two, and three. And it probably shouldn’t mean you shouldn’t waste your time even evaluating those things.

So don’t take those boilerplate RFPs and just assume that that’s gospel and that’s what you need to measure. You really need to tune to the things that are gonna be important for your options. I I tend to think of those lists as a they’re they’re useful checklist of, you know, questions to think about. But, it’d be rather like going to the BMW dealership and saying whether checklists and saying, does it have spark plugs?

Does it have wheels? Does it have a steering wheel? You get a yes to all of those then I’m gonna buy it? Well, that’s not really how the thing goes.

There’s those are interesting questions for conversation perhaps, but they’re not the same as, an indication of whether it’s the right fit or not. I would also say, you know, and, having worked for a couple of vendors over the years.

If you concentrate on the on the questions and those things that really mean something to you, you’re gonna get deeper, more thought out responses from any vendor.

If you just throw the whole thing in them, you know, and you give them two days to do it, you can imagine, you know, imagine what would happen to you. If someone did that to you, that’s pretty much what happens.

And, you know, it’s, you know, it’s physics, and you have to get it done. And if there’s eighty, if there are eighty questions, versus twelve that are really meaningful to you, you’re gonna get, you know, some time spent on those. I one other thing. It just reminded me of their bill. Quite often, When a customer, a perspective customer comes to us with an RFP or something like that and a lot of questions, and they want us to fill it in. Our our reaction is tell us a bit more about your tell us a bit more about your business requirements.

And some most often, we we get into a good conversation, and that allows us to to give a good quality response to the RFI.

From there, sometimes it’s they’re treating it as a procurement process, and they are very resistant to talking about their use case sometimes may maybe there’s a good reason for that, but I will tell you that in every case, you’re gonna get a poor for a quality response because we’re not able to take your contacts into account. Just an Yeah. Question is, you know, fifteen percent of the value you need, you need a lot more guidance than that from people, I guess. Yeah.

I think that’s that’s something I see over and over is good to better to be pushing and as asking you, hey, tell me about your use cases and the business outcomes you’re trying to realize before I answer this RFP, because again, we’ve got it every vendor out there has a space army knife. We need to know where to put focus and where to put detail and even perhaps recommendations into that response. And if there is no dialogue, it’s just a blind RFP to every vendor, fill it out and send it back without any dialogue. Gonna get generic answers, which makes it really difficult for you and your evaluation to understand which solutions are really more aligned once you’re currently So, yeah, it’s a really good point, Martin.

Yep.

Let me just, bring up the next. This will be kind of free flowing and we can kind of go back on ourselves a little bit as we need to.

But what are the selection criteria? I I know that Christopher, you’ve you’ve been on the receiving end of a lot of, customer requests and RPs and evaluation cycles.

What are some of the things that you would guide people towards in terms of how they should structure their value their evaluation process? Access. Yeah. It’s that this really comes down to, I think you’ve probably heard throughout this whole seminar that, choosing to launch a data management program inside your organization takes some thought and investment.

It takes a lot of thought investment before you get started. And the same thing is true when you get to the point of saying, hey, we do think we need some technology to support our data management initiatives to support our business outcomes you really need to put some investment into structuring your evaluation and defining your selection criteria.

Like I said, many, many times, I’ve seen, requests from customers. I hear a prophecy and and other MBA vendors that I’ve worked at, that are very generic. And it’s it’s very difficult. I I can’t concern immediately, because I’m concerned that the customer is not gonna be able to really figure out the nuances and differences between the different vendor responses when all this sent out as a sub generic question. So You really need to think about how you structure evaluation process. And many organizations will use an RFP, but that’s also just one step of the process.

One of the first things that going back what we were just saying a minute ago is, you know, sometimes if you’re public sector, you don’t have a choice, but one of the pitfalls that I’ve seen is highly structured evaluation processes where there’s an RFP sent and There’s no interaction between the vendors and you, other than this this kind of rigid dialogue that’s completely managed by procurement.

One of the things that you ought to be looking for is vendors that are helping that are helping me educate you and and having interactions to flesh out use cases leveraging their experience with other customers to inform what you actually think you want to do.

In a rigid process prevents that. Right? And a good evaluation process is not just results in you selecting a technology.

It results in you being more informed about your solution. And the right technology to support. And in order to do that, you really need to be interacting with vendors, not just having this rigid formal process that’s, you know, completely managed via documents. There’s just nothing better than getting three different vendors in and drawing out the, the solution vision on a whiteboard, you know, you’re gonna learn from that. You’re also gonna get a clearer understanding of, does the vendor understand your use case in your business out So I strongly recommend against these highly rigid or structured evaluation processes that don’t include that kind of interaction with the vendors. Look, It’s an investment on your part. It’s an investment on the vendors part, but you should want to do it, and you should work with vendors that want to do that.

The other thing is, you know, if you’re focused on business outcomes, then you also need to be pushing your vendors to not only understand those outcomes, but understand the data and the data challenges that are underlying. Which means, you know, it’s great to do some initial demos with maybe just stock demos from a vendor with their information, but to really evaluate will the solution support the use cases that are driving our our business outcomes?

We recommend you push the vendors to work with your data. Right. Most vendors have mechanisms for doing that, and doing it in a way that is secure. If it happens to include any kind of, PII, but you’re gonna get much more, a much clearer understanding does the vendor actually support your use cases or not if you use your own data. So I think that’s something that’s an important push. The other thing, and we touched on this yesterday when we were talking about implementation styles, Some of the stakeholders inside your organization, and some of the leaders inside your organization may not be as up to speed on MDM, and Indian technologies as the team that’s running the evaluation. And if what you present to them are generic demos with data that’s not relevant, the likely vote of them being able to connect the capabilities being shown by the vendors you’re looking at, but business outcomes they care about goes down tremendously.

So remember, you’re trying to sell this vision of data management as a benefit to the organization to some stakeholders who may or may not understand as of how to connect those dots and using generic data versus your own company’s data, it just creates even more likelihood of that that bridge not being or that gap not being bridge.

Okay. Bill Biller Harvard, do you have what what are your thoughts on, guidance that you would give to a perspective, customer or someone who’s doing an evaluation as to what they what they should be looking for and and what they should be avoiding.

I would say that the thing the the two things that I would add in, and Christopher really touched on on them to some degree is, you know, be flexible be ready for example. If you see something that looks like one of your use cases, don’t be afraid to ask, you know, this looks like this applies to this. Could you explain that a little more? Be willing be willing to change your evaluation criteria, you know, during the process. If you see something that it looks like something you you hadn’t thought of or hadn’t brought to the business, you know, one thing we wanted to bring up, I know for sure is, some of the some of the less than best practice as I’ve seen over the years were, you know, bringing these vendors in, to evaluate them and letting them do all the work and not having enough resources ready to to face off with the results of the evaluation.

And in effect, I I I wanna balance the discussion that I came at from one direction in the beginning, you know, you wanna focus on business outcomes, but eventually you do need to get the capabilities from the mapping down from those outcomes. And you want to know, for example, at the end of an evaluation, how did you do that? You know, what do what did you do? What how did you said configuration not coding, show me all the configuration and the fact that you didn’t have to code anything.

You know, I was Are you seeing there’s a potential for smoke and mirrors with software vendors, Bill, that Is that what you said? I had a vendor once twenty years ago spend. It was an ETL vendor. Spend a month with me for free.

The vendor was a fine vendor, but we had a lot of very complicated data structures. And after a month, the fellow the poor fellow did a demo and it was basically a one big code frame. He had written procedural code inside the UI of this this application, this platform, and he was at, like I said, I always say, he was out on the sidewalk about ten minutes later because someone piped in, and again, twenty years ago said, I could have written this in Cobalt in half an hour.

And and then everybody else could maintain it, you know, we and it’s a shame because it was a good tool, but we couldn’t move forward because of that.

So, again, This is a platform, not an app, which means there’s a lot of flexibility, things that we put in, for example. So, you know, prophecy has an SDK, but that’s there for outliers. Right? It’s there for someone who’s who who has the product and just wants to do something that’s really unique, and there’s no way anybody’s gonna provide it, and they wanna control it, a hundred percent, That’s what that’s for.

You know, if if if you see somebody using something like that to fulfill five of your six use cases, let’s say, take a pause because, that that means that’s what you’re gonna be doing, or somebody you’ll have to pay a lot of money to.

Yeah. Absolutely.

Let’s talk about quote for a minute. That that comes up in selection, checklists, a lot these days.

And, you know, deploy in the cloud means a lot of different things at this point between SaaS, software as a service, IS, infrastructure as a service, and pass platform as a service.

And they all have different, implications. Oh, and being fully managed, or hosted, versus the customer doing it for themselves. Why don’t you start pick up a little bit and talk a little bit about some of those different options and, some of the important distinctions between them very often customers come to us with a request and we don’t most of them are pretty cynical as to whether they really understand the depths of or the implications of the request.

And in this we could almost rename this entire thing. We say that evaluation pitfalls don’t get tripped up. It’s You could rename it prior beware.

Sometimes things that are being proposed by vendors are are being done deliberately.

Some of the solutions available on the market are very complex.

And so vendors will propose, hey, we, we offer this great hosting service. Let us host for you. And the reason being is that, hey, under infrastructure as a service, if you try to host it yourself, you’d have to be dealing with this huge complex behemoth and complex patches and upgrades and difficult installations and multiple VMs to support the solution.

So the vendor will propose, hey, let let me do an SP service. Let me host it for you.

And one of the reasons for doing that is not just to add a different service or get some incremental revenue and sometimes they’re trying to mask the underlying complexity.

So be careful about you know, contemplate why your vendors are are recommending what they’re recommending and and be willing to probe those things because sometimes these the recommendations are masking some underlying issue with complexity.

Indeed. Someone wanna talk a little bit about the difference between, infrastructure as a service and VMs and the skills required and then platform as a service.

Bill? Sure. I can I I can, as as as I have to approach this academically as an analyst? So I can give the academic view. It’s a little in this case, the academic view is a little oversimplified just to make the point.

But but I think it’s probably helpful. So infrastructure as a service, the way to think about that is, actually, I’m gonna go backwards.

So software as a service. We get this a lot. I I I wanna I wanna software as a service MDM solution.

And, you know, at Gartner, we would say, you know, you don’t tell me why, and then they would, let’s say whatever capabilities or or use cases they had. And we would say, you know, that you don’t don’t want that, and it really doesn’t exist in most cases. There are MDM solutions out there, with data models. They’re more like apps and platforms.

They tend to have been around longer. I actually helped to build, one of them. And it there are use cases where that’s quite appropriate. They’re they’re in but they’re but they’re they’re very they’re pretty narrow.

As well as being infrequent.

So the idea is, you know, without a fixed I’ll I’ll cut right to the chase. Without a fixed data model, software as a service doesn’t make a whole lot of sense. You know, there are no SQL solutions out there that do that say they do it, and they they do because they use document databases. So, yes, the documents have a different structure everywhere, but they’re all documents. So we can call that software as a service, and I don’t think that’s incorrect.

But in the relational world, unless you’ve got a fixed data model, it’s really hard to do, if not impossible, to be software as a service.

Properly because, you know, I always compare it to look, you can do go into the cloud, software as a service for your HR app. Or or even your ERP, those data models are the same for every customer that you that does that with whatever the the vendor or provider is. And that you may even be in the same physical tables. And that’s not a bad thing, but it’s more appropriate to a fixed application than a data management.

Environment, which platforms are now the predominant style of implementing.

So that’s that platform as a service, which is where we fall.

And we’re we’re the only really pure one out there. I I I think for MDM is, you know, we use a lot of shared resources we do allow in in the client’s tenant, for example, on Azure, you know, a separate instance, and we still use the same engine across that and allow upgrades to happen, initiated by us, but happening on a tenant by tenant basis. So, you know, again, you get the model flexibility. You get the resource flexibility, but you don’t you’re not tied down to a model, as you would be with software as a service.

And again, this is the academic definition. So take it that way. Finally, we have what most what most of our competitors do, honestly, is infrastructure as a service. And even at Gartner, I would get briefings where the vendor would say, here’s our s here’s our SaaS solution, and we would listen and say, that’s infrastructure as a service.

Well, yeah. But people people say SaaS and cloud interchangeably, so that’s we just tell them it SaaS because it’s too hard to explain all this stuff.

And sometimes it’s not helpful, honestly. But infrastructure as a service, you could just think of it as it’s just like I did it myself, but it’s not on my hardware.

Yes. You know, or on my real estate. And, you know, the sooner you people figure that out the happier they are, it’s a it can be appropriate in some instances. But it shouldn’t be confused with what people asking for when they say software as a service.

I I hope that’s helpful.

You know, it seems it seems really geeky, but it comes it it’s important at some point in your process. Yeah. Yeah. One thing that, If you only look at the surface, you may go to a vendor’s website and maybe click here to install on the cloud or to to bring up your cloud instance, whatever.

And it may take only a couple of minutes to get something running, but what’s it gonna take to then configure that and, manage it over time and apply patches to it and things like that. If you’re in an IAS world, infrastructure as a service, you’re essentially just installing lines of code on someone’s, hosted server. And you still need Java or whatever kind of skills to set it up and configure it and run it and and, maintain it. So you may not be getting all of the cloud quote cloud advantages that you you thought you were asking for.

And it’s one of those things. When you need to ask some very precise questions in order to make sure you know what you’re getting in for. By contrast, I would say in generally generally speaking, platform as a service, using techniques like containerization, you should be getting much closer to what you want to, which is, the ability to have very flexible, data definitions and flexible access to your data and things like that, but not having to, have a lot of technical skills on a on hand to, to manage it. So, there’s there’s a whole spectrum of ways that Bill was talking about of being quote in the cloud.

Some of them may work really well for you and some not. So that’s, that’s very much a buyer beware kind of, thing. The right question. You also wanna make sure, that the code not as if you can’t make sure the codes are the same across all the environment, so you, at least make sure it has the same capabilities. I’ve actually seen that over the years where somebody went to the cloud from an on prem. They migrated and found out, you know, the top five, use cases they had couldn’t be a hundred percent supported anymore when they got to the cloud. For whatever reason.

And, you know, again, the safest thing, obviously, if the code base is exactly the same as ours is. But if it can’t be, at least make sure you understand what what the what the delta is between the the environments?

That’s absolutely true. The other thing that really gives me the EVG, because I still get this is we have, prospects come to us and say, well, we want a cloud based solution.

That is, That is a really risky way to approach this. You really need to make sure you understand and detail the difference between infrastructure, software, and platform as a service. And then you need to make sure that you really push the vendors that you’re looking at to really vet because again, they’ll just say, oh, we’re clouding. They’ll they’ll try to skirt the detail and script the the questions and represent something as cloud native when it might really just be infrastructure as a service.

The other thing I would say is if you are looking at vendors that are infrastructures of service, what you really need to do is is make sure that you get some references some reference call set up. And you need to ask about, hey, how much time do I need to plan? How much money do I need to plan on? For patches and managing and just, you know, managing my infrastructure out there in somebody’s cloud service.

And then the big question, really big one is, How often do you have to upgrade? Are there forced upgrades and how much effort was that?

And you really need to ask every one of the the vendors that you’re looking at especially if it’s infrastructure as a service. Right? It’s just super, super important that you’ve got full clarity on that, in that your criteria should not be I want a cloud based MD. Yeah. Your criteria should be we prefer cloud, but we also need to make sure we understand what flavor of cloud are the vendors proposing and what are those intersections?

That kinda brings up a another, related question around skills and, technology fit.

How do you guys view, the the skills or the the the the internal bias of the customer, in terms of, you know, Java or dot net or whatsoever as as being part of it. Usually, they’re asking functionality questions. Talked a lot about business outcome, but where does the, is is there a, a place for the technology fit in the evaluation.

Oh, go ahead, Chris. Go ahead. How top of that? I think that’s a super important consideration.

You know, I’ve I’ve literally over the years, I’ve I’ve represented different platforms in this space. That are built in different technology stacks. And one of the things that is is a bad problem for you. Right?

If you’re selling MDM to your organization, your leadership that outcome is to select a solution and technology solution that has all the bells and whistles that you thought you wanted, then come to find out There are certain skills required to configure and maintain it that you don’t have. And now you’re either gonna have to go out and spend money on consultants or hiring those skills And that’s not a fun conversation to go back to leadership with.

So it’s important that you think about, hey, what is the underlying technology If I do need to do something truly uniquely one off and use an APR and extension what are the tools and skills that are required to do that, And are those skills and tools that we are those resources that we have available, you know, that we could allocate towards that purpose versus having to go higher or, get consultants or third parties.

And I it’s often that’s part of the criteria, but sometimes I see it overlooked. By by prospects. And and again, that’s scary because it’s it’s a risk factor.

Exactly.

Sometimes we we in evaluations, we ask questions, when it, about, you know, can you do x or can you do y? And, feels like we’re being asked about the latest, you know, fad, that, may or may may not be relevant. Can you, Christopher talked a little bit about to product features that might sound great, but may or may not be as, about the customer’s specs or or or that we think they may never even use. So that’s this is there’s two things here. Those I put those as the, the pie in the sky requirements.

That come out from, from people that, hey, we wanted to do x, y, and z.

And if you actually prove it as to why do you need that, or the specific use cases and business outcomes, they usually stumble. It’s usually because while it’s neat or taught, or it’s a cool technology, right, which is That’s not a very good evaluation criteria. And often, those capabilities don’t even end up being utilized. So I’m always a little bit nervous about some of these pie in the sky.

Requirements. And the reality is, look, we’re technologists. Most of the people that are evaluating MBM technologies or technologists in We we are interested in technology innovation. And so we are attracted to the the new hot things.

You need to make sure that the criteria that you’re driving to and the capabilities that are relevant are tied to a specific business outcome, not some hot new bus Right? Because we get excited by the buzzwords. Software vendors are guilty of latching on to buzzwords and throwing them into their marketing material where they’re relevant and not we’re sort of like moths to a light. I’ve seen there’s somebody who goes around there.