Re-Architecting Enterprise Go-to-Market: Why the Hybrid Customer Success Role Failed and What Replaces the Technical Gap

I spent three years in customer success for a services company in Atlanta, specifically the Google Apps program. In the fourth year, Google started flying partner Customer Success Managers to California to sit with the product managers for Drive, Gmail, and the rest of the Apps suite—round-tripping field data back into the product organization. That experience is why I believe the gap this article describes was never a mystery. It was a choice: product organizations could have built a durable path for in-the-field reality to shape the roadmap, and most did not.

After time in the partner services channel I moved to the technology innovator side, specifically Customer Success, Sales Engineering, and then Forward Deployed Engineering. I only state this before diving into the thesis because it’s not coming from casual external observation. This has been my life for almost 15 years.

The Zero-Interest-Rate Illusion and Market Stratification

Customer Success became a standard organizational pattern in 2012, the year venture firms began treating a dedicated CS function as a funding requirement and the year the Customer Success Association was founded. Salesforce had stood up Customers for Life in 2005 after a real churn crisis, but 2012 is when the practice stopped being niche and became expected.

It was institutionalized out of necessity, but not under pressure. SaaS had already created a low barrier to exit—every year was a renewal decision, and switching costs were no longer the sunk hardware and implementation of the perpetual era. Realized attrition remained artificially suppressed. Early Pacific Crest surveys showed median annual gross dollar churn in the 5–8% range, allowing the median provider to exceed 100% net revenue retention simply because expansion outpaced leakage. Capital was near-free: the federal funds rate sat at the zero bound through most of 2015 and peaked at only about 2.5% in 2019. Companies could still outrun moderate leakage with new logos.

As capital costs normalized, retention metrics bifurcated by annual contract value. KeyBanc and Benchmarkit surveys show blended median net revenue retention compressed to roughly 101% across private B2B software, but the aggregate conceals the structure. In the small and midsize tier (sub-$25,000 ACV), median NRR fell to 97%. In the enterprise tier (contracts above $100,000), median NRR remained robust at 118%, with gross revenue retention stabilizing near 90%. Customer Success budgets were historically distributed across these segments, yet the relationship-first model routinely failed to protect the complex, high-value deployments where technical friction—not a lack of relationship management—was the primary source of risk. The function was active. It was misaligned with the technical demands of enterprise scale.

The operating model that spread matched the easy-money environment. Salesforce’s early CSMs were relationship-first. Gainsight, launched in 2013 into a world with roughly a thousand CSMs, was outcomes-first: health scores, usage visibility, and playbooks. Gainsight’s later framing—Customer Success 2.0—argued the discipline should be company-wide rather than a single department. The diagnosis was early and correct. The funding never followed it. Both the early models and the later vision rested on the same practical assumption: that one person could facilitate the relationship and deliver the outcome. That assumption holds only when attrition is not looming and capital is cheap enough that moderate leakage can be ignored or outrun.

It was a Finance challenge as much as an operating one. In the perpetual-license model (pre-SaaS) the large cash event was front-loaded; ongoing maintenance covered support while high switching costs limited exit risk, so post-sales OpEx could stay lean. Subscription inverted the cash timing without a corresponding rewrite of the margin model. Value is now realized over time, and the post-sales experience is no longer a cost center supporting an already-captured sale. It is an ongoing investment that protects and expands the revenue stream. Finance largely continued to apply the old expectations. CS costs cluster in the 5–10% of ARR range at scale, and the COGS-versus-OpEx classification debate has always been shaped by the desire to protect reported gross margins. The contribution is indirect and future-oriented, so it loses budget fights to nearer-term new-logo spend.

The benchmark was set during easy money. Calling the sizing “rational” assumes the conditions for which it was sized would last. They didn’t. A cost center that fails at its job is not a cost center. It is a broken function. SaaS multiplied the number of companies needing sellers and post-sale people, and demand for those roles rose faster than the supply of people with the technical depth and executive presence the work required, so the definition of the role diluted to fill the seats. At the same time the growth-at-all-costs paradigm rewarded new-logo velocity. When rates rose and the definition of success flipped toward net revenue retention and efficiency, companies discovered that the back end had never been built for the defensive problem the subscription model had always contained.

The Psychology of the Premortem Signal

Terms like “broken function” pre-suppose the function’s charter wasn’t met. So what is the charter of Customer Success? At least part of that charter involves acting as a bi-directional information channel to and from the product organization. But why? Product has always received customer input—support tickets, sales objections, user research, advisory boards. The challenge with existing product feedback channels is they all arrive in a form product could not act on or with an attached bias for which one cannot account at scale. Support tickets are a self-selected sample of already-frustrated customers. User research places people in a setting where they know they are being observed, so they perform rather than behave. Customer advisory boards tend to be populated by those seeking professional and political visibility instead of a representative sample of your target users. Also, all are postmortems. Embedded technical field teams provide a continuous premortem signal: the environmental context required to identify why a rigid product abstraction will fail inside a specific enterprise architecture before that failure manifests at scale.

The cognitive value of that signal is rooted in decision science. While Gary Klein popularized the premortem in the mid-2000s and Daniel Kahneman later endorsed it in Thinking, Fast and Slow, the underlying mechanism—prospective hindsight—was empirically validated earlier. Mitchell, Russo, and Pennington’s 1989 study in the Journal of Behavioral Decision Making showed that shifting an observer’s temporal perspective to analyze a future event as though it had already occurred increases the ability to identify reasons for future outcomes by 30%. Forward Deployed Engineering operationalizes that principle at enterprise scale. By placing functional prototypes inside real customer architectures, these engineers force the product organization to confront integration bottlenecks, data quality constraints, and compliance hurdles before they become commercial attrition.

The disconnect is not primarily product arrogance. Product organizations are measured on building standardized, multi-tenant software that scales without accumulating custom debt. Field teams surface acute, customer-specific friction. Absorbing every request unfiltered would fragment the product. The practical problem is signal filtering: turning bespoke enterprise needs into durable platform abstractions. That is the work Forward Deployed Engineering is positioned to do when it is staffed and funded to generalize rather than merely deploy.

This gap was reinforced by a quieter claim: customer care is not the product organization’s job. Their job is to build for customers, not care for them. Care is a cost-center function. “Not our job” has been an effective way to keep field insight out of the roadmap. The claim only makes sense if the company’s purpose is to build product. It collapses if the purpose is to solve the customer’s problem. When product treats the product as the means and the solved problem as the end, investment in value realization stops being a residual expense and becomes the unfinished part of the work.

Decomposing the Impossible Job Description

The original Customer Success role tried to collapse three necessary jobs into one person. Account management owns the commercial relationship, renewal, and expansion. The function that owns success outcomes in perpetuity for an individual customer—technical account management, customer success, or whatever name a company gives it—owns the ongoing relationship, adoption, and realized value. Forward deployed engineers own scoped technical engagements and the generalization of what they learn back into the product. Those three functions have different scopes, different skill profiles, and different funding logics. No single person can hold executive presence and relational acumen alongside design thinking and engineering depth at the level each job requires. The role was not merely underfunded or diluted. It was an impossible job description.

Organizations that have made the decomposition explicit keep the functions distinct. PostHog’s public handbook places sales, technical account managers, customer success managers, and forward deployed engineers under a shared growth umbrella, but assigns clear ownership. Sales retains commercial ownership. The Customer Success Manager is the permanent base layer on every account above $20,000 ARR, managing adoption health and executive alignment in perpetuity. Technical resources are deployed as time-bound overlays for complex integrations or severe friction. There is no disruptive handoff when the technical engagement concludes. The Customer Success Manager never leaves the account. The engineering overlay is retracted once the deployment stabilizes, leaving the go-to-market team with a functional product and the relationship intact. The pattern echoes the one pioneered by Palantir: engineers embed to solve the immediate integration reality, abstract the bespoke solution into the core platform, and exit—leaving both the customer environment and the software platform improved. Palantir’s model has run for roughly two decades; its funding structure is not the same as the product-funded design this article describes.

The GAAP and ASC Funding Matrix

Forward Deployed Engineering still faces the same funding tension the earlier functions did. Industry reports, including TSIA surveys, indicate that a majority of organizations fund FDE as cost of goods sold—the structure that applies traditional professional services utilization targets (typically 75–85% billable) and thereby penalizes the non-billable work of turning a customer-specific pattern into platform capability. A smaller share fund it as customer acquisition cost, and a still smaller share as research and development. Under pure COGS the most valuable hour is the one least likely to be rewarded. Some industry research reports that strategic, non-utilization-constrained FDE work can drive four to six dollars of sustained platform consumption for every dollar spent; those multipliers should be treated as directional rather than independently verified. The incentive problem is real either way.

Reclassifying the spend is not free, and the accounting is more precise than a simple COGS-versus-R&D binary. Under ASC 340-40-25-5, incremental costs of fulfilling a contract must be capitalized as an asset if they relate directly to an identifiable contract, generate or enhance resources the entity will use to satisfy future performance obligations, and are expected to be recovered. Those costs are then amortized over the period of benefit, protecting current-period gross margins and aligning the cost of the technical deployment with the long-term value of the customer relationship. Separately, when engineers write code that abstracts a customer-specific solution into a multi-tenant platform feature, that labor is governed by ASC 350-40 for internal-use software. The recent ASU 2025-06 update removed the requirement to complete a preliminary project stage and lowered the threshold for capitalization once management commits funding and completion is probable. With auditable, ticket-level time tracking, the platform-abstraction portion of the work can be capitalized rather than immediately expensed. Capitalization under ASC 350-40 is not the same as classifying the cost as research and development under ASC 730; R&D is generally expensed. The funding classification must follow the precise nature of the work.

The Generative AI Catalyst and Production Complexity

The contemporary acceleration of the engineering overlay model is not solely a reaction to macroeconomic tightening. It is also a response to technological complexity. Generative AI, machine learning pipelines, and modern data infrastructures require production-grade software engineering at the customer boundary. That intensity of integration demand did not exist at the same scale when Customer Success was mainstreamed. A 2025 Massachusetts Institute of Technology study found that 95% of enterprise generative AI pilots fail to deliver measurable financial returns, driven largely by integration friction and learning gaps. Traditional relationship managers cannot bridge that technical chasm, and isolated product teams lack direct access to the customer’s proprietary data pipelines and operational workflows. Without specialized forward-deployed capability, complex enterprise software rapidly devolves into bespoke professional services, and the feedback loop between the field and the core platform severs.

Outcomes that require a human in the loop to scale are not systems—they are professional services. Methodology is the exponent on technology. Without a durable path from field reality into product capability, every successive function remains a temporary patch for the same missing pipeline. Measuring these teams by pure billable utilization recreates the incentive problem. The more useful frame is the one used for product engineering: track field-originated platform changes that actually ship, and the failure rate of those changes (the DORA dimensions of deployment frequency and change failure rate applied to the field-to-product path), paired with time-to-value on the customer side. That keeps the generalization work visible and rewarded, so field learnings cannot be silently dropped and the function cannot quietly turn into professional services.

Product-led Forward Deployed Engineering, structured so that generalization is part of the job and capitalization rules are applied correctly, is the correct design for the technical engagement function. It is not a replacement for account management or for perpetual value realization. Those remain go-to-market responsibilities. The model is too new to have a clear record of failure, but the temptation for it to be a pure GTM function with exclusively GTM incentive structures is already visible. If that becomes the norm, it will inherit the same underfunding and utilization pressures that broke the earlier functions. The companies that separate the three functions, fund the technical one so that patterns travel, and keep the long-term account ownership continuous will stop inventing new titles for the same underfunded gap. The companies that do not will keep collapsing incompatible work into roles that cannot be staffed.

Sources

Customer Success Association founding & VC requirement: customersuccessassociation.com
Salesforce churn crisis & Customers for Life: customersuccessassociation.com; Nick Mehta, The Recurring Revenue Tsunami
Pacific Crest churn data: forentrepreneurs.com (2015 survey citing 2012–2014)
Federal funds rate: federalreserve.gov
Gainsight Pulse 2013 / Customer Success 2.0: gainsight.com
CS cost benchmarks: saastr.com; founderpath.com
NRR and GRR by ACV tier (KeyBanc, Benchmarkit): investor.key.com; industry benchmarking surveys
Premortem and prospective hindsight: Mitchell, Russo & Pennington, 1989, Journal of Behavioral Decision Making; Klein, The Power of Intuition (2004) and “Performing a Project Premortem,” Harvard Business Review (Sept 2007); Kahneman, Thinking, Fast and Slow, Part 3, Ch. 24
TSIA and related FDE funding surveys; consumption multipliers treated as directional industry reports
PostHog handbook (role ownership, continuous CSM base layer, overlay model): posthog.com/handbook/growth/sales
ASC 340-40-25-5 (capitalization of fulfillment costs), ASC 350-40 / ASU 2025-06 (internal-use software capitalization), and ASC 730 (R&D generally expensed): FASB; Deloitte, Grant Thornton guidance
Enterprise GenAI pilot failure rate and primary causes (integration and learning gaps): Massachusetts Institute of Technology, 2025
DORA metrics applied to field-originated platform changes: standard software delivery performance literature