Sahil Mehta

6 Thoughts About Forward-Deployed Engineering (FDE) and Customer Success (CS) FDE has been all the rage in startups in the last year. Originally pioneered by Palantir, the concept has been reinterpreted - and some would say overloaded - for many categories of companies. This is all happening while startups are trying to understand the role of CS in the AI world. Having launched Gainsight and run it for 13 years, we spent a lot of time thinking about these problems. We shared our learnings in 5 published books and iterated with customers in hundreds of events worldwide. As such, I now get a LOT of questions from AI founders about CS and FDE. Some are “I have a CS team but I want to make them FDEs” and others are “I have an FDE team but I want to scale with CS.” And now that OpenAI, Anthropic and Google have all launched FDE initiatives, this idea is going mainstream (side note: I love the sibling rivalry between the labs!) So here are 6 thoughts on these related ideas: 1. The Goal of CS is the Goal of FDE - Outcomes: If you rewind back to our original book on Customer Success 10 years ago (!!) that sold 100K copies, we defined the concept as: "Customer Success is when your customers achieve their desired outcome through their interactions with your company." Now let's go to the definition of FDE in the OpenAI Deployment Company launch: "[FDEs] help organizations move from identifying high-value AI opportunities to building production systems that deliver measurable results." This is why I’ve always believed “CS > CSM,” meaning Customer Success was a strategy with many roles, including Customer Success Manager (CSM), Professional Services (PS), Training and Support. 2. The Commonality Is Vendor Ownership of the Outcome: The old pre-SaaS model, before FDE and CSM, was that the customer owned if they got value or not. Since they paid for software upfront, the vendor had no incentive to do otherwise. The vendor offered paid Support and paid Professional Services. But if the customer never got the outcome they were looking for, it was on them. They owned the outcome risk. 3. The Token Model Made This More Important: In the SaaS model, a lot of CS work was defense. They could talk about revenue growth, but so much was revenue protection and churn mitigation. Hence, CFOs felt the link between revenue and CS was tenuous - it entailed proving the counterfactual (“would they have churned without this investment?”) Tokens and consumption changed everything. FDEs removed bottlenecks to consumption (e.g., finding the use cases and implementing them) Now, the land can be less complex. But the real growth comes from customers increasing token spend, leading to some firms having absurdly high Net Dollar Retention (eg 400%). 4. Tokens Justified More Investment in FDEs: CSMs always aspired to be the ones driving business outcomes. But two things prevented this: The lack of clarity on ROI of CSM led companies to stretch CSMs across too many accounts, preventing them from getting deep enough with any given client. The lack of business case also meant companies couldn’t invest in the appropriate amount of technical resource to take the learnings from a CSM and turn them into deployment changes or product changes. Now, FDEs are core revenue drivers so companies are hiring more of them with more technical and expensive profiles. 5. But You Still Need an Ongoing Relationship: Historically, PS and CSM were separate because PS could be “project-aligned” (start/stop) and CSM could be “account-aligned” (perpetual). From an operations research perspective, this makes sense. Otherwise it’s very complex to manage people doing deployments and then getting overloaded with existing customers. I’m seeing the more mature AI orgs with FDEs adding in CSMs for the ongoing management of value. 6. Forget the Titles; This is Vital: Some people say “FDE is what we used to call PS and CSM.” Others say “FDE is a brand new idea.” With all terms in tech, both extremes are true. Thesis, antithesis, synthesis, as they say. But one thing I can say for sure, it’s never been more important to invest financial resources into the success of your clients of AI products. Because in a moatless world, this is the best chance we’ve got of building durable businesses.

Forward deployed engineers, or equivalent, are about to become one of the most in-demand jobs in tech. And one of the most important functions for AI rollouts. Deploying agents is far more technical of a task than most people realize, often far more involved than deploying software. Software generally works the same way every time, and generally for the past few decades has been updated versions of an existing technology or concept (which basically means easier for the enterprise to update their workflows on a newer system). With agents, you’re actually deploying the equivalent of work output within the enterprise. The customer is effectively using you as a professional services provider for a task, which they expect to get solved nearly end-to-end now. This means you need to actually deeply understand the business process as a vendor, and get the customer from the current to the end state seamlessly. Companies need help figuring out which models will work best for their workflows, they need extensive evals setup often, they need change management support for workflows, they need to get their data setup for the agents, and constant tuning of the agentic system for their process. Massive role in tech now. And another example of the kind of highly technical work that AI is creating.

Google enters the FDE race

GOOGLE TO RECRUIT HUNDREDS OF ENGINEERS TO ASSIST CLIENTS IN EMBRACING ITS AI – THE INFORMATION

In 2023, Stanford professor Graham Weaver gave his last lecture on how to destroy fear & live a wildly ambitious life. His frameworks: - Suffering is inevitable - Signup for "10 years" test - "Not me" & "Not now" traps 13 lessons on how to build an asymmetric life:

Eli Goldratt's book, The Goal, was famous for its (then unpopular argument) that keeping every machine running 24 hours a day, the metric most plant managers cared about, was actively making factories worse. I suspect we're seeing the same fallacy in how many people are using AI agents. Goldratt's point was that machine utilization isn't throughput. What you want from a manufacturing plants is making good widgets as cost-effectively as possible. It doesn't necessarily follow that running your machines all the times optimizes that. Picture a three-station assembly line. Stations 1 and 2 each crank out 200 widgets an hour. Station 3 can only handle 100. Running stations 1 and 2 around the clock doesn't ship more product. It just piles up half-finished widgets in front of station 3, ties up cash in inventory, and creates more work managing the pile. He developed the Theory of Constraints to point out that what matters is solving the bottleneck in the system, not increasing machine utilization. I suspect a lot of agent usage right now is the same fallacy at higher resolution. Running 20 Claude Code sessions in parallel can feel productive because something is always happening. But, if the bottleneck in your work is judgment about what's worth doing, more agents just generate more output for you to wade through. This is not to say there aren't workflows running 20 agents in parallel very effectively, I'm sure there are. And, I suspect there's a general retraining we all need to do around evolving historical workflows. But.... The constraint for most knowledge work is deciding what's worth executing and no one is task switching between 20 things at the same time effectively I don't think. I find I can run maybe 2 or 3 things in parallel with maybe 1 or 2 admin-y type things on the side and that is only if I'm very locked in.