Your Product Catalog Is A Poison Pill (and AI will make it worse)

Today I'm talking for the second time on monetizing AI with Kevan Dasgib. He's VP of go-to-market operations at Payscale. Kevan spent, what, 10, 15, maybe more years building and fixing revenue operations for high-growth companies like ZoomInfo, Mural, Tegus, now Payscale, which just acquired Data People. So I imagine you've got some really interesting operational initiatives ahead on the integration. You know, one thing I really have always appreciated about you in our conversations is, you know, and this is maybe slightly self-described as well, but you're this moneyball-minded operator. And I think that you've really operated with a belief that RevOps is about finding the right story for the business in the data. It's about uncovering the constraints on the business and then removing those constraints methodically. And so today we're going to dig into, I think, a bunch of interesting topics around the technology that we're using to grow our companies, particularly in software, particularly in AI. I think we're going to talk about the quote-to-cash stack. We're going to talk about tool sprawl. We're going to talk about data. And so I'm really excited. I'm really grateful to you for being here.

Well, thank you, Fynn. I'm happy to be here. It's always great discussing such pressing and I would say often conversations that have a tremendous need in foresight based on the needs of high-growth businesses. And your questions always are always a thought scratcher for me. So I'm looking forward to seeing what you've got cooked up.

Well, let me kick off. I'll just start by like something that I'm writing a piece on this right now. It's something I've been thinking about a lot and it's how And if you kind of look at the modern software company, it is like a machine and it is built on top of other machines. And, you know, in companies that I've worked for, like we've hired companies like Salesforce and NetSuite and various CPQ tools and outreach tools like Outreach or Salesloft, call recording Gong, customer success tools like Gainsight, which are kind of like CRMs in and of themselves. A long list of billing tools, all of these end up stitched together. All of these are sort of purchased by different functions within the business, you know, in the spirit of helping the business grow faster. And yet there's sort of a paradox, right? Like you end up with all these best of breed tools in these different functions across the business. And it gets very difficult to retain efficiency. It gets really difficult to evolve monetization. It gets really difficult to have really high-fidelity data that is normalized and that's trustworthy across different functions. And so I think you've lived and breathed a lot of this, and I think this is a paradox. And so maybe my first question to you today is, when you look at the modern quote-to-cash stack, how do you think about its structural flaws as well as its structural opportunities?

Oh, way to start with a doozy. So I'd say the biggest structural flaws that I see with modern quote-to-cash is comically in the product catalog itself. Businesses often forget that the product catalog is as much a product as your product is. And what I mean by that is the various things that you're selling, the things that you're pushing to go to market. Whether that is add-ons, features, integrations, the core bundles themselves, those should be treated like a product, uh, in itself, like how you package it is a product, which means that you need to have change management. You need to have a single source of truth for, uh, what is this product actually, its capabilities. So your product catalog is Okay, who governs this? Who, uh, uh, price, term, entitlement, identities, uh, how do we take all of the various feature flags and functionality and bucket them under product families, subfamilies? Which of these things are datasets? Which of these things are integrations? Which of these things are the core software platform? Because a lot of these also not only have, uh, uh, customer experience, but they have tax implications, they have revenue implications. So the way you bring your entire product suite to market has material financial impacts on the business. If you are selling just a single bundle, which has a dataset, an integration, software as a, as a software bundle, all of those things have different financial implications. So why would you want to sell a dataset as an integration when you should be parsing those things out? So your product family dictates, okay, if we're selling, this is our product. It comes with 3 different pieces. Maybe we charge for those, maybe we don't, but you should have them categorized within the product catalog if there's specific features or functionality that then dictates some level of You know, uh, how this appears on an order form, because those are the things that tie from, from implementation all the way to, uh, revenue recognition. So that's the biggest thing right now. And that, uh, I see that as constant across every business that often that when that becomes a critical like blocker is when organizations start to say, cool, we need to redo our pricing and packaging. Like that is, and that's usually because there is an inconsistent story on what are we selling? Customer success has one perspective, account management, new business, product obviously has their own perspective. Finance is on the, the very tail end of all of this. And they're like, well, we just take whatever is given to us. We'll have to create new product codes inside NetSuite or whatever your billing system of choice is. And you end up in this world where like every change turns into a bespoke project. Where billing, CPQ, the CRM product, each claim to be their own source of truth. And you get into this wonderful dynamic that happens. I say wonderful with all the quotes and italicization I can do on that is, oh, product is, this is how it looks like in the product. Then you have to have a crosswalk to say, these products is how this looks inside the CRM in terms of like, What is the master product on this account? Or what is the, uh, the, the core feature bundle that they have on this account? And then you have to go look at the opportunities and the order forms to see, well, what are the actual things that they're paying for to double-click into, well, the account tells me this, or the, the, the op— the, or the like customer instance tells me this. The product tells me all these lists of feature flags and the order form tells me like 9 other things. And there is no. Interconnection between the three of them. So you spend the time going, I have a spreadsheet that tells you these features are part of this set of quote bundles on the order form, which relates to this, this detail, this checkbox, this picklist on the Salesforce account. And it's maintained by one or two people. And then God forbid one of them leaves. Now, now you have all that intrinsic tribal knowledge disappears. No one's managing that spreadsheet. It gets out of date in two weeks. And now you want to go make a change and CPQ will launch a new feature and no one knows how to actually make that happen to make all of the systems talk to each other. So that's what I say, like, it really needs to be treated as part of, like, the product deployment effort is how do we manage this as critical a component as just pushing a new feature to the production environment? As it needs to be treated as our product catalog is just as rigorously controlled and It, so are its downstream impacts across systems.

So first of all, it's incredibly interesting to me that you started with product catalog as the biggest flaw in the modern quote-to-cash stack. It's interesting to me because I also believe that, and I'll, I'll sort of riff for a second on what I've observed, but maybe before I do that, I'm curious, you know, do you think that if we polled 100 RevOps leaders, that would've been their first answer as well. No. And I think just to synthesize your answer, I think what you said, I think the biggest flaw that you're describing is you have disparate product catalogs across multiple systems.

I would say no. And I think that's because, and this is not to knock on obviously a world of stellar RevOps leaders out there, but you have to have some perspective on both the product and financial elements of this, not just the go-to-market, to know what are those downstream implications. Uh, I'd say that RevOps leaders are probably more likely to identify issues in CPQ configuration than anything else, first and foremost, because that is where systems teams are going to spend the majority of their time. Uh, you're going to have, well, likely some sort of deal desk team or at least a deal desk manager who is involved in closely working with go-to-market and finance and legal to build out contracts and order forms for our, for your customers. These are all things that are like near and present danger. So they take up a disproportionate section of our mindshare, but that is like, like horse with blinders on. You're, if you're focused on, okay, my CPQ system is a problem right now. Maybe our users are encountering errors constantly. Like, I have my own grievances with Salesforce CPQ, and there's lots of new CPQ, you know, software that's on the market, some of them very good, that simplify a lot of the challenges that we see in the code-heavy environments like Salesforce CPQ and Revenue Cloud. So if you're thinking about how do I make this system less bloated, chances are you're not, you're essentially at, uh, solving a symptom rather than the root cause, which has either become the business has a difficulty reporting on products and revenue. And so some of that burden has been shoved onto CPQ to create a set of weird reporting dynamics that's made Salesforce bloated. It's made, uh, uh, the data incongruent. Then there's also the element of like product is saying, hey, we need to know what to turn on or what are the feature flags or the implementations team, whoever's doing onboarding is like, we don't know what to turn on in the system because CPQ isn't as explicit as it should be. Or we don't have that obvious kind of like crosswalk that says these order forms equate to these feature flags inside, inside, you know, an instance when we turn them on. So what ends up happening, either CPQ starts to become bloated because order forms become essentially just lists of feature flags to turn on, which is not what CPQ is intended to do. Or you get into a world where CPQ has now copious number of data points for RevRec purposes because you didn't build out the product catalog crosswalk between your billing systems and CPQ. So one of those situations is likely causing the downstream impact of CPQ doesn't make sense anymore. It's not intuitive. It's not easy to use. It's hard to make changes in it. So that's the thing I would always push our RevOps leaders across, you know, across the entire sphere is take a pause. Like, is CPQ broken because just CPQ is implemented poorly, or is it because it is the downstream catch-all for other upstream business challenges?

So, okay. I think that this is such a, this is a subject with a lot of potential surface area to go into. I want to, I met a guy named Mercia Panna 2 years ago who was running product at VMware and he'd spent a lot of his early career in telecoms. And he said, you know, one of the things that was so interesting about telecoms is it really kind of figured out quote to cash or quote to order. From a systems perspective in a way that I don't think SaaS has. And I asked him to explore it a bit and he said, I think what I have observed in software is we have very little respect for the product catalog as a critical component of both how we are going to commercialize our products, but also how we are going to maintain true business efficiency from the release of new products all the way to quoting, closing, revenue recognition expansion. And he said something, I kind of have always sort of remembered the quote, but he described it as we should think about the product catalog as, I think he described it as a unified design environment rather than as like a mere SKU registry. And I think what he was trying to say is like the product catalog is like this critical unifier within a company. And so it sounds like you would agree with him and it's really interesting. And when I asked that question, I think I was kind of coming to a similar observation, like something that I have said many times to folks at Schematic is it feels to me that all of the innovation in the modern quote-to-cash stack You could deduce it all to a simple single battle between the vendors, and it is a battle for ownership of the product catalog. And while that sort of might make sense from a strategic perspective for a vendor vying for share in this market, what's sort of left as sort of a dissatisfying truth is Very few of these vendors, and you're, you're kind of using the terms downstream and upstream, can actually control and enforce how we monetize our products. And so I wonder if, if what I just said resonates and how you might sort of respond to it and maybe kind of like go deeper on that idea, that idea that CPQ is a system that is in some ways informing how we might quote a customer, but it's not actually controlling how we monetize our products end to end. Maybe react to that a little bit.

Well, before I get into that, I want to like comment on that telecom comment, which I think that is something that explains, I think it touches on something that is a larger SaaS issue. And that is something that any company that has had a physical deliverable, right, has had to solve this because there's a supply chain issue, right? If my product catalog involves physical pieces of hardware, you know, yes, there's obviously data components and implementations and services fees and all that stuff, but there is fundamentally, I'm delivering you a product that is physical, requires installation, requires running something like, again, I'm not pretending to be a telecom expert here, But the reality is there's often some element of a physical delivery of something of value. It forces a company to be able to trace that deliverable all the way through the supply chain for a variety of, of COGS considerations, right? So like, if, and that's what SaaS hasn't had to do because inherently everything you do is digital. So you can deploy quickly, you can ship changes, you can react to customer needs quickly, but your product catalog starts to spiral out, spin out of control because why? You didn't actually have to at any point in time tie back that deliverable to like, I needed to order this part from a manufacturer, from a distributor to build here and see every connected dot. And I think that plays a role is that many SaaS companies should start to treat a lot of the ways that they ship and deploy as a supply chain. Because then allow you, fundamentally, that, that logic, that logistics framework ensures that you always do remember the product catalog as part of your deployment process. Because otherwise, it's, you're, you're not ensuring the connective tissue makes sense. As a result, you don't have the supply chain, the logistics in place. So, um, I, I fully agree with that, uh, that perspective that telecom had this figured out. But I think that doesn't apply to telecom. It applies to any company. That has a— any company that's selling something that has a physical deliverable involved.

When it sounds like the implication there is any company that has, you know, real COGS. And maybe what you're saying is software has for so long had these very predictably high gross margins as an industry that has gotten software off the hook from having to care about a product catalog as a unified design environment. And even though that creates inefficiencies for companies, for example, if I have a product catalog in Salesforce CPQ and in Stripe and in NetSuite, that means a change to pricing is a change in, in all of these systems, not to mention my database. You're saying the world can accept that because we have predictably high gross margins. My question is, as we move into AI, do you think that that changes where our gross margins become less predictable? Are we forced to actually care about this? Not purely because it's inefficient, but because we now have to from a gross margin perspective. Would you buy that or would you challenge that?

I would say that AI does actually push us to be more thoughtful in how, because at the end of the day, Copilots that draft flows, validation rules, tests, data quality agents, all those things. These are all elements that start to very quickly erode your gross margin. I think we're seeing what that— there was a study I saw on, was it like 2 weeks ago that like, say at this point, like 90% of AI projects launched at companies fail, like, which I don't think anyone who's in our position is surprised by that. Because the wave of AI that came about with the, I would say thunderous boom that ChatGPT came onto market created this sudden hype that this is going to be a ground-changing fundamental shift in how companies go to market. And in many cases it has, right? There's, there are things that has fundamentally changed. There are plenty of things it has done nothing for. Uh, and there are leaders who are spinning their wheels in the mud trying to figure out how do I make AI do something for me? It's like, chances are AI hasn't been properly applied yet, uh, in the cases of this specific business context. And, you know, the thing that I think about AI is that, this is going to sound overly cheesy. But you can't do anything with AI until you sign like a data contract with yourself, right? Like that is your business needs to have, uh, because AI is only as good as the data you feed it. Like that's it, right? You can build, uh, and the infrastructure that you have to layer AI on top. Uh, if you want to have an internal AI that tells your, helps you onboard new employees, well, it has to have context on all of the various facets of the business. Do all of your different go-to-market teams, product finance teams have all of their contextual knowledge tagged with similar metadata signals that you can then use to feed an AI model that can then answer questions to an end user that respects the security permissions that those individuals that have? Because last thing you want is like a junior employee asking a question about, you know, the company finances that the board only sees, right? Like that is, uh, That is a thing you cannot do until you have like a comprehensive data contract across the entire business. So I think that as we launch more and more AI features and Anthropic, OpenAI, all of them are just going to start eating our lunches on token consumption because we want to launch a chatbot that does this, or we want to layer on AI, uh, vibe coding just to make things more dynamic and exciting for our engineers to debug later on. You know, those are things that are going to constantly come up and they're going to erode our gross margins. So, you know, coming back full circle is the more AI you use in your business, the greater degree of fidelity you need to pay to your internal data contract across all of your all of your teams. And if you don't do that, then your AI costs are going to spiral out of control. And you're going to have, and that goes back to the supply chain question is, I have these out of control AI features that are potentially consuming outsized budget components, but I don't have a way to tie that back to either specific sets of features or billing codes, which means that my product catalog is out of date. And suddenly my gross margins are disappearing faster than I anticipated they would. And I don't think this is going to cause companies to suddenly lose profitability, but these are like the percentage differences in your EBITDA that change your valuation by, you know, millions. So why you put that risk on yourself? So I would say, and I'm not telling companies not to use AI. I'm saying use AI. It's great. There's plenty of ways to do that. But you need to first ensure that your data strategy internally is in a way solidified on the concrete foundation that you can build AI on top of it. Otherwise you're just adding noise on top of noise.

Maybe that your data strategy is in the right place, but also that you have designated, I think you described like a, a source of truth for the product catalog. Yeah. It, it does feel like an opportunity maybe that is tangible for companies to really consider is there is this opportunity to designate one representation of the product catalog that exists in some ways to maintain like all product definitions, as well as reconcile product catalogs from other systems if you feel you need to use multiple systems., but also that, you know, can direct and enforce changes within the product itself. Um, and I'm curious, and I think that that takes me back to CPQ because something that has felt truer and truer to me as we've moved further into a world of consumption pricing and hybrid pricing and hybrid selling with product-led and sales-led and channel and OM and all of it, is it is our products that dictate and drive how we make money. And that requires a level of control for how we actually set those products up to be monetized, how we gate features, how we meter limits, how we enforce those limits. That control feels like it's lacking in the mainstream downstream tools that are largely owning the way we monetize software today, CPQ tools and billing tools, namely maybe to some extent, you know, NetSuite, you know, as a portion of their business being SaaS ERP. And so I would love for you to react to this line of thinking with me and explore it, you know, this idea that the downstream business systems cannot control how we monetize our products and therein presents a problem in a world where you do need to be able to have a single source of truth for a product catalog that is quickly delivering both correct invoicing, correct quoting, but also correct product experience.

Yeah, I think this kind of like, if I were to break this apart into two kind of like thought streams, first one is like, tool, like tools slow teams down because that's the nature of it. There's an inflection point as every company grows, as every business problem becomes more significant, is that what was being done by a human, because of the flexibility of the human mind, the adaptability of our ability to meet the challenges, there comes a point where the complexity of a problem scales out where you need a tool to augment a person to do something, right? So I think that's an important piece is that initially, especially we're talking about companies that are sub $10, $20 million in ARR, there's a lot of things you can just do with raw human horsepower, right? And I think what we find is that investors advise, operating partners, board members, they all advise, oh, you need to get this stuff in place. Do you, like, that's my first question is like, do, don't go dropping in tools because leaders buy point tools to treat symptoms instead of causes. Like, that's just how it is. So if the problem is, oh, we're, let's use a very simplistic example. We are unable to get order forms faster. Like our business is growing. We've gone past the 10-person small shop. We now have enough of a sales motion that we need to push You have to process a couple contracts a day. Great. That sounds fantastic for your business. Is the problem that you have a single person doing DealDesk and they're drowning? Is it because you don't have, you know, terms and conditions linked into your order forms? Is it because that, uh, every contract essentially is a bespoke order form based on the various features that you haven't cataloged, that you haven't taken the time to put together as a product catalog? Like there's some elements of like, hey, you didn't do the pre-work before the system can actually have value. So, you know, that was, you start getting things like, we're selling features, but we're skipping architecture, right? That's, so I would say that before I lose my own train of thought, like there's an element there where like we leaders like to say to treat a symptom instead of a cause. Then there's the other side of this, like, who owns this product catalog? Who owns the stack, right? And I'll say like the quote-to-cash stack in general. And I think in practice, no one owns the quote-to-cash stack, and they shouldn't. But there should be a, I'm gonna call it a revenue council of sort, which has a shared backlog, SLAs, a change advisory board. Sandboxes, things like that. And that could, that is a combined operating team that is product marketing, product, some finance representation, likely go-to-market operation, some capacity. And if you have someone who owns pricing strategy specifically, that should be your revenue counsel. Now, I'm not saying that you need to hire for all these departments. There's probably people who are doing these functions inside of, you know, as a company scale, there are people who have multiple hats, right? Maybe your product marketer is also handling pricing. Cool. Happy that you have two of those jobs to be done covered on the revenue council. But the idea here is that this group is the one that architects the strategy, and then they are the ones who say what tools we need to support that strategy rather than, hey, each of these teams built a tool to solve their specific business case. And then you shove them all together afterwards and say, now you all have to figure out how to make your tools work together. It's backwards logic. It's, that is putting the cart before the horse entirely. It's like, that is like, uh, there's two pieces, like the tools, you have to remember that this is not a, uh, this is not a symptoms, it's a cause question. And then how do you actually do the change management and the governance? You have to build a revenue council that is these individuals. Maybe the pricing manager, the product marketer, or the product is like the, you know, PM for this group, but you have them all together and they're the ones deciding, how do I make sure that the product catalog is equally and, uh, uh, the data fidelity is, uh, is held up to the highest standard across CPQ, billing, and product systems. And everyone on that same, and everyone on that call, everyone on that meeting circle speaks the same story. They all are able to understand, oh, if you want to go here, that's what that data looks like. It crosswalks into XYZ and this is how it's built here. And this is our changement. You want to launch a new product? Cool. This is how we do that. This is how we launch a new feature. This is how we update existing features. This is how we retire old SKUs. This is how we take the old SKUs and the legacy SKUs and what these map into the future pricing and packaging strategy. Otherwise, yeah, it becomes, as I said earlier, it becomes a bespoke project. I need to launch a promo. Okay, cool. So you just send a SKU from sales into go-to-market operations. They load it into CPQ. They kind of send a note to finance. Finance, we created a new SKU. Also, we gotta just let product know real quick that these are the feature flags that they need to put into this. Product's like, hey, we didn't agree to this. We, you know, we could do this. Like, well, it's cool. We need to launch this promo next week. So figure it out. Like, that's, I think every go-to-market leader can relate to that experience in some way, shape, and form the past quarter.

I think you're 100% correct. And I love the idea of the council. And we did that at Automox a bit as we tried to right-size the go-to-market tech stack. And I think it was a really useful and clarifying exercise for all of the different C-levels. To like really understand the extent to which the stack was accelerating them or constraining them because of things like bad data and things like that. One more question on this front, and then I'd love to kind of go into, you know, a slightly more detailed question around data and pricing. But before we do it, there's this idea that we've been floating, which is you should have one source of truth for the product catalog. What do you think that source of truth should be?

Here's my controversial hot take. It doesn't matter where, like, it's like, it just has to exist. I'll use us as an example. We're, you know, we're, we're building out, uh, we, we have our own product debt. Uh, I sit here opining on all of the, uh, philosophical and, uh, technical implementation, but we have, we're, we're, we're working on it internally as well. We're figuring out those things. You know, I've been here a few months now and I'm working with our core leaders on, who all have a very similar mindset on how do we get to a place of an ideal state of harmony between product finance systems and CRM and CPQ, right? And I'd say that we're of the mindset that it could be a spreadsheet. It literally can be a spreadsheet. The product catalog could be a spreadsheet. But there is a warden of that spreadsheet and nothing gets pushed into any of the systems, nothing until it gets reconciled against that spreadsheet. Either it is added somewhere, it is a net new item, it is retiring an old item, uh, and then that change then has to be reflected across all of the other tools because that product catalog is the strategy. That is the North Star. It could be spreadsheet, it could be, it could be Confluence, it could be the back of a napkin. Like it just needs to be someone is the steward of this and everyone agrees that this place is the source of truth. Now, I am sure there are fantastic products that can help you do that to reconcile across different systems, but I'd say it's the, it's the crawl, walk, run approach. If you don't have that first, Cool. Make your revenue council, have your designated governor of the product catalog that the revenue council is the one that like authorizes changes to it. And then the product catalog is maintained by, yo, a handful of individuals who have that kind of governance over it. It should be treated as such. It should be treated the same way that we do any other system that has integrity and controls around it.

So makes a lot of sense. I really like it. And it's, I think it's a really accessible crawl, walk, run approach. And maybe the question I'd like to spend the last few minutes of this on is related to data, but a particular type of data, and that's product usage data. And another type of data, which would be pricing or billing data, something I, I have started to feel. And maybe something I sort of felt was a very kind of frustrating problem at every company I've operated within has been, it's hard for me to tell you how the ideal behavior of a customer and how that translates to our pricing. And maybe another spin on that would be, I couldn't tell you how customer A's usage and pricing compares relative to other customers who use the product in a similar way. And that made it really difficult to do things like, okay, well, this cohort is actually like very high potential to expand, or this customer cohort is very high potential to churn, or, you know, plenty of kind of additional sort of permutations of that type of question, which is like, where is their opportunity and where is their risk? Can you talk a little bit about how you have observed that at PayScale and the extent to which you can answer those questions really easily or the extent to which you're building the practice and the tooling to answer those questions really easily?

I'd say that we have done, when I say we, as some of this work predates my arrival and that just shows, I think how forward-thinking around usage analytics and product development, you know, PayScale is. And one of the big ones I've seen is that it's simple as, you know, we have a suite of products from good, better, best to enterprise flagship products, right? Datasets, integrations, all of these things. Because we are a, you know, best-in-class equity platform for HR leaders and compensation experts. So the question of like, who's using this platform? How are they using it? When are they using it? Is something that has been done, that has a material amount of work has already been done. We have a strong, I think, best-in-class data science team. Now, I appreciate that not every company has a fully staffed data science team, but that's part of our product. We have internal data science to support the product. But we've done our own, we've eaten our own dog food. We've used these resources to analyze the users on the product. What are they doing? What are the things that they interact with? And importantly, based on that, configuration of data, built multi-logarithmic, uh, multivariable logarithmic regressions to identify, hey, what's the propensity for someone to renew based on their interaction with the platform, which is like one of my beloved projects. Anytime I go somewhere, I try to do that. Um, uh, and we, we've done a lot of that and we have some very helpful, uh, uh, usage-driven statistical models that help us identify which customers on the set of products are at risk based on their engagement. Now, is it foolproof? No, there's always going to be false negatives and false positives, but directionally it's very strong and that helps us understand risk. But importantly, why is there risk? Is it because they haven't interacted with certain core features? Is it because a bunch of our users, uh, use the platform as like a search function? They go in and they quickly are solving it. Well, If that's the case, we should find ways to make the search function more intuitive, more, uh, more intelligent, more, um, bake in more value into that initial upfront experience that the, the end user has. Like, these are the questions that drive a lot of product behavior and product strategies. We're looking what our customers are doing inside the platform, then looking at the customers who interact in that way, how many of them renew versus not. And then from there we determined, well, the features that we were investing in and spending time on, did those actually align with what our users are using? No. Cool. That's not going to make a material effort on the revenue side of things, which is driving GRR or NRR. So let's not do that. So kind of a long-winded to say, you need to ensure if you want to make sure that your product catalog is constantly evolving, your product roadmap is evolving in a way that can continually meet the demands of the market because your business, your, the customer's businesses are going to change. They're going to meet their own conditions and you need to keep up with them. You need to build a way so that usage data ties clearly to the customer experience in a way that is both intuitive for your analytical minds to go and build a story off of it, but then invest in the people that can build a story so that non-technical stakeholders can understand what are the business implications of not doing this. Does, uh, if I don't invest in this product feature, does that actually mean that we're at a competitive disadvantage because our competitors are investing in this feature? Now, I'm not saying you should always just do what your competitors do, but be aware, is it because that feature is fundamentally very important and your competitors are trying to keep up with you? Because that does happen pretty often. Similarly, do you have product features that you're heavily investing in, but the market has suggested that is not valuable and people are— it's not, not easy to monetize those. Uh, there's often a question with a lot of SaaS companies that have good, better, best models is how do I differentiate between each of these products? Well, take a look at your usage. Is the reason that you don't have a lot of people buying the best product versus the better product because it, the the feature differentiation isn't material enough to warrant someone to purchase that more premium product, then you need to start talking to your customers to identify, hey, what are the things that you want to see in a premium product that you'd be willing to pay for?

And that's—

the data will give you a good signal on what that is, what conversations you need to have, and also which customers you need to talk to.

You—

chances are your leadership team, your go-to-market team know who should be your 6-figure contracts. But if they're not, you should talk to them and figure out what are the things that you're not seeing out of our feature set that would indicate that you should be purchasing either more usage, more users, broader integration access. How do we deploy broader? There's something missing and that should dictate, that should be somewhat evident in the data already. So, and it kind of goes back to my, like a point that I haven't really touched on. How do you get all of this data accessible? You know, yes, you have your CRM that has Salesforce, you have your CPQ to handle all of the product configuration, but all of this shouldn't be coming together in some sort of data warehouse. You should have, uh, uh, Snowflake, Databricks, something, right? That is, uh, uh, ingesting all of this. You have some sort of reverse ETL to pump usage data back into Salesforce when it's necessary for go-to-market to execute on, Amplitude or Mixpanel or something for product analytics, and then bring all of that together in a way that you can essentially have this— you have this versioned product catalog that ties to usage behavior that is housed in a data warehouse that ties seamlessly to product configurations on both the platform as well as your CPQ and billing system. And you get this world where you can understand, uh, uh, usage relative to taxonomy, relative to commercial outcomes. So, uh, thanks for coming to my TED Talk here.

Well, first of all, really impressive what PayScale has done on the usage side. I mean, I think maybe for another time, but I, I think when companies try to go attack that opportunity or that challenge, it's it's like, what is the data that we need to understand really good customer behavior and how that might translate to propensity to buy more or propensity to churn? My sort of experience on this has been you really have to be able to understand like how recently the customers use the product, how frequently they're using the product and what they're paying. And if you understand those three things on top of that, you can, you can do a lot of damage in terms of like really understanding propensity and taking action on propensity. This has been awesome. Thank you so much for the time. I think the main theme here has been the opportunity for companies around the product catalog. And maybe the way I would describe it is like a source of truth with a very concise representation of what you're offering to customers, a clear definition of like the entitlements that a plan would grant to customers, for example. The ability to add additional products or test new definitions, and then, you know, basically a translation of those products into other systems. And to your point, maybe it doesn't matter where the source of truth really is, but that translation across the other systems, it has to exist.

Yeah, yeah, yeah.

Um, thank you so much, Kevan. Um, always a great pleasure. Anything else you'd want to Anything else you would close with today?

I'd say that if you were, I think the thing I'd close is that the best time to implant the product catalog was yesterday. The next best time is today. So that would be my parting wisdom, you know, to reappropriate some other well-phrased, was that about planting a tree? It's like the best time to plant a tree is yesterday, planting today. Yeah. So that's, we can apply that to product catalogs.

Um, awesome. So good to be with you. Talk to you again soon. Thanks, Ben.