Janis Zech: Hello and welcome to another episode of the RevOps Lab. We are here with a returning guest, Gabe Rothman. Hey, Gabe. How are you?

Gabe Rothman: I'm doing great. Yeah. It's great to see you guys again. Looking forward to getting into it.

Janis Zech: Yeah. Same here. So I think as a podcast, you know, you're growing older when you have people returning. We very much enjoyed our first show together. But maybe, you know, before we start and as we've grown quite substantially over the months, you know, maybe you can give a quick intro. Who are you? What do you do? And then we jump right into the topic.

Gabe Rothman: Yeah. As said, Gabe Rothman, the vice president of operations at Rescale. Rescale is an orchestration platform to run basically engineering driven computer simulation on public cloud high performance computing. So the example I always like to give to kind of, like, frame it up for people is we have a lot of automotive companies as customers. And so the probably the two biggest categories of simulation — or two of the biggest categories of simulation automotive — are computational fluid dynamic simulations. So, like, wind tunnel testing, at least wind tunnel testing in the context of automotive, and crash testing. Right? Simulating crashes that don't actually have to destroy an actual automobile before they get to the final phases. Right? So that's kind of what we do, and we're sort of the connective layer between the public cloud and the simulation software. And then there's a whole bunch of feature functionality built out around that as well.

Janis Zech: Well, it actually feels like we could just continue on that topic because I think for Philipp and me, it would be very interesting to dive into that type of software. But our topic today is architecting an enterprise ready tool stack and build versus buy analysis. And I wanna jump into the first question, and, you know, I think we know this. Right? I actually, today, just posted on a — like, my first attempt to a RevOps maturity model on LinkedIn. So if anyone has any thoughts, you know, it's the v one. I'm gonna incorporate the feedback for v two. But I think, you know, when it comes to tool stack, right, like, usually as the organizations grow, the tool stack, the tech stack changes. And so I'm curious, like, if you were to, you know, build a go to market tech stack from scratch, like, what categories would you add in what order? How would you approach it? I know it's a big question, but, yeah, super curious what you think.

Gabe Rothman: Yeah. So I think a lot of it depends on where the company is when you start that process. So if you're — let's say you're a brand new startup, or close to brand new — and, you know, you have a vision for RevOps that early in the company's evolution, which would be great. I think most companies frequently don't, which is fine. Makes sense. Right? You wanna focus on engineering and sales generally that early. But if you do and you're starting, you know, pretty close to from scratch at that point, obviously, I focus a lot on foundational elements. So, you know, the obvious answer as a starting point is CRM. I happen to be a Salesforce person. I think, you know, reasonable minds can differ, but I would start with CRM. And then because you're so early and you're gonna be sales focused, I think you could probably go with these two in any order. But, again, more likely to have your early salespeople on board than your early marketing people on board at that point. So probably a prospecting tool — I know that's very sort of tactical and not necessarily, like, what you would think of as a foundational element. But I think it's important to arm your salespeople very early. So when I say prospecting, obviously, there's a lot of things that fit under that umbrella. I think initially, I'd be focused on, like, the data enrichment side, or the prospecting — like, anything that gives you access to your actual potential customers. So things like LinkedIn Sales Nav, ZoomInfo, or other, like, data providers. And then moving on to marketing automation once you're starting to bring on the marketing folks. Right? Because that obviously gives you — CRM gives you the sort of repository to house basically all of your company information. Right? Your CRM is where every customer originates ultimately. And then prospecting, giving you the ability to find people, find out who you need to be talking to, and marketing automation — getting that rolling early is also critical so you can start talking to your market. And then from there, then I would start to spread out. Again, whether or not some of these additional tools are needed, reasonable minds can differ. But I probably then, after marketing automation, move into some sort of, like, prospecting automation tool. But, again, it depends on the size of your sales team. Do you have a — you know, are you starting to build out a BDR team? But, you know, like a Salesloft or an Outreach. Or alternatively, I would maybe look at getting into some of the, like, call intelligence and activity capture. The sooner you start getting that stuff into your CRM, the better in some respects because you can start to learn about, like, what does a good sales cycle look like? What does a good call look like? What does our sort of golden motion look like from an activity point of view? It's hard to know that stuff if you don't obviously have the data to look at it. Now the challenge there is when you're really early, you obviously don't wanna jump the gun because that stuff may not be useful at all to you for a number of reasons, not the least of which is you could pivot entirely because, you know, early startups do frequently pivot. You can change your entire messaging or positioning in the market pretty frequently and quickly. So, obviously, you wanna make sure you evaluate where the company is at from those points of view when evaluating this stuff. And then down the line, I think these are things that you probably look at as the company starts to hit a much more mature state. You know, you have a pretty solid kind of north star from a product perspective, a marketing and, like, messaging perspective. But then I might start looking at things like forecasting and then business intelligence tooling. You know, BI tooling is something that once the company gets to a certain level of maturity, can be very important to give you insights into what's happening. But there's a long period of time as a company is evolving through its early stages that you don't really need it. You can get the reporting that you need, the sort of table stakes reporting that you need from your CRM or some combination of CRM and, frankly, like, Excel and Google Sheets. So I think BI is more of — like, there's a certain sort of maturity index you wanna hit. Forecasting, I have mixed feelings about. I know a lot of people use lots of forecasting tools. I've used them in the past. Again, I think it's just a matter of maturity to some extent, but also really evaluating, like, what do you actually need? I mean, we, at Rescale, we used a forecasting tool for several years and ultimately decided, you know what? We don't think this is giving us a whole lot of additional value beyond the ability to just structure a meeting, a forecast call around the most critical deals, and have a discussion about it. And so we actually deprecated that, and we've just been using Salesforce forecasting for at least two years now and it's been very effective for us. Yeah. That's kinda how I think about it. But, it depends on where the company is.

Janis Zech: So I have one thought and then one more question as a follow-up here. Obviously, super curious about the forecasting as we play in this space. We always say forecasting is actually the outcome, but what the input is is really good data — so activity capture, CI, and then good deal hygiene that ideally needs to be automated because the reality is that often it's just not happening if you don't automate it. So contact intelligence, activity intelligence, conversational intelligence that ideally auto populates all the fields on your methodologies so you have better understanding of what's actually going on so you can quickly review deals to inspect and then also take action. Right? And then that feeds basically, you know, the forecasting and sales analytics there and ideally, it's deeply integrated into Salesforce. Right? So this is basically what we've built with Weflow. And we still don't know really how to talk about it best, I think. You know, this is, like, still a challenge for us. Right? But it goes, like, way beyond — I think if you think about your prospecting example and prospecting automation, you know, like, it's very clear how to use a cadence. But then if you think about how to actually manage deals and manage your pipeline, it is very up to, like, the individual to do that effectively. And so how do you provide more structure as a workflow — as an intelligent and smart workflow solution that ideally has all the data so you can act on them? Right? So that's just a, you know, some thoughts on that space that I think is fundamentally changing. One follow-up question on the stack. So one topic that often comes up is CPQ. How do you see that? You know, does that play a role as well? And then the CPQ, I think, has evolved also a bit — like, you know, it's not just configure price quote, but it's actually quote to cash process. So I'm curious how you see that specific category.

Gabe Rothman: Yeah. Actually, before I answer, I wanna respond to what you just said, though. I think that's a really good point because I think what forecasting means has evolved a lot as you pointed out. Right? Even five years ago, six years ago, seven years ago, forecasting meant forecasting. Right? You get on a call, talk about the deals. And I think we're all aware of this convergence in functionality around forecasting and activity capture. Right? You know, like, Gong started as call intelligence, and they've added other forms of activity capture, and now they're rolling in forecasting. We used to use Aviso — that was the forecasting tool that we used. They started primarily as forecasting, and they've rolled in call intelligence and activity capture. Right? So all of these tools in that sort of suite are converging on kind of a common feature set that is now this combination of intelligence, activity, reporting, forecasting. So that is a good point. So, yeah, when I was referring to forecasting, I was really talking about just the, like, actual forecasting piece. So I do think that having tools that enable you to capture all of that, like, critical intelligence about how your company actually goes to market — that is lost at an individual level if you don't capture it in some structured way — I think it's important for sure. In terms of CPQ, I mean, I think that some type of CPQ-like functionality is obviously indispensable. You have products. You have to quote. You have to send out order forms. You gotta get them executed. You have to configure that stuff in your CRM to know what you sold to people. So in that respect, it's almost like a nonnegotiable feature. Now whether you use Salesforce CPQ or DealHub or some other tool, I don't have very strong opinions on it, honestly. I think it's important to sort of know what is gonna work for your company. And I would say more broadly, my thinking about — and this sort of actually, in a sense, ties into the kind of build versus buy stuff that I think we might talk about a little later — my thinking on tooling in that respect has evolved over the years. When I first got into this world, I was very, like, oh, all these tools are so cool. It's so neat that you can, like, buy all these things that can solve all these problems for you and do all this really interesting stuff. And I still think that that's cool, but one of the things I've realized over the years is that some of these things — I've started to lean back toward a more consolidated tools approach. Right? So not having so much sprawl, not having people in the organization have to use so many different tools or go into so many different places, especially AEs — trying to keep AEs working out of one place as much as possible for a variety of reasons: to keep sort of all the data in one place, to keep their focus in a single place. Right? The more sort of different types of activities and, you know, places that you're requiring your salespeople to go to effectively sell, the more, I think, fractured and potentially friction-filled you're gonna have in your sales process. So that is to say that we went with Salesforce CPQ again to keep people in Salesforce. Obviously, it was very tightly connected into the sort of opportunity structure. The other reason we did it, though, is that, you know, we have a really interesting and sort of complicated business. We sell some subscription type product, but, like, fundamentally, we're a consumption model. And so the way that our products need to be structured in SFDC requires a high amount of customization because there are things that we need to be able to do. Like, we have a whole suite of SKUs that have pricing, but no actual value that makes sense, not in terms of the opportunity — because they're consumption products. Right? So, like, core infrastructure. Right? There's a price. We put the price to the customer, but the price just tells them what they're gonna pay when they consume. Right? So it doesn't actually, like, roll up into the opp. So just as an example of things we've had to customize heavily to make sure that our CPQ works for our product suite.

Janis Zech: I think what I'm hearing here is also, like, the pricing for your product — it's like a core part of your business. Right? This is not like you sell a seat for your solution for fifty dollars per user per month. That's right. So that's like a basic model. And you don't need to build something custom in order to cater to that need and requirement, but your case is quite specific. So if you were to purchase, you know, like, a solution, most likely, you would end up in a situation where the vendor makes some promises and then actually ultimately is having a very hard time to deliver. You become a burden for them. They will have to constantly scramble to satisfy you, and in the end, no one will be happy.

Gabe Rothman: I mean, that's us. Right? Like, I mean, to some extent —

Janis Zech: Yeah. Not a good, like, match of expectations and reality, and the vendor is not, you know, honest about it, and also the buyer is not really thinking it through fully. So I think, like, with a business like Rescale, I think in that regard, you know, like, this question of build or buy — it just makes so much sense. And it kinda — from me, it's like what you said earlier, right, it depends on where is the company at, what is the underlying business model and problem. And I think as a RevOps person, you need to be, like, honest to yourself, and really evaluate — because, I mean, that's a huge purchasing decision for a big — right. And that basically has change management involved. Like, the finance team — that's not just sales. Right? That's a lot of different teams. So that's a decision you gotta be really, really, really careful about. This is not like, do you buy Chili Piper or some other scheduling solution? By that, you can, like, switch out, and it's not, like, super crazy if you make a mistake here. Right. Yeah. So just wanted to add that. Because I think it plays into this whole, like, build or buy question a lot.

Gabe Rothman: Yeah. It does. And I think CPQ is actually a great example for that discussion because it's a very sort of, like, multifactorial decision. Because it's not just how much customization are we gonna need in our CPQ, for example, in order to serve our business needs. Obviously, that's a big piece of it. And, you know, if the vendor, to your point, can't evolve the solution to fit your needs, assuming it doesn't fit your needs from the outset, it's gonna be slow and frustrating. But the flip side of that is do you have the capabilities within the company to own a solution like CPQ and evolve it to fit your company's needs. Because if you don't, then you're in a similar position in that you can't do it. You can't do it either way. Right? You certainly can't evolve someone else's third party solution, at least not any more than is, you know, available within the constraints of their product. We know how flexible Salesforce is, but, again, we also know what a double edged sword that can be. Right? You can kinda do anything with it, but you need the capabilities to do that. So if you don't, then you're faced with a decision — well, we need to hire that capability, which, in my opinion, people should always hire to have that capability. I think relying on external, like, consultants and vendors — which is the second choice, right, bringing in a consultancy to build out that customization — is worse than going with the inflexible software solution. Because now you have something that literally only that consultancy can manage. You have no insight into the mechanics of what's happening behind the curtain, and you have nobody whose sole focus is managing that thing. Right? At least if you buy a tool like DealHub, for example, at least that is what that company does. Right? Their whole existence is to support that tool. I think that if you're faced with that situation and you're, like, at the point where you need CPQ and you're deep into the evaluation and you don't have the capability and now you realize you need to hire someone, that's not a good position to be in because it's gonna take a while to hire someone. But I think that goes back to staffing. I think you should always have at least one person in your company who is a true technical expert on this stuff. So, yeah, it's, you know, it can be a catch twenty two if you're not properly staffed and prepared for it.

Janis Zech: I think, like, basically, if you work with an external agency — and I think external agency is totally fine. Right? Like, I'm not gonna hate on them. It's definitely a spicy take, but I think that's good because it is a decision that you need to think through. I think if you want to work with an external agency that does Salesforce development or HubSpot development, whatever, for you, you need to have a product person in house that is able to build acceptance criteria, catalogs, and do test QA, and who understands it. Otherwise, you shouldn't. Right? Like, if the agency basically tells you, oh, no. Don't worry about it. We have, like, a project manager. They will take care of you. No. They just don't do it.

Gabe Rothman: I a hundred percent agree. Yeah. You have to know what was built. Right? At the when that project is delivered, there has to be somebody internally that can tell you exactly what was built — and not just like, oh, it does these things. Like, what did we actually put into our system? For sure.

Janis Zech: Yeah. Yeah.

Gabe Rothman: So I will say, we did use an agency in our initial CPQ implementation, but we worked very closely with them. And that's actually a great distinction, which is that, like, CPQ is a beast, and we have at Rescale a lot of internal technical capability around Salesforce and the Salesforce ecosystem, but not around specifically CPQ. Right? So we brought an agency in basically to help make sure that we didn't, like, fall into any traps or screw anything up. We worked with them. And then when that was done, we knew exactly what was built. We worked hand in hand with them. They told us all of the, like, gotchas to look out for. And after the implementation, we knew our entire system. We were able to take it from there and run with it. So I think you're absolutely right. It does have its place, but it needs to be very strategic. It needs to be a very tight feedback loop. I think the notion that you can ever just sort of, like, throw something over the fence to an agency and say, just do it — yeah.

Janis Zech: Exactly. Yeah. This was just my thinking. Right? Like, it's this dream of, like, okay. I don't need to deal with it, then it's gonna be all good. But I think that's just fantasy. Right? I think in reality, it doesn't work that way. And I think you have a lot of ripple effects and what we call upstream effects, right, that basically then trigger. I'm curious. Right? So all this discussion, right, it always is in context of your go to market motions. Right? Like, very different if you're high touch versus low touch, whether you're inbound driven versus outbound driven, whether you're product led. Right? Pricing consumption versus seat based — or, like, completely different pricing. Like, you know, that all has a big impact on all these decisions. But what I'm curious of is, like, would you say that you need this kind of vision, right, like to basically know, hey. Look. This is where we wanna be in two years and this is how we're gonna get there, or is it more an iterative approach or both?

Gabe Rothman: I tend to lean more iterative because — well, I mean, my whole career, I've been in startup land. And, I mean, even at Rescale where, you know, we're a pretty mature company at this point —

Janis Zech: Just for the listeners, how big is the company now? I mean, you don't need to discuss the company, but, like —

Gabe Rothman: Yeah. We're around a hundred and seventy five people, something like that. It's fluctuating, you know, hiring, whatnot, but around a hundred and seventy five people. We're Series C, and we should be announcing maybe another round here coming up. But as of right now, we're Series C. Even two years ago, you know, we were in a pretty different place than we are now in terms of, like, our overall company strategy — not just in terms of the product and the vision for the company, but, I mean, even in terms of, like, our financial posture. I think a lot of companies were, you know — especially three years ago. Right? The VC and investor environment has changed a lot in that time frame, and investor expectations have changed a lot. And the way companies are run has evolved. The way that we're run has evolved — we've become much more efficiency focused. You know, cash flow positivity has become a much more emphasized factor than just pure growth. And so that changes the way that you view everything across the company. But in the context of this conversation, it very much changes the way you view your stack. We've carved a ton of spend out of our tools stack over the last two years. And so I think it's good. It's always good to have a vision for how you want things to evolve, but I think, especially at startups, you can't help but be iterative. And to that point, I think — I forget if it was Janis, it was you earlier — we were talking about, you know, tools that — like, I think you mentioned Chili Piper. Right? Nothing against Chili Piper, but it was a good example of, like — it's a great tool, but it's, like, the type of tool you can plug and play. Right? If you use it and you decide, you know what? This isn't for us or just not getting enough value, whatever it is. And that could be Chili Piper as a, like, generic stand in for any of these tools. Right? We're not picking on Chili Piper.

Janis Zech: Love Chili Piper.

Gabe Rothman: Love Chili Piper. Yeah. But with those types of tools, like, if you have to rip it out, it's not that big a deal. You could literally turn it off, and it's fine. Like, nothing's gonna blow up in your go to market motion. So from that respect, I think you can also sort of split the way that you think about those things. Right? The core foundational elements of your stack, obviously, you should be as strategic as you possibly can about. You should have a vision and at least a mental road map, if not literally a written road map, of how those things are gonna evolve. And then the other stuff, yeah, iterate on it. Experiment. Try things. I mean, we've over the years tried a bunch of tools that we used for a year or even a couple years, and then said, yeah. You know what? We're fine. We're good. I mean, we've had honestly, we've had tools that were more heavily integrated into our stack that we kind of played around with and then removed and replaced. The example I'm thinking of is a tool called Tray, Tray dot io, which is a great tool. I actually really liked it. And we used them initially because we had some need around integrating Salesforce with — no, sorry — with Asana. We had a weird period of time where, like — I don't know why, this predates me, but some of our engineers were on Asana and some were on Jira. And I was like, what are we doing, guys? What's happening? So we had this integration that we needed, and we used them to do a bunch of orchestration around, basically, the field team being able to request stuff from engineering from within Salesforce and then having a feedback loop with Asana and, ultimately, Jira. And so that was living in Tray for a long time. And, eventually, we moved off of Tray and onto a tool called Syncari. And the reason primarily is not that Tray wasn't a good tool — it's a very good tool. But Tray is very, like, point to point type of an integration. So with Tray, none of the integrations have any sort of, like, awareness of any of the other integrations. Right? It's kinda like — I never know how to pronounce it — Zapier or Zapier. Don't know how they pronounce it. On steroids in a way. Right? It's a lot more robust, but similar concept. Right? Like, you just have — I'm gonna integrate Salesforce to Asana, Salesforce to Jira. I'm gonna integrate Redshift to whatever. Right? And the challenge is as our integration needs got more and more complex, the data piece started to become messy. Right? Because you're like, I don't know where any of these data concepts are mastered anymore. Right? And so we switched to Syncari because Syncari stores data. It has its own database. Right? So everything integrates into Syncari and then out. So you can develop more of a golden record concept, or at least a centralized concept — an easier way to make sure that all systems have some sort of, like, quote unquote awareness of identifiers and, like, account customer concepts across tools. So that's an example of, like, a pretty heavyweight solution, complex build out, stuff that we put a lot of time into, that we decided, you know what? This isn't the right thing for us anymore, and we — it took some elbow grease, but we replaced it. And, again, love that tool. Syncari is working really great for us. So that's the type of stuff where I think it's always a sort of, again, multifactorial analysis. Right? You could rip and replace almost anything. It's how significant is the need, how much value you're gonna get out of it, how much work and effort is it gonna take to replace it. Right? Like, Salesforce, we're never ever ever gonna rip out Salesforce.

Janis Zech: Don't say that too loud. Your account exec —

Gabe Rothman: I already told my — that's how I talked to him. Yeah. They know it. They know it. They're not — they know it.

Janis Zech: So this is Gabe — just curious. Like, maybe we could, like, go for it, like, as an exercise. Like, so let's say, right, there is a need to purchase a new type of software. And there's a need to solve for a certain pain point that exists at your company, and you are evaluating whether you wanna buy or wanna build. Like, how would you actually — for you, okay — let's walk through this.

Gabe Rothman: Yeah. I could speak about it not in the hypothetical because we're doing it right now. So I'm gonna give you a little history on this tool category, and I'll talk about what we did. So this actually dovetails nicely with our last interview, which is commission planning. Right? So we used a tool for a while. I can never remember what it was originally called. I think they were either acquired or just renamed at some point to a company called Vericent. And so, like, the early history of that tool was when the ops team was very small at Rescale, and I didn't have the bandwidth to manage a commission tool. Finance came to us and said, hey. We wanna get a commissions tool. I said, great. I'm happy to support it technically, but you guys have to own the, like, actual implementation. And then fast forward, the main stakeholder for that tool left, and it was never really developed appropriately. And so we looked at it and we're like, well, we're already customers, and we knew we needed at that time a broader sort of, like, more supported implementation. And so we said, well, let's just stick with these guys. They at that time were working on replatforming the tool. So they were making a bunch of changes, and they said, hey. We'll give you some amount free while we're replatforming, blah blah blah. I said, great. That's fine. Very long story short, it just didn't work for us, and we decided, you know, we're gonna cut bait. That was midyear in twenty three. And so we realized, well, if we're gonna go through a whole evaluation to find a new tool and then buy something and implement it, you know, we're in July now. We're not gonna be done with that until, I mean, at least the end of August. If not September, that's the end of the year. Like, does it really matter for commissions for the remainder of twenty twenty three? Finance can continue doing what they're doing for the remainder of the year. So instead, we built out a — it's like a POC of, like, a homegrown commission system in Salesforce and used it in Q4 just to see, does this work? Do people like it? And it worked pretty well. It's all Salesforce automation and custom objects. And so we used it this year. And we've had a couple of, like, hiccups here and there, but overall, it's been very effective. Fast forward to now. We're at the end of the year. We got twenty five coming up. We're doing commission planning. And one of the things we've realized that is a challenge with that tool is it works great, but I built it. And we don't have anyone else on the ops team that can manage it because it's complicated. I built the whole thing. So anytime we need to make changes, especially on the automation side, I have to go and do it. It's not the end of the world, but it's a lot of work. And I have to get involved every time we have any type of, like, a nonstandard type of a commission scenario. Like, we have to do an override or we need to, like, remove and rerun a bunch of commissions for whatever reason. Right? So it is scalable from the point of view of, like, when it's running and we're not making changes — very scalable solution. Right? It runs great. It does not require a lot of maintenance. But from an evolutionary perspective, an iterative perspective, it does. And so looking at it from that point of view and also the point of view of, like, you know, we like our gallows humor at Rescale. You know, we call it the, like, the bus problem. Right? If I get hit by a bus, you know, like, what do we do? So we're evaluating commission tools now. We're almost certainly going to deprecate the homegrown system and move on to a commission tool. And I think that's a totally appropriate evolution. Right? We took a look at a homegrown solution. We knew we had the internal capabilities to do it. It worked. It saved us money if you don't count all of the many hours of my salary that went into building the homegrown one. But, again, you know, it's one of those things where, like, you don't wanna waste effort and money, but you also can't be too precious about the things that you build or your stack or even tools just because, like, a certain subset of people really like it. I mean, that is a valid reason to keep something. My point is that, like, you don't wanna, you know, fall into sort of, like, some sunk cost fallacy or, like I said, get too precious about the things that you built. But I think it provided the value for us that we needed at the time, and now we need to go in a different direction. Was that a helpful example, Philipp, for kinda what you're thinking of?

Philipp Stelzer: Yeah. Yeah. I mean, for sure. I mean, you basically just went through the whole thing — from buying to building back to buying. Right? And I fully agree. I think it's a totally okay choice to make, I think, as long as you make it consciously. Right? And I think that's the tricky thing — to think it through. The fact that in your case, basically, now you are the bottleneck is also — right. That's, like, a good reason to switch.

Gabe Rothman: Yeah. I also think one other thing to think about there too is, like — especially when you talk about, like, you know, we bought and then built and then now we're gonna buy again. When thinking about buying too, it's very easy to get starstruck by, like, bells and whistles. Right? But it's really important to think about, like, yeah.