Monetizing SaaS: Episode 20 with Kayvan Dastghieb, Global Head of Rev Ops at Tegus

Hey, thank you so much for being here. I've had such a fun time getting to know you over the last, I think, 2+ years now. And you've had this really amazing career. You've led sales and revenue operations teams at a host of very impressive companies across a lot of different industries—ZoomInfo, Fisher Investments, A Cloud Guru, Mural, Tegus. Can you tell us about your career journey? How did we get to now in your words?

Uh, well, I think like anyone that you could ask who works in revenue operations, they didn't wake up one day or put on their kindergarten dream board that they wanted to work in RevOps. Uh, I think most of us didn't even know RevOps existed as a potential, uh, career path until much later into our, uh, uh, into our career journeys. Uh, interestingly enough, I found my, my place in, uh, in, uh, RevOps after working at a smaller edtech company that was acquired by OnCourse Learning about, about 10 years ago. And I was leading, uh, customer success and help desk team. And I found that I really enjoyed the, the mechanics of the customer journey, arguably much more than the actual, uh, customer success itself, which is where I found like, okay, maybe this is more so what I enjoy building out the processes, the contract closing, all of those things. And lo and behold, that was the work that, uh, I had no idea at the time was, was the, you know, formative of like customer success, customer success operations. And, uh, after they were acquired and, uh, they wanted me to move to Wisconsin, I didn't want to do that. And I found this opportunity at this, uh, uh, smaller, uh, sales and marketing intelligence company, DiscoverOrg, now ZoomInfo. That was looking for a CS operations manager. And so I applied and that was my first foray into it. I jumped in there and essentially built up the knowledge through CS and sales operations. And that was the catapult to the rest of my RevOps career. But comically enough, it started off working as a help desk manager and finding out that I liked the mechanics of the customer journey and how did I build all of this connective tissue between sales, customer success, and marketing. That was, that was the things that got me excited. And clearly it's, uh, it's worked out so far.

So, so from ZoomInfo, tell what, what happened after that? From ZoomInfo to—

I, uh, decided, uh, after, uh, the ZoomInfo acquisition, uh, I wanted to try out, uh, a different, different industry. Uh, so I went over to Fisher Investments, which was looking to build out a, uh, SMB, uh, B2B business within their broader, you know, wealth management firm. And they were looking to implement a lot of what they saw in tech spaces in terms of RevOps and alignment, uh, at a company that was, you know, at this point a well-established leading, you know, wealth management firm, uh, but try to think about what are the ways we can make things agile? How do we build this scalable infrastructure? And then from there, interestingly enough, I saw many DiscoverOrg, you know, ZoomInfo alumni moving over to A Cloud Guru. This was probably early 2020, just before the pandemic. And I figured someone had put up the, you know, the bat logo in the sky and I didn't get the memo. So I saw that there was quite a few people I respected working there and I reached out as I saw they were hiring for a head of revenue operations. And it ended up being a very, very engaging, very enriching opportunity. And that's obviously where I met some of the individuals that have connected me with you in the past. So it was definitely one of the most exciting opportunities. They were growing rapidly and we were able to not go through essentially one major acquisition of Linux Academy. And then of course, were then acquired by Pluralsight about a year and a half later. So overall,, you know, major opportunity. From there, oh, I tried working, uh, well, with a smaller fintech based out of Australia. Uh, so it was, uh, that was a smaller, shorter stint. And then from there I went to Mural, which was, you know, obviously a, a very, uh, involved, very larger, much larger organization, uh, where it was really a lot of turnaround work of how do we implement a lot of best practice operational infrastructure and work on scaling an organization healthily after what was starting to become that like 2021-2022 downturn that obviously proceeded into 2023 and essentially ensure that they had the right framework, the right go-to-market foundation to scale into the future. And after Mural, I'm here at Tigus, which is I think one of the most exciting firms I've had the opportunity to work with.

It's an impressive journey. And, you know, for listeners out there, I think the first time I met you, I was trying to think about how we would build a RevOps organization at my last company. And I asked you how you define RevOps. And at the time, I wonder if you remember your answer. You've almost kind of said it today, but how do you define RevOps?

Oh, I don't remember what I told you.

Well, what you told me was it is the mechanics of the customer journey, actually. Oh, well, I'm glad I was like, boom, there it is. Like, that is such a good definition. But yeah, how do you think about kind of communicating out to these? I mean, you've worked in some organizations that are A, growing very quickly, and that means changing very quickly. I mean, A Cloud Guru, a couple acquisitions like within a year. Mural, that sounds like a bit of a turnaround, but had experienced explosive growth. And then TIGR is obviously a ton of growth too. So how do you think about defining and painting a picture of what RevOps is to companies at this level of scale with, I'm sure, like really effective, powerful, thoughtful leaders across different functions that care about revenue?

I think the first advice I'd always give is that the best time to hire RevOps was yesterday. The next best time is now. Right? I think many organizations don't realize the value of RevOps until they finally have it within the building and this metaphorical building, if you're a remote culture, because it is such a cross-functional role that acts as the connective tissue between sales, marketing, customer success, finance, product. Your various solutions delivery teams. Having that person in seat can be so groundbreaking for movement on how do we just ensure all of our OKRs are in the same direction? How do we make more business-oriented, data-driven decisions that inform the perspectives and the gut instincts that we have? And importantly, how do we just future-proof our, our go-to-market organization by building it in a way that we're laying groundwork that is going to be sturdy enough for us to build new things on top of it? I think very, very often we find organizations that have hired RevOps too late have realized that they built on very shaky foundations. Some clear examples are they're relying too hard on superstar sales teams. And they don't have a framework to hire new talent and scale them up and enable them to grow the organization. That's a very scary game because now you're very much at risk of not having the repeatable playbook to introduce yourself into new markets or to new products or even jump into higher segments because the team that you built early on could be superstars of SMB and mid-market sellers. And now you want to jump into enterprise. Well, you need to start building a playbook for you to bring on those enterprise sellers so they have something to work with. Otherwise, you're very much at risk in bringing on enterprise sellers who know what they know but not know what you know. And lo and behold, you've set them up for failure. So it's—

Yeah, it's such a good example.

So those are things that really stand out, like really clear pain examples. Other things that come up is the infrastructure of the organization, the tooling. The technology and obviously things like monetization, pricing and packaging. How do we ensure that we're contracting our customers in a way that's scalable, that helps us have wiggle room and ability to grow and also provides a best, uh, essentially a best flavored relationship for our customers that are out there. So, uh, kind of think I lost my original point, but I think when we're thinking about RevOps, You really want someone who's going to help you make sure the people are working together in a direction that is synonymous with the business objectives. You're going to want someone who's there to, or a team that ideally is there to ensure that you have the infrastructure to build upon successfully. So technology is not the roadblock, it's not the bottleneck, it's a force accelerator. And last but not least, you're trying to introduce data-driven decision-making early and often rather than relying on a lot of ad hoc perspectives or gut instincts that don't have a lot of validation. There's often a lot that we learn when we double-click into the data that can challenge what our existing perspectives might be. And you want to introduce that muscle early so they don't get— so those problematic perspectives don't get entrenched.

Yeah, yesterday, as it were, is when you want to introduce all this. So at TIGAS today, where are you spending most of your time right now?

Oh, right now, I'd say that there's two places that take up the bulk of my time. First is gross retention. Nowadays, I think The tone of B2B SaaS has definitely changed in the last 2 years to really focus more so on how do we ensure that the customers we have today are staying with us tomorrow and the ones that have the ability to grow with us, we are ensuring that we're doing the right work in terms of onboarding, account management, relationship building, and value delivery. To, uh, essentially to sustain the growth we want to see and use our customers as our own true pipe gen, because they will be the best advocates for us within, you know, within competitor spaces when they are our strongest advocates for the value that our product brings to the table. So that's a heavy focus of mine right now, is how do we ensure that we're looking at the data within our product the interactions between our go-to-market teams and our customers, uh, and of course layering that all together with what we knew from the actual, like, sales, you know, the pre-sales journey to bringing them on to ensure that, uh, we're doing everything we can to ensure our customers stay with us. So that's probably number one.

And I imagine that's, that's top of mind for many RevOps leaders. In fact, um, I think it was Sam Jacobs, who's the CEO of Pavilion, who just within the last few days wrote a post on LinkedIn talking about how gross revenue retention is sort of at the very heart of what he described as an existential crisis in SaaS. Maybe you could just kind of riff for a second, like why has gross revenue retention become such a lightning rod and maybe so much more top of mind for companies than it was maybe 2 or 3 years ago?

There's an ugly truth that I think we've all come to terms with, was that the world of VC-backed growth at all costs was inherently non-sustainable. Uh, when, when cash is falling from the sky, budgets are inherently less restrictive, and as a result, value delivery, ROI, and honestly ensuring you have a really buttoned-up product are not as pressing a need. We saw many organizations that have essentially fallen out because they didn't have a strong defined product. They didn't have a well-defined product market fit. And as a result, they weren't as sticky of a product as they thought, and they were determined to be a nice-to-have rather than a must-have. And That's arguably the fundamental aspect of growth is that you're building a product that is a must-have for your target market. And if it's not a must-have, then it's a high likelihood that when push comes to shove and budget becomes restrictive, churn is an inevitability. So, I mean, Sam Jacobs is 100% right. It is an existential crisis right now because if we look at the patterns of go-to-market organizations in the past few years, we heavily indexed on spending more, essentially more funding and budget on sales teams, marketing teams, focusing on customer acquisition, not so much on customer retention. Every CS leader I speak to talks about how they were either an underfunded department, they didn't have the headcount, they didn't have the playbooks, they didn't have the tooling that would essentially allow them to be the best-in-class partners that they want to be for their customers. And at the same time, product marketers, product managers spent a lot of time about how do we continually add new functionality to attract new users, attract new prospects, attract new customers, and less so on how do we deliver the value to the customers that signed us with an— listen to our early adopters to ensure that they're continuing to get the value from us that they need from us as they grow. And that major disconnect has now led to a place where many organizations are thinking, we need to focus more on true account management, true customer journey. And you don't do that unless you're looking at gross retention on, and all of the leading indicators for it on a religious basis.

Fully agree. What is the second big kind of body of work that's occupying a lot of your mindshare right now at Tegus?

I'd say the second one is going to be our pipeline conversion. So our new business pipeline conversion spends is the second chunk of my focus. And that is going to be due to, you know, we're trying a lot of new things here at Tegus for within our go-to-market organization. Earlier this year, we introduced specialization across new business and our customer-facing teams. Uh, we also are, you know, specifying a bit more— specializing a bit more in our public versus private investor, uh, uh, you know, you know, prospects, trying to ensure that we're enabling our sellers to be able to speak to the needs specifically of those, uh, different types of investors. And because we're tackling different segments, different regions, and we're implementing a lot of these newer, like, trials playbooks. We're implementing prospecting flows and workflows outbound. We're introducing some new tools to help us with lead acquisition and lead identification. We're implementing new tools that help us build us more comprehensive data-driven books of business, essentially cutting out more of the garbage and focusing on a tighter fit of specific logos that AEs can spend more time I'm talking to people and less time trying to figure out which of these logos in my book are not quite going to, you know, help me hit my number. And the biggest way I can identify if the elements that we're playing with, experimenting with, are actually going to drive value is if I see our conversion rate of essentially deal value at stage 2 to stage 6 either go up or stay flat or obviously, you know, close lost. And that ARR conversion and that win rate conversion are going to help me identify, are the things we're doing moving the needle? If not, why are we doing it? And that's really important. If you think about, like, every— if our most expensive resource is time, I need to make sure that the, the, the levers that we're pulling are going to affect either gross retention or pipeline conversion. If they're not doing either, we have to reassess if this is worth doing.

It's really illustrative, I think, of your definition of RevOps being the mechanics of the customer journey. When you zoom out and when you think about building SaaS companies in this era of, let's say, money's not falling from the sky anymore, what are the big inflections that have really caught your eye or have kind of really driven your energy and your curiosity? Big inflections in the way software companies are built and run.

I think one that stands out to me and I think is a, and it's because I'm going to be more of a, I'm generally a glass half full kind of guy. I think you need to be in RevOps, otherwise everything can be very depressing. You have to find optimism when you're generally the arbitrator of bad news. When I think about some of the biggest trends right now. I understand, I'm following the AI journey very closely, but I'm following it for a variety of different reasons because just like the SaaS boom that we saw in like 2019 and 2020, where there was a lot of like, think about it, user-centric products, product usage trackers, a lot of like web interface plugins, a lot of data that helped you kind of like track, are your users using the product the way you want them to? I think there was, you know, I lost track of how many that launched that were some way of saying we're going to drive customer adoption within your tool. But they were a symptom. They were, they were essentially treating a symptom that didn't really surface until later on, which was these were product market fit product market fit issues that did not actually solve the business problem. So you're trying to monitor if people are using your product because you think if you engage with them at certain times of their, you know, certain times of the day and feed them features, that will solve the problem that the product isn't doing the thing you needed it to do for the, for, for your customer, right? So, uh, Now there's AI, right? And that's the next big flavor. And it's, okay, this is going to be augmenting everything we do. I think there are some very real applications of generative AI and how it's going and these large language models and what they can do for the, for SaaS. But it's going to take some time to cook. And I think as soon as ChatGPT came out, I figured I was going to take out my my dartboard and start betting out, uh, or get out a bingo card and start scratching which of the new ChatGPT wrappers is going to be the next big buzzword company out there. And I still feel like there's one every, one every 24 hours. So that is a big trend. And what I would caution for many go-to-market leaders is don't jump on the hype just yet. Don't buy every new AI tool that's out there. Otherwise you're going to be landing with more shelfware, budget that you could have used on something else, like more RevOps, or even something like a spiff for your go-to-market team by buying an AI wrapper tool because you think that's going to be the big that augments your go-to-market team substantially. I think the applications of AI are going to be far more evident in our engineering and product spaces. And how they're able to augment the ability of engineers to build product at a faster clip, because that is arguably one of the single most significant bottlenecks in most B2B SaaS orgs right now. There's just not enough developers out there. Every go-to-market team is dependent on their product team being able to, to ship updates, to ship major optimization, ship major product experiences. And if R&D is the thing that is the bottleneck, then AI is likely going to be the thing that facilitates growth there more so than on the go-to-market side.

Monetization in B2B SaaS is getting more and more complex for companies to figure out how to support. And I wonder if you could try to explain why. Why is monetization complex for B2B companies to support? And maybe the precursor question is, what is monetization? What's a good framework for people to think about this concept?

I think a lot of monetization challenges come from an inherent lack of sophistication in understanding the customer journey. Truly. When we think about monetization, we're often trying to think about how do I extract the most value from our customers? In a way that the customer feels that it is a reciprocal exchange of value, right? That, you know, things like price gouging and predatory billing, those things, they throw them out the window. But truly, I'm ensuring that I am pricing the value of my product and the experience it provides in a way that has a market clearing price that is going to be appetizing to both my early adopters and eventually remain a sticky price point that is resilient to competitive pressure, right? Those are, that's like the overarching philosophy that we're trying to tackle with monetization. But if we look at the last 15, 20 years of SaaS pricing, it's been seat-based. Yes, there are SaaS companies that are consumption-based, but the vast majority of B2B SaaS products are seat-based and seat-based. Only really works if the vendors that you're working with or the customer that you're working with are constantly needing to buy more seats. We saw that, you know, as, uh, in the last 2 years, as sales and marketing teams had to face— all revenue teams had to face significant budget cuts, they stopped hiring. They weren't hiring as many marketers, sales, CS professionals. They just weren't doing that. So, I mean, we saw Salesforce had record lows in their performance, and that's because people are not hiring 50 AEs anymore. They're not hiring this. So if your entire product pricing strategy is based off of growth due to seat growth based on your company's, your customers growing, if they stop growing, your ability to grow is entirely flattened out. And now you're going to face the only opportunities of growth is going to be new customer acquisition, which which is we're realizing is not great. So when you think about monetization, it's inherently right now very black and white. And the consumption billing element is a very scary game for, uh, for seat-based companies right now, because the last thing you want to go do is introduce a pricing, you know, pricing and packaging strategy that creates a major erosion in your annual recurring revenue, right? So you're like, oh, I don't have a sticky product, but maybe going to consumption-based is going to make things work out better. But then suddenly you realize that your adoption isn't so great, and now consumption drops to a point where you're no longer at a level with your existing seat-based pricing. Yeah, you're going to be— start— your board's going to look at you and think, what are you doing? So it is inherently a very nascent component of B2B SaaS, uh, I think it's even more, uh, in its infant stages than, than, uh, than we're seeing it than AI, realistically. Because why? Most organizations don't know what they're actually trying to accomplish with pricing and packaging, and as a result, their monetization strategies can seem all over the place. And that's just like any other alignment issue— it's going to lead to, to cracks in the foundation.

And then top that off with maybe you introduce another product and then you've got a whole kind of world of new complexity. But if I were to play some of that back, I mean, it sounds like one of the reasons this gets so complex is there's this strategy question, which is what should the price be? How should we package this product? But then there's the actual, like, how do we action that strategy side of the equation? Um, and that's, that's challenging from a systems perspective. I wonder if you could speak to the systems challenges that you've seen. Like, how have those problems played out in real-world sort of visceral examples that you've seen at companies?

Oh, there's— when we think about a product, right? An app experience. There is an almost infinite permutation of features and functionality. That a user interacts with inside your product, right? And this also goes back to like this mini tangent here is that when we think about like customer health scores, you're trying to think about, oh, I need to know what are the signals in the product that tell us if the customer is getting the value out of the product. And that really just comes down to like, what are the features? What are the things that people are doing in your product that actually carry the price value, right? There's so many bolt-ons and add-ons and search features and all these things that we add because we believe that they are going to be the thing that helps drive price-to-value conversations. But at the end of the day, you only really get that perspective by going out and talking to your customers and finding out what is the thing that really matters for you in our product that you cannot live without. And that's what's going to carry the price, right? All of the other little features are bells and whistles. They don't drive price, right? It's the core value prop that does it. So when we think about the systems and infrastructure, right? One side is provisioning. One side is going to be, how do I actually build my product in a way that allows me to add new features as with controls, right? It's user provisioning, it's user entitlements. And are features packages within themselves? I'm thinking packages purely as like a systems, like, is this set of features, a functionality that comes with the basic experience? Is this an enterprise experience? Are these experiences that are user provisioning enabled? Like, is this something that only is available to admin users, or is this something that's available to, daily users, right? There is a lot of difficulty, and at least in a couple of my experiences to date that some of the companies worked at, the product has been essentially you log in and you get everything. And that was because as the product was developing, as the organization was growing, there was more and more tools being added to it, more and more functionality to add value. And then we start thinking about how do I actually differentiate and give us more pricing options? You now have to go back to the entire engineering infrastructure and start taking things apart to package similar themed functions together so that you actually can introduce, you know, maybe an entry-level price and an enterprise price. And maybe, you know, maybe there's a mid-market price functionality. But if all of your functionality is built as is inside the system, yeah, you're going to start running into issues where you may want to do different pricing options, but your product is, yeah, it's either A or B. It's either it's all or nothing. And that is, that could be a major, major 1, 2 year endeavor to go undo all of that, uh, that tech debt. It could be real big, a real big game changer for your go-to-market motion is if you cannot enter the enterprise segment because you're trying to introduce an enterprise solution but you don't have the functionality parsed out to give yourself a, um, an enterprise value prop.

There are two things you said there that I would like to try to, um, dig into if we can. The first is you described sort of this maybe what feels like an inevitable evolution that a lot of successful companies go through, where they maybe launch with a single product, they find some fit, they grow eventually they're maybe doing 5, 10, 15 million in revenue. They start to think about pricing and packaging at a certain point because there's an opportunity to grow faster should they be really intentional around that. But then if they want to implement whatever that pricing and packaging evolution should be based on the analysis, they have to go through engineering. That's what you said. And that's, that stuck out to me because it means engineering is critical path to what is effectively a good go-to-market monetization decision. And I wonder, my question is, have I captured that correctly? If so, have you ever been at a company where engineering is not critical path to the evolution of monetization and pricing and packaging? Oh, never. No.

Uh, the R&D teams, product, and the engineering teams have been always, uh, critical to whatever monetization strategy that's in front of you. Uh, I think the only places I've seen it not be so is if there's like a solutions delivery professional services element. That's, that's the only time, right? Uh, but whenever your product is going to— let's say, like, take a step back. Let's say you use a very clear example. You have a, uh, mid-market focused product that's been growing well in the mid-market space. You want to enter the enterprise, right? So your team needs to make a strategy decision to, to Essentially to spend the time to develop additional functionality that is going to have the value necessary for enterprise. That's a cost investment, right? And the ROI likely is going to be determined based on the functionality demanding a higher ASP on your contracts with enterprise customers, right? That just simply, the simple math is there. Now, if your infrastructure does not— because an important element is that you need to keep that functionality separate from your core mid-market product because there's a high likelihood that enterprise functionality will not be an appealing value-add for your mid-market customers. And importantly, your mid-market customer is going to be most sensitive to any price increases due to any functionality you want to add. So truly, your Excel math needs to show We are adding this functionality 'cause it is gonna allow us to sell into this enterprise market, which will command this higher ASP, but it will need to be specific to this enterprise segment without eroding our current mid-market base, right? Because if we try to just give them this feature, they may not get the value out of it and they may see this price, they may not have the same price-to-value perspective as enterprise will. So what does that mean? Engineering needs to build a way for this functionality to be a bolt-on feature and an add-on to the, to the customer experience that is separate from the core product, right? And if they don't have that functionality, you need to delay your go-to-market enterprise product launch, likely until that roadmap supports that delivery. And that can be a major, you know, blow to any leadership team that's looking at, oh, we want to get into enterprise this year. And it's like, you don't have an enterprise product yet, so, uh, good luck. You're going to essentially set your sellers and your marketing team up for failure. And more importantly, you're going to set the organization up for failure later on down the road when you finally do land enterprise customers and they churn because your product, uh, was not as sticky as you thought it would be because you didn't have the functionality well baked at the time.

So it's, it's a really great example, and it just, it's a reminder to me of, of sort of the unfortunate binary trade-off I think most SaaS companies are having to deal with, which is I could allocate engineering resources towards new features, or I could allocate engineering resources towards supporting monetization initiatives. And it's often one or the other, unless I'm, you know, super well capitalized and can figure out how to do both. But, um, it feels like a really unfortunate trade-off that kind of crushes business objectives.

Staffing is such a challenge. If you don't have enough engineers to work on things, the capacity question comes in. If I'm going to get value, it becomes another math question. I want, I can probably get new functionality and it's arguably a bit easier, I think, for the napkin math to work in the business's, you know, at least theoretical favor. Generally doesn't actually, I think, pan out that way, but at least napkin math shows us, oh, I build out this feature. I should be able to get some market releases. I can generate probably 3 million in new pipeline, and that with a 25% conversion rate will end in X over X, you know, new business bookings for the next 6 months, right? That's the math. It works that way. However, it generally diminishes very quickly. You lose that early buzz. It's mainly early adopters interested, but there may not be the stickiest product. And meanwhile, you've let your actual long-term growth suffer because you're still battling the tech debt from the last couple of years that you haven't addressed.

That was the other nugget that I wanted to try to dig into a little bit, this idea of tech debt. And the reason I think it's interesting is because I think you're describing a type of tech debt that to some extent lives in the product, but to some extent it lives between the product and downstream business systems. And I wonder if you could, I wonder, does that mean that this is really some form of go-to-market debt or commercial debt or monetization debt? I mean, but maybe the better question is, can you talk about the flavors of this type of debt that you have seen be most constraining to companies?

I'd say the most consistent that I've seen at this point, and we're dealing with it here at TIGIS as well. You're growing. I think actually last time we talked about this, I used, I think I mentioned this. When your customer base is small, it's easy to, all right, I've got these 10 customers, I've got these 15 customers. These are the users. These are the functions. These are the features. These are what they're interacting with. And your go-to-market team that's engaging with them, even your product team probably knows intimately what's happening, right? Because it's a full team selling motion, right? As the organization gets bigger and you get more and more customers, uh, which is, you know, a great problem to have, you start realizing that you are, uh, missing the ability to have a cohesive picture of the customer. And it becomes even more problematic as you start bringing on enterprise customers. Where there's multiple teams at a single customer. When you're thinking about multinational global organizations with 50,000+ employees, the likelihood of this team and this team needing to be on the same instance of your product is probably close to zero, right? So, and they may have different billing, they may have different feature needs, they may have different, different everything. And so now you're starting to wonder, okay, well, I had a, you know, like I said, I had a Tegus company profile in here. I have their teams. I have their LinkedIn data. I can see how many locations and users that I need to provision for. But I only am able to govern provisioning at the firm level or at the company level and not at a user level or the team level. So what do most organizations start doing? Well, they start creating TIGIS 1, TIGIS 2, TIGIS 3. They start creating TIGIS Kevon's team, TIGIS Fynn's team.

So what would we call this? Is this like some form of SKU sprawl, or how do you talk about this problem specifically?

Oh, I generally call it just enterprise data architecture as the overarching problem. Because at the end of the day, you're trying to build a cohesive understanding of the go-to-market relationship and align it with a cohesive understanding of the product relationship and the product experience. Yeah. And those two things happen independently almost all of the time, which is when organizations get big enough and they start asking the question, well, I want to see how this data ties with our churn, or "Which of our product users tied to the most growth?" Or worse, our customers are asking, "Which of my users are on this renewal?" And you start to get to a point where you're like, "I don't know how to answer that question," because you didn't build the connective tissue between two core systems, your go-to-market provisioning and essentially the user entitlement element of that side, the contracting, the relationships, the renewals, and who gets access to what, and how does this tie to revenue? When you don't have that connective tissue, it is going to be a lot of rubber bands, duct tape, trying to push data in different connectors into this system, into that system, 8 different lookups. And you're like, I think we're like 80% of the way there. And everyone's like, cool. So what do we know? Oh, I don't know. Like, and anytime we do make a monetization strategy change at that point, that entire infrastructure breaks. So, yeah. Okay.

So that, that I think you've painted a picture of the debt very well there. You know, and maybe we can try to solve the world's problems in the next 10 minutes. If you just described at least a component architecturally that's really important, and that's this idea of like a unified company profile. If you could wave your magic wand and solve this connective tissue enterprise architectural problem and you were to do so with a set of architectural components that were they to exist from the beginning, they'd make life a lot easier and companies a lot more agile. What components or services spring to mind? For example, this idea of a company profile. Are there others that you think are like, these have to be a part of a standard architecture?

Well, if I were to opine, I'd say it's, you need a way. Well, first, I think at the end of the day, you first have to answer the question, what does feature access and functionality mean for my customer? Is it a user-based thing? Is it a firm? Is it a company-wide element? Do I need to have team-level specificity? Right? You have to be able to answer those questions, right? If there is even the remote possibility within the next 6 months to a year, that you expect your customers to be able to have, to have potentially have multiple customer teams at an organization that are independently operating from one another and importantly also have the high likelihood of needing different feature functionality on your product, then you need to have some sort of essentially layer between your product environment and your go-to-market, you know, tech stack, Salesforce, HubSpot, Microsoft Dynamics, take your pick, right? That allows you to translate these users are this set of provisions and this set of functionality. And that's how this, essentially that communicates the product environment. And then bidirectionally, you now can say this user and these functionalities are tied to this go-to-market contractual agreement. And that passes to Salesforce. So you can have those contacts, those users, and those renewal relationships all in one spot. If that is an unlikely circumstance, I don't think you need to have that conversation immediately. But dollars to donuts, I think everybody's having that conversation, which is I need to be able to— yeah.

Is a way to describe, like if we were thinking in services or components, is the service that you just described kind of like an entitlement service or is Or you use provisioning as a provisioning service?

I would say it's probably entitlements because provisioning, I think most people can figure out a way to handle provisioning where you can say, hey, have this user get created there. And then I don't think that's the issue. It's entitlement. It's the permissions management. It's the features and functionality that a user once provisioned gets access to. And if you're able to take out the pain of having signed a new contract with 10 users at this firm and you're like, "Cool, I provisioned them the environment, but I don't know exactly how to make it so that these different features are immediately tied to this package or this set of products," then that's where it's painful. It's not the provisioning element, it's the actual entitlements that are associated with the provisioning. Yeah.

What are other potential components? So you've said entitlements, you've said company profiles, what else? Are there other really discrete components that have to be there architecturally?

I mean, the ability to manage entitlements easily and play with that.

I've heard some other engineering leaders describe, you know, in this same exercise, the idea of like a product catalog. I've heard other people talk about subscriptions. I've heard other people talk about We'll go down.

Absolutely. So if you think about looking at like Chargebee and Stripe, right? There's an element here where someone signs on and they have, oh, it's such a painful experience for most customers, for most B2B products, especially if you're thinking of PLG space. Someone signs up on your website, they put in their credit card, they get Chargebee says, cool, you're ready to go. And now Chargebee is generally passing that data you know, to some sort of engineering stack that is tying that Chargebee paid user to a set of functionality. Right. But managing the different types of— well, here's it. If you want to think about, do I need this user to be on consumption billing or subscription billing? Do I need the— the— the— I need to time gate the entitlements themselves. Trials. Do I need users to have trial access within an enterprise product on a team? Does this team get 1-year access? Does this team get 2-year access? Right now, many organizations, especially early on, are very binary, you know, or they just have arbitrary date fields to turn off. But what if you wanted to trial functionality that's part of the enterprise package? Chances are you can't. Time-gate different aspects of the entitlements. It's either all or nothing. Your user gets access to all of this all at once, or they don't. And so now you're putting a lot of manual labor on both your engineering and your consumer and your customer-facing teams to essentially do the manual efforts of, "Okay, I put them on the user access to get the enterprise features. I turn them off after 3 months." They've got calendar reminders to turn off functionality and update things manually. But because the functionality, the entitlements, the time gating, the subscription billing, all of that hasn't been built, it's generally done through a series of manual triggers governed through Slack workflows.

Well put. Kay, I could talk to you about monetization infrastructure, RevOps, the connective tissue for a long time. And I know you have to jump soon, so. One of the closing questions that I like to ask is, can you talk about a specific moment or experience that has been the most formative or influential in your career?

I think comically enough, there was one that resonates with me. It wasn't as impactful, I think, as to my boss at the time. I don't think he realized how formative it would be for me, but I use this line often with my own teams. I remember I was looking at a forecasting tool. This was back in like 2016, 2017., and I thought it was a really neat tool. And I was like, this is, I knew that we had issues with our own forecasting and I was thinking, hey, this, this looks like it solves the problem. Take, it saves a lot of time and reps being able to put in their forecast. And it looks like it's, you know, fairly accurate. Uh, it, it's got some initial machine learning in it. And I remember bringing, you know, I, I was being the influencer, you know, the gatekeeper to our, to our, to our AE who was, you know, trying to get to my boss who was the decision maker. And I bring him this proposal and he looks and he goes like, this is nonsense. And I was like, why? And he was like, your entire pitch here is that it saves reps time. And I was like, yeah, isn't that a good thing? He's like, why? So they can spend more time on Reddit? He's like, no. He's like, tell me how it's going to make them better. Tell me how it's going to drive revenue. Tell me how it's gonna drive their ability to generate pipeline. If it doesn't do those things, you're not doing the team any favors either, because all you're doing is introducing change management and tools and products disrupting their existing workflow for the optics of potentially saving time. But the reality is the actual change management is going to eat up all of the savings of time that you thought it would, you know, gain, but it didn't actually drive any revenue or books. If anything, it may actually help make us lose sight into what we know to be true rather than, you know, uh, trying to identify the actual problems that the business is facing and fixing those, right? So for me, it was like, it wasn't about the shiny new toys that help us, you know, that we want to implement with their teams. It always has to be solving one of the core functions of the go-to-market motion. So for me, whenever I'm talking to my team or whenever they're bringing me ideas, I ask them Is it going to affect pipeline? Is it going to affect retention? Is it going to affect our bookings number? Does it do any of those things? No, then why are we talking about this? Right? Because that makes sure that not only do they spend their time, which is a limited resource, on the stuff that's going to be most valuable, but it helps build on stakeholder trust. If our go-to-market leaders, if our product leaders, if all of our various stakeholders trust that the things that we're doing are going to meaningfully impact the work that they're doing, and we're not just doing work for the sake of doing work, they will trust us when we come to the table with counsel on if something is worth doing, right? So that was very helpful advice for me many years ago. And I like to, I practically keep it as like a Post-it on my monitor. Does it affect pipeline? Does it affect bookings? Does it affect retention? If it doesn't, don't do it.

It's such a fantastic story. Thank you for sharing it. Where can people learn more about Tegus or reach out to you if they've got questions about building their own RevOps org?

Well, obviously they can reach out to me on LinkedIn. I also do essentially AMAs on Sharebird about once a quarter. I think I've done a couple other podcasts to date as well. So they can obviously reach out and look for that information. Of course, if they want to reach out and learn about TGIS, happy to have that conversation as well. Uh, but they can also go to tgis.com to see all of our fantastic products that are helping essentially, uh, build the best, uh, fundamental research platform for, uh, for investors.

It is an amazing platform. Okay, this is so, so much fun. Thank you for doing it.

You're most welcome. Pleasure to chat, as always.