A few weeks ago, I opened the Moment conference with a belief I can’t stop talking about: as intelligence gets cheaper, customer context and customer success become more important. I know what you’re thinking: “John, customer success is your hammer. Everything looks like a nail.” Fair. But have you read the Anthropic S-1?

I went through all 557 pages—with my friend Claude, of course—and found 154 references to the customer success playbook: expanding accounts, getting AI into production, gathering customer context, driving adoption and proving value. It’s everywhere, from the growth strategy to the risk factors, where Anthropic tells investors what could break its business.

That’s a lot of nails! 🔨

The six that matter most

If you only read six, read these.

1. The growth engine is land and expand. Anthropic explains its ~900% net revenue retention this way: “This pattern of initial deployment, demonstrated value, and rapid expansion has been replicated across organizations.” That is the customer success playbook, credited with the headline metric (p. 195).

2. Failing at customer success is a named risk to revenue. If Anthropic can’t help customers “identify, deploy, and scale additional high-value use cases, demonstrate measurable return on investment, or integrate… into their core workflows,” customers may “fail to renew at expected levels,” which “could materially slow our revenue growth” (p. 79).

3. The bottleneck is people who can deploy. Anthropic put $100 million behind the Claude Frontier Academy to address “the shortage of engineers who can take AI from an initial use case into production,” with a goal of 10,000 engineers by the end of 2027 (p. 194). Its partner network has already certified over 150,000 practitioners (p. 193).

4. The missing pieces aren’t intelligence. “Intelligence is one limiting factor, but so are connectors that do not yet exist, governance frameworks that are not yet written, and orchestration logic that needs to be built from scratch” (p. 192).

5. Depth of adoption is worth 20x. Claude Enterprise users who didn’t use Claude Code spent under $75 a month. The top 5% who did spent about 20 times that (p. 195).

6. Outcome pricing is on the table. Anthropic lists “outcome or task-based pricing” as a model it may have to offer (p. 60). It’s framed as a risk, but it’s in the filing.

What this means for post-sale leaders

Expansion is the revenue model. Consumption makes up “the substantial majority” of Anthropic’s revenue (p. 138). In that model, a workflow a customer never adopts is revenue that never shows up. NRR stops being a lagging retention metric and becomes the growth plan.

Customer context is becoming product. The filing says skills “turn institutional knowledge into agent capabilities” (p. 200), and that Claude can use an organization’s “accumulated context to suggest the next workflow worth automating” (p. 207). Some of the most useful knowledge about a customer has always lived in account notes and in the heads of the people closest to the business: which system is authoritative, which exceptions need a person, what counts as done. Now it has somewhere to go.

Outcomes are the scoreboard. Each of the 20 customer stories in the filing (pp. 208–227) opens with a “Results” box, not a feature list. That’s why Will Patterson and I wrote Outcome Metrics 1.0. Deployment cost, time to first outcome and expansion into additional workflows show whether customers are getting results and whether a company can afford to deliver them.

The career move is to get closer to building. Start with a workflow you know well. Map its inputs, decisions and exceptions. Learn enough about context management, tool calls and evals to work through a deployment with an engineer. Customer knowledge gives you a head start. Technical fluency lets you turn it into something the system can use.

Models open the gap. Customer success closes it.

This isn’t to say models don’t matter. They widen what’s possible, and sometimes customers expand on their own. But the same filing warns that customers may not expand because of “technical challenges in integrating” (p. 43). It also says that if models converge, buyers may choose on “application features, user experience, distribution, integration into products they already use, or the strength of a sales organization rather than model capability” (p. 41).

As intelligence gets cheaper and more alike, what separates one provider from another is how well it gets that intelligence working inside a customer’s business.

Here’s the entire list:

Definitions and prospectus summary (pp. 1–12)

1. p. 1 · Deployment — “‘Applied AI’ refers to a discipline and organizational function focused on embedding AI capabilities directly into production business environments to address specific customer requirements. Applied AI teams, which include forward-deployed engineers, work with enterprises to design and deploy custom solutions, specialized workflows, and domain-specific implementations tailored to a customer’s own systems and processes.”

2. p. 2 (repeated on p. 68) · Customer metrics — “Because spending $100,000 or more on our products is generally characteristic of organizational rather than individual usage, we use the number of and revenue from customers with $100,000 or more of revenue on a TTM basis as our measure of enterprise adoption and engagement with Claude throughout this prospectus, including in references to ‘enterprise customers’ and ‘enterprise adoption.’”

3. p. 2 · NRR & expansion — “‘Net Revenue Retention’ reflects customer expansion, contraction, and churn as of a measurement date. We calculate Net Revenue Retention by dividing the Qualified Customers’ Current Period revenue by their Base Period revenue.”

4. p. 3 · Revenue function — “‘pay-for-intelligence’ or ‘consumption’ refers to our revenue model under which customers pay for their usage of our intelligence service, which is metered in tokens and priced according to the model selected.”

5. p. 3 · Deployment — “‘SIs’ refer to systems integrators, or third-party technology and professional services firms that design, build, and deploy integrated solutions for customers by combining products and services from multiple technology vendors into unified systems tailored to customer needs.”

6. p. 6 (repeated on p. 180) · Deployment — “Our enterprise strategy is built on the belief that frontier AI is most valuable in real-world settings, as deployment across enterprises is where economic impact is greatest and where the improvement loops from customer feedback are richest. Accordingly, we have organized our research priorities, our product roadmap, and our go-to-market and Applied AI teams around enterprise use cases, which range from routine knowledge work to the most complex problems.”

7. p. 6 (repeated on p. 180) · Adoption — “The customer feedback we gather directs our research focus and makes Claude more capable over time. This broadens where Claude can be deployed and further expands enterprise adoption, which helps ensure that the benefits of our AI reach people and organizations at scale.”

8. p. 7 (repeated on p. 186) · Adoption — “We also believe that safety, alignment, and ethical behavior resonate particularly strongly with enterprises, where rigorous safeguards, predictable model behavior, and demonstrable accountability have become decisive criteria in selecting an AI partner for mission-critical workloads.”

9. p. 7 (repeated on p. 189) · Context — “Virtual Collaborators carry the access rights, system connections, and context that their organizations grant them, which allows them to function more accurately and reliably. They can navigate and use internal tools and execute workflows that span multiple steps that require sustained reasoning.”

10. p. 8 (repeated on p. 190) · Context — “What makes Claude Code a Virtual Collaborator is its sustained reasoning, a harness that translates intent into actions, an execution environment that maintains a persistent state whether on a developer’s machine or in a sandboxed cloud environment, integration with existing tools and systems, and a user-friendly interface.”

11. p. 8 (repeated on p. 190) · Adoption — “Software developers are powerful advocates for Claude—they understand how systems work, have credibility evaluating technical tools, and often serve as internal champions for adopting new technologies. Winning their trust creates a foundation for broader diffusion of Virtual Collaborators across enterprise workforces. We are already seeing this pattern play out with non-technical teams increasingly adopting Claude Code and Claude Cowork to manage their own workflows.”

12. p. 8 (repeated on p. 190) · NRR & expansion — “By extending beyond Claude Code with applications purpose-built for specific professions and industry verticals, we accelerate Claude’s diffusion into new categories of knowledge work and deepen our presence across the enterprise.”

13. p. 8 · Customer metrics — “Our customer base as of September 30, 2026 includes: • More than 11,900 customers with $100,000 or more of revenue on a TTM basis;”

14. p. 8 (repeated on p. 181) · Adoption — “The speed and depth of our enterprise customer adoption are powerful evidence of Claude’s position at the frontier of AI.”

15. p. 9 (repeated on p. 191) · Support & ROI — “They come to us for access to frontier AI across our platform and applications that deliver real-world outcomes.”

16. p. 9 (repeated on p. 191) · Adoption — “Our investments in research on AI alignment, interpretability, cybersecurity, and enterprise-grade controls aim to deliver the predictability and dependability that organizations need in customer-facing and regulated contexts. This trust means that enterprises can expand the scope of the work that they delegate to Claude, as well as the systems into which Claude is integrated.”

17. p. 9 (repeated on pp. 139, 181, 207) · Support & ROI — “Customers realize value from Claude in three primary ways: more productive employees, faster processes, and embedded intelligence in their products. As Claude’s capabilities grow, our customers benefit and often broaden their adoption of Claude in new workflows.”

18. p. 9 (repeated on p. 191) · Support & ROI — “Beyond our models, the Claude Platform provides primitives that enable customers to accelerate time-to-value and leverage Claude’s intelligence in a variety of use cases.”

19. p. 9 (repeated on p. 181) · Deployment — “Much of the diffusion of Claude has been organic. We amplify this with our go-to-market and Applied AI teams, which extend our reach by meeting customers where they are through distribution partnerships that place Claude inside customers’ existing technology stacks.”

20. p. 9 (repeated on pp. 181, 198) · Deployment — “Ecosystem partnerships also expand our reach, allowing customers to adopt Claude through SIs, such as Accenture, Deloitte, KPMG, and PwC, consultants, and data platforms, such as Salesforce and Snowflake. We recently launched an AI services company, Ode with Anthropic, in partnership with leading private equity firms to bring Claude’s capabilities to mid-sized companies across sectors, building solutions on the Claude Platform and supporting customers over the long term.”

21. p. 10 (repeated on pp. 182, 194) · NRR & expansion — “Our enterprise strategy is designed to drive durable customer adoption by embedding Claude directly into business-critical workflows and enabling the development of products built on Claude. We believe that enterprise customers achieve a compelling return on investment from Claude, as agentic workflows can drive both top-line growth and efficiency. This enables us to expand quickly with customers, as demonstrated by our Net Revenue Retention of approximately 900% as of September 30, 2026.”

22. p. 10 · Revenue function — “Diffusion also accelerates as our models become more capable and efficient, allowing us to lower the cost per task for customers. For example, Claude Opus 5.5 reduced customer costs per task by approximately 40% compared to Claude Opus 5. Lower costs per task drive greater usage, which in turn drives broader diffusion of Claude.”

23. p. 10 (repeated on p. 182) · Context — “Enterprise deployments of Claude deepen our understanding of the hard problems, edge cases, and domain-specific challenges that matter most to our customers. We improve our models, platform, and applications based on feedback from customers using our offerings in production across their businesses. These improvements result in wider deployments and adoption that fuel the next cycle of improvement.”

24. p. 10 (repeated on p. 183) · Revenue function — “Revenue from expanding enterprise adoption helps us to fund the compute, research, and talent needed to improve Claude.”

25. p. 11 (repeated on p. 179) · Adoption — “In our view, the world has only begun to use the capabilities of today’s frontier models, and the gap between what Claude can do and how broadly it is used represents one of our largest growth opportunities, alongside continued advances at the frontier.”

26. p. 12 · Deployment — “• Claude’s Adoption. We intend to grow our direct go-to-market and Applied AI teams, deepen cloud distribution partnerships, invest in brand and marketing, and expand our international presence to drive adoption of Claude as the trusted AI partner for organizations worldwide.”

Risk factors (pp. 27–131)

27. p. 29 · Support & ROI — “Further, the industry benchmarks commonly used to test AI models may not accurately reflect real-world performance or utility, and even models that perform well on such benchmarks may not meet customer expectations when deployed in production environments, which could lead to customer dissatisfaction, reduced usage, or reputational harm.”

28. p. 32 · Revenue function — “We must grow our customer base and expand revenue rapidly in order to generate the cash flows necessary to satisfy these commitments. However, our revenue is primarily consumption-based, and much of it is not subject to long-term contractual commitments, while our compute and infrastructure commitments generally extend over multiple years.”

29. p. 41 · Adoption — “If differentiation among advanced models narrows, or if customers increasingly select AI providers on the basis of application features, user experience, distribution, integration into products they already use, or the strength of a sales organization rather than model capability, competitors that have invested more heavily than we have in those areas could be better positioned than we are.”

30. p. 42 · Revenue function — “Many of our customer contracts allow customers to reduce usage or terminate with limited or no notice. Customers are not obligated to renew their subscriptions or contracts with us.”

31. p. 42 · Revenue function — “Even minor degradations in model performance or increases in response latency could cause customers to reduce usage or switch to competitors. If we are unable to retain existing customers or if our customers do not maintain their usage levels, our revenue and growth could be adversely affected.”

32. p. 43 · NRR & expansion — “In addition to retaining customers, our growth strategy depends in part on expanding usage within our existing customer base by increasing usage volumes, selling additional capabilities, and expanding adoption across departments and use cases within customer organizations. However, customers may not expand their usage for a variety of reasons, including satisfaction with current usage levels, budget constraints, technical challenges in integrating our models, platform, and applications more broadly within their organizations, or preference for multi-vendor AI strategies in order to limit dependence on any single provider.”

33. p. 43 · Revenue function — “Due to our consumption-based pricing model, customers may reduce or cease usage at any point within a given period due to budget or internal procurement constraints, organizational spending controls, or other factors unrelated to the quality or performance of our models, platform, and applications, and may not resume usage until a new budget period commences or additional spend is approved, even where demand for our models, platform, and applications remains strong.”

34. p. 43 · Adoption — “Our ability to generate revenue and achieve sustainable growth depends in significant part on the extent to which enterprises, software developers, and other users adopt AI technologies, integrate them into existing workflows, expand usage over time, and are willing to pay for our models, platform, and applications at levels that support durable economic value at scale.”

35. p. 43 · Support & ROI — “As AI capabilities improve across the industry and a broader range of models becomes available, customers may conclude that incremental performance gains at the frontier do not justify the additional cost, and may migrate toward smaller, cheaper, or open-source alternatives that adequately address their needs. If we are unable to demonstrate sufficient differentiated value from our frontier models relative to less capable alternatives, our revenue and growth could be adversely affected, even in a market where overall AI adoption continues to grow.”

36. p. 46 · Context — “These systems are designed to possess enterprise-level permissions, integrations, and contextual awareness and to operate autonomously for extended durations, including sustained multi-step workflows lasting hours or days, which amplifies the potential severity of any errors, misalignments, or security incidents that may occur during such extended autonomous operation.”

37. p. 52 · Revenue function — “Customers and enterprise partners who choose to deploy our models, platform, and applications based on our safety positioning may lose trust in us, terminate or decline to renew their contracts, demand refunds, publicly criticize our company, or switch to our competitors, which could result in harm to our reputation, revenue loss, and reduced market share.”

38. p. 55 · Context — “Customers may increasingly demand specialized solutions or specialized integration and tooling that we do not currently offer and may not plan to offer, or may seek AI solutions embedded more deeply into enterprise workflows.”

39. p. 57 · Revenue function — “• some of our customers may redesign their systems to require fewer of our services with limited notice to us and may choose not to renew or increase their purchases of our models, platform, and applications;”

40. p. 60 · Revenue function — “As a result, we may be required to reduce our prices, offer shorter contract durations or offer alternative pricing models, such as outcome or task-based pricing, any of which could adversely affect our business.”

41. p. 62 (repeated on p. 138) · NRR & expansion — “Our recent growth may reflect early-stage adoption dynamics, the nascency of the AI market, and rapid initial customer expansion that may not be sustainable over time, and it may decline significantly and more rapidly than we anticipate, as our revenue base increases, as the market matures, and as a result of the other factors described below.”

42. p. 67 · Revenue function — “Both our consumption-based and subscription-based revenue may fluctuate from period to period, and in particular, our consumption-based revenue may fluctuate significantly or decline if customers reduce, limit, or do not expand their usage or spend, or shift usage to lower-priced models, including in response to competitive offerings, pricing changes, changes in customer budgets or strategic priorities regarding AI investment, seasonality, or general economic conditions.”

43. p. 68 · Deployment — “Accordingly, such metrics may differ materially from performance outcomes experienced by any particular customer or user in their specific deployment environment or use case, and should not be relied upon as indicative of the results any customer or user will achieve.”

44. p. 76 · NRR & expansion — “Whether we are able to increase our sales to existing customers, identify and engage new customers, and enter new U.S. and non-U.S. markets, each with a focus on broadening use of our models, platform, and applications across departments and entire organizations, will depend, among other things, on our ability to successfully test new market segments and customer types, validate product-market fit through early customer engagement, timely and effectively scale our sales motions, and adapt quickly when market conditions change.”

45. p. 77 · Revenue function — “We have a limited history under our current go-to-market strategy, and our efforts to scale and evolve our customer acquisition, engagement, and retention model may not be successful.”

46. p. 77 · Revenue function — “Our future success depends in part on our ability to continue attracting, onboarding, expanding, and retaining customers under this model, including determining whether, when, and how to target, develop, and deepen relationships with individual customers over time.”

47. p. 77 · Deployment — “Scaling our operations, including hiring, training, and retaining additional sales, sales engineering, and customer-facing personnel, and evolving our go-to-market strategy may take more time and require more effort than anticipated, and the results of these efforts are difficult to predict.”

48. p. 77 · Deployment — “We have organized our research priorities, our product roadmap, and our go-to-market and Applied AI teams around enterprise use cases, and much of the diffusion of Claude to date has been organic— driven by individual users, including software developers and prosumers, who adopt Claude and often serve as internal champions for its broader adoption within their organizations—rather than by a large direct sales organization.”

49. p. 77 · Adoption — “This approach has allowed us to scale with a smaller team relative to other large enterprise technology companies, but it assumes that our applications and distribution will be sufficient to deliver the capabilities of our models to customers and that individual adoption will continue to translate into organizational adoption and expansion.”

50. p. 77 · NRR & expansion — “Because we have a limited operating history with our current business model and go-to-market strategy, we have less experience predicting customer adoption, expansion, and retention patterns, and customers may be slower than expected to adopt our models, platform, and applications or expand usage.”

51. p. 77 · Support & ROI — “Our ability to attract, retain, and expand relationships with enterprise customers depends in significant part on our ability to meet their generally heightened operational, technical, security, reliability, and compliance requirements. Enterprises typically expect high levels of system uptime, performance consistency, data security, auditability, internal controls, and scalability, as well as robust support and service levels.”

52. p. 77 · Context — “These requirements may be heightened for our agentic offerings, where enterprise customers may require detailed logs of each action taken by an autonomous agent within their environment, including the agent’s reasoning, tool invocations, and interactions with external systems. Any inability on our part to provide such logs at the level of granularity customers require could limit adoption of our agentic offerings by enterprises or result in customer attrition.”

53. p. 79 · Adoption — “However, these benefits are inherently difficult to measure, free usage may not generate the awareness or advocacy we expect, and individual adoption of our products may not translate into organizational adoption or expansion.”

54. p. 79 · Support & ROI — “If we fail to maintain high-quality customer support, our ability to retain and expand customers could suffer, which may adversely affect our prospects, business, financial condition, and results of operations.”

55. p. 79 · Deployment — “Our customers rely on our customer support services to resolve issues and realize the full benefits that our models, platform, and applications provide. In order to deliver high-quality customer support and engagement, we must successfully assist our customers in deploying and continuing to use our models, platform, and applications, resolve performance issues, discover and deploy our models, platform, and applications in new use cases, provide hands-on technical implementation, customization and solution engineering support, provide training and guidance to help customers effectively adopt and scale their use of our models, platform, and applications, address interoperability challenges, and respond to security threats and cyberattacks and performance and reliability problems that may arise from time to time.”

56. p. 79 · Support & ROI — “The importance of our support function will increase as we expand our business and pursue new customers. Many enterprises have complex internal systems and require high levels of focused support to fully realize the benefits of our models, platform, and applications.”

57. p. 79 · Support & ROI — “If we do not help our customers quickly resolve issues and provide effective ongoing support and enablement, or a market perception develops that we do not maintain high-quality customer support and experience, our ability to maintain and expand our subscriptions to existing and new customers could suffer, particularly with respect to our enterprise customers.”

58. p. 79 · NRR & expansion — “In addition, our growth model depends significantly on driving deeper adoption and expanded use cases within our existing customer base. If we are unable to effectively provide support and integration efforts that enable customers to identify, deploy, and scale additional high-value use cases, demonstrate measurable return on investment, or integrate our models, platform, and applications into their core workflows, customers may limit usage, fail to renew at expected levels, or reduce their spend, which could materially slow our revenue growth.”

59. p. 79 · Support & ROI — “We expect to continue to increase our customer base, and that growth may put additional pressure on our customer support teams, which may require additional personnel to respond to customer demand.”

60. p. 79 · Support & ROI — “To the extent that we are unsuccessful in hiring, training, and retaining adequate support personnel, our ability to provide high-quality and timely support to our customers will be negatively impacted, and our customers’ satisfaction and their use and subscription of our models, platform, and applications could be adversely affected.”

61. p. 80 · Support & ROI — “In addition, as we continue to grow our operations and reach a larger and increasingly global customer base, we need to be able to provide efficient services that meet our customers’ needs globally at scale, and our customer support teams may face additional challenges, including those associated with delivering support, training, and documentation in languages other than English and providing services across expanded time-zones.”

62. p. 80 · Support & ROI — “Our product and investment decisions are informed in large part by our commitment to AI safety, expanding our models, platform, and applications securely and responsibly, and providing high quality customer support, all of which, in addition to our status as a PBC, may not necessarily maximize short term financial results.”

Management’s discussion and analysis (pp. 133–176)

63. p. 133 · Revenue function — “As new customers adopt Claude and existing customers expand their usage into new workflows, our revenue grows.”

64. p. 134 · Deployment — “Claude’s intelligence is a primary driver of its diffusion and our revenue growth: because Claude leads at the AI frontier, customers rapidly adopt it, quickly see real value, and organically expand their use. We complement this intelligence-led growth with direct go-to-market and Applied AI teams and extend our reach through native availability across all three major cloud platforms—AWS, GCP, and Azure—and through partnerships with SIs, consultants, and data platforms.”

65. p. 134 · Customer metrics — “We had more than 11,900 customers with $100,000 or more of revenue on a TTM basis as of September 30, 2026, up from more than 950 as of September 30, 2025.”

66. p. 134 · NRR & expansion — “In addition, as customers further embed Claude into their most critical workflows and growth initiatives, many rapidly expand their deployments into higher revenue tiers. As of September 30, 2026, we had more than 1,900 customers with $1 million or more of revenue on a TTM basis and approximately 250 customers with $10 million or more of revenue on a TTM basis.”

67. p. 134 (repeated on p. 181) · Customer metrics — “For the three months ended September 30, 2026, over 50% of our customers with $100,000 or more of revenue on a TTM basis used Claude Platform and at least one of our first-party applications, up from approximately 30% for the three months ended December 31, 2025.”

68. p. 135 · NRR & expansion — “This customer momentum is driven by significant usage expansion as customers realize the value of deploying Claude across their organizations. The value that Claude delivers to customers has helped drive our Net Revenue Retention of approximately 900% as of September 30, 2026.”

69. p. 135 · Adoption — “The growth in our business reflects the degree to which enterprises are embedding Claude directly into their business-critical workflows. Despite these trends, adoption across the global economy remains nascent.”

70. p. 136 · Revenue function — “Our go-to-market model reflects this as well—intelligence-led growth and broad distribution partnerships enable us to rapidly expand customer adoption and revenue without being limited by the rate at which we can grow our sales and marketing organization, resulting in greater sales efficiency as compared to typical enterprise technology companies.”

71. p. 138 · Revenue function — “Pay-for-intelligence, our consumption-based revenue model, is our primary revenue model and currently represents the substantial majority of our total revenue. Under this model, customers pay for usage, which is metered in tokens and priced according to the model selected.”

72. p. 138 · Revenue function — “A growing number of enterprise customers agree to non-cancelable annual or multi-year contracts with minimum spend commitments in exchange for a committed price list. These contracts result primarily in consumption-based revenue.”

73. p. 138 · Revenue function — “We expect consumption-based revenue to continue to represent the substantial majority of total revenue for the foreseeable future.”

74. p. 139 · Adoption — “This feedback loop deepens customer relationships with each release and makes Claude more capable for all customers.”

75. p. 139 · Context — “Software developers have been core to our strategy: they are simultaneously the architects of applications built on our platform, and they encode their workflows and institutional knowledge into Claude-powered agents.”

76. p. 139 · Adoption — “Claude Code is now embedded in software development workflows across major organizations, with these relationships often beginning with individual engineers who recognized the value of autonomous coding agents and accelerated adoption across their enterprises.”

77. p. 139 · NRR & expansion — “Claude is extensible: regardless of entry point, enterprises quickly discover that frontier AI applies to a wide and expanding range of tasks across their organizations. As a result, what sometimes begins as a single use case frequently expands into broader adoption spanning coding, legal analysis, financial modeling, customer operations, and other knowledge-intensive work.”

78. p. 139 · Deployment — “Ensuring the accessibility of such intelligence is also critical, and we do that in the following ways: through our composable platform and applications that meet customers where they are, through our go-to-market and Applied AI teams directly, and through partnerships that extend our reach at scale.”

79. p. 139 (repeated on p. 193) · NRR & expansion — “This pattern repeats across organizations: prosumers become internal champions, teams expand their use of Claude, and what begins as a single workflow grows into something that impacts how an entire organization operates. This pattern has been core to our revenue growth.”

80. p. 139 (repeated on p. 193) · Adoption — “By the time our direct teams engage a customer, Claude is often already in use. Our go-to-market teams use this organic momentum to build executive sponsorship and drive enterprise-wide adoption.”

81. p. 139 (repeated on p. 193) · Deployment — “Applied AI Teams. Our Applied AI teams embed more deeply with select customers, building solutions that make it easier for organizations to benefit from Claude’s intelligence. They work with enterprises to design and deploy custom solutions, specialized workflows, and domain-specific implementations tailored to the customer’s own requirements. This work drives deeper adoption within individual customers and generates the feedback and information from users that help to shape our platform and product roadmap.”

82. p. 140 · Deployment — “Claude is accessible on all three major cloud platforms, AWS, GCP, and Azure, allowing enterprises to deploy Claude within the infrastructure, security perimeters, and commitment structures they already operate.”

83. p. 140 (repeated on p. 193) · Deployment — “Ecosystem Partnerships. Major global SIs have built dedicated Claude practices with teams trained to deploy our platform and applications. Go-to-market alliances with leading data platforms embed Claude into data infrastructure that enterprises already operate, facilitating adoption of Claude within existing workflows and making it easier for enterprises to realize value from Claude.”

84. p. 140 (repeated on p. 194) · Deployment — “We recently launched an AI services company in partnership with leading private equity firms to bring Claude’s capabilities to mid-sized companies across sectors, building solutions on the Claude Platform and supporting customers over the long term. Ode with Anthropic will partner closely with our Applied AI and go-to-market teams.”

85. p. 140 · Customer metrics — “Together, these approaches have led to a structurally efficient approach to facilitating the diffusion of Claude in the economy, with our sales, marketing, and partnerships expenses representing 19% of revenue for the six months ended June 30, 2026.”

86. p. 140 · Adoption — “Our experience is that as we deliver models with meaningfully improved capabilities that deliver higher intelligence per dollar spent, customers find new applications for AI across their businesses, accelerating adoption and revenue growth.”

87. p. 140 · NRR & expansion — “As we deliver more capable models, customers have expanded their usage into new use cases and increased their spending accordingly.”

88. p. 141 · Adoption — “The best measures of our progress are Claude’s intelligence and capability, and customer adoption of Claude. Our ability to convert compute investment into frontier model performance, and then increase customer adoption, will be a key determinant of our access to capital.”

89. p. 141 · Adoption — “Our financial performance depends on the pace and breadth at which AI, and in particular Claude, is adopted across the global economy. While Claude’s capabilities already address a wide range of enterprise use cases, we believe that enterprise adoption remains nascent.”

90. p. 142 · Adoption — “Our growth depends on continuing this pace of product innovation and reducing the friction between Claude’s capabilities and customer workflows.”

91. p. 142 · Adoption — “We believe that enterprises prefer models that are safe and aligned, and that our continued investment in safety strengthens customer trust and supports long-term adoption.”

92. p. 142 · Deployment — “A large portion of our growth to date has been self-service and organic. As AI adoption extends further into enterprises and more regulated industries, we are investing in direct go-to-market, Applied AI teams, and partnerships across all three major cloud platforms, SIs, consultants, and data platforms.”

93. p. 142 · Revenue function — “The effectiveness of these investments, and our ability to hire and retain go-to-market talent, will be a meaningful determinant of growth.”

94. p. 142 · NRR & expansion — “Over 50% of the Fortune 500 and over 30% of the Global 2000 were customers with $100,000 or more of revenue on a TTM basis as of September 30, 2026. We believe we are in the early stages of our expansion within these customers, with our revenue from these Fortune 500 customers representing, on average, less than 0.1% of their total expenses for the three months ended September 30, 2026.”

95. p. 142 · Customer metrics — “For the three months ended September 30, 2026, revenue from our top 10 Fortune 500 customers represented, on average, less than 1% of their total expenses—still a small fraction of their overall spend, but over eight times the average of our Fortune 500 customers with $100,000 or more of revenue on a TTM basis.”

96. p. 142 (repeated on pp. 151, 153) · Customer metrics — “The number of customers with $100,000 or more of revenue on a TTM basis grew from approximately 200 as of December 31, 2024 to approximately 1,500 as of December 31, 2025. Total revenue from these customers grew from approximately $220 million to $3.5 billion and represented approximately 57% and 76% of total revenue for the years ended December 31, 2024 and 2025, respectively.”

97. p. 143 · NRR & expansion — “We believe the difference reflects the substantial runway we have to deepen adoption, both within our largest customers and within customers earlier in their adoption of Claude.”

98. p. 143 · NRR & expansion — “At the same time, our largest customers continue to expand. For the three months ended September 30, 2026, our revenue from each of our top five customers reached a record high.”

99. p. 143 · Adoption — “For example, model versions released in the six months ended September 30, 2026 accounted for over 80% of our revenue for the three months ended September 30, 2026. As we have released successive versions of Claude models, we have continued to see revenue growth as new capabilities unlock additional use cases, prompting new customers to adopt Claude and existing customers to expand their usage.”

100. p. 145 · Revenue function — “Customers adopt and retain our technology based on whether our models are at the frontier of AI capability and maintaining that frontier position is essential to revenue generation.”

Business, customer stories and culture (pp. 179–241)

101. p. 186 · Adoption — “Further, we publish safety methodologies, model evaluations, and our Responsible Scaling Policy because we believe transparency is a prerequisite for trust, and trust is a prerequisite for the responsible deployment of frontier AI at scale.”

102. p. 188 · Adoption — “As models take on agentic roles with access to critical business systems, trust and reliability are paramount. And as capabilities increase, the ability to operate safely becomes one of the key determining factors for commercial viability.”

103. p. 189 · Support & ROI — “We have built our models, platform, and applications for usefulness in production environments instead of benchmark performance. This distinction matters, as many AI systems prove difficult to implement and fail to deliver the expected value in complex enterprise environments, where governance and security concerns remain among the top barriers to adoption.”

104. p. 189 · Adoption — “As enterprise customers integrate Claude into increasingly complex workflows, they surface the use cases and requirements that shape our roadmap. They also provide feedback that allows us to continuously improve our models, platform, and applications as well as develop new solutions to advance their AI adoption.”

105. p. 189 · Adoption — “With each model and product advancement, Claude is able to address more valuable use cases, deepening its impact for existing customers while lowering the adoption threshold for new ones. When a model crosses the capability, reliability, and trust threshold required for a category of work, adoption in that category generally moves quickly from experimentation into production.”

106. p. 192 · Context — “The most demanding deployments need intelligence that is reliable, connectable, and deployable within the specific data environments, regulatory constraints, and workflow patterns of each organization. Intelligence is one limiting factor, but so are connectors that do not yet exist, governance frameworks that are not yet written, and orchestration logic that needs to be built from scratch. Our platform seeks to close these gaps, and we believe the breadth and speed with which we have done so is a primary reason customers build on Claude.”

107. p. 192 · Context — “Above these sit composition primitives such as our Agent Software Development Kit (‘SDK’), Claude Managed Agents, agent skills, multi-agent orchestration, and the Model Context Protocol (‘MCP’) for universal connectivity to enterprise data and tools. Together, these assemble into complex production workflows.”

108. p. 192 · Context — “While these agents have different connectors and agent skills, they have the same SDK, protocol, and orchestration framework. That composability is one of the reasons our customer base spans across industries and why customer expansion can happen seamlessly across additional use cases without significant integration work.”

109. p. 192 · Context — “In their Domain. Claude for Financial Services, Claude for Financial Advisors, Claude for Healthcare, Claude for Life Sciences, Claude for Legal, Claude for Education, and Claude for Government come with domain knowledge, data connectors, skills, and compliance controls pre-loaded.”

110. p. 192 · Context — “As enterprises adopt our platform and applications, we become deeply embedded in their businesses over time. Software developers build applications and internal tools on our platform, and they encode their workflows and institutional knowledge into Claude-powered agents.”

111. p. 193 · Deployment — “To accelerate the growth and capability of this ecosystem, in March 2026, we launched the Claude Partner Network, committing an initial $100 million in 2026 to fund partner training, technical certification, and joint market development with the firms that bring Claude into enterprise environments. As of September 30, 2026, this network comprises over 150,000 practitioners across over 4,000 organizations who have received certifications through our Claude Certification Program.”

112. p. 194 · Deployment — “In October 2026, we launched the Claude Frontier Academy (the ‘Academy’), backed by a $100 million commitment, to address a key constraint on enterprise AI adoption: the shortage of engineers who can take AI from an initial use case into production. Drawing on our own experience deploying Claude inside large enterprises, the Academy trains our customers’ and partners’ engineers to the same standard as our own engineers, with each participant leading a Claude deployment at their own organization.”

113. p. 194 · Deployment — “We aim to train 10,000 engineers through the Academy by the end of 2027, beginning with cohorts from leading consulting firms and enterprises.”

114. p. 194 · Adoption — “From there, adoption can scale frictionlessly, and through our Applied AI teams and partnerships, we help enterprises realize more value as their adoption grows.”

115. p. 194 · Adoption — “We believe enterprises are still in early phases of deployment, and we believe most knowledge workers have yet to fully experience what frontier AI can help them accomplish. We believe many industries have barely begun to explore the transformative potential of AI-native workflows.”

116. p. 195 · NRR & expansion — “Our customers’ journey using Claude often begins with a single use case before expanding across departments, applications, and workflows. As our models become more capable, customers often deepen our partnerships—they find more ways to embed Claude into their workflows, increasing the scope of what Claude can accomplish within their enterprises. This pattern of initial deployment, demonstrated value, and rapid expansion has been replicated across organizations and is reflected in our Net Revenue Retention of approximately 900% as of September 30, 2026.”

117. p. 195 · NRR & expansion — “We see this expansion as customers adopt agentic products like Claude Code. For example, in the three months ended September 30, 2026, Claude Enterprise users who did not use Claude Code spent less than $75 per month on average, while the top 5% of Claude Enterprise users who used Claude Code spent approximately 20 times that amount.”

118. p. 195 · NRR & expansion — “In the past, when we have launched new model versions that deliver a significant increase in capability and a lower cost per task, we have generally seen customers expand their use of our intelligence service.”

119. p. 195 · Revenue function — “Enterprise customers embed Claude in business-critical workflows, driving stronger retention and higher monetization than consumer AI.”

120. p. 197 · Adoption — “As Claude’s capabilities advance, we believe it will address entirely new categories of use, resulting in deeper adoption and greater demand for our platform.”

121. p. 197 · Deployment — “Drive Adoption Across Existing and New Customers. We intend to grow our direct go-to-market and Applied AI teams to deepen enterprise relationships, build custom agentic solutions for complex deployments, and help customers expand Claude across their operations.”

122. p. 197 · Deployment — “We intend to deepen our cloud distribution partnerships and expand the enablement of partner field teams to sell, deploy, and integrate Claude.”

123. p. 197 · NRR & expansion — “We also plan to continue investing in our prosumer channel, where individual users often become internal advocates who pull Claude into their organizations.”

124. p. 198 · Context — “Our platform unifies frontier intelligence with the harnesses, connectors, governance, and orchestration that are all required to put that intelligence into production. As customers build on the primitives we provide, Claude becomes an integral part of their data, workflows, and institutional knowledge, and the relationship deepens with each integration.”

125. p. 198 · Adoption — “We also design our products to close the gap between what Claude can do and how fully customers use it, which we believe is important to helping customers realize the value of frontier intelligence.”

126. p. 198 · Support & ROI — “We believe that as we extend the frontier and broaden our application surfaces, customers realize value faster, embed Claude more deeply into their operations, and increasingly rely on us as a primary provider for their AI transformation.”

127. p. 200 · Context — “Developers can connect context to Claude for their agents and applications using context primitives.”

128. p. 200 · Context — “MCP defines a universal interface through which Claude, as well as other AI tools, can connect to enterprise data sources, tools, and workflows. Claude Platform’s native MCP connector handles connection management, tool discovery, and error handling automatically.”

129. p. 200 · Context — “A modular framework that lets organizations encode repeatable tasks, workflows, and domain expertise into reusable packages, or skills, that Claude loads on demand.”

130. p. 200 · Context — “We provide pre-built skills for common formats like Word, Excel, PowerPoint, and PDF, while custom skills can capture anything from engineering standards and regulatory processes to proprietary toolchains. These skills turn institutional knowledge into agent capabilities.”

131. p. 201 · Deployment — “A model alone is not an agent. Running one reliably in production is challenging, because agents must survive crashes and interruptions, act on systems with scoped and auditable credentials, and scale across variable workloads.”

132. p. 201 · Context — “Autonomous operation requires a harness, which provides the secure environment, credentials, memory, and orchestration loop a model needs to plan, call tools, verify its work, and complete a task safely on its own. Building and operating that infrastructure is specialized, continuous work that, until recently, each customer had to take on themselves.”

133. p. 201 · Deployment — “We host the sandboxes, store the credentials, maintain the memory, and run the agent loop; customers define their agent’s tasks, tools, and guardrails. When a new model becomes available, customers do not need to rebuild their agent loop.”

134. p. 202 · Context — “An open-source plugin system lets users install or build packages bundling skills, data connectors, and workflows.”

135. p. 202 · Adoption — “Claude.ai delivers top-of-funnel demand generation for enterprise adoption.”

136. p. 202 · Context — “With the context of the surrounding conversation, enterprise software tools, shared documents, and channel-scoped memory, Claude returns answers, drafts, analyses, and pull requests directly in-thread, operating as an ambient teammate that knows when to proactively join the conversation.”

137. p. 202 · Adoption — “Claude Tag brings Claude into the multiplayer workflows where teams already coordinate, extending adoption from individuals to entire organizations.”

138. p. 203 · Support & ROI — “Our vertical solutions arrive purpose-built and are embedded with domain knowledge, controls designed to support industry-specific compliance requirements, and pre-configured data integrations that reduce time-to-value.”

139. p. 203 · Context — “Claude for Financial Services plugs directly into the data sources those firms already use (e.g., market data, data warehouses) and runs inside the tools financial professionals utilize—such as Excel, PowerPoint, Word, Outlook, and Claude’s own apps.”

140. p. 203 · Context — “Claude for Legal plugs directly into the systems and tools legal professionals already rely on. Through MCP connectors, Claude for Legal connects to e-discovery and legal data intelligence platforms like Relativity, AI contracting platforms like Ironclad, legal research databases, deal rooms, and matter management systems.”

141. p. 203 · Context — “Each agent and workflow is configurable to a team’s own precedents, processes, escalation chains, risk calibration, and house style—with controls designed to support attorney-client privilege, ethical walls, and confidentiality obligations.”

142. p. 206 · Deployment — “Across industries, enterprises deploy Claude in mission-critical production workflows—for example, underwriting insurance policies, writing clinical reports for life-saving drugs, detecting and remediating cybersecurity threats, and analyzing portfolios for asset managers.”

143. p. 206 · Context — “Our enterprise customers include a wide range of organizations deploying AI at scale, from AI-native startups building products to the world’s largest organizations that require enterprise-grade security, governance, and compliance before a single workflow impacts production.”

144. p. 206 · Deployment — “These production deployments surface the governance, reliability, and integration requirements that only emerge under real enterprise load, which creates feedback that flows back into our roadmap and deepens our customer relationships with every release.”

145. p. 207 · Adoption — “The adoption of Claude Code began with individual software developers who noticed the potential of autonomous coding agents before enterprise procurement teams had considered the category; Claude Code is now becoming the default choice inside many enterprise engineering organizations.”

146. p. 207 · NRR & expansion — “Prosumers serve as a powerful top-of-funnel engine—we have consistently seen that individuals who experience Claude’s value firsthand become advocates within their organizations, seeding adoption that accelerates from individual use to team-wide and ultimately organization-wide deployment.”

147. p. 207 · Adoption — “Adoption most often begins here. An individual experiences the impact that a frontier AI model can have on their own output—for instance, hours of financial analysis or code review completed in minutes—and that conviction spreads from the first user to their team, and from one team to the entire company.”

148. p. 207 · Context — “Our Claude Enterprise plan provides the governance, security, and administration to support adoption of Claude at organizational scale.”

149. p. 207 · Context — “As adoption deepens, Claude stops being something employees consult and starts being something the organization runs on. As organizations encode more of their workflows into Claude—their data, systems, conventions, and prior work—the platform becomes more valuable for them. Claude can draw on that accumulated context to suggest the next workflow worth automating, reducing the effort required for each successive deployment.”

150. p. 207 · NRR & expansion — “Across all three dimensions, a significant share of expansion requires minimal to no new deployment at all.”

151. p. 207 · NRR & expansion — “As a result, customers can increase usage, utilize higher subscription tiers, and bring additional workflows onto the platform without a new sales cycle or procurement decision.”

152. pp. 208–227 · Customer outcomes — Twenty pages of customer stories (Accenture, AIG, Bristol Myers Squibb, DoorDash, Lilly, PayPal, Shopify, Walmart and more), each led by a “Results” box rather than a product description. Among them: “45,000 Accenture professionals trained on Anthropic,” “Dozens” of internal data sources connected at Bristol Myers Squibb “via MCP integrations,” and Lilly reporting “5x” under “Expansion since rollout.”

153. p. 228 · Deployment — “But the culture of intellectual rigor extends to non-technical functions as well: our policy team publishes detailed policy frameworks and proposals; our go-to-market team co-develops deployment architectures alongside customers; and our Applied AI engineers sit at the frontier of what is possible with agentic systems.”

154. p. 236 · Adoption — “Beyond direct competition, one obstacle to the diffusion of Claude is the natural resistance to change within organizations. Many enterprises operate with deeply entrenched legacy systems, established workflows, and institutional processes that have been refined over many years. Adopting frontier AI capabilities such as Claude often requires substantial change management, including workforce retraining, process redesign, internal policy development, and shifts in corporate culture. These can introduce friction, cost, and perceived risk that can delay or prevent adoption.”

Use the list

The list is long on purpose. Every line is Anthropic’s own words, with a page number you can check. Take the five that fit your next budget conversation, board deck or hiring plan.

In 15 years in this function, I haven’t seen this much attention on the work between a sale and a customer getting dependable results. Now that work is written into one of the most important filings ever in technology. I’m excited and you should be too!

- JG

Source: Anthropic, PBC Form S-1. Page numbers are the filing’s printed page numbers. Inner quotation marks are set as single quotes.

Disclosure: Some SuccessVP LPs work at Anthropic.

Closing the distance between roles is one of the critical changes in modern go-to-market. The person who understands the customer’s problem can do more to solve it. That changes how you support customers: fewer handoffs, less context lost, and more responsibility with the person already helping them.

This is the shift I’ve been writing about in The Rise of the Forward Deployed CSM. Decimal empowers that behavior in technical support.

Think about a familiar question: “Why did our integration stop syncing?”

The person handling the issue understands what the customer is trying to do. But the answer could depend on a permission, a feature flag, or a failed request. Finding it means connecting code, logs, and account-specific context, often with help from engineering.

We’ve built entire workflows around that handoff. The ticket moves, the context gets reconstructed, and the customer waits.

Decimal brings the investigation into the customer-facing workflow. The team gets findings, references to the underlying evidence, and a suggested response. They can examine the explanation, add context, and run the investigation again.

That’s why we invested. Decimal gives the people closest to the customer more of the technical capability to move the problem toward resolution.

Getting the answer right

Technical support needs enough context to investigate the problem and a way to check whether the answer is right. An explanation has to hold up against what actually happened to that customer. Closing a ticket is an imperfect substitute for resolving the issue. The test is whether the customer can get back to what they were trying to do.

Decimal’s published Granola case study shows the workflow. For a missing meeting transcript, Decimal investigates the relevant code, CloudWatch logs, and user context, then puts its findings into Plain for a support engineer to review. Granola reports handling twice the ticket volume with the same-size team.

The team still has to get the answer right. It starts with an investigation rather than assembling every piece itself.

Each resolution can also improve the next one. Decimal’s knowledge gap workflow can propose documentation updates through pull requests for review. The broader opportunity is to bring that customer understanding into implementation and product development.

Why this team

Sanjeet Hajarnis and Kevin Raji Cherian bring experience in both AI and production systems. Sanjeet led AI at Eightfold after working on ranking at Facebook and pricing at Uber. Kevin built Databricks’ vector search product and led infrastructure at Eightfold, where the two met.

They’re building for a world where customer-facing teams can do more of the technical work themselves. We’re proud to back Sanjeet, Kevin, and Decimal alongside Khosla Ventures and our friends at Kearny Jackson.

JG

📅 Moment 2026: NYC Customer Success Week is back on October 6 at Convene, 225 Liberty Street — 700+ post-sales leaders, operators, and builders, and 40+ speakers from Anthropic, OpenAI, GitHub, Figma, MongoDB, and more, all working through what AI and outcome-based pricing are doing to CS. Tickets are on sale now; use code FounderLedCS75 at checkout. Hope to see you there.

I have never once woken up wanting a Lincoln… or more Salesforce, but give Matthew McConaughey three minutes in that baritone and apparently I need both. Lincoln in the driveway, Agentforce in the CRM. Alright, alright, alright. Take my money.

Nobody markets quite like Salesforce. Dreamforce opened with a sizzle reel of McConaughey telling us it’s not the end of software… it’s the end of software that makes humans do all the work. It’s worth a watch, the language is spot on.

The argument underneath it was simple:

The models are already incredibly capable. They know a lot about the world. What they don’t know is your world — your customers, your workflows, your data, your permissions, all the weird context of how your company actually works. And without that, intelligence is just intelligence. It isn’t useful work.

I have to admit, the timing is interesting. Six days before Dreamforce, Dario published We Must Pace the Frontier, making the case for slowing the rate of capability gains, mostly on safety grounds. Then he walked onto the Dreamforce stage and said that even if the technology froze today, we’d only be capturing 5–10% of the value of the models we already have — “there’s so much diffusion left.”

I’m not going to opine on the safety components of AI, but I do think it’s worth considering what is maybe a less obvious business argument. Anthropic filed confidentially for an IPO in June, and it’s been reported they’ve told investors adjusted operating income would be positive for a second straight quarter… a number that gets there by stripping out what it costs to develop the models: compute, training, inference, etc. On the bottom line they’re still deep in the red.

Meanwhile the catch-up window keeps collapsing: SemiAnalysis has open weights closing the gap to the frontier in five or six months, down from eighteen, with Kimi and GLM passing Opus 4.5 and GPT-5.2 this year. Tough spot to be, spend enormously on a new frontier model only to watch something free show up two quarters later and take the floor out from under your pricing. A slower frontier isn’t only a safety position, perhaps it’s also a world where the expensive part costs less, what you already shipped sells a just little bit longer, and that uncaptured unused model ability, the 90–95%, becomes the margin story on top of the most incredible growth story in history.

We’re entering the deployment era of AI.

We spent the last few years focused on capability — better models, benchmarks, context windows, etc. Meanwhile there’s still a massive gap between what the models can do and what companies have figured out how to make them actually do it. I hosted a dinner in New York City this week with prominent go-to-market VPs, CROs, and CCOs, and they’re still struggling to find these huge productivity gains in their enterprises. Connecting the context, understanding the workflow, building the evals, dealing with permissions, defining what “done” means, components required to produce a really good unit of work from AI, that’s where the major work still has to happen… and I don’t even know if we have all the infrastructure to make it a reality yet.

And that changes where the hard work happens in this phase of the AI rollout. The constraint is now deployment and my belief is that the frontier moves inside the customer. Someone has to figure out how the work actually gets done, connect the context, define what good looks like, build the evals, and keep the system true as the work changes. You can’t do all of that from the model layer. You have to do it with the customer.

If you believe that, the people who live closest to the customer are about to become a even MORE more important.

Phase 1 of AI was about making the models smarter. Phase 2 is about making all that intelligence useful… And a lot of that work is going to happen at the frontier of the customer as much as it will happen in the labs.

Deployment is the work great the best customer facing people do: understand the customer, understand how the work actually gets done, and close the gap between the technology and the outcome. Let’s go!!! 🚀

- JG

Pretty much every founder I spoke with wanted a forward-deployed engineer before hiring a salesperson. They need someone who understands the customer’s operation and can make the product work inside it. For anyone who has spent a career helping customers get value from technology, that hiring priority should get your attention.

The work is familiar: understand the operation, get the product working, and prove it delivers. What’s changing is how directly that work shapes the product. Three themes in this batch help explain why.

AI is moving into the physical world

Some of the most interesting companies are building technology that has to work alongside people, equipment, and the unpredictability of physical environments. Cosmic Robotics builds autonomous construction equipment, starting with solar and data centers. Shiraz AI builds robots that learn manufacturing tasks from a single human demonstration and delivers the hardware, model, and on-site deployment.

A working demonstration is the beginning. The system still has to perform inside a particular customer’s operation, with its equipment, exceptions, and ways of working. Someone needs to understand those conditions well enough to help the product succeed there.

That is what I mean by the edge: where technology meets the customer’s actual operation. The edge is a condition, not a geography. It can be a factory floor, a construction site, or a complicated workflow inside a software company.

Context and evaluation are becoming products

A capable model still needs enough context to do a job and a way to determine whether it did that job correctly. Those two conditions sound straightforward until you try to supply them inside a real business. The information is scattered, important rules are undocumented, and experienced employees know things they have never needed to explain.

Companies in this batch are building around that problem. Ooak Data turns company data into environments for training and evaluating agents. Context.dev supplies live web information that agents can use while they work.

For customer leaders, the significance is practical. Understanding how a customer works and what a good result looks like can become context the system uses and evaluations engineering runs. Customer knowledge becomes an input to the product’s performance.

Agents are taking responsibility for work

The third theme is software taking on more of the coordination and execution that people previously handled. A team of agents needs to know who owns a task, what belongs in a handoff, when to escalate, and what counts as complete. Those are operating questions as much as technical ones.

We invested in Dock before it presented at Demo Day because this is a problem its founders understand firsthand. Mike Molinet and Govind Kavaturi helped grow Branch past $100 million in ARR. They experienced the coordination required to scale an organization and built Dock as a multiplayer workspace where specialized agents communicate, unblock one another, and work alongside people.

Mike put the problem to me clearly earlier this year: copiloting breaks down when the human becomes the copy-paste middleman between chat windows. Dock is building toward agents that can coordinate their work, reducing that burden. The operating knowledge required to make those handoffs useful is part of what the product must encode.

Why this should excite customer leaders

Across these themes, founders need people who can connect technical capability to the way customers actually work. That helps explain why deployment expertise is showing up so early in their hiring plans. Getting the system working is part of finding and building the product.

I see the relevance of this experience in the CS, support, and forward-deployed leaders in our community at companies like Anthropic, OpenAI, and Lovable. They work where technical capability meets customer expectations. Their judgment can help founders anticipate deployment problems, identify the people they need, and understand whether customers are getting value.

There is a technical learning requirement here. Customer knowledge becomes more useful when you can translate it into requirements, evaluations, and improvements engineering can act on. Start with one workflow you know well: document its exceptions, define successful performance, and help the team address a recurring failure.

That is what left me excited after Demo Day. These founders are building ambitious companies, and customer understanding is among the first capabilities they need. For people who have spent their careers close to customers, there is an opportunity to bring that experience further into the product—and help shape what gets built next.

— JG

📅 Moment 2026: NYC Customer Success Week is back on October 6 at Convene, 225 Liberty Street — 700+ post-sales leaders, operators, and builders, and 40+ speakers from Anthropic, OpenAI, GitHub, Figma, MongoDB, and more, all working through what AI and outcome-based pricing are doing to CS. Tickets are on sale now; use code FounderLedCS75 at checkout. Hope to see you there.

I met Abby DeVito, who leads Success, Implementation, and Support at Tern, about nine months ago. Growth at Tern has been wild; 600-plus paying agencies, north of 12,000 advisors, and on pace for 20,000–30,000 by year end. The company is growing like gangbusters.

But what impressed me the most is the support organization AVI is building. Her team is routinely hitting an 90% AI resolution rate on customer support month after month, up from the 70s last year. All while shipping product weekly and scaling the user base several times over.

Usually when companies grow as fast as Tern is, support gets worse, before it gets better, and it can take a long time. The combination of rising volume and improving resolution rates usually track in opposite directions, so needless to say I was eager to have Abby walk me through exactly how her team is having the success it is.

Here’s the Tern model:

The split: 20% named, 80% engineered

Tern has 600-plus paying agencies, and as much as Abby would like to give every one of them a named point of contact, that math doesn’t work at this growth rate. From my experience, it never does.

Instead, they’re institutionalizing a model where the top ~20% get a traditional Customer Success Manager relationship: implementation, launch, activation, growth, the full motion. That is paired with a dedicated data migration specialist for the genuinely hard problem of moving ten years of legacy agency data into Tern. That top slice pays a professional-services fee because their processes are complicated enough to require white-glove service.

The other 80% get something different, which is the part I think is worth studying.

What it isn’t is “no support.” Rather, it’s a different service model built around a health-scoring system, tiered automated outreach, and community experts who are contracted power users rather than full-time Tern employees. “We’re still trying to serve that 80% we don’t have named account ownership for,” Abby told me, “with different types of touch points.”

At the center of it is a rules-based health bot built in Hex that watches for 30/60/90-day product milestones. When an account misses a threshold, it triggers a yellow or red alert in Slack, segmented by account size, onboarding stage, and persona.

From there, they’ve built a Zapier pipeline that routes the action into a drafted message to the agency owner. A lighter-touch account gets an automated nudge: I.e. “Here’s why credit card authorization matters, here’s the training that goes with it.” A higher-touch account gets a prompt to book time with a human.

Importantly, they didn’t just make these rules up. They’re based on what Abby and the team have learned actually gets customers to change their behavior. Now they’re trying to automate as much of that playbook as they can.

The part everyone gets wrong about AI support

Here’s the number that actually explains the 90%: it isn’t the model. Tern runs Intercom’s Fin, same as a lot of companies. What’s different is what feeds it.

Abby’s team uses standing Claude projects to continuously crawl newly shipped product, training and office-hour transcripts, and live ticket queues. They turn what they find into internal response guidance for Fin and public Help Center content. The result is a knowledge base that understands not just the documentation, but how customers actually use the product and the many ways they ask for help. It’s what I’ve written about before as context and correctness, but treated as a living system rather than a one-time setup.

The 10–15% of tickets that still escalate tend to be things where someone actually needs to do something. That leaves Tern’s support reps spending roughly 60% of their time on escalations and the other 40% on reach-outs, training, and health-driven interventions for agencies without a named CSM.

Support didn’t shrink. It changed jobs.

Measurement is starting to catch up to the model

Tern’s support team is still measured on fairly traditional metrics: first response time, CSAT, resolutions, and Intercom’s CX score, which uses sentiment analysis to evaluate conversations even when a customer doesn’t fill out a survey.

The more interesting metric they’re adding is conversion. Does a health-triggered intervention actually move an account from red to yellow, or yellow to green? That will tell Abby whether the 80% motion is actually working.

For named accounts, the measurement is evolving from activation toward growth. Today, Tern’s Success Manager is largely measured on launch and onboarding milestones. As Tern monetizes bookings through its supplier integrations, Success will increasingly own integration usage and expansion. That changes the job from getting customers live to getting them to do more business through Tern.

Under the hood:

Making all of this work requires getting the right information to the team at the right time. Hex is one example. Abby used to need a business analyst or data engineer to pull account-level reports that could take hours to prepare. Now she can query Tern’s data herself in natural language and get an answer in minutes.

On one customer call, she went from asking, “Who’s the top user of this supplier integration?” to identifying a specific advisor and using that person’s success as the story for the rest of the agency.

And really, that same idea runs through the whole system. Health signals tell the team which accounts need attention. Slack alerts them. Zapier helps route what happens next. Hex lets them dig into the data. None of these tools on their own is particularly novel. It’s how they’ve put them together that I find interesting.

What I take from Tern

None of the tooling Tern is using is particularly exotic. Hex for data. Zapier for routing. Slack for alerts. Claude for synthesis. Fin for resolution. What’s interesting is how they’ve put it all together and how much attention they pay to continually feeding the system with what they’re learning from customers.

That’s also why I don’t think the 20/80 split is a compromise. The 80% aren’t simply getting less service. They’re getting a different kind of service that Tern can improve and scale without adding another CSM every time it adds more customers.

I think there’s something bigger happening here. We’ve spent a lot of time talking about how AI will make Customer Success more efficient. But Tern is a good example of something I find more interesting: AI is starting to change what the job actually is.

Support reps spend less time answering questions and more time stepping in when an account needs help. CSMs spend less time pulling data and more time using it to drive adoption and expansion. And more customers can be served without needing a named person assigned to them.

It left me thinking about a pretty simple question: if you were building your Customer Success organization from scratch today, knowing what these tools can do, would you build the same organization you built five years ago?

I don’t think I would.

— JG

Thanks to Abby DeVito for the conversation this is built from (Granola transcript, Jul. 23, 2026).

One of us spends his weeks inside the deployment — embedded with customers, doing the unglamorous archaeology of getting an agent to read a system that was never built to be read. The other spends his weeks underwriting the category — deciding which of these companies compounds into something durable, and why. A forward-deployed engineer and a venture investor. Bottom-up and top-down.

We got introduced, traded a few posts, and expected the call to be a friendly argument. It wasn’t. We’d independently written the same diagnosis in two different vocabularies. One of us calls it the context gap and system archaeology; the other calls it the deployment bottleneck and the two conditions. Same finding, different altitude: the model stopped being the hard part. What’s hard is everything wrapped around it — the context, the correctness, the integrations, and the judgment about what’s actually worth building.

So we did something more useful than argue. We put both bodies of work on one table — one of us literally fed the other’s entire back catalogue into the model that runs his thinking — and looked for the seams. This is what we found: where the map overlaps (more than we expected), the one place it forked (and how the fork turned into the most interesting idea of the call), and where we think the role is going next.

Where the map overlaps

The bottleneck isn’t the model — and the wiring is getting harder, not easier. Everyone wants to talk about model capability. The real wall is integration. Not the marquee enterprise accounts — those companies run modern, API-friendly systems. It’s the long tail: the SMBs running twenty-year-old software with no API, often not even in the cloud, where the cost of changing the system of record runs from half a million to tens of millions of dollars. Nobody is ripping that out. So the work is to reach into it. ⚑ One of us recently backed a company doing exactly this — agents operating legacy systems (think medical practices, hotel booking) by clicking like a human on a screen the model can’t natively see. The point both of us keep landing on: the low-hanging API fruit is gone. What’s left is thirty years of technical debt, and that’s now the job.

The work is mostly process engineering — and better models pushed it further that way. This surprised exactly no one who does it, but it’s worth saying against the “AI writes the code now” noise. As the models got better, the share of the job that is writing code went down, and the share that is understanding how a business actually works went up. The building blocks exist; agents wire them together; the scarce skill is figuring out which blocks, in what order, for a process nobody has ever written down.

The honest test of an FDE: does the work feed the product? This is the line between a company and a consultancy. If what you learn in the field flows back into the product, you compound. If it doesn’t, you’re billing for labor with extra steps. In practice it’s messy — at an early startup it might be ~40% feeding product and the rest keeping revenue alive, and the ratio shifts with maturity (a mature voice-API company or a frontier lab feeds the harness and adjacent tooling, not the core model, and that’s fine for them). But the principle holds: feeding the product and driving the outcome are the two things that earn the title.

Do FDE well and your whole post-sales org gets smaller. Here’s a move stolen from the old SaaS playbook. Investing in onboarding used to buy you downstream efficiency — fewer support tickets, less change management, customers reaching value sooner, CSMs not constantly restarting dead accounts. That effect is amplified in applied AI, because you’re no longer selling seats on a platform — you’re selling units of work. So the forward-deployed function isn’t protecting an annuity; it’s driving revenue, and it compresses what used to be five roles (pre-sales, solution architect, project manager, change management, account relationship) into one. The counterintuitive consequence: done right, FDE shrinks the post-sales organization. Support doesn’t disappear — it inverts. Tier-one goes to AI (low cost of error, much like code). What’s left for humans is the harder tier-two and tier-three work: longer to resolve, touching more of the organization, and frankly more exhausting. The people who do support now are more tired, not less.

Eval pass rate is the new NRR — and the cost of error sets the bar. If there’s one metric the forward-deployed function should organize around, it’s the rate at which the system’s work clears the customer’s bar for “correct.” That’s the new driver of stickiness and net revenue retention. But the bar isn’t universal — it’s a function of the cost of error. In aerospace, a part with a defect is catastrophic, so the bar is 100%. For a wholesaler, shipping to the wrong address costs fifty cents, so 95% is fine and the value is in everything built around the core task. You can see this in the job market: the most eval-obsessed forward-deployed roles cluster in the domains where mistakes are expensive — legal, medical, finance. Define the cost of error first; it tells you what “good enough” has to mean.

The argument that collapsed into a better idea

We went into the call hunting for a real disagreement, and we thought we’d found it on defensibility.

One of us had written that, as models commoditize, lock-in is the next move — the labs are building deployment arms whose solutions are coupled to their own models, so switching becomes a re-implementation by design. The other had written that the moat is the opposite of lock-in: a private eval — your own proprietary library of what “right” looks like, the thing that lets you swap models underneath and keep climbing your own hill. One view says trap the customer; the other says own the judgment and stay portable.

Then we realized we were describing the same animal from two sides. The lock-in view is about the labs’ incentive; the private-eval view is about what actually stays valuable when the model underneath is a commodity. Push both one step further and they meet in the same place: when models are roughly interchangeable, the differentiator moves to the harness — and then one step beyond the harness, to the opinionated product experience wrapped around it.

That’s the real moat, and it’s an old venture truth in new clothes: a strongly opinionated product that produces work which clears a very opinionated eval bar. Think about why you stay in your coding tool of choice — not because it’s the only model, but because it has your context and a point of view about how you should work. Think about Apple shipping products that aren’t always the most innovative but are relentlessly opinionated, and winning anyway. The defensible thing isn’t the model and it isn’t even the harness; it’s the taste encoded into the product and the private bar it’s measured against. The hardest moat for AI to copy is the one that can’t fully articulate itself — the “I don’t know what it is, I just know it’s right.”

The forward payload: the FDE is splitting in two

The most interesting thing we found wasn’t in either of our archives — it fell out of the conversation.

Two forces are pulling on the role at once. Sovereignty — a government or regulated buyer mandating which models may touch their data — and cost — the minimum tokens required to clear the eval bar — both push toward model-portability. The same harness may have to run on a Canadian model for one customer, an open-weight model for another, a frontier model only where the work genuinely needs it. That makes one half of the forward-deployed role more technical, not less: you have to know what each model is good at, what it costs, and how to orchestrate several of them (a powerful model conducting, cheaper models doing the sub-tasks) to produce a unit of work that passes the bar. The skill isn’t syntax anymore; it’s judgment about the implications of technical and model choices.

But the other half of the job — gathering context, mapping the org, holding the customer relationship, reading the political weather of a deployment — isn’t getting more technical. It’s getting more like the role we used to call customer success. And as the CSM role collapses into the deployment motion, that’s where the context-gathering half of the FDE lands.

So the role bifurcates: a deeply technical forward-deployed engineer and a context-gathering, account-holding partner. Two roles inside one account. If that sounds familiar, it’s because Palantir has been running it for years as Delta and Echo — the engineer who builds and the domain person who holds the context and the value — each correcting the other. The AI-native company is about to re-derive the same pair from scratch.

This also quietly settles a question one of us had been holding: whether teams drift toward more engineers than domain experts as judgment gets abstracted into the product. The better answer may be that it was never a ratio. It’s a pair — and the durable unit is the technical FDE matched with a context partner who is, increasingly, the evolved CSM.

What’s still transitory

A caveat we both hold: all of this is written in pencil. The whole edifice assumes the current model paradigm, where out-of-the-box AI delivers a minority of the value and the wiring is genuinely hard. Every month the models eat a little more of both conditions — more context, more verifiable correctness — and when a generation closes that gap on its own, parts of this thesis compress. One of us leans that the shape is partly transitory; the other that it’s durable and expanding. We’re comfortable not resolving that in print.

Two questions we’re still chewing on, and we’d rather show them than pretend they’re closed: whether the technical/ context pair eventually collapses back into a single hybrid person, and how to hire for the role — for raw slope and drive, or for accumulated domain judgment. We disagree at the margins on that last one, which is probably the next thing we’ll write about.

Close

We came at this role from opposite ends and drew nearly the same map. That’s either a sign we’re both right or a sign we’re reading from the same hymn sheet — and the only way to find out is to keep publishing the disagreements as we find them. If you came here from one of our newsletters, the other one is the other altitude on everything above. We’ll keep comparing notes in the open.

The trap is the SaaS metrics stack — logins, QBRs, health scores, blended NRR. None of it survives a system that either produced the outcome or it didn’t. Carry it into work-done software and you don’t get a slightly-wrong read; you get a confidently-wrong one. So before the four metrics, one thing first.

First, audit the work

We’ve always started a CS rebuild with a time-and-motion study. This is the same move, pointed at a new target.

Start with one question: what is your unit of work? Not your pricing. Not your packaging. The discrete thing a customer is actually paying you to produce — the thing a person used to do by hand, or the thing they always wished they could hire for and never could. A resolved ticket. A closed loan. A merged pull request. Name it in the smallest, most concrete terms you can, agnostic of how you happen to bill for it.

Then map the inputs on both sides. What context does the system need to produce that unit — the data, the workflow, the edge cases nobody wrote down? And what does verifiable correctness look like — how do you know, mechanically, that the output cleared the bar? Almost no business has both sides handed to it for free. (Code did. That’s the whole reason it went first — I made that case in Post 1.) Most of you are strong on one side and exposed on the other.

Then find where it breaks. Where does the model fall down? What is it genuinely best suited to own, and where is the delivery constraint that only a person can solve? That last question is where your headcount goes.

Run that audit and the rest of this gets easy, because you finally know the thing you’re measuring — and which side of it, context or correctness, you’re short on. (That gap is exactly who you hire for; I spent all of last week’s post on it, so I won’t repeat it here.)

Okay. Work named, gap known. Now the fun part — what to actually measure.

Measure 1 — Eval Pass Rate

The share of AI outputs that clear the customer’s quality bar.

This is your clearing line of value, and it’s the one metric I’d stand up before any other. If you can’t measure your eval pass rate, you don’t have a product yet — you have a demo that sometimes works. What gets measured gets done; for the first time in this category, the unit of work is discrete enough that we can actually measure it.

Read it like a vital sign. If it’s drifting down, you have a churn signal arriving weeks before the renewal conversation — non-deterministic systems drift, sometimes gradually, sometimes off a cliff. If it’s climbing, you have a renewal you can see coming. Either way you’re reading the truth of the product, not a proxy for it.

Measure 2 — Time to First Value

How fast each customer reaches their first verified unit of work in production.

First resolved ticket. First closed loan. First merged PR. For years I wanted to measure time-to-value and couldn’t — in theory it was the perfect metric, in practice it was hopeless, because “value” was a judgment call you could argue about forever. Now the unit of value is discrete, so the clock is real. You can put a number on the exact moment the system first did the job to the customer’s standard.

Measure it because everything downstream hinges on it, and because getting there fast is mission-critical. This is why teams are pulling the forward-deployed engineer forward — into the pilot, sometimes into the sale. You can’t gesture at a dashboard and say “imagine your data in here” anymore; you have to produce a real unit of work to win the deal. (One caveat from my own files: be careful with hard benchmarks here. Fast time-to-value correlates with retention, but a lot of that is selection — better-fit customers both activate faster and stay longer. Treat it as a clock to beat, not proof of causation.)

Measure 3 — Velocity

How fast the work is getting done — and whether it’s accelerating.

Here’s where most teams will reach for the wrong number. The cheap proxy is usage — DAU, WAU, MAU. Did they show up? It’s a fair leading indicator, and change management around AI is daunting enough that “did they even log in” is worth knowing. But it’s the floor, not the goal.

The real signal is units of work completed — and not the volume of them, the velocity. Per day. Per cohort. Are we stacking? Remember what we’re chasing: not “can we do the task,” but “can we draw a Cursor-like curve in this account.” Velocity tells you the efficiency of your product and your team in one number. Volume is the lagging indicator; velocity is the leading one. Measure the slope, not the level.

Measure 4 — Reset your NRR

The ceiling is the customer’s business — not your seats, not your catalog.

In SaaS, 120% net revenue retention was good work. In applied AI, I’m watching 200% become the standard, and the teams in my portfolio that have genuinely tapped the unit of work are reporting numbers north of 300%. If your NRR target still has a SaaS-era number on it, you’ve capped your own outcome before you started.

The mindset shift underneath it is the whole series in one line. For a decade CS existed to protect the annuity — deliver value, defend the renewal, guard the thing that compounds. But work-done software isn’t going after the software budget; it’s going after the work budget, the latent demand that never had enough people to do it. For every dollar a company spends on software, it spends roughly six on the services around it. We’re not protecting a renewal anymore — we’re a toll booth on work that was never getting done. So capture, don’t protect. The motion goes from defense to offense: discover new use cases, expand into adjacent workflows, grow the surface area of the work.

Two cautions. First, know whether your domain is capped or uncapped. Some unlock unbounded work; others shrink it — a genuinely great support product means fewer tickets, not more. Know which one you’re in before you promise 300%. Second, comp creates gravity — so place your builders near customers. Compensation will pull your best people somewhere; the only choice is whether it pulls them toward the work or away from it. Build with that gravity, not against it.

What this all adds up to

Four metrics: eval pass rate is your clearing line, time-to-first-value is your speed, velocity is your slope, and a reset NRR is your ceiling. They share one property the SaaS stack never had — they measure the work itself, not the activity around it. A login is evidence someone might get value. A unit of work that clears the bar is the value. That’s the difference, and it’s why none of the old numbers carry over.

Which is the uncomfortable part, and where I’ll leave the series. Customer Success has structurally changed. The function I spent a career building is being rebuilt around outcomes the software produces, and the only way to keep up is to stay in front of where the work is going — instrument it before the org you’re in needs you to. You won’t get a 30-60-90 to figure this out; the curves are too steep for that.

I don’t have all of this figured out — nobody does yet, and that’s exactly why I’m writing it in real time. The people building at the frontier want to hear from you, because it’s on all of us to prepare each other for what comes next.

— JG

That’s the series — Context and Correctness, the two jobs, and now the four metrics. If it was useful, the best thing you can do is forward it to the one CS leader you know who’s about to land in a company growing faster than their playbook. Subscribe for what I learn next.

Subscribe now

It’s the role the entire industry is racing to hire, and it answers to a dozen names — forward-deployed engineer, solutions engineer, agent engineer, implementation lead, legal engineer. The title shifts from company to company. The job doesn’t.

This person exists for one reason. A model doesn’t understand your business out of the box, and it can’t reliably tell you whether its own output is any good. Left alone, it produces work that is confident, plausible, and unverified. Someone has to feed it the context and check the correctness. That someone is the forward-deployed engineer — and the role went vertical because the two conditions don’t engineer themselves. (I traced that rise here; this is the hiring version of that argument.)

It’s also exactly the capacity OpenAI and Anthropic just spent billions to build, which I covered in Post 1. Those joint ventures weren’t bets on smarter models — they were bets on the people who deploy them. The next bottleneck in AI isn’t intelligence. It’s deployment.

You can see the whole job in the FDE postings. Read them side by side and they sort cleanly into the two conditions.

Context — capture what the model needs to know. Decagon‘s forward-deployed engineers sit with customer stakeholders to “define success criteria, gather requirements,” and translate them into what the agent has to do. Sierra‘s agent engineers specialize each deployment to “perform in particular use cases relevant to each business customer.” Different companies, same work: get inside the business and capture what the model can’t infer on its own.

Correctness — verify the output is right. Cursor‘s forward-deployed engineers own “tracing, evals, metrics, debugging model behavior… and failure modes.” Harvey staffs the same function with former lawyers it calls legal engineers. And Hippocratic AI — building patient-facing healthcare agents, where a wrong answer can do real harm — validates its system with thousands of licensed nurses and physicians before it reaches a patient. The higher the stakes, the more obvious the rule becomes: only someone who has done the work can certify the work. Same job in every case — decide whether what the model produced actually clears the bar, and build the evals that keep it there.

Most hires fill one of the two conditions. The rare ones fill both — hold that thought. But first, here’s where founders go wrong on day one.

The mistake almost everyone makes

When founders realize they need this person, the instinct is to hire “someone more technical.” Usually that means one specific thing: can they write code, do they come from a developer background.

Sometimes that’s exactly right. Look at Cursor again. Their forward-deployed engineers need real proficiency in Python and TypeScript — because Cursor’s entire job is to automate coding. The work the AI is doing is engineering, so the person who can tell whether it’s right has to be an engineer. When the domain itself is technical, “more technical” is the correct read.

But that’s the special case, not the rule. The thing you’re actually hiring for isn’t technical. It’s judgment about the work the AI is doing — and the work is only sometimes code.

Harvey’s correctness function isn’t staffed with generic engineers. It’s former lawyers, because the only person who can tell you whether an AI’s contract analysis is right is someone who used to do contract analysis. The same logic runs through the category: the accountants, the underwriters, the recruiters, the procurement leads. They verify the output because they used to produce it by hand — and they ask sharper questions on the way in, which is half the battle in capturing context.

So the real variable isn’t technical depth. It’s domain depth — fluency in whatever work the model is now doing. At a coding company, that’s an engineer. At a legal company, it’s a lawyer. At a procurement company, it’s someone who’s run procurement. Confusing the two — reaching for “more technical” when what you needed was “from the domain” — is the most common and most expensive hiring mistake I see.

This also breaks the SaaS-era hiring reflex. In SaaS, domain experience faded fast — I watched it happen in the trucking industry. People from the domain could build rapport and speak the customer’s language, but they broke down under the mechanics of a software business: a book of 80 accounts, a heavy renewal quarter, a forecast to defend. They were role players, not workhorses. In applied AI, that flips. Because the job is judgment about the domain, the domain expert gets a much longer runway — and in many cases becomes the most valuable person in the deployment.

Two halves, two profiles.

The cleanest way I’ve found to staff this is to stop thinking about “a CS hire” and start thinking about the two conditions as two distinct jobs — two models for two halves.

Model one — context. This is the forward-deployed engineer. Maps the data sources, documents the undocumented workflow, integrates the system, builds the eval libraries. The work splits roughly 80/20 — about 20% is genuinely technical (ship something to a production environment), and about 80% is process engineering: tracing how work actually flows through the business, getting to the root of the implied workflow, and producing brutally good documentation of it. Ex-consultants who’ve gone technical do this well. So do solutions engineers who can actually build. (Decagon and Sierra hire squarely here.)

Model two — correctness. This is the domain expert. They’re the first eval library you have — on day one, before any automated eval exists, they’re the human who can look at the model’s output and say “right” or “wrong,” and explain why. They speak the customer’s language because it’s their language too. (Harvey‘s legal engineers and Hippocratic‘s clinical validators are this model.)

First, audit what you get for free

Before you hire anyone, run the audit Post 1 sets up: of the two conditions, which does your product already hand you, and which do you have to build?

Code got both for free — centralized context, automatic correctness. That’s why it went first. The wave after code usually gets one for free, and which one changes everything about who you hire.

Take Harvey. Law comes with an enormous, structured corpus — case law, statutes, contracts — almost all of it in English and already written down. A huge share of the context a legal AI needs is simply there. Not all of it — a firm’s own templates, house style, and client preferences still have to be captured, and that’s real work. But the baseline is unusually rich; most domains don’t start anywhere close. So Harvey’s scarce condition isn’t context. It’s correctness: is this analysis actually right, in a domain where “right” is a judgment call rather than a passing test? That’s exactly why Harvey staffs the role with former lawyers. The free condition was context, so they spent their hiring on the one that wasn’t.

Flip the domain and you get a different company. An AI support agent often gets correctness nearly free — resolution and escalation rates are clean signals of whether the work landed. What it doesn’t get free is context: every customer’s help center and ticket taxonomy is different and mostly undocumented. Scarce condition: context. The hire tilts toward the engineer who can capture it.

And then there are the hardest companies — the ones whose domain hands them neither condition cheaply. Unstructured context and fuzzy correctness, both engineered from scratch, no tailwind. These are brutally hard to build, and if that’s you, the most valuable thing you can do is know it going in. Whether you get one condition for free is one of the biggest predictors of how hard your road will be.

Then hire against the gap

If you’re venture-backed and can run the experiment, hire both profiles as a two-by-two: a domain expert for correctness, a forward-deployed engineer for context. The domain expert lives in the nitty-gritty of the account and staffs the workflow; the engineer builds and deploys. The domain expert is usually the cheaper hire, which helps the burn math. Within six months the data tells you which condition was actually scarce for your business — and my hunch is most teams end up needing more engineers than domain experts over time, as the domain expert’s playbook gets abstracted back into the product.

But the pair is a luxury, and plenty of companies that aren’t venture-backed can’t afford it. If you only get one hire, the audit is what saves you. Don’t split a single person across both halves and hope — the gap shows up fast. Put them on the condition your product doesn’t give you for free: the verifier if context is handled, the context-capturer if correctness is. Make the one hire count by aiming it at the gap.

Bonus — model three: build everything

I’ve described two models and told you to pair them. There’s a third. I left it out of the talk this series is based on, but it belongs here — even though most companies can’t run it.

It’s the original. The full Palantir Forward Deployed Software Engineer. Palantir never split the work into context and correctness and staffed each half. They hired exceptional engineers — “strong coders” in Python, Java, C++ — embedded one of them with a single customer, and had that person build the whole thing end-to-end: understand the business, architect the solution, ship it to production, and fold what they learned back into the core platform.

This is the highest-ceiling version of the role and the hardest to staff. It works under three conditions: you can attract that caliber of engineer, the domain is technical enough that one person can both capture the context and verify the output (the Cursor case again — when the work is code, the engineer who built it can also tell whether it’s right), and you want the field work to harden your product, not just serve the account. When all three hold, a single embedded engineer is the most powerful version of this hire there is — every deployment makes the product better for the next one. When they don’t, you’re back to the pair.

Most applied-AI companies are not Palantir, and most domains are not code. That’s why the two-model pair is the default. But if you can build model three, it’s the one that compounds.

So: three models. Context (capture it), correctness (verify it), or build-everything (one engineer who does both). The right one depends on your domain and the talent you can attract — but hire for judgment about the work, not the résumé. The title is incidental — forward-deployed engineer, legal engineer, procurement specialist, it doesn’t matter. The two conditions are not.

You’ve now got the people who engineer the conditions. The next question is how you know they’re working.

— JG

The easy read is that the technology isn’t ready. It is. The bottleneck isn’t capability — it’s structural. And once you see the structure, the failure rate stops being mysterious.

Every AI deployment that actually works meets two conditions. Every one that stalls is missing at least one of them.

Condition one: high context. The model has to know enough about the customer’s business to do the work — the data, the workflow, the constraints, the edge cases, the things nobody wrote down.

Condition two: verifiable correctness. Once the model produces something, someone — or something — has to be able to tell whether it’s right.

That’s it. Context and correctness. When both are present, AI produces value. When either is missing, it stalls — no matter how good the model is.

Code had both for free.

Ask why code was the first place AI produced real, undeniable outcomes, and you’ll usually hear “because engineers were early adopters.” That’s not it.

Code was first because it’s the one domain where both conditions came pre-installed.

Context is centralized and versioned — the codebase lives in one place, the syntax is standardized, and the history of every decision is sitting in commits, issues, and docs. And correctness is verifiable by definition. The code compiles or it doesn’t. The tests pass or they don’t. No judgment call required.

Cursor, Cognition, Replit, Lovable — they didn’t win because code is easy. They won because code is the rare domain where context is free and correctness is automatic. If any category was going to go vertical first, it was always going to be this one.

Most domains aren’t so lucky.

Step outside code and the conditions start to fray.

Tier-1 support and lead qualification are close — and not coincidentally, they’re where applied AI took hold next. Support has documentation, help centers, and ticket history (context), measured against resolution and escalation rates (correctness). Lead-qual has firmographic data and intent signals (context), measured against meetings booked and conversion (correctness). Both map cleanly to the two conditions. Both got real, fast.

But most business problems don’t arrive with either condition met. The context is trapped in someone’s head, scattered across a dozen tools, or simply never documented. And correctness isn’t a passing test — it’s a judgment call that only someone who’s done the work can make.

This is the same gap I described in Customer Success is a Wrapper, seen from the other side. AI closes the old wrapper gaps — products get easier to build, customers more self-sufficient. But it opens a new and more acute one: getting a non-deterministic system to actually work in a specific customer’s environment.

Someone has to engineer the conditions.

If a domain doesn’t hand you context and correctness for free — and almost none of them do — then someone has to build them. Capture the context. Define what right looks like. Make a probabilistic system reliable enough to trust in production.

That work doesn’t happen on its own. It isn’t a setting you toggle on. It’s a job. And it has quietly become the vendor’s job — the thing standing between a model that could work and a customer who’s actually getting value.

That’s the 95%. Not models that can’t perform — deployments where nobody engineered the conditions for them to.

Don’t take my word for it. Watch where the labs put their money.

In the first week of May 2026 — within roughly a day of each other — both Anthropic and OpenAI stood up enterprise deployment arms. Not as experiments. As multi-billion-dollar bets.

Anthropic launched a joint venture valued around $1.5 billion with Blackstone, Hellman & Friedman, and Goldman Sachs. OpenAI raised roughly $4 billion for a deployment company of its own, backed by TPG, Brookfield, Advent, and Bain. Both copied the model Palantir invented a decade ago: forward-deployed engineers, embedded inside the customer’s business.

Here’s how Anthropic described the actual work:

“An engagement might begin with the company’s engineering team sitting down with clinicians and IT staff to build tools that fit into the workflows that staff already use.”

That is not selling a model. That is capturing context and engineering correctness — in person, one customer at a time.

Think about that for a second, if the companies building the most capable models on earth just concluded that the models are not the bottleneck — and put billions behind the people who deploy them, the lesson for the rest of us isn’t subtle!

Which raises the only question that matters next: who, exactly, is that someone?

That’s the next post.

— JG

Take Harvey: their legal engineers are former lawyers. It turns out the best person to capture the context and check the correctness is someone who's already done the work.

For most of software history, the product and the work were separate things. You bought software to help you do work. Whether it helped — and how much — depended on how well you implemented it and how thoroughly your team adopted it. Software gave you capability. What you did with that capability was up to you.

A new class of software companies has inverted this. They do not sell access to software. They sell work completed by it. Per resolved ticket, per originated mortgage, per qualified lead, per executed contract review. The software is infrastructure. The work delivered is the product. And every major metric we built to run software businesses — ARR, CAC payback, NRR, health scores — was designed for the old model. Applied without modification, each tells an incomplete story.

Three things are structurally different about building and running this kind of business. These are not predictions about where the market is going. They are descriptions of companies already operating this way — and finding that none of their reporting infrastructure was built for it.

The category is moving from art of the possible to operational reality. The metrics need to move with it. That’s what this guide is for.

Unpacking the Assumptions

These three assumptions are not abstract. Each one has a structural mechanism behind it — and each one changes how the business needs to be measured. Before introducing the new framework, it is worth understanding exactly what changed and why.

Assumption 1: From Adoption to Deployment

In a seat-based world, every seat has to be justified at renewal. The only way to justify it is if someone is using it. That made adoption the gating function for value — and it created an entire post-sale motion designed to drive human behavior. Health scores tracked logins. QBRs told the story of engagement. The CSM existed to close the gap between what the software could do and what the customer had done with it. Whether users were actually getting value was almost always a matter of interpretation — and interpretation was the CSM’s job.

Outcome-based software is self-adopting. The system either completes the work or it doesn’t. There is no user to train, no behavior to change, no adoption curve to manage. But deployment is heavier — for two reasons.

First, AI-native software is non-deterministic. A mortgage rate calculator returns the same answer every time. An AI underwriting model fed the same application twice may reach different conclusions — because it operates in a domain where correct is probabilistic rather than rule-governed. You cannot test it once and trust it indefinitely. Non-deterministic systems have to be made production-safe in each customer’s specific environment.

Second, the degrees of freedom are wider. In SaaS, one company’s instance looked a lot like another’s. In an outcome-based deployment, every customer’s data, goals, guardrails, and edge cases are different. Someone has to connect the model to the customer’s environment, configure it, evaluate its outputs against real production inputs, and resolve the problems that only emerge once the system is running.

This is the origin of the Forward Deployed Engineer — and the reason the FDE job posting chart went near-vertical between 2023 and 2025. The role is not a rebranded CSM. It is a role built for software that does enough of the work that the old CS motion stops making sense.

[Figure 1 — Forward Deployed Engineer job postings per month, 2020–2025.]

Two archetypes are forming. The product-building FDE, rooted in Palantir's model, treats customer proximity as a forcing function for platform evolution — field solutions get abstracted back into the core product. The outcome-driving FDE embeds in the customer's operating environment and measures success by whether the AI is producing reliable work in production. This is the more common archetype in applied AI today. Most companies draw from both. The metrics in this paper are built around the outcome-driving motion. The product-building FDE operates under a different cost structure — one worth measuring separately, but outside the scope of this framework.

This emphasis on deployment is not a phase that immature products grow out of. Highly tailored deployments are a structural reality of outcome-based businesses — and they are here to stay.

Assumption 2: Value Is Quantifiable

Every software business model can be understood through a single lens: the distance between when a customer pays and when they formally commit to paying again. Everything between sale and renewal — QBRs, health scores, executive business reviews — is activity designed to close that gap.

The history of software business models is the history of that gap narrowing.

On-premise software stretched it to years. Enterprise implementations averaged 12 to 18 months before the system was live, and whether the investment had paid off was often unclear until the next major buying decision. Seat-based SaaS compressed the gap to more frequent, often annualized cycles — and shifted risk toward the vendor. Switching costs dropped. Software that wasn’t delivering value could be replaced, not shelved. That exposure is what created Customer Success. Consumption-based software compressed it further. Each unit of usage was its own small act of recommitment.

Outcome-based software eliminates the gap entirely. Value and the software effectively become one and the same. A resolved ticket is not evidence of value — it is the value. An originated mortgage is not a proxy for ROI — it is the ROI. The work delivered and the value confirmed are the same event.

[Figure 2 — The Value Line. Distance between initial sale and value confirmation, by business model.]

The entire SaaS post-sale infrastructure — health scores, QBRs, adoption programs, success plans — was built to manage an information asymmetry. The vendor knew more about whether the product was working than the customer could easily verify. Outcome-based software removes that asymmetry. The customer can see the output. They do not need a CSM to tell them whether the ticket was resolved.

And that requires rethinking the metrics that flow from it.

Assumption 3: Expansion Is Structurally Uncapped

In SaaS, every customer had a terminal value. It was bounded in two directions: the number of people using the software, and the finite catalog of products and modules the vendor built to sell. Expansion meant more seats or more products. Both had a ceiling.

In a work-done model, the upper bound on value is the volume of work the customer has to complete. That is a fundamentally different constraint — because it grows with the customer’s business, independent of how many people they hire or how many seats they buy.

Uber is the clearest illustration of this. Uber did not replace taxis. It captured a latent demand for transportation that taxis could never have served at scale. Before Uber, if there were no taxis available, people walked, or waited, or didn’t go. Uber made those trips economical — and in doing so, grew the total market for transportation, not just its share of it.

Outcome-based businesses do the same thing to work. Before AI, if a workflow was too expensive or too labor-intensive to run at scale, it simply didn’t happen. A customer who resolves 5,000 support tickets per month with AI may never have staffed the team to handle 5,000 human resolutions — not because the demand wasn’t there, but because the economics didn’t justify it. The demand was latent. The AI makes it economical.

This is why the expansion surface in outcome-based businesses is structurally different from SaaS. The denominator is not the customer’s headcount or their willingness to pay for additional modules — it is the total volume of work they have to complete. And as the cost of completing each unit falls, that volume expands: customers process more work and deploy AI into workflows that were previously uneconomic to touch.

If SaaS is an annuity, outcome-based businesses are toll booths collecting revenue on every outcome that passes through. Every unit of work completed is its own small act of recommitment. The revenue grows when the customer’s business grows, when they trust the system with more processes, and when they run work through it that they never ran before.

These are not the same business.

The Value Creation Journey

The three assumptions above are not independent — they compound across a single customer relationship in a predictable sequence. Understanding that sequence is the prerequisite for understanding why the metrics are defined the way they are.

Every outcome-based customer relationship moves through four distinct stages. They are not arbitrary divisions. They map directly to how capital flows, how risk resolves, and how the economics of the relationship change over time.

[Figure 3 — The Four Stages of an Outcome-Based Customer Relationship. The curve drops linearly from contract signature to First Outcome as deployment costs accumulate, then climbs through Outcome Velocity as outcome revenue builds. It crosses zero at Deployment Payback and compounds into Margin Inflection territory.]

Stage 1 — First Outcome

First Outcome is the moment the AI produces its first measurable unit of work in production. A ticket resolved. A lead qualified. A document reviewed. This is proof of concept — the system works, it is producing something, and the customer can see it. It is also the psychological inflection point in the customer relationship. Every day between contract signature and first delivered work is foregone revenue against a fixed deployment investment, and customers who see value early expand early.

A note on the dominant selling motion in applied AI. The proof-of-concept-heavy approach that characterizes most early-stage AI deals is not a go-to-market decision or a sign of weak positioning. It is the structural reality of selling a non-deterministic system. A customer cannot be asked to commit at scale to a system whose outputs are probabilistic until they have seen it perform reliably in their own environment. The proof of concept is not a sales technique — it is the mechanism by which a vendor demonstrates that First Outcome is achievable in this customer’s specific context. Founders who feel defensive about POC-heavy pipeline should reframe: they are not stuck in proof-of-concept mode because their sales motion is immature. They are there because the product requires it.

Stage 2 — Outcome Velocity

Outcome Velocity is the repeatable phase. The system is producing its first outcome consistently — the customer is pushing more work through the same workflow, trust in the agentic process is building, and edge cases are being resolved in production. The goal of this stage is momentum. If the first outcome was proof, outcome velocity is signal.

This is the account-level equivalent of product-market fit: are customers choosing to run more work through the system, or are they waiting to see more before they commit? A deployment that stalls here — where a customer saw the system work once but never expanded volume — almost always traces back to the economics not being compelling enough to make expansion an obvious decision.

Stage 3 — Deployment Payback

Deployment Payback is the moment cumulative outcome revenue crosses the combined cost of acquiring the customer and deploying the system for them. Until this point, the vendor has spent more than they have recovered. Everything between contract signature and Deployment Payback is investment — in sales, in integration, in configuration, in getting a non-deterministic system to reliable production output in a new customer environment. Everything after it is return.

This is the milestone that will matter most as the category matures. In a capital-rich environment — as exists for many well-backed applied AI companies — it is easy to overlook. Deployment costs get absorbed, payback periods go unmeasured, and growth masks the underlying unit economics. But as these businesses scale, Deployment Payback will become the first evidence that a go-to-market motion is financially justified. The speed of the path from First Outcome to Deployment Payback is a direct signal of business model health — a steep, fast trajectory means outcome volume is ramping quickly relative to the cost it took to stand the system up. The founders who measure it now will be the ones who aren’t surprised later.

Stage 4 — Margin Inflection

Margin Inflection is everything beyond Deployment Payback. At this point, the integration is done, the system is calibrated, and the customer’s value from the AI is proven. Each additional unit of work completed from here flows directly to margin. There is no new customer acquisition cost. There is no new deployment cost. The compounding engine is running. This is the phase that makes outcome-based businesses structurally different from SaaS: there is no seat ceiling, no license cap, no negotiated renewal to survive. The only constraint on revenue growth is the volume of work the customer has to complete.

The New Cost Structure

These four stages play out against a cost structure that looks fundamentally different from SaaS.

Deployment cost is no longer separable from the path to revenue. In product-led and mid-market SaaS, deployment was largely the customer’s responsibility — light onboarding, self-serve setup, a few hours of training. In enterprise SaaS, deployment was substantial but billed separately, classified as non-recurring revenue, and structurally kept off the ARR line. Investors applied lower multiples to services revenue than to subscriptions, so vendors had every incentive to minimize it as a reported category. Either way, deployment cost was separated from the metric that mattered. It was friction to minimize, not investment to optimize.

In outcome-based models, that separation disappears entirely. Deployment is not peripheral — it is the precondition for revenue, because vendors only start earning when the system is producing work.

The table below captures how this and other structural differences flow through every major operating dimension:

The Metrics

The seven metrics below apply to businesses that price on the work their AI completes. That work spans a wide range — from a discrete action taken on a customer’s behalf, like a support deflection, to a complex outcome produced by a sequence of actions, like an originated loan. Some businesses price on the action. Others price on the outcome. Many will price on both as their product matures. The metrics apply across that spectrum.

Metric 1: Cost of Deployment (COD)

Cost of Deployment is the total spend from contract signature to the first measurable unit of AI work delivered. It is the price of turning a probabilistic system into a reliable one.

COD matters because it must be recovered before a customer becomes profitable. In SaaS, the cost of acquiring a customer was the primary threshold to clear. In outcome-based businesses, there are two: the cost of winning the customer, and the cost of deploying the system for them. Both must be recovered from outcome revenue. Until they are, the vendor is underwater.

We recommend tracking COD at the customer level, not as a blended average. A digitally native customer with clean APIs might carry a COD in the low five figures. A regulated enterprise navigating legacy systems and multi-step compliance workflows might carry a COD of $100,000 or more. Blending those two obscures the economics of both.

Metric 2: Time to First Outcome (TTFO)

Time to First Outcome measures the number of days from contract signature to the delivery of the first measurable AI work unit in production. Every day of delay is foregone revenue against a fixed deployment cost.

TTFO has one meaningful advantage over time to value as SaaS understood it: it is binary. In SaaS, value was subjective — when had the customer truly gotten value from the software? The answer depended on who you asked, what they prioritized, and how the story was framed at renewal time. TTFO has none of that ambiguity. The ticket was resolved or it wasn’t. The loan was originated or it wasn’t. This binary quality elevates time-to-value from a soft narrative construct into a hard operational number that can be tracked, compared across deployments, and improved systematically.

We recommend treating TTFO as the single most important operational metric in the first 90 days of any customer relationship. Customers who reach First Outcome quickly gain confidence fast and expand early. Customers who wait months tend to second-guess the investment before they have seen it pay off. In Genera’s work supporting AI-native deployments, the best-performing companies are consistently reaching First Outcome in under 14 days.

Metric 3: Outcome Cost Efficiency (OCE)

Outcome Cost Efficiency is a new metric — one that has no direct analog in the SaaS era. It measures how many dollars of human labor value a customer receives for every dollar they spend on AI-completed work, and it is a primary predictor of both retention and expansion.

A customer paying $8 per AI-resolved ticket, replacing work that costs $25 per human-resolved ticket, has an OCE of 3.1x. They receive $3.10 of labor value for every $1.00 they pay. When this ratio is high, customers have a structural economic incentive to expand. When it is low, they do not — regardless of how satisfied they are with the product.

We recommend using fully-loaded labor cost, not base salary. A $55K support agent costs closer to $90K when you account for benefits, management overhead, real estate, training, and turnover. Using base salary understates OCE and misreads the expansion signal.

OCE may also prove to be the leading indicator of churn — ahead of satisfaction scores, ahead of NPS. A customer whose OCE has compressed below 1.5x may simply not be saving enough money to justify the relationship, regardless of how they feel about the product. A customer with an OCE above 3x who encounters friction is likely to stay anyway — because leaving means replacing cheap AI-completed work with expensive human labor. If that hypothesis holds, it inverts the entire logic of how post-sale teams prioritize accounts.

Two open questions this framework does not yet resolve. First, how OCE behaves in labor-constrained markets, where the relevant comparison is not cost but availability — the alternative to the AI is not a cheaper human, but no one at all. Second, whether competitive pricing pressure will compress OCE over time as vendors compete for the same workflows.

Metric 4: Gross Margin Per Outcome (GMO)

Gross Margin Per Outcome measures the profit on each individual unit of work completed. It is the unit-level margin metric for outcome-based businesses.

GMO has one structural property worth understanding: inference and token costs — a significant component of the cost of goods — have been falling rapidly, declining roughly 10x per year over the past two years. Falling compute costs are not new. Moore’s law has been compressing hardware costs for decades, and SaaS companies benefited from cheaper hosting and storage throughout their history. What is different is where compute sits in the cost structure. In SaaS, compute was a small fraction of COGS — people costs dominated. Falling hardware costs were a background benefit that improved company margins gradually over years. In outcome-based businesses, inference is a direct input to every unit of work delivered. When a significant cost component is falling at this rate, the margin impact is immediate and visible at the unit level — not buried in a blended P&L.

Whether this deflation continues at its current pace, slows, or reverses for frontier-class models is an open question. What is observable today is that the direction of the cost curve favors GMO expansion for businesses running on commodity inference. Businesses whose outcomes require the most capable models may face a different trajectory entirely.

At current pricing, an AI support agent at $8 per resolved ticket with $1.40 in total cost of goods produces a gross margin of 82.5%.

We recommend measuring GMO at the unit level, not as a blended company margin. Blended margins incorporate human oversight ratios, escalation costs, and managed service layers at varying stages of deployment maturity — they are a lagging indicator of fleet-wide deployment health. GMO measures the margin on a single completed work unit, which is what governs deployment economics.

Metric 5: Two-Sided Payback Period (2PP)

In SaaS, the payback period measured one thing: how long it took the vendor to recover the cost of acquiring a customer. In outcome-based businesses, the customer’s payback period is equally critical — because it is the primary driver of expansion velocity, and expansion is the growth engine.

When the vendor absorbs the full deployment cost, the customer’s payback approaches zero — positive ROI from the first unit of work delivered. This is a powerful expansion accelerant but concentrates all of the deployment risk on the vendor side.

We recommend tracking both sides explicitly and treating the slower of the two as the binding constraint on expansion velocity. A vendor recovering costs quickly while the customer sees weak ROI produces a stalled account. A customer seeing enormous value while the vendor bleeds through a long payback produces growth that can’t sustain itself. The flywheel only fires when both sides are short.

[Figure 5 — The Two-Sided Payback Matrix. The growth flywheel only fires when both vendor and customer payback periods are short.]

Metric 6: Process Penetration Rate (PPR)

Process Penetration Rate measures the percentage of a customer’s addressable AI workflows that are currently deployed. It is the metric that tracks progress from first outcome toward the theoretical ceiling of what an account can become.

Every account has a terminal value — the point at which all addressable work is running through the system and process expansion is exhausted. Where that ceiling sits is ambiguous. The world does not know yet, in the same way that even the best investors underestimated the size of the market Uber would create. But getting a handle on what that terminal point could be — and ensuring the organization is working toward it — is precisely where the post-sale motion earns its keep.

We recommend defining the denominator against the customer’s current human-staffed workflows — the processes they are already running with people. This is a conservative baseline and an honest one. The true addressable surface is likely larger: as the cost of completing each unit of work falls, customers deploy AI into workflows that were previously uneconomic to touch. Current labor volume is a floor on demand, not a ceiling. PPR against current labor gives operators a measurable, defensible denominator today. PPR against total addressable workflow — including latent, unlocked demand — is the number that will matter as the category matures.

Metric 7: Net Revenue Retention — Reframed

Every operator and investor reading this paper already tracks Net Revenue Retention. In outcome-based businesses, the formula doesn’t change. But three things about how NRR behaves will mislead you if you read it the way you’ve always read it.

First, the shape is wrong. SaaS NRR compounds relatively linearly from month one. Outcome-based NRR J-curves. It looks weak in the first 60–90 days because of the deployment ramp — the system is being made production-safe, edge cases are being resolved, and outcome volume hasn’t reached steady state. Then it accelerates sharply as process economics compound. A founder who sees 80% NRR in month three and panics is misreading a healthy deployment. An investor who sees 200% NRR in month twelve and assumes it will sustain at that rate may be looking at a one-time process expansion that won’t repeat. The early dip is not a warning sign. It is the expected shape. The question is not whether the curve dips — it will — but how steep the acceleration is once it turns.

Second, the ceiling is wrong. The best SaaS businesses achieved NRR of 130–140%. Outcome-based businesses are already reporting NRR above 200% — a figure that would be structurally impossible in most seat-based SaaS, where expansion was bounded by headcount and a finite product catalog. Every NRR benchmark the industry has built was calibrated to a model with a ceiling. That ceiling no longer exists. Comparing your NRR to SaaS benchmarks tells you nothing.

Third, the exposure is different. Outcome volume is coupled to the health of the customer’s underlying business in a way seat-based revenue never was. A customer processing fewer transactions in a downturn will produce lower outcome revenue — for reasons entirely outside the vendor’s control. SaaS NRR was insulated from this. Outcome-based NRR is not. The same mechanism that creates that downside sensitivity also produces the uncapped upside. The risk and the opportunity are the same feature.

We recommend decomposing NRR into its two expansion components rather than reporting a single blended number. Volume growth within deployed processes and new process deployments have very different economics. A rising NRR driven entirely by volume growth within existing processes has fundamentally different operational implications than one driven by new process expansion — and blending them obscures whether the growth is automatic or requires active forward deployed investment.

How to Use These Metrics

The outcome-based dashboard has seven core metrics. Each is a diagnostic for a specific failure mode. Together they give a complete picture of deployment health, unit economics, and expansion trajectory.

For operators standing up this infrastructure for the first time: start with COD and TTFO. They govern the deployment phase, they're the easiest to instrument — COD is an accounting exercise, TTFO is a date — and nothing else you measure will mean anything until you know both. Add OCE once you have outcomes in production. Layer in GMO, 2PP, and PPR as volume matures. Track NRR from day one, but read it differently.

On the Limits of This Framework

Every framework is wrong in some ways. This one treats all outcomes as equivalent — a resolved support ticket and an originated mortgage carry very different economics. The thinking is anchored primarily in support, customer experience, and early sales automation — other verticals will develop their own patterns. And it does not yet capture the value of the proprietary data and workflow-specific fine-tuning that outcome-based businesses accumulate over time.

This is Version 1.0. The goal is to give operators, founders, and investors a shared language. The rest will be built in practice, by the people building at the frontier.

Acknowledgements

David Skok’s SaaS Metrics 2.0 at Matrix Partners is the direct inspiration and intellectual foundation for this work. The conversation between Bret Taylor (Sierra) and John Collison (Stripe) on the Cheeky Pint podcast provided critical grounding for the outcome-based pricing framework. The Palantir FDSE role description (”A Day in the Life of a Palantir Forward Deployed Software Engineer,” 2020) provided the clearest articulation of the product-building FDE archetype. The forward deployed job posting data is sourced from Bloomberry, “What I learned analyzing 1K forward deployed engineer jobs,” 2025.

The thinking here has been shaped by ongoing conversations with founders navigating these dynamics in production — including the teams at Loamy, 1mind, and especially Genera. Michael Edelstein, Cassie Young, Michael Boyd and Junan Pang provided early feedback that strengthened the framework materially. Many Customer Success leaders across the SuccessVP LP base were generous with their time, their pushback, and their operational insights — thank you! All errors are the authors’ own.

Customer Success exists to cover the gaps. Change the gaps, and you change Customer Success. It is not a fixed function—that’s why there are so many different definitions of what the role actually is.

It expands and contracts based on three variables: product complexity, customer sophistication, and how value is exchanged. As those variables increase or decrease, the shape of the organization you need shifts with them.

The more complex the product, the harder value is to prove, and the less sophisticated the customer, the more Customer Success you need.

Almost every role that sits under a CCO exists to solve one of these three problems. That’s the wrapper.

For as many types of companies as there are, there are Customer Success organizations shaped to match them.

Salesforce—with its historically difficult implementations, multi-product offering, wide range of customer sophistication, and two decades of per-seat pricing creating renewal friction—is one of the companies that defined Customer Success as we know it. It reflects nearly every dynamic in this framework: heavy product complexity, broad customer sophistication gaps, and misaligned value exchange. The result historically is a full-stack CS organization spanning professional services, implementation, CSMs, and renewal and account management roles.

Snowflake, whose commercial model is usage-based, ties cost directly to consumption. This reduces the need for a traditional CSM motion to sell value at renewal. Instead, the primary gap shifts toward product complexity. Getting customers to the point where they can become heavy consumers of the product depends on data integration, modeling, and query design—creating a meaningful, often front-loaded deployment effort and a more technically oriented services motion.

Stripe, with an API-first product, a technically adept developer buyer who self-serves, and a pricing model that expands with usage, compresses all three gaps. Product complexity is simplified, customer sophistication is high, and value exchange is tightly aligned with usage. The result is a relatively lean Customer Success motion, with more of the value realized through the product itself.

Customer Success in an AI World

This same framework is useful for understanding how Customer Success evolves in an AI world.

The most important shift is happening at the application layer—applied AI companies building on top of foundation models, much like SaaS was built on top of the cloud. Here, we begin to see a different shape emerge. AI starts to close some of the traditional wrapper gaps while simultaneously creating new, more acute ones.

Start with what’s collapsing. Products are getting easier to build and customize. Coding tools, copilots, and chat-based interfaces allow companies to simplify complexity and enable customers to do more on their own. This compresses parts of the product complexity gap and chips away at customer sophistication constraints.

At the same time, pricing is shifting. Many companies are moving toward consumption or outcome-based models, often reflecting the amount of work completed and, in some cases, underlying model or token costs. As pricing becomes more closely aligned with usage and actual work completed outcomes, the exchange of value is tighter, more transparent and reduces the need to “sell the story” at renewal since the value exchange is on going.

But as these gaps close, a new one opens.

AI systems don’t just need to be adopted—they need to be configured. The quality of the output is heavily dependent on context. These systems are non-deterministic and require the right data, the right workflow, and the right constraints. Getting to that state is often non-trivial, and in many cases customers can’t run a meaningful pilot without deep context gathering and careful setup.

This is a different kind of complexity. It’s not about learning the product or integrations—it’s about making the system actually work. At its core, this is a blend of engineering, professional services, and change management. Getting these systems to work requires integrating data, shaping workflows, aligning stakeholders, and changing how work gets done inside the organization.

That shift moves Customer Success closer to deployment. The work becomes structuring data, tuning outputs, and iterating in production. The role, especially with enterprise customers, becomes more technical, more embedded, and more product-adjacent. It’s this shift that is driving the widespread adoption of forward-deployed Customer Success.

What’s exciting about this is simple:

Deployment becomes revenue.

In an AI world, customers aren’t buying software—they’re buying outcomes. That changes the motion entirely. Many of these deals start as pilots, but a pilot is misleading. To generate a meaningful result, you have to deploy the system end-to-end: integrate the data, configure the workflows, and get the model producing real work.

One founder I recently spoke with described it as two sales:

1. Winning the pilot

2. Getting the system to produce enough real work to justify the cost of deployment

The second is where the value is realized—and where revenue is actually earned.

If you get there, the upside is enormous. In a usage- or outcome-based model, once the system is working, expansion happens naturally. More work flows through the system, and revenue scales with it—often non-linearly.

If you don’t, you lose everything: the deployment cost, the forward-deployed investment, and often the customer itself.

That’s exactly where Customer Success moves.

We’re already seeing it. Founders aren’t looking for traditional CSMs—they’re looking for people who can deploy, configure, and own outcomes. People who can sit inside the customer’s workflow and make the system work.

They can’t hire them fast enough.

This is the opportunity for Customer Success. The role doesn’t shrink—it moves closer to revenue, becomes more technical, and becomes directly responsible for outcomes.

— JG

Fun story:

Years ago, I was the first hire at a startup. I did every job in the company, and eventually the founders asked me to run Customer Success—which I was less than thrilled about. At the time, it didn’t even sound like a real job title.

So I set out to learn everything I could. My friend Harry Stebbings was just getting started with his podcast at 17, and he interviewed my now friend, Nick Mehta. Nick shared advice his father had given him: in software, you either “build the product” or “sell the product.” His argument was that Customer Success is the new sales because it ultimately owns the most revenue in a recurring revenue business. That was enough to convince me.

In the end, I’m not sure that fully played out. Growth is king in the startup world. Recurring revenue matters—it creates the foundation—but growth is what ultimately drives valuation.

And that’s what makes this moment so interesting. For the first time, Customer Success isn’t just supporting growth—it’s becoming one of the primary drivers of it.

Most of the conversation around AI in Customer Success is about tools — summaries, ticket drafts, automated notes. These improvements are real. But they assume the underlying model stays the same. It isn’t. The SaaS model that created Customer Success is under structural pressure, and the teams built on top of it are next.

The Model Break

Customer Success was born inside seat-based SaaS. Multi-tenant architectures meant that software was standardized by design — one company’s Salesforce instance looked a lot like another’s. That standardization made adoption the proxy for value.

More users → more productivity → renewal.

The CSM translated product usage into an ROI narrative.

That assumption — that software needs humans to extract value from it — is what’s breaking.

The CSM role grew 736% between 2015 and 2019, becoming the fastest-growing job title in enterprise software. That growth was real and justified. It was also entirely dependent on a model where the software was a tool, not an agent.

AI-native software changes the equation. The system doesn’t need a champion. It needs a configuration.

The Loop Is Closing

Copilots still follow the SaaS playbook — the professional stays in the loop, the tool makes them faster, the CSM relationship holds. That model works, and will keep working where human judgment is the rate-limiting step.

But the line is moving. As models improve, judgment gets absorbed into the system. The professional moves from producing outputs to reviewing them, then approving them — until the question becomes whether they need to be in the loop at all. That transition is already underway in the most intelligence-heavy categories. Fin, Maven AGI, Decagon, and Sierra are resolving support tickets end-to-end.

These are the companies where the Forward-Deployed Engineer emerged fastest — not as a rebranded CSM, but as a role built for software that does enough of the work that the old CS motion stops making sense. As autopilots expand, that role rises. Understanding a business deeply enough to configure an AI system for real outcomes is consultant-level judgment work. The CSM motion runs in the opposite direction: the productivity narrative that justified it loses its footing as software stops needing a human to demonstrate its value. What replaces it isn’t a productivity story — it’s a simpler, harder conversation: did the system produce the outcome, and what does it take on next.¹

Outcome-Native

The quality of an AI system’s output is largely a function of how well it was configured. A team running Fin isn’t measured on ticket volume or login rates — they’re measured on resolution rate and customer satisfaction. The outcome was determined at configuration, before most customers ever touched the product.

That shifts the critical work earlier. Onboarding stops being enablement and becomes value creation. QBRs measured usage. Health scores tracked logins. None of that survives a system that either produced the outcome or it didn’t.

The CS team that wins isn’t the one that drives adoption. It’s the one that engineers the outcome from day one.

Where the Effort Goes

In SaaS, CS effort concentrated after the sale — ongoing coverage, renewal management, expansion plays. AI systems invert that. The critical work happens at deployment: configuration, workflow design, systems integration.

Post-deployment, the question is no longer whether customers are engaged — it’s whether the system is performing. That’s a technical problem, not a relationship one. Different skills, different metrics, different structure.

Organizations that have figured this out are already restaffing. The CSM-heavy model is giving way to teams weighted toward deployment engineers and technical operators. The work has changed and the org chart reflects it.

The Structural Read

What’s happening in Customer Success isn’t a tooling upgrade. It’s a change in where value is created.

Two shifts are happening simultaneously, and most CS leaders are tracking only one. The software model is shifting — from seats to outcomes, from renewal probability to output verification. And the team structure is shifting with it — not just more productivity per head, but different heads doing fundamentally different work.

Optimizing your existing CS team with AI tools addresses neither. It makes a fading motion faster.

The CS leaders who will win are asking a different question: what does this team look like when the software closes the loop itself? The ones who answer that question now — and staff toward it — won’t be caught flat-footed when the rest of the market catches up.

¹ I’ve written more about the different types of forward-deployed work and what they signal here: Forward-Deployed Engineering and the Hard Problem of AI-Native Teams

Special thank you to sponsors Planhat, Sonora and SuccessVP 🍕

There’s a lot of talk right now about how fast Customer Success is scaling. In reality, it’s not just CS—it’s every function in tech. The pace is relentless. And when everything is moving that quickly, the hardest question becomes: Where should I focus?

In moments like this, community becomes a competitive advantage.

When I first moved to San Francisco, the company I joined was growing at what felt like AI-era speed—before AI was the story. In my first nine months, we went from $1M to $60M in ARR. It was exhilarating and overwhelming at the same time. I felt constant pressure to make sure my learning curve matched the company’s growth curve.

I’ve always consumed a lot of content—blogs, podcasts, frameworks. But reading alone can distort your perspective. Online, it can feel like everyone else has it figured out. In real conversations, you learn the truth: nobody has it fully figured out. Most people are adapting in real time. They just don’t post about the uncertainty.

That realization changed everything for me.

Meeting Junan Pang was a turning point. He had started working on a small Customer Success Meetup, and together we began building it out. From the beginning, our goal was simple: real operators sharing real experiences during real periods of hypergrowth. No posturing. No polished hindsight. Just what was actually happening.

Our first meetup had more pizzas than people. We laugh about that now. But even then, something clicked. The conversations were honest. People felt less alone. They kept coming back.

Over time, the community grew beyond what we could host in a single room. A few years ago, we took a leap and hosted our largest event yet in New York. More than 1000 people showed up. It wasn’t just a meetup anymore—it was proof that community scales because people need it. (Mark you calendar for ‘26 Customer Success Week, Oct. 6, 2026)

That’s the lesson. In periods of rapid change, your edge isn’t just better tools or better tactics. It’s proximity to other builders who are in the arena with you.

Our first gathering of the year is coming up, and we can’t wait to see you in San Francisco. We’ll also be hosting events this year in New York and Boston.

If you’re navigating growth—personally or organizationally—come be in the room.

– JG

One of the clearest signals of this shift is Forward Deployed Engineering. FDE has moved quickly from niche to mainstream. As adoption has spread, however, the definition has fractured. Today, the same label describes meaningfully different roles across companies, and those differences matter.

One of the clearest signals of this shift is Forward Deployed Engineering. FDE has moved quickly from niche to mainstream. As adoption has spread, however, the definition has fractured. Today, the same label describes meaningfully different roles across companies, and those differences matter.

In practice, two archetypes are forming, not as a binary but as ends of a spectrum.

• The “E” in FDE (Engineering-led): This model emphasizes engineering ownership and product evolution at scale. Forward-deployed engineers build production-grade solutions for the company’s largest customers, influence the roadmap, and help determine what should become core product versus bespoke work. The role looks and feels like senior product engineering, with customer proximity as a forcing function rather than the end goal. Ramp’s Senior Forward Deployed Engineer role is a clear example of this orientation, explicitly positioning FDEs as engineers who scope, design, and implement solutions that shape the platform itself.

→ Ramp JD: https://engineering.ramp.com/post/forward-deployed-engineering

• The “D” in FDE (Deployment-led): This model emphasizes deployment, interpretation, and business impact. Forward-deployed engineers embed deeply with strategic customers to understand their operating context, translate intent into working systems, and drive real outcomes in production. The center of gravity is not feature delivery but problem discovery, configuration, and time-to-value. Intercom’s Senior Deployed Engineer role reflects this clearly, framing the work around customer embedding, solution design with customers, and codifying learnings back into the organization rather than owning core feature development.

→ Intercom JD: https://job-boards.greenhouse.io/intercom/jobs/6697033

Most AI-native companies draw from both of these archetypes, but few treat them as interchangeable. Both roles are deeply technical. Both work closely with customers. What differs is where leverage is applied: extending the product versus interpreting the customer, shaping the roadmap versus shaping how the product is deployed in the real world.

The key decision is not where a company sits on a spectrum, but which archetype it is intentionally optimizing around. That choice has real consequences for hiring profiles, incentives, and how learning flows back into the product.

What’s often underestimated is that FDE is not a localized post-sales decision. It changes the organization around it.

When forward-deployed teams work directly with customers, expectations can shift quickly. Reliability matters sooner. Edge cases surface earlier. In the best implementations, this raises the implicit quality bar for new features across the company.

But the inverse is also true. If forward-deployed work becomes a permanent shim—absorbing product gaps without feeding learning back into the roadmap—the quality bar can quietly fall. The same mechanism that accelerates learning can just as easily mask structural weaknesses.

Teams that succeed here invest heavily in cross-functional alignment. Product, engineering, and customer-facing teams need shared clarity on what is experimental versus durable. Without that coordination, FDE can fragment the customer experience instead of improving it.

Beyond FDE itself, AI-native companies are redefining what excellence in post-sales looks like. The strongest operators no longer resemble traditional CSMs. They look like hybrids: part product manager, part systems designer, part operator. Technical fluency, product intuition, and business understanding are now table stakes.

This shift is also widening the gap in customer experience. Strategic accounts receive deep technical engagement and forward-deployed support. Smaller customers are often expected to self-serve, even when they struggle to translate their needs into AI-native workflows. Closing this gap without turning the business into a services organization is one of the defining challenges ahead.

Why this matters?

AI-native software is fundamentally less opinionated than traditional SaaS.

Classic SaaS products are multi-tenant by design. While customers differ, the product experience is largely the same across accounts. Most configuration happens around data integrations, permissions, and dashboards. Outcomes may vary, but the path to value is relatively standardized.

AI-native software is different. These products are often general-purpose systems that only become valuable once they deeply understand a customer’s business, data, and operating model. Two customers using the same AI product may pursue entirely different outcomes, with very different definitions of success. The core work is no longer configuration. It is interpretation.

That shift moves the burden of sense-making out of the product and into the organization. Someone has to understand the business, shape the problem, translate it into the system, and continuously refine it as the model learns. That work cannot be fully abstracted away by software alone.

This is why team structure matters so much. Forward-deployed roles, hybrid post-sales operators, and tight product feedback loops are not organizational luxuries. They are the mechanism by which less opinionated AI systems become useful at scale.

Companies that get this right will scale outcomes, not just usage. They will shorten time-to-value across a broader customer base and compound learning back into the product faster than competitors. Companies that don’t will look successful on the surface, with strong demos and impressive logos, but struggle to turn flexible AI systems into durable, repeatable value.

In an AI-first world, org design is strategy. The structure of your post-sales team is no longer a support decision. It is a core determinant of whether your product actually works in the real world.

—

This week’s post on incentives in Customer Success in an AI-native world struck a nerve. That was intentional.

I wrote it as a cliff hanger because the truth is: we don’t actually know yet what the modern Customer Success role looks like—let alone how it should be staffed, comped, or modeled in a P&L when AI is doing more of the “work” and humans are increasingly forward-deployed to prove outcomes.

And that’s the point.

We’re in the middle of a transition from buying software to hiring software. That shift is breaking old GTM assumptions:

Where Customer Success sits. What counts as sales vs. R&D. How many people you need—and what success even means.

My friend CJ Gustafson, who writes the excellent Mostly Metrics newsletter, just published a piece called “How AI Is Changing GTM Org Structures — And WTF Does ‘Forward Deployed’ Mean?” and, more importantly, launched a short survey to help us all answer the real questions operators are wrestling with right now:

• How should Customer Success be paid?

• Where should it live on the P&L?

• What ratios still matter—and which ones are obsolete?

• How big should these teams actually be in an AI-native world?

Rather than pretending we already have the answers, CJ did the advice I give founders most often: he asked the market!

If you work in Customer Success, finance, GTM, or leadership—and especially if you’re feeling the tension between old SaaS playbooks and what’s actually happening on the ground—I’d strongly encourage you to take this survey. It’s quick, anonymous, and CJ will publish the results later this month.

👉 Take the Mostly Metrics Customer Success Survey here:

https://mostlymetrics.typeform.com/to/LXSdtTOS

And if you’re not already subscribed to Mostly Metrics, you should be. CJ consistently does one of the best jobs out there translating messy, first-principles GTM shifts into clear operator thinking.

We’re all trying to figure this out in real time. This is one of the better ways to do it—together.

They determine how work actually gets done, where tension accumulates inside the organization, and—most importantly—whether you can correctly diagnose what’s broken when growth stalls.

If incentives are wrong, every signal you think you’re reading is noisy.

The Mistake Most Teams Make

Most early teams design compensation defensively.

• What can we afford?

• How do we keep burn down?

• What’s market?

These are reasonable questions—but they’re the wrong starting point.

The right starting point is much simpler and much harder:

What behavior must exist for this business to work right now?

Until you answer that, the spreadsheet is fiction.

Growth Roles Should Feel Like Growth Roles

If a role is truly responsible for growth—new revenue, expansion, conversion—then compensation needs to feel like growth.

Once base salaries creep high enough, something subtle but fatal happens:

• There’s no real consequence for missing

• There’s no real pull toward winning

• The role becomes operational, not kinetic

You don’t need people living on ramen. But if someone can completely miss their number and still feel comfortable, you’ve removed the tension that makes growth roles work.

That tension isn’t cruelty. It’s alignment. And alignment is non-negotiable if you want to build something real. Sales leaders have long understood this. Customer Success, historically, has been structured differently—broader mandates, more defensive scope, and a much smaller variable component. That made sense for a long time. But the role of CS is changing—and compensation has to change with it.

Variable Pay Isn’t Protection — It’s Signal

Founders often get this backward.

Variable pay isn’t about protecting the company.

It’s about protecting the signal.

When upside is large and obvious:

• If performance is strong, everyone wins

• If performance is weak, you immediately know it’s not because incentives were misaligned

That clarity is priceless.

Under-incentivize, and when growth slows you’re left guessing:

• Is it the product?

• Is it the market?

• Is it the person?

Or, did we simply fail to motivate correctly?

This is why I err on the side of generosity. A generous incentive plan eliminates an entire category of excuses—and excuses are incredibly expensive.

Why This Matters Right Now for Customer Success

AI-native companies have fundamentally changed how software is priced, packaged, and sold.

• Consumption-based pricing.

• Outcome-based pricing.

• Paid pilots.

• Trials.

• Fast implementations.

And in many cases, the product doesn’t even work without a human doing the heavy lifting during setup.

The sale is no longer the moment of growth—it’s a sales stage that grants permission to prove value. Increasingly, that value is proven not by sellers, but by forward-deployed Customer Success teams. I’ve heard of organizations that have more FDCS people than sellers. In the old world, you might have one sales engineer for every eight AEs. In today’s AI-native world, the way deals are supported has inverted.

Customer Success is no longer a downstream function. It now sits directly inside the revenue engine.

The more customers use the product, the more value they experience. The more value they experience, the more they pay. That flywheel doesn’t start at renewal—it starts immediately after the first yes. The fastest-growing teams are winning because they’re the most helpful.

This shift has elevated Customer Success from “retention insurance” to growth infrastructure—and most compensation plans haven’t caught up.

Where Things Break

Here’s where it gets dangerous.

I’m intentionally avoiding titles, because we haven’t settled on what they are in the modern GTM model. What I do know is this; When one person sources the opportunity, and another converts it into real revenue.

Credit becomes radioactive.

This tension has always existed between Sales and Customer Success—but AI-native speed compresses the cycle and amplifies the conflict.

If the person who sourced the deal can see meaningful dollars on the other side of conversion, every handoff feels like an attack on the rep’s personal bottom line.

This is how resentment forms:

• “I did the hard part.”

• “They’re getting paid for my work.”

• “Why am I capped when they’re not?”

This isn’t a people problem. Most people are rational. It’s an incentive design problem.

Sometimes You Should Double-Pay (On Purpose)

Here’s my unpopular but practical take:

Early on, it’s often better to overpay than to under-incentivize.

Yes—sometimes that means paying two people on the same revenue. It feels inefficient. It is inefficient. But it buys you something far more valuable than efficiency:

Certainty.

• If growth happens, you know product–market fit is there.

• If growth doesn’t happen, you know incentives weren’t the blocker.

You can clean this up later—and you will. But you only earn the right to fine-tune incentives if you have crystal-clear signal on PMF. The failure mode to avoid is realizing too late that incentive misalignment, not product execution, was what actually held you back.

At the end of the day, your job as a founder—or as someone who reports to a founder—is simple: make sure you’re building a product customers actually need.

Metrics Don’t Create Ownership — Control Does

Many teams tie Customer Success compensation to outcomes individuals don’t fully control:

• Retention

• Net dollar expansion

• Long-term usage

These metrics truly matter—but they’re often downstream of product quality, roadmap sequencing, and timing.

People are most motivated when:

• They can directly influence the outcome

• The reward is close in time to the action

• The rules are simple and obvious

If someone feels judged on forces outside their control, motivation decays—even if the metric is philosophically correct.

This is where many CS comp plans quietly fail.

The Real Question Incentives Should Answer

Incentives aren’t about motivation. They’re about truth.

They exist to tell you whether the product works—or whether you’re lying to yourself about why it doesn’t.

If the business fails, it should fail with clarity. Anything else is self-deception.

Reading the filing was a moment of reflection. Motive is a company I joined very early and helped build during some of the most meaningful years of my career. Seeing that chapter enter the public record carries real weight. It marks a long journey—of people, customers, and products—that shaped both the company and me.

Several thoughtful writers have already unpacked the filing. They’ve covered the market opportunity, the competitive dynamics, the financial profile, and the complexity of building a large hardware-plus-software business. All of that context matters. But buried in the middle of the S-1 is the metric that stood out to me most—and the one I’m most proud of from my time there.

Net Dollar Retention.

You see it most clearly in the enterprise cohort. Large customers are retaining and expanding at 126%, revenue per customer continues to rise, and the business has shifted toward larger, more complex relationships. It’s the outcome of how deeply the product is embedded in customers’ operations.

What’s often misunderstood about a number like NDR is where it actually comes from. It’s tempting to think of it as a Customer Success output—something driven by renewal motions, playbooks, or process. Execution certainly matters. But sustained net dollar retention is ultimately a reflection of whether customers continue to find new and meaningful value in the product itself. Without that, NDR is one of the hardest numbers in SaaS to influence.

At Motive, Customer Success became more than a department—it became a core learning input. From the beginning, founder and CEO Shoaib Makani invested heavily in support, onboarding, professional services, and sales engineering—not to “handle customers,” but to understand them. Time-to-value mattered, but time-to-understanding mattered just as much. Proximity to customers created signal, and that signal informed strong product decisions over time.

That dynamic showed up clearly in the people. Many of the strongest CSMs and onboarding professionals I led went on to productive careers in product. That wasn’t a formal pathway, but it was telling. When teams spend their days inside real customer workflows, they develop instincts that translate naturally into product thinking.

Those instincts didn’t just shape careers—they shaped the product itself.

Motive didn’t start upmarket. It started at the very bottom. A free hours-of-service tracking app designed to make drivers’ lives easier. It worked, and because it worked, it spread. That early product earned trust and distribution. When regulatory requirements changed, Motive was already embedded in the workflow, and the company expanded into broader fleet management from there.

Over time, the product surface expanded across driver safety, equipment monitoring, fleet and workforce workflows, and spend management, with AI increasingly embedded throughout. As with any long product journey, some bets proved stronger than others. What mattered was that those bets were grounded in real customer exposure—understanding how customers actually ran their businesses shaped what got built next.

That context shaped how I approached the Customer Success motion. It was less about defense and more about enablement—helping customers fully use what they already had, then identifying where additional capabilities could support their operations more effectively. As products matured, those conversations became more strategic and less reactive, grounded in a shared understanding of the customer’s business. In many cases, our strongest CSMs and sales partners became true extensions of the customers they supported.

I led that motion from single-digit ARR into the hundreds of millions in ARR. While short-term playbooks and execution mattered along the way, the durability of the model came from continually deepening customer understanding. That understanding compounded over time, and the product evolved alongside it.

The Operating Lesson from Motive

For founders

• Treat Customer Success as a learning system, not a downstream function.

• Invest early in customer-facing teams not for efficiency, but for signal.

• Net dollar retention isn’t optimized late—it’s earned slowly.

For Customer Success leaders

• Your leverage comes from proximity to customer reality.

• The most impactful CS leaders develop product intuition.

• Strong products shift CS from defense to enablement.

That dynamic only works when it’s modeled from the top. One of the defining traits of Motive’s journey has been the founder mindset that enabled this learning loop. Shoaib Makani is a disciplined product builder with a clear view of where insight comes from. The consistent investment in customer-facing teams reflected a belief that durable products are built by listening carefully and often.

When Customer Success functions as a source of understanding rather than a cost center, something powerful happens. Retention becomes a byproduct. Expansion becomes more natural. And metrics like net dollar retention emerge as signals of product relevance rather than goals in themselves.

That’s what this S-1 represents to me—not a prediction or an endpoint, but a visible snapshot of years spent learning from customers and translating that learning into product.

I’m grateful for the time I spent at Motive, proud of the teams who continue to build there, and appreciative of the customers who helped shape the journey.

— JG

* These reflections are based on my personal experience and publicly available information and should not be read as investment advice.

Over the past two years, experimental AI revenue has flooded P&Ls, inflated valuations, and made for spectacular headlines. But underneath the gloss, something more fragile has been forming — what my friend Cassie Young calls the “Gross Retention Apocalypse.”

We’re living in a churn bubble, and it’s about to pop. And when it does, it will expose a hard truth: many companies haven’t built enduring value, they’ve built experiments with impressive demos and short half-lives.

And yet, every reckoning carries renewal. The very forces that expose weakness in this cycle will create the next generation of durable growth. That’s why this coming reset — painful as it may be — is also the moment that will give rise to a Customer Success renaissance.

The Real AI Shakeout

AI has accelerated innovation, no doubt. But it’s also compressed learning cycles and eliminated excuses. Products now ship faster, get adopted faster, and — when they don’t deliver value — get abandoned faster. The time between hype and disappointment has collapsed.

This is why Customer Success is more important than ever. Not only as a department, but as a discipline of truth. AI-native growth will soon expose which start-ups genuinely understand their customers — and which are just guessing.

Why I’ve Stayed Patient

So if Customer Success is so important, then why have I invested in so few Customer Success companies? I mean, I run a fund called Success Venture Partners — I’m clearly long on the function.

The reason is simple: enduring value always starts with the product. Without it, Customer Success becomes triage. With it, Customer Success becomes transformation.

If the product doesn’t deliver real outcomes, Customer Success becomes a bandage, a function compensating for what the product should have solved. But here’s what’s new: AI is changing that equation. We’re entering an era where products can deliver value with a level of precision and ease we’ve never seen before. When products improve this dramatically, customer needs change just as fast — and the systems designed to support them must evolve too.

That’s why I’ve been waiting.

A Forcing Function Called 1mind

Backing 1mind at seed has been the single biggest forcing function in reshaping how I think about the next chapter of Customer Success. Co-investing alongside Cassie at Primary, and now seeing their $40M Series A led by Battery Ventures, has only reinforced that conviction.

If the Gross Retention Apocalypse is the storm, 1mind is the sunlight breaking through.

1mind sits at the intersection of two defining shifts that are reshaping how companies grow and build trust.

The first is structural — the transformation of go-to-market itself. Onboarding, support, and renewals are no longer distinct stages; they’ve merged into one continuous customer experience. Furthermore, when AI increases the capacity of marketing, sales, and support teams, where does that capacity go? Do we see the rise of a new hybrid operator — one customer-facing role that spans them all? Perhaps.

The second is emotional — the transformation of customer trust. AI interactions no longer feel mechanical; they feel personal. Customers now expect technology to understand intent, tone, and urgency — to respond in ways that feel human, not automated. If AI can mirror empathy and anticipate needs, what happens to the foundation of trust itself? A high do–say ratio has always underpinned trust — and AI, perhaps, delivers on that even better than the best CSM.

Across every 1mind deployment, one thing is clear: customers are happier. Interactions are faster, more consistent, and — most surprisingly — more empathetic than what human-only teams can deliver at scale.

HubSpot brought this to life with Fiona, their 1mind-powered “Superhuman” built to engage and convert SMB buyers. Fiona handles the entire process — pitching, scoping, pricing, and closing — with no human in the loop. The results are remarkable: an 88% engagement rate, a 78% increase in free trials, and a 25% lift in conversion to closed/won. It’s a glimpse into what AI-native sales truly looks like — and it’s not hard to see how this can be tuned for support, success, and other service functions. HubSpot is already expanding Fiona’s role across every segment.

Other customers are seeing similar step-changes: 2–5x higher conversion rates than basic chatbots, 2x pipeline performance, 20-day shorter sales cycles, 2x ACV growth, and hundreds of millions in new business sourced.

The takeaway is clear: companies that master these two transformations — structural and emotional — won’t just define the next era of Customer Success. They’ll define what enduring growth looks like in the AI age. 1mind is already showing us how.

The Waymo Moment

It reminds me of Waymo versus Uber. A self-driving ride feels strange at first — maybe even unnatural. But once you experience it, it’s objectively smoother, safer, and more predictable.

What feels less human at first often turns out to be better. That’s the paradox we’re living through now.

The same debate is playing out across customer experiences everywhere. Some people miss the friction of human touch; others crave the seamlessness of AI. But soon, that won’t even be a debate — because AI-driven experiences will become the default, and human touch will become an intentional product design choice.

Think about it: at the Four Seasons, the in-person check-in is the brand — an act of hospitality designed into the experience. At a Best Western, a flawless, automated self-service kiosk check-in might actually match the product best.

The key isn’t choosing between human and machine, it’s designing both intentionally.

The New Definition of Success

That’s exactly what makes 1mind so compelling. It isn’t another AI assistant bolted onto legacy workflows — it’s a system built from the ground up to make AI feel personal, to understand tone, intent, and context in ways that elevate every interaction.

The results speak for themselves: higher satisfaction. Faster resolution. Richer insight.

For go-to-market and Customer Success leaders, this is the new game board. The challenge ahead isn’t deciding whether to use AI — it’s deciding where human connection still matters most to create the best customer experience and, ultimately, deliver the greatest product value.

The Renaissance Ahead

We’re still early. AI adoption will move through its own hype cycles, just as SaaS did.

But one thing is certain: we’ll look back on this moment as the time Customer Success evolved from a department into a design principle. The next generation of leaders won’t be defined by who can sell the fastest, but by who can help customers realize value the fastest. That’s the real frontier.

The future isn’t human or AI. It’s human by design — and AI everywhere else.

— JG

Differentiation at the model layer is collapsing faster than anyone expected. Each release narrows the gap. The advantage window is now measured in weeks, not years.

If the models are converging, where does lasting value accrue? My thesis: it lies with applied AI companies that build from the customer back. In that world, Customer Success plays an outsized role.

The Missing Link: Adoption and Outcomes

Across industries, companies struggle to operationalize AI — connecting data, retraining workflows, and changing behavior. That’s where Customer Success, onboarding, and enablement become the constraint. Whoever shortens time-to-value wins.

Deployment is where the real race for AI value is being fought. We’ve entered the adoption era of AI. The models are astonishing, but the tools built on top of them have become just as remarkable — and at this stage, adoption determines who captures value. Joe Tsai, co-founder of Alibaba, put it best: “There’s no such thing as winning the AI race; my definition of winning is who can adopt it faster.”

I’ve been noticing this urgency among friends leading Customer Success and post-sales at both the labs and the fastest-growing applied AI companies. The way they allocate headcount feels drastically different from what was normal in the SaaS era — and the data is finally starting to quantify what I’ve been hearing in conversations.

According to ICONIQ’s 2025 Operating Trends report, AI-native companies now dedicate roughly one-third of all GTM headcount to post-sales functions — nearly 50% more than traditional SaaS peers. In the SaaS era, sales was the growth engine; in the AI era, adoption is.

Adoption and revenue are now inseparable. The faster a company goes to market, the more it must invest in ensuring customers realize value. AI adoption has jumped from the #9 to the #5 board-level priority year over year, while GTM acceleration remains number one. Customer Success is now the most strategic lever — not a support function, but the front line of growth.

The Customer Success Playbook Has Changed

Speed breeds ambiguity — and ambiguity demands guidance. ICONIQ’s data shows AI leaders reaching $100M ARR two to three times faster than traditional SaaS benchmarks. Companies are rethinking go-to-market from the ground up — not just to sustain that momentum, but to drive growth itself — giving rise to a new hybrid role that blends pre-sales, post-sales, and product.

These aren’t traditional CSMs or solution engineers. They’re technical operators who embed with customers early — often before the deal closes — to shape proofs of value, guide integrations, and demonstrate outcomes in real time.

ICONIQ’s data shows that nearly half of AI-native companies now deploy these “forward-deployed” roles during trials, closing deals about a month faster than their SaaS counterparts — and staying with the account to guide its growth after the deal closes. These companies aren’t winning because they sell harder; they’re winning because they make customers successful sooner.

The new org chart mirrors that shift. AI-native companies are 57% R&D-heavy, with leaner Sales & Marketing (32%) and G&A (11%). Engineering now sits closer to the customer — and increasingly, inside the customer’s environment. Over the past year, there’s been a twelvefold increase in forward-deployed engineer hiring: part engineer, part strategist, part trusted advisor. They debug alongside users, translate feedback directly into code, and serve as the connective tissue between customer needs and product evolution.

The New Measurement

For Customer Success leaders, this new era demands fluency in the same metrics that product and engineering teams have long mastered. The lagging indicators that defined the last decade of CS — renewals and NRR — still have their place. But the real unlock now lies in the leading indicators: adoption, engagement, and outcomes. These determine how quickly customers realize value — and how efficiently a company grows. Leaders who can translate that data into action will define the next generation of go-to-market excellence.

I encourage every Customer Success team to operationalize these three dimensions:

1. Adoption — Track active usage, trial-to-paid conversions, and net-new ARR to measure how quickly customers are realizing value. High adoption velocity is the first proof that your product is solving a real problem.

2. Engagement — Measure depth and breadth of use. WAU/MAU ratios, product and feature retention curves, and platform breadth utilization reveal how deeply your product is embedded in the customer’s workflow. The more integrated you become, the higher the likelihood of expansion.

3. Business Outcomes — Outcomes are often the hardest to measure — but it’s possible. For most teams, this starts with qualitative insights: time saved, cost reduced, or productivity gained. To get there, you need a deep understanding of your customer’s domain and how those outcomes map to actions within your product. For example, if a process used to take hours and you can see a breadcrumb trail of that same workflow happening faster in your software, quantify the improvement.

The key is to build a go-to-market system that captures these leading indicators — your new control panel for the AI speed of business.

In this era, ensuring every customer reaches their desired outcome isn’t optional; it’s the difference between trial ARR and lasting growth. The best teams already know it — and they’re building for it now.

Let’s go! 🚀

—JG

This week in New York, more than 1,100 Customer Success leaders filled four stages for the city’s largest CS event ever—fifty-plus speakers, standing-room-only sessions, hackathons, and events across the city. A community alive with momentum, powered by the surge of AI reshaping the future of the craft.

We opened with a simple truth: software is being reimagined like never before. And when how we build, deliver, and experience software changes, everything changes—including Customer Success.

Customer Success came of age in the SaaS era—built on long onboarding cycles, standardized workflows, and inflexible multi-tenant experiences. That model worked in a world of predictable deployments, where success was measured in seats sold and contracts renewed. But in the AI-native era, it breaks down. The expectation now is value from day one. Intelligent support. Personalization for every user. What worked before has gone stale. The old playbooks are broken. A new era of Customer Success is beginning—right now.

Familiar to Uncharted

Today every CEO, across every industry, carries an AI mandate. The rules of evaluation, buying, and deployment are being rewritten in real time. Pressure is high. Urgency is everywhere.

And this is where Customer Success has stepped in first. In the leading AI companies, CS leaders are the ones educating organizations on how to harness AI. We are the partners guiding customers through uncharted waters. That consultative nature—the one this community has always championed—has never been more valuable.

“Customer Success isn’t becoming obsolete—it’s becoming more essential.”

Liz Starling, Head of Customer Success at Anthropic, underscored it: “Customer Success isn’t becoming obsolete—it’s becoming more essential.” Her team sees innovation cycles collapsing from years to weeks. Every CEO they work with wants AI to drive outcomes, but few know how. On the ground, CS is the guide.

At the macro level, PwC projects AI will contribute $15.7 trillion to the global economy by 2030—a tailwind for Customer Success like we’ve never seen before. Together, these forces make one thing clear: the shift from familiar to uncharted doesn’t diminish CS—it makes it indispensable.

Seats to Outcomes

For too long, value was thinly tied. You sold licenses. You counted seats. You hoped usage mapped to impact—and when it didn’t, you hid behind multi-year contracts.

That world is gone. In the AI-native era, value isn’t implied—it’s explicit. Clear. Companies only grow if customers are extracting it in measurable ways—and in many cases, it’s literally how you get paid. In a consumption and outcomes model, value is no longer a proxy. It’s the product. It’s not how many people log in—it’s what the software delivers for the business. Incentives have never been more aligned. Companies only win when their customers win.

Incentives have never been more aligned. Companies only win when their customers win.

Here’s what most people still miss: in this model, Customer Success is how revenue is generated. It’s not a forced upsell. It’s not a sales conversation disguised as an EBR. Value is tied directly to consumption—and consumption is tied directly to revenue. That’s why “forward deployed” has become such a hot subject with the sharpest founders. The earlier and deeper you help your customers, the faster you grow.

Planhat CEO Kaveh Rostampor put numbers behind it: 80% of leaders believe companies should sell outcomes, not products. Value has become the only real currency.

The shift from seats to outcomes puts Customer Success at the very center of revenue.

Steady to Accelerated

AI has collapsed timelines. Code ships faster. Tickets are answered instantly. Release cycles shrink. Bugs are fixed before they spread. Roadmap features move from backlog to production in weeks, not years. What was unimaginable 24 months ago is now the baseline.

AI hasn’t just raised expectations—it has redefined them. The standard of “good” has shifted higher, and the best in CS are already augmenting themselves with new AI capacity.

The standard of “good” has shifted higher, and the best in CS are already augmenting themselves with new AI capacity.

Amanda Kahlow, Founder and CEO of 1Mind, showed how this acceleration is already creating new possibilities. At 1Mind, AI agents run workflows end-to-end while humans focus on judgment and trust. The proof is real: HubSpot’s 1Mind-built superhuman, “Fiona,” drove 88% engagement, lifted free trials 78%, and increased influenced purchases by 25% in just 30 days with higher NPS scores.

Abbas Haider Ali at GitHub added by giving a glimpse of the new CS leader: the specialized generalist—someone who can orchestrate AI, spike in technical or commercial depth, and deliver outcomes at speed. His takeaway was clear: the faster the cycle, the greater the opportunity for Customer Success to lead.

The shift from steady to accelerated elevates Customer Success into the role of guide, strategist, and growth engine.

The Defining Era of Customer Success Begins

AI-native software has reset the rules. Familiar has become uncharted. Seats have become outcomes. Steady has become accelerated.

And through every shift, one truth is clear: the companies that win will be the ones that put Customer Success at the center of their operating model.

Customer Success is a role. It is a department. And it always will be. But more than ever, it is the operating model for how modern companies build, sell, and grow in the AI era.

This is the beginning of its defining era—because in the AI-native world, growth is impossible without it.

Some of my favorite moments from the week:

— JG