Philipp Stelzer: Hello, and welcome to another episode of the RevOps Lab podcast. I'm here together with Janis, and our guest today is Hans Lees. And Hans wrote an article called Mastering Discovery: A Smarter Path to Impact for RevOps professionals, obviously. And we're here to chat about it today. But I'll let Hans introduce himself. I think he's probably the better person to do that than I am.

Hans Lees: Yeah, thanks, Philipp. I'm super excited to be here today. I followed the RevOps Lab podcast for some time. It's made me better at my day job, which is Director of Revenue Operations at DroneDeploy. Been there about four years. I've seen a lot. And now I'm starting to share a lot of what I know and what I've learned. So I'm excited to talk about discovery and RevOps today.

Philipp Stelzer: Great. Yeah. We're lucky to have you. Thank you for joining. And just to kick it off, really focused on the article itself — what inspired you to write it? Yeah, to write about the importance of discovery as part of the job as a RevOps professional.

Hans Lees: Yeah, you bet. So RevOps discovery is sort of something that I came up with as a framework for better operating. And it's pulled from sales. A lot of B2B SaaS is focused around solution selling and there's a big focus on the discovery process, which is really an act of listening. So it's sitting down with your customers and understanding what the company's goals are, what the individual's goals and frustrations are, rather than just diving into sort of like a feature gap analysis. And as revenue operators, we kind of have to see the full picture in the same way. But I think it's really hard when you don't have a strategic framework to go after or to go off of. You're often kind of getting pulled in a million directions and there's more work to do than you can have time for. So a lot of revenue operators in the strategic space will say slow down to speed up. And that is absolutely true. That's really the heart of RevOps discovery — how can you actually sit with all of the different people involved in a company, understand the go-to-market initiatives and the metrics that you're actually trying to impact, as well as the different stakeholders and end users interacting with the solution. So really slowing down, gathering a 360 view of things before diving into solutioning.

Philipp Stelzer: Yeah, for sure. I think there's a lot to unpack there, a lot of different parts that you touched on. And I mean, I totally get it. I think, like, from a product perspective — as a product person myself — I think discovery is always just so important because if you just run off and you start building something, chances are pretty high that maybe your view on the world or a specific topic is maybe not the view that your target audience actually shares. And it's just expensive to build stuff, you know, not only as an engineer, also someone who manages product like a CRM, Salesforce, or HubSpot, or other integrations in there. And some of these purchasing decisions for software can be quite expensive and can have huge ripple effects. So yeah, I mean, I fully agree. I think it's a good mindset to have. One thing I think that would be helpful is maybe if you could explain a bit like your framework of how you think discovery should be done. I'm sure it's always a little bit different depending on the type of company where you're at and the culture, the size, the people you work with. But from your point of view, what is a good starting point for doing discovery?

Hans Lees: Yeah. So the entry point kind of happens in different ways. Sometimes there's sort of like a bubble-up, bottoms-up approach to a project origination. And that would be if there's a lot of noise in the system or in your case queue or things like that. You're hearing a lot of feedback where there's a lot of friction points. And so that's end users surfacing areas to focus on or data surfacing areas to focus on. And then sometimes there's more of a top-down OKR style approach. And oftentimes, they're related. And that's kind of the heart of discovery — creating unification of the different parties involved, the different goals and the different voices — is that really at the end of the day, most of the time, you're going in the same direction. You want the same goals, obviously. The same thing that provides customers with value is what drives rapid growth, is what pays out commission. So there really is shared goals and alignment, but a lot of times that's missed. So typically, you have some sort of project origination, but you need a little bit more of like a container around how to go and solution it. And so for me, discovery is really the first step in that process. It's before you start to point fingers at the system or the process or the data, you kind of take an intake and then you start to categorize where do those different friction points, where do those different problems live, and how do they actually drive an outcome. And by attaching yourself to a single metric or to a single goal, you're really able to eliminate project bloat or scope creep, which is a big problem in the operator's world. And you're also able to develop a foundation that you can then scale on because metrics themselves are usually pretty evergreen. If you're trying to improve a conversion rate at any point in the customer journey, you theoretically always want to improve that. And so a lot of times when you go and create some sort of acceleration product to improve a conversion rate, you're probably doing a lot of foundational work to start because you need to make sure that the systems and the data are reflected or reflecting the process that's intended. But then once you have a foundation, you can continue to manage that metric, build operational cadences around it, and continue to drive strategy to influence that metric. So I guess I can talk through the sort of like four steps of RevOps discovery, if you'd like.

Philipp Stelzer: Yep. I mean, go for it. Go for it, I would say.

Hans Lees: Yeah, you bet. So there's four steps in my framework for RevOps discovery. The first is it starts with strategy. So no matter where the origin point is, you always want to make sure that you understand the actual current state of the business and the strategy. And that's where it kind of becomes bigger than operations, which is really exciting if you think about leadership and empowering a bunch of different end users to drive an impact — tying to strategy makes the whole movement, the whole momentum a lot more powerful. So that's really the first piece: understanding what's a priority and being able to tie that operational work to that. The second piece of that is pinpointing the actual metric that you're going to influence, because what gets measured gets managed. And so if you're able to actually pinpoint what that metric is, then you're able to be a lot more impactful in not only quantifying the work that you're going to do — so telling a really good story upfront and measuring the impact — that gets a lot of people on board, a lot of excitement around that. It also helps you prioritize. But then later, it helps you focus and manage your success and keep the momentum going. It also allows you to have a better sort of way of making sure that the data is reflected in the system when you have a more data-driven approach to RevOps projects. And then the third piece is really spending a lot of time doing user interviews. And this is with the different voices in the room. And really, all of them are important. And this is really just an act of listening — making sure that you understand the stakeholders. So if you're thinking through lead to op conversion, you want to make sure that you're interviewing with marketing and with sales leadership and just understanding their viewpoint, their experience, their goals. Again, this is really to create that alignment in goals. And that's where that metric becomes really powerful in creating that sort of shared vision of what you're trying to impact. But then you have the end users, and this is really important. I think a lot of times it can be somewhat overlooked. I know I've learned this lesson so many times in my career — your end users, the sales folks, the BDRs, the CSMs, they are the ones that are interacting with the customers. They are interacting with the systems that you implement, and their voice is so important. And then the fourth piece is really being able to take that feedback and categorize the pain points. This is what allows you to have really like a paint-by-number solution at the end of this discovery. It kind of makes things obvious. It illuminates everything. When you take all of that feedback and you put it into people, process, data, and systems — all of those pain points are important, but you're solving for sort of different things but together under one shared project.

Janis Zech: Yeah. I love it. I mean, so hi — I'm also here. I'm frozen the whole time. But just to recap for the audience — step one would be you start with a strategy. Step two is define the problem with data. Step three, really engage with the stakeholders, listen, learn, and get a full understanding from a first-principles perspective. And then step four is basically categorize those different work streams, especially around pain points. Maybe we can dive through those a bit deeper, and you can share some learnings on the different aspects. So if you think about the strategy part — I mean, often we all go through this annual planning exercise that ideally also sets out the strategy for the next year. And then in Q1, everybody has already forgotten what we actually talked about, and sometimes the metrics are not even talked about in bad cases. Right? Ideally not, but that happens. So I'm curious — what would you look at when you say start with strategy? What would be your recommendations of things that you should look at, and what would be some examples maybe?

Hans Lees: Yeah, well, sort of to your point, the top-level strategy depends on the stage of growth of the company and where they're trying to go. But a good place to always look, I think, is conversion rates, because conversion rates really pinpoint opportunities for operational efficiency, acceleration, and operational health. So I would always kind of pinpoint those. So if your goal is to do more with less and to make more out of your top-of-funnel leads — so you want to convert more of your highest intent leads to qualified opportunities — that's a really great way to tie yourself to efficient growth, because that's being able to grow pipeline with your same sort of like top-of-funnel inputs. And that's a really great place to kind of look in strategy alignment because there's so many different pieces at play there. And there's a giant handoff between marketing and sales. So you sort of have your customers or your prospects interacting with your website. So you need to make sure that that is optimized, that you're driving people into a demo request flow. So there's messaging there. During that process, you're then ingesting those leads, you're enriching them, you're doing sort of prequalification — lots of opportunity there. And then you're handing off those leads to sales and you're expecting them to act on those, of course, and quickly too. And so there's a lot of interaction between strategy, people, data, and systems and tooling there. And there's lots of opportunity for automation, but there's also lots of opportunity for alignment on goals, expectations — setting up a good SLA between that handoff can be really effective in making sure that there is a shared approach to those leads. But then as you start to kind of dive in, you might realize that you don't have the data infrastructure in place to actually track those steps. And there might be a couple of reasons for that. One, you might need to kind of look at your staging logic and make sure that that's reflected in the system. And then two, you need to make sure that there's visibility in the system of all of those things that happen so that you can accurately track those leads through. Then you can start to get into things like, is there visibility? So is there the right notification in place for sales? And does sales like the quality of leads? Or what is their feedback on the quality of leads? And that could point to a lot of different things. It could point back to messaging on the website, but it could also point back to enrichment or routing logic and those sorts of things. So you have all these different moments at play, but it's really all centered around that same efficient growth in the top of funnel and driving that conversion of lead or demo request to qualified opportunity. But you could see then you really need to do discovery to actually sort of diagnose what's going on and then also be able to set the foundation to scale.

Janis Zech: Yeah. I love this example a lot because I think it's a great example where you have so many different aspects that play into the actual core metric, which then would be kind of the strategic goal for you to change and improve. But then at the same time, it is very, very complicated to know what is actually driving it. Right? Is it the channel? Is there a difference in lead quality by channel? Is there a difference in audience or in geo? So there's so many factors. And so I think it's a great example where if you just go in and say, okay, the CMO comes or the VP of marketing says, I believe this is the problem, and then you just go out and you do it, you might actually work a lot, but you don't change the metric fundamentally. And then I think the other piece, which I think is a great example here, is obviously it's not just about the tooling. It's also about the process. It's about process compliance. It's about behavior. And I mean, I think we see this with outbound all the time. Actually, we ran an episode on signal-based outbound and the new orchestration tools that drive those — like Common Room, for example. And I'm a big fan of that because I think it's actually not new. It's something the best companies have done for many, many years. But the problem was that the visibility and the actionability wasn't there. And this was basically very challenging for a lot of companies to do unless they had very good RevOps and marketing ops folks to essentially operationalize the whole thing. And I think that gets democratized right now. It's actually a lot bigger revolution than AI in my mind in terms of outbound, where you basically change the game from cold outbound sequence-based, very static, to dynamic signals that overlap and you combine multiple to essentially have better outcomes and efficiency — both where people spend their time and what they do. So I think I'm not proposing this is the answer here, but I think it's such a good example of why discovery is so important. So thanks for sharing that. Maybe the next one — define the problem with data. If you would go further into that second step, can you give some specific examples of how you've seen this can be done well?

Hans Lees: Yeah, absolutely. I mean, this is where storytelling is so powerful. So pinpointing a single metric, I think, is so important because I think we're all really smart in B2B SaaS. And so it can be really enticing to get into the weeds of mapping out every single conversion rate, every moment of interaction — all of those sort of nitty-gritty metrics, they're all important to sort of define, but you kind of need to gather around a single metric in order to actually focus the project around a single impact point and actually quantify what you're trying to do. So if you take demo to op conversion, that's a great metric point to quantify because the power of it is so palpable when you sort of dissect it. So if you have a hundred leads and you're converting twenty percent, then you have twenty of those leads converting into opportunity. If you fix the conversion rate, you are building a foundation that now does more with your input. So if you fix that conversion rate, let's say you double it, you get it to forty percent — now those same hundred leads are converting at forty percent, right? So you have forty qualified opportunities. That's a lot easier to do because of all of the different sort of ways that you can improve conversion rate that we just talked about. There's the people, the data, the process, the system — all of those things will influence the conversion rate. And when you increase your conversion rate, now when you have two hundred leads, instead of converting two hundred of those leads at twenty percent, which would be forty leads, you now have eighty leads converted into opportunities. So that story is really powerful because you're basically saying we don't need to go and drive more leads just yet. Let's focus on fixing the conversion rate. And then when we go in and we apply AI or we apply more sort of like product-generated leads, they're coming into a funnel that's a lot more efficient. So to me, having a single metric where you can really rally around tells a really powerful story. It is also such a great unifier because sometimes when you are improving systems and data, that is not translated super well to your end users or your stakeholders, even though it is important. But when you have a metric that is sort of a shared goal — like who wouldn't want more qualified pipeline out of the leads that you have? That is a shared goal. That's a shared goal for the prospects that come through because they're looking for something. They're requesting a demo, and now you're actually delivering enough value. You're following up with them immediately, engaging conversation. So you've improved the customer experience — that's most important. You've generated more pipeline — that's top-level strategy as well as the individual sort of stakeholders. You're making more out of those marketing leads, which obviously makes marketing happy. And then you're generating more pipeline, which is really attractive to sales because now that's that much more pipeline that's likely to convert into a closed won. And so that metric allows everybody to kind of have the same vision forward, which was always the case, but it sort of clears the path and clears away some of the friction and creates that momentum and alignment around how you're going to solve that problem or accelerate that metric.

Janis Zech: Yeah. I like that you start the data part — the second step, defining the problem with data — with the story piece also. I mean, our listeners have heard me say this multiple times. I think it's so important. People are afraid of data. I think it's just a reality. You know, for many people, math in school was not like their favorite class. For some it was — good for them — but for many it wasn't. So data always feels for many people like they're a bit scared of it, in quotation marks. Don't want to exaggerate here, but I think there's a truth to it. So I think telling the story with data is really important. And what I really like is how you actually put that in your article — you said use data to highlight opportunity for change. So you basically say, hey, you can use that data to really tell a story around there being a real financial opportunity and a revenue opportunity by making a change. And I think this is also a really good way of actually getting other people that you need to bring along — like the other stakeholders who all have a say in this to some extent, particularly in RevOps, you're often pulled in so many different directions with sales, marketing, leadership, finance, and so on, all these different teams. So to bring them together and to use storytelling for that — yeah, I love it. And I also think — and sorry, then I'm going to ask you a question — I love it because I think it's also good to start with this. I think a lot of times people will maybe say, hey, start with the qualitative aspect first and talk to people and so on, then from there start looking at the data. Actually, I think doing it the other way around actually puts you in a better position because you're a lot better prepared to engage with these stakeholders — it's then not only about asking them, but you come informed, and you're also able to steer the conversation in a specific direction. And not because you want to do something bad — you don't want to convince them to do something bad. You want to help them move in the right direction and get their support for it. So yeah, that's my perspective. That's how I sort of interpret what you're writing and saying there, and it definitely resonates extremely well with me.

Philipp Stelzer: Before you ask a question, just want to jump in because I think it's almost like you put a north star to a project, right, and you rally everybody around the north star instead of rallying everybody around the problems. And the problems are there — okay, we can talk about why the current state is so bad. And then you'll have sales say the typical thing, the leads are shit. And marketing say, well, sales doesn't follow up quickly enough. And you're suddenly in that conversation, which is obviously very bad for RevOps because what you actually want to do is you need everybody to rally around a future state that is better and then work together to improve it. And without the people, you will not achieve it. It's impossible to achieve. So really love this. Janis, back to you. What's your question? Sorry.

Janis Zech: Hans, do you want to intervene? Or do you agree?

Hans Lees: Sorry. Completely agree. I mean, one of the things that is so important to remember is that the metrics that you measure themselves — those don't change that dramatically. I mean, they change in the quantifiable metric, but the metric that you're measuring, the conversion rate, you always want to measure that. And so that's why it's important that that's your north star, because that's sort of a neutral thing. It's like, well, of course we want to improve this conversion rate. And so when you're rallied around sort of this neutral opportunity, it's kind of like you always want revenue growth year on year — that's almost a given. When you have that, then you can say, okay, but how do we do that? The tech that's available, the historical context, the feelings and the frustration — that will point back and there will be criticism of that metric from those conversations. But that's where you go and you start to strengthen that metric so that now you have data architecture in place where that metric is really solid because people are acting on the process. The process is really clearly defined. It's reflected in the data, activities logging back to the system. There's a feedback loop to marketing and there's just a lot more cleanliness in that data point. That also sets you up in the future to go back and do a re-acceleration of that metric with a lot better foundation. But you're saying now we're going to roll in a new AI initiative into that really strong foundation — it makes it easier then to continue that acceleration.

Janis Zech: Yeah. Okay. Thank you. I think it's an important addition. Let's move to the third step. Already teased it a little bit here — that's actually bringing in all the different stakeholders, engaging them, creating a fuller picture. And I think there's a big risk there. You start bringing in all the other people, every person has an opinion — this is probably sometimes hard to balance. What's your experience there? What would you recommend people when they get to this step in the discovery process?

Hans Lees: It's hard. That's my advice. It's really hard. No, it is. I mean, it's something I've been humbled by. I've had to learn many times in my career is just the importance of the people that are interacting with the process, with the systems, and with the data and their perspectives and just how important that is. There's a lot of trust building that can only come from conversation. It actually doesn't matter that you've run it through the data warehouse and that it's now certifiably good data and you share that out and everybody should just now believe it and trust in it. You have to spend time actually understanding what people are experiencing. And that's not necessarily like a one-time thing. So I think doing user interviews — if you have dashboards in place, watching folks interact with the data and share their experience, where they're getting confused, where there might be a disconnect in your visual versus your CRM or their actual day-to-day experience. If you're talking about the lead to demo example, making sure that you know where those notifications are and how they act on that. So actually watching them go through their process. There's a lot of times if you're looking at the conversion but you're not even sure how many of those leads are being worked — it's not always that they're not being worked. Sometimes it's that activity, as you guys know very well, is not logging back to the system. And so there's enablement opportunities, or maybe there's actually a problem in whatever tool you're using for activity capture or for telephony that you didn't realize even existed. And maybe there's international considerations and that sort of thing. Maybe they're not even seeing all of their leads. They're using different list views. I mean, could be really simple stuff, but watching them go through their day-to-day gives you a much fuller picture. You also can start to see why it is that the feeling is that lead quality is not as high as they would like. And you can start to pinpoint that, because maybe again, it's messaging to do some pre-qualification or some filtering on the front end, but there's also probably enrichment at play. There might be routing considerations. So there's all those different things that you can only really diagnose by watching people go through their motion and how they understand what it is that you're presenting with them. I think it's really easy as operators when you are in the midst of this massive cross-functional project to feel like you know it inside out and therefore everybody should too. And there are a lot of areas for things to get lost in translation. And the more things get lost in translation, the more trust erodes. I adopted this saying that distance does not make the heart grow fonder. And so pulling in those different voices in the room, those different stakeholders and users closer, understanding their experience and partnering with them is really, really important, especially through change management.

Janis Zech: Yeah, I love this very much. I mean, you have the end user stakeholders, you have the stakeholders on the leadership side and the executive side, and I think you have to manage the discovery process very differently for each. I think you outlined the discovery process on the end user side very nicely, actually. At the same time, you're getting pulled into a direction from leadership, which is always happening. And so I think from the leadership side, it's almost more about ensuring that everybody understands there are trade-offs. I think the leaders think more on strategic initiatives. They don't really care about the end user experience as much — they don't know. But that doesn't mean it doesn't matter. And I think this is so important. So forgetting about that often — right, like you can sit in a room with a lot of leaders and it's basically the ivory tower. And the leaders would basically sit in the same room and still create a solution where the marketing or salespeople on the front line say, well, actually, that's not helping. That's actually complicating things or making it even worse. And so I think having this kind of triangle — good in-depth discussion with your team on the RevOps side, very deep discovery and time spent with the end users, and then working with the leadership stakeholders on the more strategic alignment on what needs to be worked on and ensuring that there's an understanding of trade-offs and timelines and project scope and capacity — I think that's a good way to think about it from my point of view.

Hans Lees: So, so important. Yeah, I mean, and when you think of like a discovery process, there's a lot of those sort of like questions that ask the prospect to qualify themselves a little bit. So you kind of touched on that, of almost being able to explicitly ask, is this a problem or is this a priority? And actually hearing from the voices of stakeholders and users what actually is the problem they're experiencing, or to your point, why something actually won't solve what they're experiencing. Where in sitting in that boardroom, sitting in that strategy room, it feels so obvious — we're going to streamline this handoff and then it's going to be brilliant and it's going to be received really well. Actually, one, it's not going to land unless that really actually originated from the end user themselves. And two, it might not actually be directly solving the problem. The strategy is correct. The direction you want to go is correct, but it's kind of missing the translation piece. And so being able to sit and actually extract that is so important. Plus, from a human side, if you are the one who voiced a need and that need is fulfilled, that is the ultimate customer or end user experience. And so if you can get them to state the need and then you as the operator are sitting on the other side saying, okay, great, thank you for telling me exactly how to make good on this — then that's where your roadmap becomes really clear, and your story becomes really powerful too. And then you have champions on the other side as well.

Janis Zech: Yeah. I mean, I have this concept of product development where discovery is the stage where you actually don't know and you try to find out. And you go very wide and you basically open up all different possibilities and then try to bring them in order. And this is both on the strategic side, where you trade off different metrics in your example, and then also the specific solutioning to the problem. And you bring them basically in order. And then there's the roadmap, which is the second process where it's a lot more centered around knowing exactly what the execution part is, but you've already selected the strategic initiatives and you've already worked on the solutioning. So I think there are different layers of discovery. And yeah, I think it's actually beautifully outlined how you wrote it and talk about it. Maybe a last step — categorizing pain types. Can you share a bit more about some specific examples there? And then I think this is probably the last one, then we wrap up at some point given the time. But yeah, curious about this one as well.

Hans Lees: Yeah. So I kind of outlined four different pain categories. And the first is people. And that's a big one, right? Because emotions live in the people bucket. So if there are frustrations, you absolutely have to address that and take note of it. I think sometimes that can be sort of overlooked as important. But again, we are ultimately building systems and processes that humans interact with. And so if the humans are not on board or feel frustrated, that is a health problem that you have to solve for. So being able to intake that is really important. And the other piece of the people bucket is understanding where there needs to be coaching or behavior change. And then the second piece is the process. And the process supports the people, but the process also informs the systems and the data. And so it does kind of both of those things. And it also is your roadmap for strategy. So I think process is sort of the heart of what you're trying to do, and it needs to be reflected in the other three. And then the third piece is data. Data builds trust. And data also makes sure that your process is reflected in the systems. And so a lot of the data piece is making sure that the right activity is captured, that there is staging in place and those sorts of things — that is also your foundation. So hopefully, you get to a point where your data is so solid that that's not as big of an issue in future accelerations or iterations. And then the last piece is the systems. And this is kind of important as the last piece because I think so often it becomes the first piece. And it's such a powerful piece. I mean, if you think about the whole conversation around how to apply AI, it's only really relevant if it actually accelerates the process and accelerates the metric that you're trying to drive and that humans are able to use it. So the systems piece, while extremely important, is sort of the last piece in your discovery. So being able to take that 360 intake and then categorize into those pieces, you sort of have your roadmap of how to go about your project planning. Those are your four categories of outcomes. Hopefully your umbrella or scope is not so large, but you're sort of step by step on how to actually go and make improvements to the foundation, but then also put your strategy and enablement piece on top of that too.

Janis Zech: Yeah. No, I think that's great. And I mean, I fully agree. I think many people think about tools as a first step. And this week alone, there are several conversations with prospects who were interested in Weflow but actually didn't really know what their problem was. So that is — also in selling — a huge part of the whole discovery, making sure you guide them and actually guide them towards understanding what they are trying to solve. So yeah, it's not only in RevOps. It's also in product sales. It's a universal thing. Don't start with the tool — this is probably always the worst idea you can have. Hans, thank you so much for joining our little podcast. I think your article — it's a short one, but I think it's very concise, and I highly appreciate that. We'll put it, of course, into the show notes. So everyone, definitely check that out. Some diagrams also in there, which I think will help you structure that conversation — maybe open it up while listening to us. Actually, I should have maybe said that in the beginning.

Philipp Stelzer: Yeah. We have to plug it in the beginning, actually. Yeah. Let's plug it in the beginning. I think it's a good one to add.

Janis Zech: And yeah, always one final question — what book or books would you recommend to our audience?

Hans Lees: Yeah, you bet. So I've got a stack of books. I think books are so important. They help me every day in my job. This one right now — Sean Lane, he was the head of operations over at Drift — The Revenue Operations Manual. He talks a lot about really end-to-end RevOps, but he talks a lot about operational cadences. And what I love so much about that is it sort of reframed my mind from project management to program management. And once you sort of have that foundation at play, you're going to have to have more of an operational cadence as to how you improve and scale day to day. And then the other one, just relevant to our example — Sales Acceleration Formula. This is Mark Roberge — I'm not sure I said his name correctly, but he was the CRO at HubSpot. And he really simplifies how to run a really effective marketing to sales funnel. And he talks about this idea of the sales and marketing SLA, which is so simple but so brilliant, that I have shared it around with many people that I work with. So anyway, those are two that I'd recommend.

Janis Zech: Great. Actually, we had Sean on the show also talking about the book. So yeah, fully agree. And these cadences — I think it's extremely — sorry, just jumping in here — these cadences are extremely undervalued. Again, typical conversation where we have prospects talking to us about forecasting or pipeline management. First thing is always like, hey, what's your operating cadence actually look like? Because the best tool, if you don't have a cadence in place of how you actually run — you know, for operations, but also for sales