---
title: "The Lie Behind Failed Quarters"
episode: 83
podcast: "The LeanScale Podcast"
publisher: "LeanScale"
guest: "Andrew Geisse"
guest_title: "Chief Revenue Officer, Pallet"
date_published: 2026-05-28
date_modified: 2026-07-22
duration: 00:49:50
word_count: 8499
topics: ["gtm-strategy", "forecasting", "consumption-revenue", "pricing-packaging", "ai-in-gtm", "enterprise-sales"]
canonical_url: https://leanscale-knowledge-hub.netlify.app/podcast/andrew-geisse-failed-quarters-gtm-planning/
source: "LeanScale Podcast Knowledge Hub — https://leanscale-knowledge-hub.netlify.app"
license: "Free to quote and cite with attribution to The LeanScale Podcast."
---

# The Lie Behind Failed Quarters — Full Transcript

> Episode 83 of The LeanScale Podcast, with Andrew Geisse.
> Published May 28, 2026 · 00:49:50 · 8,499 words.
> Machine-transcribed and **not diarized** — speaker attribution is inferred, so verify
> attribution against the audio before quoting a specific person.
> Structured breakdown: https://leanscale-knowledge-hub.netlify.app/podcast/andrew-geisse-failed-quarters-gtm-planning/

## 00:00 — Intro: the consultant who became a CRO

**[0:00]** Today, I'm talking with Andrew Geiss, the CRO at Pallet. They're building AI workforce automation for logistics. But what makes Andrew's perspective valuable goes beyond any one company. He spent nearly seven years at DocuSign building enterprise sales, then led North America sales at Reputation, and before that, he was at Deloitte. And he told me something in our prep call that stuck with me. Most of the jobs he's had, he wasn't technically qualified for. But he's figured out how to walk into unfamiliar environments, put structure in place to make them understandable, and then execute. We're going to get into that framework, especially his belief

## 00:46 — Walking into roles you're not qualified for

**[0:46]** that most GTM motions fail not because we lack data, but because we're not honest about what's really happening. Andrew, you told me most of the jobs you've had, you weren't technically qualified for, but you've figured out how to walk into chaos and execute. How did you develop that skill? I mostly have to thank Deloitte for that, being a consultant. So for the better part of 10 years after undergrad, I did that job. And every new engagement you do with every new customer is some version of that, an industry, a function, a problem that you're tackling for the first time. So you

**[1:24]** build that muscle. And so when you think when it came time for me to leave Deloitte, my first job at DocuSign was in product marketing, a function I knew some stuff about, but certainly wouldn't qualify myself as an expert in. And then as you know, I did a number of sales jobs, sales strategy jobs after that, again, all new for me. And that's been the theme, I think, for most of my career. To be honest, Anthony, it's also partially what I like, it's exciting to step into a new place, a new environment where I'm not necessarily the expert and try to figure it out with the team.

## 01:59 — The first 90 days: absorb, then find the truth

**[1:59]** Yeah, I think it's always, if you're not learning and growing, you're regressing and going backwards into your career. So I think if anybody's feeling that uneasy pressure, sometimes it manifests as imposter syndrome. But if you're feeling imposter syndrome, it probably means you're doing the right thing and pushing yourself in a healthy way. I think the part that some people have a challenge with is where do you start? You find yourself drop shipping into a new role, new environment. What does that process actually look like? Like first 90 days or whatever that

**[2:34]** timeframe is to where you start getting productive? I think the answer to that depends on the problem set that you walk into. And anytime I'm starting a new role or new company, the first 90 days, a lot of that time is absorbing as much information as possible. That's talking to the people on the ground that are doing the selling, doing the implementing, that's looking at the data that you have available and forming a perspective coming out of that. Marrying those two, there's probably more than just those two things, but marrying those two perspectives together to

**[3:08]** formulate what you think is the truth about what is actually happening. And out of that process, you get a sense of the things that you can do, priorities that you might have to help either point the organization in the right direction, problems that you need to fix within the organization to help it operate to its full potential as an organization. The same thing is true for people or the things that you can do with the people to help them also start operating at their full potential. As you reflect on your career, are there any missions you've gone on that feel like they were the most challenging and you had

## 03:44 — Why Pallet is the most challenging mission yet

**[3:44]** to flex this muscle more than any other time? The company I currently work for, Pallet, is probably that, partially because the scale of the opportunity that we're tackling. The difficulty is magnified by the fact that it's a first time thing for everybody. The AI companies have only been around for a handful of years. They're just starting in the last couple of years to be in production and in industry. Everybody is figuring it out for the first time. So then there's very very little things you can point to have been there did that. Whereas if I look at my last

## 04:29 — Where he goes for resources and peer learning

**[4:29]** company, Reputation, a more traditional software company, if I had a problem, I could usually find somebody that had tackled that problem before and at least use what they had done as a starting point for how I might think about what we do at Reputation. Whereas here, it's like every day, we're doing something new and exciting and building the way that the industry will work, AI kind of in general, every day. Are there any resources you use to help you place your bets, any areas you like to go to to give information? I think a lot of people we work with, we're mainly

**[5:02]** working with B2B, SAS and AI companies. It's a new frontier for all of us. Where do you stay up to date to make sure the decisions you're making are grounded in some form of data or at least giving you a direction of where to go? I think there is the same version I mentioned before of talking to the people and looking at our own data of what trying to try to formulate what's actually happening here. And we try something new for the first time, a way to position this particular product, a way to think about pricing this way, getting enough data points within our own environment to see if that's

## 05:38 — The usage-based pricing problem in AI

**[5:38]** working or not. There is the emotion of building a network of peers of people in my industry loosely, not direct competitors, but people selling AI solutions to certain companies, B2B that are resources for, "Hey, if you tackled this problem, how did you think about it?" Pricing is a good one. I think that comes up quite a bit in my current job. And that's also super helpful. Yeah, I think pricing in the AI era has been a huge challenge for everyone, especially migration to usage-based pricing. It creates a whole slew of go-to-market operations issues as well. How do you do comp plans? How do you do territories,

**[6:24]** assign quotas, you name it. It's really difficult to do. So I think everybody's experiencing that same challenge. And I think it's going to be some time before we know what normal looks like in AI pricing. I feel like the old cloud era solidified, "Hey, it's seat-based or platform fee is very clear. This is where the market goes." I'm not sure exactly where AI goes, but I do think it's going to have a heavy usage component in general. Okay, there's a lot to unpack there. I agree with you with the last part. So for our platform, for example, many of our enterprise

**[7:06]** customers in particular have expressed a desire to be able to build and execute workflows on our platform by themselves. And in that world, they need to be able to do that, understand what that's going to cost them to run without having to give a phone call to us. And so that looks something like usage-based pricing. I think that topic though, even though how you price AI solutions is a bit, people are doing a whole bunch of different things and doing some experimenting, us included. The usage-based pricing is a thing that is, I don't know if I want to say fully

**[7:39]** understood, but there are other companies in the SaaS world like Twilio that have gone through many iterations of usage-based pricing. And so even there, there's a topic where some people have some opinions, some thoughts, some battle scars about how it's happened in the past that could inform if you're going to do usage-based pricing as an AI company, how you might do that, how you might structure comp plans for a user that you're driving the right behaviors for the company. I definitely have my own battle scars with some of our customers that are usage-based, but also

## 08:10 — Emailage, JP Morgan Chase, and articulating ARR

**[8:10]** as an operator, I had a RevOps for a company called Emailage, fully usage-based pricing company. And it wasn't the norm. So I had a hell of a time trying to articulate what our ARR was to investors or the board, setting up comp plans and assigning quotas. Really, really difficult. And probably biggest example of this, we closed JP Morgan Chase and they had this forecasted amount, but the commitment was zero. How do we resource it? The only thing I think that's a little bit different from that time, our cost structure was relatively fixed and low. And we didn't have to

**[8:50]** worry about capacity too much where the cost side of AI now is a real part of the equation where before maybe you didn't have to focus as much. I agree. And so I can only speak from my personal experience. Most of the problems that we are tackling for our customers, if you just reframe to the value of what we are doing for that customer, it still is well above the, if you just look at the raw LLM costs that you have to do to process that workflow. But to be intellectually honest, it's not just the raw LLM costs. There are more traditional software processing costs or general R&D costs for us to continue to involve the platform.

**[9:31]** But regardless, even when you consider all of those, typically the ROI that we are doing for the customer is still well above that. How that changes when it's a pure usage-based contract, that's still TBD, I think. Again, it's a problem I think that certainly we're going to have to solve because like I said earlier, customers are going to want to build their own agents and execute their own agents on our platform for sure. Well, when you solve it, we'd love to get the template. I've been working on it for probably about a decade now and still don't feel super confident

**[10:06]** about it. But we'd love to know where you land. Yeah. So I was just going to say usage-based pricing as a concept is difficult. When we were considering that topic and we're still talking about it internally, I called some people I knew that had worked at companies like Twilio and a couple other usage-based companies, and they had the same problems that you did. Even if you could solve the rep compensation problem, we're going to compensate you based on actual consume usage. We're going to compensate you based on a commitment and then do true ops. I've seen many different

## 10:38 — Reporting usage-based revenue to the board (estimated ACV)

**[10:38]** models. One, none of them seem to be that perfect for AEs. If you talk to the sales ops people, they would think the plan would work well. But I talked to both sales ops people and then sales people in both these companies. And the sales people felt like the compliance were hard to understand, which is not a great thing to put in front of a salesperson. But you touched on a really important problem of even if that's going relatively smoothly, how do you report that up to the board when the board is used to C-based pricing where the ARR for the next year is going to be very, very predictable? And that problem, I think, is difficult to solve.

**[11:15]** We had to be unbelievably clear about what our definitions of ARR were. And we had a concept of estimated ACV, estimated ARR. And we would stack them. So if you're looking at our ARR chart in our board deck, we would say, hey, this is contracted. So you could take this to the bank. That's good. But I don't want to discredit us. We did close chase. The forecasted amount for them is, let's say it's a million dollars a year. We would take a fraction of that, say, hey, let's take half of it and stack it into our EACV bucket and then put them together. So that way, we could communicate it, but still, hey, take it with a grain of salt. This is how

**[12:01]** we're doing the calculation. But it took a lot of education. And especially if you're in a-- it's fine with your current board. They'll start to understand it. It gets a little bit trickier when we were in fundraising mode or during the exit of really articulating that well. But that was how we handled it. I think that seems reasonable. My question back to you would be, when you did that, let's say you were forecasting, let's say we're almost at the start of Q2, you're forecasting the rest of the year. When you looked back on that year, how conservative or aggressive did

## 12:38 — How conservative should the forecast be?

**[12:38]** that end up typically being? We took a relatively conservative approach. So we weren't trying to-- we wanted to make sure we didn't inflate any of our numbers, but we could articulate, hey, there's still upside here too. And then that was for the new accounts, which are the trickiest to figure out. For existing, we would have historical data. And then we could do some regression testing to say, hey, of our existing book, we expect this level of growth. And we expect this level of retention. You can see it in their history. So that was a little bit easier to forecast.

**[13:15]** Also the product in general, not all products are as predictable. You have some products where you have major spikes and then retractions throughout the year, which makes it even more difficult. But it's not something we had a huge issue with. A little bit of a spike in Q4 during we worked a lot of e-commerce companies. So we'd have some holiday spikes, but we could figure that out. But yeah, it would be even more challenging if you couldn't predict when your customer is using it. Yeah, we don't have that problem by and large. There are some exceptions. By and large, there is some seasonality to deal with. But the processes that we are tackling,

## 13:56 — Pallet's successful-transaction pricing

**[13:56]** they are running generally all year on a continual basis. And I think that does not make it substantially easier, I suppose, if you do usage-based pricing. I think for us, we are currently the way we are thinking about it as a one. The philosophy is we want the cost of our service to be almost one-to-one the line for the benefit that the customer is doing or getting. So it's not really-- we are not doing usage-based pricing at the moment. It is more successful transactions. So if you think of a-- you use Palette to do an ingestion use case of some sort, you read a

**[14:36]** document. We are only charging our customers when we kind of read that document to really run the whole process around reading that document successfully. And that, I think, is a great mechanism because then it's a forcing function for Palette of-- let's say there's 10 fields. You read off a document. Another 10 fields you have to infer from as history or the contract you have with our customer's customer. Only when Palette gets that 100% right to recharge our customer and that it drives us to then be as accurate as possible. Otherwise, we're not delivering for our customer. So that's been helpful, certainly helpful in the conversation

**[15:16]** with our customers who are also figuring it out. And they talk to our competitors, direct competitors who service the freight industry. But that's also Google. That's Andropic. That is Box. Everybody is doing something AI-related. And everybody seems to have a little bit of a different flavor for how they're doing things right now. I think if you can tie to outcome-based pricing, that's always going to align what the customer needs. And just like you mentioned, really give you the motivation to make the product as strong and increase the efficacy as much as possible. So that way, you are incentivized to monetize

**[15:56]** as much as possible as well. So any time you can make that equation make sense and work out, such a solid strategy. I know a lot of companies have a difficult time getting to that point. But if you have an opportunity to do that, it's an amazing way to align values. Yeah. It has been very helpful to be able to talk about it that way in our sales cycles. And then we have our agent PM team, which is the team that implements the product, is very effective once we're with a customer at being human partners to them in their AI journey. And then also delivering on that promise of highly, highly accurate agents.

**[16:40]** Yes, we want to get paid. That is true. But ultimately, we want the customer to feel like the agent is delivering for them at a very high rate of value for whatever use case or use cases we started off with. And that's important for the success of that project. I think it's also important because most companies, there are some exceptions, but most companies are kind of putting their toe in the water. So whatever we are starting with initially is a very small subset of the value that we could deliver for that company over time. But if we misstep on that first project, if we

## 17:15 — Land tight-scope, earn the next project

**[17:15]** fail to deliver on that first project, we almost certainly lose the right to compete for the next one. And then actually, conversely, for our customers, once we deliver successfully on that first project, I don't want to say we become the de facto, because that's not true in all cases, but we certainly become a primary if not the primary consideration for, "Hey, I'm XYZ logistics company. I've got this next thing I want to tackle. I'm going to call Pallet because they have delivered successfully on the prior three projects that I've asked them to do." I think any time you can get that classic land and expand motion, you don't have to solve the

**[17:58]** entire problem right out the gate, but you can find something really tangible where you can start to show value, really, really sets up for a successful relationship. And if you can make it, "Hey, I know we're lights out at doing this thing, and it's a small enough or tight enough scope to where we know we're going to do a good job." It's such a good way to kick off that relationship. I have seen sometimes where you go for a full giant enterprise contract right out the gate, and then there's actually so much risk into landing huge right out the gate. Unless you're so confident,

**[18:36]** you have so many rounds of doing it this way, but sometimes it's from an LTV perspective, a better play to start smaller, make sure you have highest confidence possible of winning, and then over the course of a few years, grow into a bigger, longer, stickier contract. I agree with you in spirit. The only change, I would say, is that our timeline is not a few years. We are trying to do that as quickly as possible. I think at the beginning of last year, MIT put out a study that said something to the effect of 95% of the AI deployments failed. In my world, in the freight and logistics space, my guess would be that it's way higher,

## 19:17 — The 95% AI-deployment failure rate (and why freight is worse)

**[19:17]** because it's such a hard industry. Everything is almost nothing as standard. Everything is an exception or specific to that particular entity, our customer's customer. It makes it really hard for a human to do it, certainly for an AI company to get it right. The importance of, I think, doing what you said, which we have done, how do you start with a limited scope? Make sure you really do that well to prove that the solution works, to prove that you like working together as people. I think that's also an important part of the evaluation in this space. I think post that, to put a more serious point on it, the companies have, in freight,

**[20:02]** a lot of opportunity for automation to take, just in simplified terms, the mundane tasks of typing a document, or calling this person for a quick update, or where's my stuff is the most common email across all of freight, basically, no matter what company or type of company you are. It's important to answer and do all of those things, but nobody is going to say a differentiated part of my services is how quickly I respond to Anthony asking me where my stuff is. I just want to get an answer back to Anthony as quickly as possible. Once you deliver on a particular

## 20:38 — How to think about POCs and proof of value

**[20:38]** limited scope, like you mentioned earlier, I think the companies feel, this freight company feels, well, I've got a partner that I can now go do this, this, and this. I think that once you have that, the expansion, at least in our experience, has been quite rapid. The expansion has been quite rapid. What's your take on proof of concepts, proof of values? I know a lot of companies bake this into the tail end of their sales process and just add a layer to it. I've seen somewhere it's worked very, very well, somewhere it feels like they're wasting a lot of time and resources.

**[21:15]** How do you think about that and maybe your framework to understand how deep you should go on that process? Yeah. We are typically doing proof of concepts. It's just very common in our industry, I think, for companies like Pal to offer that. The customers have been, I think, I don't know, condition is the word that jumps in mind. I'm not sure if that's the right word, but they expect that that's an option, some version of try before you buy. We as a company are very open to that idea. It is important to us to know, hey, if we deliver on this proof of concept, how do we move from that to a full production agent? We don't want to invest a

**[21:57]** ton of resources as a company, only to find out that it was Anthony's pet project that's not really going to go anywhere. That's important to us. I don't think that's unreasonable. I don't mention this in sales cycles because it's an unbelief. It's just not a believable stat, but our proof of concept success rate is basically 100%. We have walked away jointly from a couple early on because we decided they were something that was not feasible in what we were trying to do, but for the proof of concepts that we started, the success rate is 100%. Again, that's something I say in sales cycle because it's just an unbelievable number. I think it

## 22:33 — Why post-sales joins pre-sales at Pallet

**[22:33]** makes me less credible, but it gives me confidence that when we sign up to do a proof of concept, that we will deliver on it successfully. I will also say that a change that we made here was when we are in the sales cycle, the host sales team comes pre-sales to do the scoping of the work.

**[23:00]** Many software companies do that, but we're not doing that when I got here. The why for that is there's many things. From my perspective, a mature company has a well-developed implementation team. That implementation is actually a great tool as a part of the sales process. It makes you, Anthony, the customer comfortable that we know what we're doing. It also means that you get to meet the people that you're likely to be working most closely with, or your team might be working most closely with in the implementation process. Then from our side, the implementation team coming pre-sales means we the sales people, I'll put myself in this camp,

**[23:38]** don't do something crazy and over promise in the sales cycle, and probably more importantly, gives that team, the implementation team and our HPM team, the context needed to be successful when we go to implementation. I think a couple of things that stuck out. One, especially if you're in an industry where they're expecting it, you probably need to put some thought behind exactly what this process looks like and scope it well to where I agree. It's weird when you have to lie about your success just because it sounds too good. You have to temper it down a little bit, but putting that

**[24:16]** into your process so you can make sure you're set up to win. Then the other thing I think people get away from sometimes is, "Hey, let's really scope out. This is a real opportunity." Let's not do POCs as a desperate Hail Mary to hope that they like the results of it when they don't actually have intent to move forward. Figuring out getting them sold first and then using the POC to close rather than using the POC to get them sold. I think I've seen a lot of companies just use it as a desperate last attempt to try to win. If you gave a desperate attempt and what you describe, I actually think we're one click to

## 24:57 — The punch list before you offer a POC

**[24:57]** the right of that. If you and I are talking about a project, it's important to me to solve something that's meaningful for you. It's also important to me that, "Hey, all cards on the table, if we solve this, this is what it looks like to go from a POC to a fully production agent." What I don't want is, I think I mentioned a version of this earlier. We do the POC and it was a pet project or we do the POC and you don't have budget to actually run the full production agent or there are internal politics that we hadn't addressed before we did the POC to go to full

**[25:32]** production. A version of that is we have had some evaluations that were run by, let's say, IT or operations, operations being the business side and IT being IT. In any environment where we're just dealing with one function, it is very common for the other function, I think rightfully so, to be brought in last minute and not be very willing participants, willing participants in the project. Those things are important to address before the POC starts. Effectively, the mentality is like, yes, we're doing a POC, but really what we're saying is we all want this

**[26:11]** agent to be in production, everything is squared away. The MSA is squared away, legal and security are squared away. The budget is squared away, IT and operations or IT and over the business customers are at the table and very excited about this. The POC is a chance for our customer to make sure that the solution does what we said it would do and that they like the people that they're going to get to work with on a day-to-day basis. I think everything you described should be the punch list before any company goes out and offers a POC to a potential customer. I think you would

## 26:47 — POCs vs. trials: it depends what you sell

**[26:47]** save so much time, resource, headaches, and your conversion will go up. You're using a very, very powerful process for the ones that you know can close. Totally. However, that's for Palette. DocuSign is a trial and it's a product that's easier for the customer to get into and use on their own. That is a very effective tool. If you have that opportunity, can a customer get into your product, use it on their own and be effective with it without your guidance? Maybe it's not to the full degree. Then you have a trial program of some sort that is a huge, can be a huge lead generation

**[27:29]** tool for your team. DocuSign was good at that. Slack was a version of that, not really a trial, but like individual pockets of companies using that that then led to bigger contracts. The answer, I think, depends on the kind of thing that you are building and selling for your customers. Yeah, I guess it's on level of investment. For DocuSign, offer a trial for Slack to offer a trial. It's all product lead. They don't need to intervene too much, maybe a few support or responding to some issues. If you're doing a process that involves getting engineers involved, implementation teams, you're going to be giving away data or processing power

## 28:07 — Why most GTM plans are built on a lie

**[28:07]** and you're going to be investing that. I guess that would be the spectrum. How much is it going to cost for me to do a POC? How many of these boxes do we want to make sure we have checked before I press go? One of the topics I'm really excited to pick your brain about and hear your experience on, because I feel like it's something I'm really going to empathize with, is you mentioned most GTM motions fail not because we're lacking analytical power or lacking strategy, but because we're not being honest about what's really happening. From your experience, what do

## 28:47 — The win-rate lie: benchmarks vs. reality

**[28:47]** you mean by that and what are some examples that have shown up in your career? What I mean by that is you miss a quarter. I think if you're intellectually honest about that quarter, you can usually tie that back into something in the planning or strategy that you weren't honest about either intentionally or unintentionally that led to that outcome. Now, in the quarter, and I have been guilty of this too, Anthony, so I can't say I have my perfect year, but in the quarter, you blame things like, "Oh, my execution on the deals wasn't correct," or something much

**[29:25]** more near term. Just to give you some examples, I worked with a team where the performance for the year was not great. If you go back to the planning process that we ran for that particular team, the planning model had a win rate for that team that was, as an outsider looking in, you'd probably say was reasonable because if you looked at industry benchmarks was in line with that, probably be a little bit below that. You'd say, "Okay, well, that doesn't seem unreasonable." But if you looked at the actual performance of the team and its win rate for the last couple of years, it was well below that. We made a decision as a leadership team to

**[30:08]** go forward with that more benchmark oriented rate without a plan to materially improve the win rate of that team. Fast forward Q3, Q4, and we're looking at the performance of the team. It is not great. What happened? The win rate had effectively stayed flat, maybe marginally improved, and we just didn't have a plan to change that. Same thing for how to do bigger deals. Everybody wants to do bigger deals. You talked about platform deals earlier. I think that's a great objective to strive for, but you have to have a plan to actually drive that outcome. And without that plan, you're just putting together a plan that's going to fail.

## 30:53 — Wanting bigger deals without a plan to get them

**[30:53]** Our ASP historically has been 200K. I want to do million dollar deals. And so our number, I'm terrible at mental math, so I realized I just picked a number that's going to make it hard to do this sort of stuff. But I want to do 10. I'm a math major, Anthony. That's why that joke is funny. I'm just the worst mental math person for a math major anywhere. It's shameful. That's why we have calculators. No problem. I've become dependent on Excel. If I say that the number's 10 million, and so to do it at a ASP of 200K, I think that's 50 deals. Okay. Well, I don't want to do 50 deals. I want to do 25 deals. So let's just double the ASP to 400K.

**[31:35]** And that's a good idea, I suppose. But without a plan to actually double that ASP, I'm going to install this pricing record. These products are going to and also do that. I'm no longer doing single use case deals. We're only doing platform deals. And here's the proof point that I can actually do those sorts of things. Then you put together a plan that is almost certainly going to fail. And anywhere I've seen a team stumble, certainly at scale, that has been the problem. I say at scale, because in some cases, when you get down to the individual team level,

**[32:08]** you might have personnel issues, or there might be market dynamics that have changed there. All those things can also happen as well. But I think the one that's controllable, if I take market dynamics out, is how do you plan for the year? And what are you realistic about what your teams can do? What do you think is motivating the line during the planning process? What do you mean by the line? You're a conversion rate example. If you can clearly see historically, we've converted at 10%. We know there's a benchmark, we should be at 25%. Is it ignorance? Is it laziness? Or is it blatantly looking at that data and choosing not to believe it?

**[32:52]** I think the answer to that question is different for every scenario. In that particular one, the feeling was, let's take your 10% and 25% as an example. Nobody wants to fund a business. This is the board level narrative, not talk with the board, but how we would think and talk about it. Nobody wants to fund a business that has a 10% win rate. And I think that's not an unreasonable statement to make in a vacuum. But in this particular case, that team was core to the business. So we're not going to walk away from that. In this case, it was an industry. We're not

**[33:28]** going to walk away from that industry. So then they think you have to say, there's a whole conversation of what are we actually measuring? Why is the benchmarks? They're very helpful, but they can also be very dangerous because everybody's data is a bit different. Every company I have been to has a different definition of win rate. And when there's like win rate versus close rate, there's so much devils in the details and that stuff. So if I take the 10% one, why is it so low? Is it low because we have been not rigorous in what we have been accepting into our

**[34:04]** pipeline? Is it where we're losing early stage deals, which indicates one kind of problem? Are we losing late stage deals, which potentially indicates a different problem? That talk track, I think is really important to think through. And then when you're doing that sort of stuff, then says, okay, well, what's realistic if we're at 10%? What do we think is actually realistic to do as a step forward for the next year? Okay, that's 14%, which is only four percentage points, but it's a 40% improvement in the win rate. That's a pretty big jump. Now, if you're my CEO, you and I can have that conversation of, oh, Andrew, like this is the big person job,

**[34:45]** four percentage points is not enough. We have to do something more. And then we have to have that conversation, of course, I suppose. I also think in this particular example, there's like the why does that matter? And if you would have asked our leadership team at that time, it's like, well, at 10% win rate, the CAC and the payback period don't make sense. And then I would say like, okay, great, but that's not the CAC and the payback period. That is one piece that is certainly correlated to that sort of stuff. But if it turns out that our outbound and inbound pipeline

**[35:27]** development costs are very small for that part of the business. And so yes, we're at 10% win rate, but the CAC and payback period are within reason, then it's not a red herring, I guess, but let's make sure we're making the main problem the main problem. Do you think teams run into rushing the planning process, not having the infrastructure in the first place to get the real data? Or are there other motivations going behind? Because in those cases, if you realize conversion rate is X, then you need to have a hypothesis of why, like you mentioned, do teams just not give themselves

## 36:04 — Planning rigor: DocuSign vs. a fast-growing startup

**[36:04]** enough time to really flush those out? Or is there another reason why those things might be missed or ignored? Yeah, I don't know. I think that depends on the company. By the time I left DocuSign and really, frankly, by the time we went public in 2018, in the years leading up to that, our planning process was pretty rigorous. We had a great sales ops or sales strategy function and FP&A functions that were really good. It's like, this is the data. Like we are going to make decisions about the data or you leadership team are going to talk about the data, that this is the data. Nobody's pulling,

**[36:41]** I'm marketing, I'm showing up with my win rate, and you are sales, and you're showing up with your win rate, and we're arguing about the win rate. This is the data. We're arguing about what it means and talk. Maybe I should say talking. Talking about what it means. Often it's arguing, but yeah, talking. It is both. DocuSign's culture was actually pretty good in that era when I was involved in it of a, we are in this together. I think by contrast, Pallet is a much smaller company. The AI space is evolving so quickly. We're growing so rapidly. Last quarter was a

**[37:22]** record quarter. I think we're going to end up doing, I don't know, 6x last quarter. Then by the Q4, my goal is 10x what we do in Q1, but we might be in a point by Q4 where it is, we end up doing 20x Q1, or maybe it's 5x Q1. We'll see how that goes. The pace is a bit more variable and rapid, so we will be a little bit more last minute in our planning than something like a DocuSign was at scale. I think that's to be expected. I think the thing to be wary of is feeling like you are heads down fighting fire, so let's say delivering the gear and not taking the time to pick your head

**[38:10]** up and think about the upcoming gear or the upcoming quarter. That I think is a, being conscious of that is really important, so you don't get to the end of Q4 and you're like, holy moly, I haven't thought about planning at all and I have no idea what I'm going to do for goals for next year and how to put a strategy together to hit those goals and so on and so forth. You mentioned in the DocuSign you had an excellent partnership with SalesOps, RevOps. As a CRO, when are you expecting to make that investment into those types of teams and are there any signals where you're saying, hey, this is when you should start investing into RevOps and this

## 38:53 — When to invest in RevOps

**[38:53]** is how you partner with them for planning as well? My answer would be you should always do those things sooner than you think. I think that's true for any role, Anthony, by the way, is if you wait till you need it, it's too late, especially for a startup. For that role in particular, I think that goes doubly so. If you've never worked at a company or worked with people who are very good at that job and I've had the benefit of seeing that in action, you don't even understand how valuable those kinds of people can be. With that said, we are in the process of hiring for that role now. Up until this point, you have me who has done that job in the past,

**[39:34]** who's been moonlining as that person in the nights and weekends thing, and then my marketing partner between the two of us, we have been covering that. On the go-to-market side, probably 10 people, 15 people, just for a scale size, we're growing quickly. We already have the problems where that kind of person could be very, very helpful to our organization. Yeah, as sitting in the seat where we're typically going in, doing cleanups, and usually we don't get called unless there's a real pain and problem. Yes, I think the sooner you can lay down that infrastructure and get that type of

## 40:11 — The plan as a diagnostic (NUCO + channel model)

**[40:11]** data, it's going to grease everything else you're doing. We'll also help in that planning process, which is one of the most important ones if you're going to fundraise again, if there's an exit on the horizon, having that data airtight and being able to articulate your story, you have no idea how much that could add to your valuation. I agree with you, and that's probably the most important thing in the context of problems, but when you miss a quarter and you're trying to diagnose what went wrong, I would argue that plan is also important. So DocuSign, you could say,

**[40:51]** okay, for this team or for this division, we had a pretty good understanding of what should come out of the customer base, and then I'm oversimplifying a bit, but NUCO becomes the plug to what the number for that team is supposed to be for the quarter or for the, let's just say, per quarter, and then that got blown back into, okay, if NUCO is going to be this, we thought about it of who do we want sourcing that? Every channel then had specific win rates and ASPs, and then it was a pretty robust model so that if you missed a quarter, you could go back and look at that model

**[41:25]** and say, well, what was different than what we had expected? And then based on that, what is the problem we think we have to solve or thing we have to change in our go-to-market motion, our sales process, whatever, to ensure that we hit the next quarter. And now, if you're really good at that, of course, you're looking at the leading indicators on the NUCO side, what is the lead flow, or we did MQLs still at the time, MQLs and Stage 0 DocuSign for Salesforce, Stage 1, we're on help spot here, so Stage 1, the pre-qualified operation, and similar thing on the customer

**[42:04]** side for DocuSign, you had the ability to look at usage by account and a couple of other factors to make a pretty good determination of by an account level, really, what the upsell was likely to be for the next, let's say, 12 months. Beyond that, it was a little bit hard to forecast. All became leading indicators for things like, oh my gosh, making up a scenario here, the usage in this particular territory is low, and therefore, the upsell we had planned is low. That's an important thing to talk about and figure out why that is and go solve that. But if we want to make the

**[42:44]** quarter or next quarter, you're doing this a quarter out or two quarters out, we need to turn up the NUCO motion, otherwise, we're likely dead in the water already. I think making sure you have that instrumentation to be able to have the data to make those decisions and then dive into the whys and then fix the problems, I totally agree. That's where the value is and just a few percentage points increase in conversion rate or decrease in sales cycle or any other part of the go-to-market life cycle, I think it has huge returns. As we start to wrap up, I think it sounds like

## 43:25 — Top-down goal, bottoms-up resourcing

**[43:25]** the line, it just tends to be a lot of it happens in that planning process. Is there any last words of advice for a team, especially maybe that early stage, like you're in that Series A, you're in that Series B growth stage of a company, any words of advice for them walking into a planning season and how they can make the most of it? Great question. My immediate thought was don't assume it's going to be done in one session and I think there's a iterative approach to that. This is my personal belief, I am sure you could find somebody who's going to disagree with this

**[44:04]** based on their experience. I think the best planning motions that I have seen are tops down and if I look at the revenue version of that, it looks something like this. Andrew, maybe from the CFO is coming from a CFO or a CEO. Andrew, our goal for next year is X, 50 million and the goal is not up for debate, that is the goal. What is up for debate is the resources that you need to go deliver that 50 million. I think that's a framing and there are different versions of that, I suppose, depending on the function that you're talking about, is I think the best way to drive a planning process. I think you have to be conscious,

**[44:51]** depending on the state that your company is in, how does that get actioned in practice? In our example of the 50 million, I would be, let's say, as the sales leader dependent upon marketing to deliver on whatever the new co-portion of that number is going to be. That requires cross-functional planning and some companies have that muscle really well built. DocuSign has that for one reason, like it's a well-built planning machine. We have that here, but it's more a function of the leadership team is very tight here and constant communication across all the functions. If you

## 45:30 — Why DocuSign starts planning in Q3

**[45:30]** don't have that, you need to be conscious that otherwise Andrew goes away in a vacuum and says, "I need one bajillion leads for marketing and a thousand people to deliver on my 50 million number." Because it's iterative and especially if you're doing it for the first time, you're not going to get it right. It's never too early to start. DocuSign started the planning process. When I was part of it, the beginning of Q3. It was largely wrapped in a good year by midway through Q4. That's all of it, all the planning process, all the head counts, all the territories, everything.

## 46:10 — The 'pissed-off RevOps leader' growth-model story

**[46:10]** They're in a February quarter, our year end start. Feb 14, AEs were getting their territories complements, so on and so forth. Never too early to start. I think that's really good advice. I also love the top-down recommendation because it forces you to get creative in attaining an ambitious goal. When I was at e-mailage, it was my first time running RevOps. We went into planning. We had three bottoms up planning meetings. What happened was we were only looking at the realm of possibility within what we've experienced in that year. Our CEO is just not accepting it at all. He's like, "It's not ambitious enough. You're not doing enough."

**[46:55]** My first time putting together, we call it a growth model here at LeanScale, was really just because I was pissed off at my CEO. I said, "Hey, you want to know what it's going to take to get to that outrageous, impossible goal? You have no idea what it's going to take. I'm going to tell you exactly how much you're going to have to spend to get there and prove to you that it's not realistic." I put the whole entire thing together and showed it to him. He looked like a kid on Christmas morning. I was like, "This is exactly what I was looking for." I think that was when it clicked for me too. Oh, that top-down pressure is what gets the

## 47:30 — The 10X-the-org exercise every leader should do

**[47:30]** creativity going of how do we really integrate this to do something ambitious. That's an interesting way to think about it. The lesson I would take away from that is I should be doing that myself, some version of the exercise of what does it take to 10x my org before my CEO comes and asks me about it. I will make a note of that to actually start that this weekend. We're in Q1 still, but an important part of that, I'll do that this weekend so I can have that conversation with him next week. I think that a great leader won't wait for their manager, in my case the CEO, to come and ask them of that. They'll go out and do that

**[48:14]** themselves so that they are pushing, pushing, pushing, pushing. If the CEO has to always be the guy that's pushing or gal that's pushing, I think that becomes a problem or a limiter. He or she can only spread so far to what the organization could accomplish. Well, I'm very sorry to give you a weekend project, but what I will send you,

## 48:36 — Closing thoughts and the growth-model handoff

**[48:36]** we have a growth model app that we built here at LeanScale. I'll share that so hopefully you don't have to take the entire Saturday to put it together. Maybe it'll save you a few hours. Yeah, well, Andrew, this has been really, really insightful. I really appreciate you, one, opening up with the vulnerability of saying, "Hey, I realized walking into a lot of the roles I've been in, I haven't technically been qualified for," but sharing your process of how you go through that to get qualified quickly, get the information you need. I think a lot of people who are high performers and ambitious with their careers are in similar situations. I really

**[49:14]** appreciate sharing that. Then I think illuminating, oftentimes the biggest issue with your go-to-market is you're not looking at reality and giving practical ways to get that reality out in the planning process, in your data, laying down RevOps infrastructure as early as possible so you can start to have those conversations. I know I've really appreciated you sharing. I know anyone in our audience is going to learn something from this one too. Yeah, well, it's great to chat. Well, appreciate it, Andrew. Have a great weekend working on your 10X plan and can't wait to see what you all do at Palette. Thank you, Anthony. Appreciate it.