--- 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 _Andrew Geisse (CRO, Pallet) on honest GTM planning, POCs that actually convert, and selling AI into a $12T industry_ **Episode 83 · The LeanScale Podcast** Andrew Geisse, Chief Revenue Officer, Pallet · Hosted by Anthony Enrico Published May 28, 2026 · Updated July 22, 2026 · 00:49:50 Canonical: https://leanscale-knowledge-hub.netlify.app/podcast/andrew-geisse-failed-quarters-gtm-planning/ **Topics:** GTM Strategy · Forecasting · Consumption Revenue · Pricing & Packaging · AI in GTM · Enterprise & Public-Sector Sales ## Executive summary Andrew Geisse has built a career walking into roles he wasn't technically qualified for — nearly a decade at Deloitte, almost seven years building enterprise sales at DocuSign (through its 2018 IPO), leading North America sales at Reputation, and now CRO at Pallet, which builds AI workforce automation for the roughly $12 trillion logistics industry (about 700% revenue growth in under two years on $50M raised from General Catalyst, Bessemer Venture Partners, and Bain Capital Ventures). His edge is a repeatable way to drop into chaos and find the truth. The throughline of the hour with LeanScale co-founder Anthony Enrico: most go-to-market motions fail not because teams lack data or strategy, but because they aren't honest about what's actually happening. The first third is a field guide to selling AI. Andrew's first-90-days move is to absorb everything — talk to the people on the ground and read the data, then marry the two into a working theory of the truth. He is candid that usage-based pricing is still unsolved: comp plans, territories, and quotas all bend under it, and even Twilio carries the battle scars. Pallet's answer is 'successful-transaction' pricing — charging only when the agent completes the whole job correctly — so revenue tracks roughly one-to-one with delivered value and the pricing model itself forces accuracy. Anthony matches him war story for war story from his own RevOps days at Emailage, a fully usage-based business where he closed JP Morgan Chase on a ~$1M forecast with a $0 commitment and had to invent an 'estimated ACV' line to report defensible ARR to the board. The middle is a clinic on POCs and honest planning. In AI sales, proof-of-concepts are table stakes, but Andrew flips the usual order: get the deal sold first — MSA, security, budget, and both IT and operations aligned and excited — and use the POC only to confirm the solution works and the teams click. Do that and, like Pallet, your POCs convert at basically 100%. He also brings post-sales into pre-sales to scope the work, which kills over-promising. On planning, the 'lie' is concrete: a team carried a benchmark win rate it had never actually hit, with no plan to improve it, and predictably missed. Bigger deals, higher ASPs, and platform motions fail the same way — as aspirations with no plan to drive the outcome. The close is about how good planning actually runs. Andrew argues for top-down goals and bottoms-up resourcing — the number is non-negotiable; what's up for debate is what it takes to hit it — which forces cross-functional creativity instead of vacuum wish-lists. He preaches investing in RevOps 'sooner than you think,' and building the plan as a diagnostic: channel-level win rates and ASPs, with new-logo 'NUCO' as the plug, so a missed quarter can be traced to a broken assumption a quarter or two out. Anthony closes with the origin of LeanScale's growth model — built out of spite at a CEO who kept rejecting his bottoms-up plans — and Andrew commits to running the '10x my org' exercise himself, this weekend, before his CEO asks. Who should listen: founders and CROs selling AI into hard industries, RevOps and sales-ops leaders who own planning, and finance leaders wrestling with usage-based ARR and forecasting. The biggest takeaway is a bias toward honesty as an operating discipline — scope pilots you can actually win, price to outcomes, report ARR you can defend, and build plans whose assumptions you genuinely believe. ## Key takeaways 1. **Walk into chaos by finding the truth first** — Andrew's repeatable move for a new role is to spend the first 90 days absorbing everything — talking to the people on the ground doing the selling and implementing, reading the available data, and marrying those two perspectives into what he thinks is the truth about what's actually happening. Only then does he set priorities and fix what's broken. _Why it matters:_ Don't lead with a plan; lead with a diagnosis. The fastest way to get productive in an unfamiliar environment is to triangulate people plus data into a shared, honest picture before you start changing things. _For:_ Founders, Revenue Executives, RevOps Leaders 2. **Most GTM plans fail on honesty, not analytics** — Andrew's core belief is that missed quarters rarely come from a lack of data or strategy — they come from a planning assumption the team wasn't honest about, intentionally or not. In the quarter you blame near-term execution; if you're intellectually honest, you can usually trace it back to the plan. _Why it matters:_ When you miss, resist the near-term blame reflex and audit the plan's assumptions. The dishonesty is upstream, in what you agreed to believe during planning. _For:_ Revenue Executives, RevOps Leaders, Founders 3. **The win-rate lie: don't plan on a benchmark you've never hit** — In Andrew's example, a team's plan used an industry-benchmark win rate that looked reasonable to an outsider — but the team's actual historical win rate was well below it, and there was no plan to close the gap. By Q3/Q4 the win rate had stayed flat and the year was ugly, entirely predictably. _Why it matters:_ Anchoring a plan to a benchmark you haven't earned, with no improvement plan attached, is a plan built to fail. Set a realistic step (10% to 14% is only 4 points but a 40% improvement) and fund the change. _For:_ RevOps Leaders, Revenue Executives, Sales Leaders 4. **Bigger deals and higher ASPs need a plan, not an aspiration** — Everyone wants platform deals and a doubled ASP — cutting a $10M target from 50 deals to 25 by taking ASP from $200K to $400K. But without a concrete plan to actually drive that outcome (pricing, packaging, killing single-use-case deals, proof points), you've just written a plan that's going to fail. _Why it matters:_ Every ambitious number needs a mechanism beneath it. If you can't name what changes to make bigger deals happen, don't put them in the plan. _For:_ Sales Leaders, Revenue Executives 5. **Price to the outcome, not the tokens** — Pallet doesn't do pure usage-based pricing; it charges on 'successful transactions.' If Pallet ingests a document and only gets paid when it reads and infers every field 100% correctly, the pricing model itself becomes a forcing function to be as accurate as possible — and value tracks roughly one-to-one with what the customer gets. _Why it matters:_ Outcome-based pricing aligns your incentives with the customer's and pushes your product to improve. Where you can tie price to a verifiable outcome, it's one of the strongest strategies available. _For:_ Founders, Revenue Executives 6. **Usage-based pricing breaks comp, quotas, and board reporting** — Anthony's Emailage experience: a fully usage-based business made ARR hard to articulate to investors, comp plans hard to design, and quotas hard to assign. He closed JP Morgan Chase on a ~$1M forecast with a $0 commitment — how do you even resource that? His fix was an 'estimated ACV' line stacked on top of contracted ARR. _Why it matters:_ If your contracts are usage-based, invest early in bulletproof ARR definitions and a conservative estimated-ACV convention — contracted revenue you can take to the bank, plus a caveated fraction of the forecast — so the board can trust the number. _For:_ RevOps Leaders, Revenue Executives, Founders 7. **In AI, cost of goods is now part of the equation** — The old usage-based era (Anthony's Emailage) had a relatively fixed, low cost structure, so you didn't worry much about capacity. AI is different: raw LLM cost, plus traditional processing and R&D, is real. Andrew argues the value delivered still clears those costs today — but how that holds under a pure usage-based contract is TBD. _Why it matters:_ Model your AI COGS explicitly and make sure ROI clears raw LLM cost plus R&D. Cost, not just willingness to pay, now constrains your pricing and forecasting. _For:_ Founders, Revenue Executives 8. **Land tight-scope and earn the next project — 95% of AI deployments fail** — Andrew cites the MIT stat that ~95% of AI deployments fail and bets it's higher in freight, where 'everything is an exception.' The counter is to start with a small, tightly scoped use case you know you can nail; misstep on the first project and you almost certainly lose the right to compete for the next. _Why it matters:_ Land-and-expand isn't optional in AI — it's risk management. Prove value on a narrow, high-confidence scope, and expansion tends to be rapid once the customer trusts you. _For:_ Sales Leaders, Founders, Customer Success 9. **Sell first, then use the POC to close** — Andrew is 'one click to the right' of the usual advice: don't run POCs as a desperate Hail Mary hoping the customer likes the results. Get the deal sold first, then use the POC to confirm the solution works and the teams click. Using a POC to get someone sold burns time, resources, and conversion. _Why it matters:_ Reframe the POC as a closing tool for deals you've already qualified as real, not a top-of-funnel gamble. It dramatically raises conversion and protects scarce delivery resources. _For:_ Sales Leaders, Revenue Executives 10. **Run the punch list before you offer a POC** — Before Pallet starts a POC, the real deal is effectively done: the MSA is squared away, legal and security are squared away, budget is squared away, and both IT and operations are at the table and excited. The POC is only a chance for the customer to confirm the solution does what was promised and to like the people they'll work with. _Why it matters:_ Make the punch list a gate: MSA, legal/security, budget, and both functions bought in. Skipping it manufactures stalled pilots that were pet projects or landmines of internal politics. _For:_ Sales Leaders, RevOps Leaders 11. **Bring post-sales into pre-sales to kill over-promising** — Pallet has its implementation / agent-PM team join the sales cycle to scope the work. It makes the buyer comfortable, lets them meet who they'll actually work with, stops sellers from over-promising, and — most importantly — gives the delivery team the context it needs to succeed at implementation. _Why it matters:_ A mature implementation team is a sales asset, not just a delivery function. Putting it in the room pre-sale is the cheapest insurance against the over-scoped deals that churn. _For:_ Sales Leaders, Customer Success 12. **Invest in RevOps sooner than you think — and build the plan as a diagnostic** — Andrew's rule: hire the sales-ops/RevOps capability before you obviously need it; wait until you need it and it's too late, doubly so for startups (Pallet is hiring for it around 10-15 GTM people). At DocuSign the payoff was a plan robust enough to diagnose a miss — every channel had its own win rate and ASP, with new-logo 'NUCO' as the plug and leading indicators a quarter or two out. _Why it matters:_ Lay down RevOps infrastructure early; it greases everything and the airtight data compounds your valuation in a raise or exit. Then instrument the plan so a missed quarter points you straight at the broken assumption. _For:_ RevOps Leaders, Founders, Revenue Executives 13. **Top-down goal, bottoms-up resourcing — and do the 10X exercise before your CEO asks** — The best planning Andrew has seen is top-down: leadership hands down a non-negotiable number (e.g., $50M) and what's up for debate is only the resources to deliver it. That forces creativity. Anthony's spite-built growth model at Emailage proved the point; Andrew's takeaway was to run the 'what would it take to 10x my org' exercise himself before his CEO comes asking. _Why it matters:_ Fixing the goal and negotiating the resources beats bottoms-up wish-lists — but it demands cross-functional planning. Great leaders push themselves, so the CEO isn't the only one pushing. _For:_ Revenue Executives, Founders, Sales Leaders ## Frameworks ### The First 90 Days: Absorb, Then Find the Truth (02:34) **Definition:** Spend the opening months of a new role absorbing information from two sources — the people on the ground doing the selling and implementing, and the available data — then marry those perspectives into a working theory of what's actually happening before setting priorities. Andrew developed this as a Deloitte consultant, where every engagement dropped him into a new industry, function, and problem. The output is a diagnosis of the org's and the people's fixes and full-potential moves — a truth you can act on rather than a borrowed playbook. ### The Honest Plan: Missed Quarters Trace Back to a Planning Lie (28:47) **Definition:** When you miss a quarter, an intellectually honest post-mortem usually ties the miss to a planning or strategy assumption you weren't honest about — not to near-term deal execution. The canonical example is a team that planned on a benchmark win rate it had never hit, with no plan to improve it, and then missed. In the quarter you blame execution; the real cause is upstream, in what you agreed to believe during planning. ### Successful-Transaction (Outcome-Aligned) Pricing (14:36) **Definition:** Charge only when the AI agent completes the entire job correctly (e.g., reads and infers every field on a document 100% right), so price tracks roughly one-to-one with the value delivered. Rather than pure usage/token pricing, Pallet ties revenue to verified outcomes. The model becomes a forcing function for accuracy — Pallet only gets paid when it delivers — and aligns Pallet's incentives with the customer's. ### Estimated ACV: Stacking Contracted + Forecasted ARR (11:15) **Definition:** Report usage-based revenue to the board by stacking two clearly labeled layers: contracted ARR ('take it to the bank') plus a conservative fraction of the forecasted amount booked as 'estimated ACV' (EACV). Anthony's fix at Emailage for a fully usage-based business where a marquee deal (JP Morgan Chase) carried a big forecast and a $0 commitment. It requires bulletproof ARR definitions and heavy education, and gets trickier during fundraising or an exit. ### Land Tight-Scope, Earn the Next Project (17:15) **Definition:** Start with a small, high-confidence use case you know you can nail, prove value fast, and use that win to earn the right to the next project — becoming the customer's primary consideration for what's next. Because ~95% of AI deployments fail (higher in freight), landing huge out of the gate invites too much risk; a misstep on the first project loses you the next one. Deliver on a narrow scope and expansion tends to be rapid. ### Use the POC to Close, Not to Sell (24:16) **Definition:** Qualify and sell the deal first, then run the POC only to confirm the solution works and the teams click — never as a desperate Hail Mary to generate intent that isn't there. Andrew is 'one click to the right' of standard advice: using a POC to get someone sold burns time, resources, and conversion. Reserving it for deals already qualified as real is why Pallet's POCs convert at basically 100%. ### The POC Punch List (24:57) **Definition:** Before offering a POC, square away the MSA, legal and security, and budget, and get both IT and operations (the business side) at the table and excited. The POC then only validates the solution and the working relationship. Skipping the list produces stalled pilots — pet projects, missing budget, or a function brought in last-minute as an unwilling participant. Making it a gate saves time and headaches and raises conversion. ### Post-Sales Joins Pre-Sales for Scoping (22:33) **Definition:** Have the implementation / agent-PM team scope the work during the sales cycle, so the buyer meets who they'll work with, gains confidence, and sellers can't over-promise. A mature implementation team is a sales asset. Its presence pre-sale builds trust, prevents over-scoping, and gives delivery the context it needs to hit the accuracy bar the product promised. ### The Plan as a Diagnostic (NUCO + Channel Model) (40:51) **Definition:** Build the revenue plan so every channel has its own win rate and ASP and new-logo ('NUCO') plugs the gap to the number — robust enough that a missed quarter can be traced to a specific assumption that broke, with leading indicators warning you a quarter or two out. At DocuSign, upsell was forecast from account-level usage while NUCO was watched via lead flow and MQL/Stage-0/Stage-1 progression. If usage in a territory is low, you know upsell is at risk; if you're behind, you turn up the NUCO motion before you're dead in the water. ### Top-Down Goal, Bottoms-Up Resourcing (44:04) **Definition:** Leadership sets a non-negotiable number; what's up for debate is only the resources required to deliver it. The exercise is iterative and cross-functional, and pairs with a proactive 'what would it take to 10x my org' model run before the CEO asks. Fixing the goal forces creativity, where bottoms-up planning only reaches the realm of the already-experienced. Anthony built LeanScale's first growth model this way at Emailage — out of spite — and it made his CEO 'look like a kid on Christmas morning.' ## Quotes _Speakers inferred from an undiarized transcript — verify before attributing._ > "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." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (01:24) > "If you're feeling imposter syndrome, it probably means you're doing the right thing and pushing yourself in a healthy way." > > — Anthony Enrico, The LeanScale Podcast Ep. 83 (01:59) > "A lot of that time is absorbing as much information as possible, and marrying those two perspectives together to formulate what you think is the truth about what is actually happening." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (02:34) > "Usage-based pricing as a concept is difficult. I've been working on it for probably about a decade now and still don't feel super confident about it." > > — Anthony Enrico, The LeanScale Podcast Ep. 83 (10:06) > "We had to be unbelievably clear about our definitions of ARR. This is contracted — you could take it to the bank. Then we'd take a fraction of the forecast and stack it into our estimated ACV bucket, but take it with a grain of salt." > > — Anthony Enrico, The LeanScale Podcast Ep. 83 (11:15) > "Only when Pallet gets that 100% right do we charge our customer — and that drives us to be as accurate as possible." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (14:36) > "If we misstep on that first project, we almost certainly lose the right to compete for the next one." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (17:15) > "MIT put out a study that said something to the effect of 95% of AI deployments failed. In my world, in freight and logistics, my guess is that it's way higher." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (19:17) > "Where's my stuff is the most common email across all of freight, no matter what type of company you are." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (20:02) > "I don't mention this in sales cycles because it's just not a believable stat, but our proof-of-concept success rate is basically 100%." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (21:57) > "The implementation team coming pre-sales means we, the salespeople, don't do something crazy and over-promise in the sales cycle." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (23:00) > "Let's not do POCs as a desperate Hail Mary. Get them sold first, then use the POC to close — rather than using the POC to get them sold." > > — Anthony Enrico, The LeanScale Podcast Ep. 83 (24:16) > "If you're intellectually honest about that quarter, you can usually tie it back to something in the planning or strategy that you weren't honest about." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (28:47) > "Everybody wants to do bigger deals. But you have to have a plan to actually drive that outcome. Without that plan, you're just putting together a plan that's going to fail." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (30:08) > "You should always do those things sooner than you think. If you wait till you need it, it's too late — especially for a startup." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (38:53) > "Our goal for next year is 50 million, and the goal is not up for debate. What's up for debate is the resources you need to go deliver that 50 million." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (44:04) > "My first time putting together what we now call a growth model at LeanScale was really just because I was pissed off at my CEO." > > — Anthony Enrico, The LeanScale Podcast Ep. 83 (46:55) > "A great leader won't wait for their manager to come and ask them. They'll go out and do that themselves." > > — Andrew Geisse, The LeanScale Podcast Ep. 83 (47:30) ## Practical advice by role ### Founders - Selling AI into a hard vertical? Start with the tightest scope you can win, prove the agent works, and expand from there — 95% of AI deployments fail, and one blown first project loses you the right to compete for the next. - Price to the outcome. Pallet charges only when the agent completes the whole job correctly, so revenue tracks the value delivered and the pricing model itself forces accuracy. - Invest in RevOps/sales-ops sooner than you think — if you wait till you need it, it's too late. Airtight planning data also compounds your valuation in a raise or exit. ### Revenue Executives - Be honest in planning: if you're missing quarters, trace it to the assumption you weren't honest about — a benchmark win rate you've never hit, or an ASP you have no plan to double. - Run top-down: set a non-negotiable number and debate only the resources to hit it. It forces cross-functional creativity instead of vacuum wish-lists. - Do the '10x my org' exercise yourself before your CEO asks; great leaders push themselves so the CEO isn't the only one pushing. ### RevOps Leaders - Build the plan as a diagnostic: give every channel its own win rate and ASP, use new-logo 'NUCO' as the plug, and watch leading indicators so a miss is visible a quarter or two out. - For usage-based revenue, define ARR you can defend and report an 'estimated ACV' line — contracted revenue you can take to the bank, stacked with a conservative fraction of the forecast. - Interrogate the metric before you plan on it: a 10% win rate could be loose pipeline standards, early-stage losses, or late-stage losses — and it might still be fine if CAC and payback hold. ### Sales Leaders - Make POCs a closing tool, not a Hail Mary: get the deal sold — MSA, security, budget, IT and operations all aligned — then use the POC only to confirm the solution works and the teams click. - Bring post-sales/implementation into pre-sales scoping; it builds buyer confidence and stops sellers from over-promising. - Match your motion to what you sell: low-touch products (DocuSign, Slack) run product-led trials, while high-investment AI work needs a scoped POC with a checklist. ## AI takeaways **Thesis:** In AI go-to-market, the hard part isn't the model — it's honest deployment. AI sales fail on over-promising and over-scoping, not on capability. The winners scope pilots they can actually deliver, price to verifiable outcomes, and account for the new reality that AI cost of goods is part of the equation. - **95% of AI deployments fail** — Andrew cites the MIT stat and bets it's higher in freight, where 'everything is an exception.' The fix is tight-scope pilots that prove the agent works before you expand — a misstep on the first project loses the next one. - **Price to the outcome, not the tokens** — Pallet charges only when the agent completes the whole job correctly, so revenue tracks ~1:1 with value delivered and the pricing model itself forces accuracy. - **POCs are table stakes — but sell first** — In AI sales the POC should confirm a deal you've already sold (MSA, security, budget, IT and ops aligned), not rescue one. Pallet's POCs convert at ~100% because the punch list is done first. - **AI COGS is now part of the equation** — Unlike the old usage-based era of fixed, low cost, LLM plus processing plus R&D cost is real; ROI must clear raw LLM cost, which reshapes pricing and forecasting. - **Bring post-sales into pre-sales** — Having the implementation/agent-PM team scope during the sale kills over-promising and gives delivery the context to hit the accuracy bar the model promised. **Agent & automation ideas** - A POC-readiness agent that runs the punch list (MSA, security, budget, IT + operations sign-off) and blocks a pilot until every box is checked. - An estimated-ACV forecaster that stacks contracted ARR with a conservative fraction of forecasted usage per account and flags board-reportable vs. take-with-a-grain-of-salt revenue. - A plan-diagnostic agent that back-tests a missed quarter against the channel-level win-rate/ASP model to isolate which assumption broke. - An accuracy monitor for outcome-based ('successful transaction') pricing that only recognizes revenue when an agent completes every field of a job correctly. ## Operations takeaways ### Revenue operations - **Invest early.** Hire RevOps/sales-ops before you obviously need it — 'if you wait till you need it, it's too late,' doubly so for a startup (Pallet is hiring around 10-15 GTM people). - **Plan as a diagnostic.** Give each channel its own win rate and ASP, use new-logo NUCO as the plug, and instrument leading indicators so a missed quarter points at the broken assumption. - **Estimated ACV for usage-based ARR.** Report contracted revenue you can take to the bank, stacked with a conservative fraction of the forecast as EACV, on bulletproof ARR definitions. - **Interrogate the metric.** Before planning on a win rate, ask why it's what it is — loose pipeline standards, early-stage losses, or late-stage losses each imply a different fix, and it may be fine if CAC and payback hold. - **One source of truth.** The DocuSign standard: 'this is the data,' so the room argues about what it means, not whose number is right. ### Pipeline & marketing ops - **Sell first, POC to close.** Reserve POCs for deals already qualified as real; using them to generate intent burns time, resources, and conversion. - **Punch list before a POC.** MSA, legal/security, budget, and both IT and operations aligned and excited — the POC only confirms the solution and the working relationship. - **Leading indicators warn early.** Watch lead flow, MQLs, and Stage-0/Stage-1 progression; if you're behind, turn up the new-logo motion a quarter or two out or you're dead in the water. - **Land tight-scope.** Prove value on a narrow, high-confidence use case; expansion tends to be rapid once the customer trusts you. ### Customer operations - **Implementation is a sales asset.** Putting the agent-PM/implementation team in pre-sales scoping builds buyer confidence and stops over-promising that later churns. - **Deliver the first project flawlessly.** In AI, one blown first project loses the right to compete for the next; nail a limited scope and you become the primary consideration for what's next. - **Accuracy is the product.** Under successful-transaction pricing, the team only gets paid when the agent delivers — so speed-to-value and high accuracy are the job. ## Metrics mentioned | Value | Metric | Context | | --- | --- | --- | | $12 trillion | Logistics market size | The size of the logistics/freight industry Pallet is building AI workforce automation for. | | 700% in under 2 years | Pallet revenue growth | Pallet's growth on $50M raised from General Catalyst, Bessemer Venture Partners, and Bain Capital Ventures. | | 95% | AI deployment failure rate | The MIT stat Andrew cites; he expects it's even higher in freight, where 'everything is an exception.' | | ~100% | Pallet POC success rate | Andrew won't quote it in sales cycles because it sounds unbelievable — the result of doing the punch list before offering a POC. | | ~$1M forecast, $0 commitment | JP Morgan Chase deal | Anthony's Emailage example of the usage-based resourcing problem — how do you staff a deal with a big forecast and no contractual floor? | | ~50% of forecast | Estimated ACV stack | At Emailage, Anthony stacked contracted ARR with roughly half of the forecasted amount as 'estimated ACV' to report defensible-but-caveated revenue to the board. | | $200K to $400K | ASP jump for platform deals | Andrew's illustration: doubling ASP to cut a $10M target from 50 deals to 25 is only a good idea with a real plan to actually double it. | | 10% actual vs 25% benchmark | Win-rate reality gap | A team planned on a benchmark win rate it had never hit; a realistic step to 14% is only 4 points but a 40% improvement. | | ~10-15 GTM people | RevOps trigger (team size) | The scale at which Andrew says a dedicated RevOps/sales-ops hire becomes very valuable at Pallet. | | Q3 start to mid-Q4 done | DocuSign planning window | DocuSign began planning at the start of Q3 and had territories and comp set by Feb 14 (a February fiscal-year start). | ## Entities mentioned - **Pallet** (company) — Andrew's company; he is CRO. Builds AI workforce automation/agents for the ~$12T logistics industry, priced on 'successful transactions' (paid only when the agent completes the whole job correctly). ~700% revenue growth in under two years on $50M from General Catalyst, Bessemer, and Bain Capital Ventures. · https://leanscale-knowledge-hub.netlify.app/company/pallet/ - **DocuSign** (company) — Where Andrew spent nearly seven years building enterprise sales through the 2018 IPO; his reference case for rigorous top-down planning, product-led free trials, and a channel-level diagnostic revenue model (NUCO, per-channel win rates and ASPs). · https://leanscale-knowledge-hub.netlify.app/company/docusign/ - **Deloitte** (company) — Andrew's first decade out of undergrad as a consultant, where he built the muscle of walking into a new industry, function, or problem every engagement. · https://leanscale-knowledge-hub.netlify.app/company/deloitte/ - **Reputation** (company) — Where Andrew led North America sales before Pallet — a more traditional software company where established playbooks existed to borrow from, unlike the first-time-everything of AI. · https://leanscale-knowledge-hub.netlify.app/company/reputation/ - **Emailage** (company) — Anthony's first RevOps role — a fully usage-based company where he closed JP Morgan Chase on a big forecast with zero commitment, invented an 'estimated ACV' line to report ARR to the board, and built the first version of what LeanScale now calls a growth model. · https://leanscale-knowledge-hub.netlify.app/company/emailage/ - **Twilio** (company) — Cited as the usage-based-pricing veteran with 'battle scars'; Andrew called people he knew there when Pallet weighed usage-based models and comp. · https://leanscale-knowledge-hub.netlify.app/company/twilio/ - **JPMorgan Chase** (company) — The marquee usage-based deal Anthony closed at Emailage — a ~$1M forecast with a $0 contractual commitment that crystallized the resourcing and ARR-reporting problem. · https://leanscale-knowledge-hub.netlify.app/company/jpmorgan-chase/ - **MIT** (company) — Source of the stat Andrew cites — ~95% of AI deployments fail — which he believes understates the difficulty of deploying AI in freight. · https://leanscale-knowledge-hub.netlify.app/company/mit/ - **Google** (company) — Named among the AI players active in freight/logistics that Pallet's customers also evaluate — 'everybody is doing something AI-related,' each with a different flavor. · https://leanscale-knowledge-hub.netlify.app/company/google/ - **Anthropic** (company) — Named (as 'Anthropic') among the AI companies active in the freight space Pallet competes and compares against. · https://leanscale-knowledge-hub.netlify.app/company/anthropic/ - **Box** (company) — Named among the companies doing AI in the freight space Pallet is compared against. · https://leanscale-knowledge-hub.netlify.app/company/box/ - **Slack** (company) — Cited with DocuSign as a product-led motion where individual pockets of usage led to bigger contracts — a trial model, not a high-investment POC model. · https://leanscale-knowledge-hub.netlify.app/company/slack/ - **Andrew Geisse** (person, guest) — CRO at Pallet (AI for logistics); enterprise-sales operator out of DocuSign, Reputation, and Deloitte who preaches honest GTM planning. · https://leanscale-knowledge-hub.netlify.app/guest/andrew-geisse/ - **Anthony Enrico** (person, host) — Co-founder of LeanScale and host of The LeanScale Podcast. · https://leanscale-knowledge-hub.netlify.app/guest/anthony-enrico/ - **Salesforce** (tool, CRM) — DocuSign's CRM of record ('Stage 0 in DocuSign for Salesforce') in Andrew's channel-level diagnostic model. - **HubSpot** (tool, CRM) — Pallet's CRM ('we're on HubSpot here') where the pre-qualified 'Stage 1' lives in Andrew's leading-indicator model. ## FAQ **Q: Why do most GTM plans fail, according to Andrew Geisse?** A: Not for lack of data or strategy, but because teams aren't honest about what's actually happening. When you miss a quarter, an intellectually honest post-mortem usually ties the miss to a planning assumption you weren't honest about — for example, planning on an industry-benchmark win rate the team had never actually hit, with no plan to improve it. **Q: What is 'successful-transaction' pricing and how is it different from usage-based pricing?** A: It's an outcome-based model where the vendor charges only when its AI agent completes the entire job correctly — not per token or per API call. At Pallet, if an agent reads a document and must get every field right, Pallet only bills when it hits 100%. This ties price to delivered value and turns the pricing model into a forcing function for accuracy. **Q: How do you report usage-based revenue to your board with the 'estimated ACV' method?** A: Stack two clearly labeled layers: contracted ARR that you can take to the bank, plus a conservative fraction of forecasted revenue booked as 'estimated ACV' (EACV). Anthony used this at Emailage, where a JP Morgan Chase deal carried a ~$1M forecast but a $0 commitment. It requires bulletproof ARR definitions and heavy education, and gets trickier during a fundraise or exit. **Q: When should you offer a POC in an AI sales cycle, and what's the punch list?** A: Offer a POC only after the deal is effectively sold. The punch list: the MSA is squared away, legal and security are squared away, budget is squared away, and both IT and operations are at the table and excited. The POC then only confirms the solution does what was promised and that the teams like working together — which is why Pallet's POCs convert at basically 100%. **Q: Should you use a POC to close a deal or to sell one?** A: To close, not to sell. Using a POC as a desperate Hail Mary to generate intent burns time, resources, and conversion. Get the customer sold first — confirm real budget and internal alignment — then use the POC to validate the solution and de-risk the relationship. **Q: When should a startup invest in RevOps or sales ops?** A: Sooner than you think. Andrew's rule is that if you wait until you obviously need it, it's too late — doubly so for a startup; Pallet began hiring around 10-15 GTM people. Laying down RevOps infrastructure early greases everything else and produces airtight planning data that can materially add to your valuation in a raise or exit. **Q: What is 'top-down goal, bottoms-up resourcing' planning?** A: Leadership hands down a non-negotiable number (say, $50M); what's up for debate is only the resources needed to deliver it. Fixing the goal forces creativity, where pure bottoms-up planning only reaches the realm of the already-experienced. It's iterative and cross-functional, and pairs with proactively modeling what it would take to 10x your org before your CEO asks. **Q: Why is selling AI in logistics and freight especially hard?** A: Andrew cites the MIT stat that ~95% of AI deployments fail and expects it's higher in freight, because almost nothing is standard — everything is an exception specific to a customer or their customer. The counter is to land a tight, high-confidence scope (like automating 'where's my stuff' responses), deliver flawlessly, and expand from there. ## Timeline - **00:00** — Intro: the consultant who became a CRO - **00:46** — Walking into roles you're not qualified for - **01:59** — The first 90 days: absorb, then find the truth - **03:44** — Why Pallet is the most challenging mission yet - **04:29** — Where he goes for resources and peer learning - **05:38** — The usage-based pricing problem in AI - **08:10** — Emailage, JP Morgan Chase, and articulating ARR - **10:38** — Reporting usage-based revenue to the board (estimated ACV) - **12:38** — How conservative should the forecast be? - **13:56** — Pallet's successful-transaction pricing - **17:15** — Land tight-scope, earn the next project - **19:17** — The 95% AI-deployment failure rate (and why freight is worse) - **20:38** — How to think about POCs and proof of value - **22:33** — Why post-sales joins pre-sales at Pallet - **24:57** — The punch list before you offer a POC - **26:47** — POCs vs. trials: it depends what you sell - **28:07** — Why most GTM plans are built on a lie - **28:47** — The win-rate lie: benchmarks vs. reality - **30:53** — Wanting bigger deals without a plan to get them - **36:04** — Planning rigor: DocuSign vs. a fast-growing startup - **38:53** — When to invest in RevOps - **40:11** — The plan as a diagnostic (NUCO + channel model) - **43:25** — Top-down goal, bottoms-up resourcing - **45:30** — Why DocuSign starts planning in Q3 - **46:10** — The 'pissed-off RevOps leader' growth-model story - **47:30** — The 10X-the-org exercise every leader should do - **48:36** — Closing thoughts and the growth-model handoff ## Related episodes - **Ep. 95: Why AI Means More RevOps Hires, Not Fewer** (Jimmy O'Halloran) — The consumption-revenue companion — quota design, usage-based forecasting owned by finance, and land-small motions, from another operator who was also at Emailage. · https://leanscale-knowledge-hub.netlify.app/podcast/jimmy-ohalloran-new-relic-revops-consumption-revenue/ - **Ep. 91: Why Outcome-Based Pricing Is a Trap for Most AI Companies** (Roee Hartuv) — Pricing-and-packaging counterpart to Pallet's outcome-based 'successful transaction' model and the usage-based comp discussion. · https://leanscale-knowledge-hub.netlify.app/podcast/roee-hartuv-outcome-based-pricing-trap/ - **Ep. 88: Why AI Won't Close Your Biggest Deals** (Michael Kiernan, CRO at Nextdoor) — A CRO's take on the limits of AI in enterprise selling — pairs with Andrew's POC discipline and the 95%-of-AI-deployments-fail reality. · https://leanscale-knowledge-hub.netlify.app/podcast/michael-kiernan-nextdoor-ai-wont-close-deals/ - **Ep. 85: Why AI + GTM Engineers Can't Replace RevOps** (Tessa Whittaker) — Reinforces Andrew's 'invest in RevOps sooner than you think' and the operating layer behind honest planning. · https://leanscale-knowledge-hub.netlify.app/podcast/tessa-whittaker-ai-gtm-engineers-revops/ - **Ep. 6: Why Your Forecast Is Broken** (LeanScale) — Foundational forecasting episode underneath the estimated-ACV and plan-as-diagnostic discussion. · https://leanscale-knowledge-hub.netlify.app/podcast/why-your-forecast-is-broken/ - **Ep. 2: How to Measure New Business With Usage-Based Pricing** (LeanScale) — The measurement problem beneath usage-based ARR, comp, and quotas that Andrew and Anthony trade war stories about. · https://leanscale-knowledge-hub.netlify.app/podcast/bernardo-alves-usage-based-pricing/ ## Full transcript _Machine-transcribed and not diarized; speaker attribution is inferred._ _Transcript only, as a separate file: https://leanscale-knowledge-hub.netlify.app/podcast/andrew-geisse-failed-quarters-gtm-planning/transcript.md_ ### 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. --- _LeanScale Podcast Knowledge Hub. Free to quote and cite with attribution to The LeanScale Podcast (https://www.leanscale.team)._