Vinoo Ganesh argues forward deployed engineers should turn customer work into product improvements

Correction, October 13, 2026: Ganesh criticizes FDE functions that fail to feed customer learning back into the platform. His essay does not provide a measured count of consultants across current FDE roles.

Kepler CEO Vinoo Ganesh argues that many FDE roles lack a path back into product development. He writes: “An FDE function that solves last miles without ever sending that signal home is a services/consulting team with a better title.” His test is whether customer work improves the product for future customers.

What he said

A Forward Deployed Engineer, or FDE, is an engineer who sits inside a customer’s own operations, embedded with their team, to build and adapt software directly against that customer’s specific problems, rather than working from a company’s own office on a generic product. In his essay on Latent Space, Ganesh argues that companies often rebrand consulting work as FDE roles. His sharpest line on what failure looks like: “An FDE engagement that ends with one delighted account and nothing changed upstream has failed […]”

His argument is that the point of an FDE isn’t to make one customer happy. It’s to take what’s learned from that customer’s specific problem and turn it into something the whole product gets better at handling, so the next customer’s version of the same problem gets solved faster. Without that feedback into the product, he argues, the function remains customer-specific service work.

Who he is

Ganesh is the CEO and co-founder of Kepler, which he describes as building “deterministic infrastructure for AI,” referring to systems that execute defined calculations and trace results to their sources. Before Kepler, he built pieces of the forward deployed function at Palantir, the data analytics company that popularized the FDE role, where he says he ran a program that trained around 250 engineers who went on to lead forward-deployed teams at companies including OpenAI, Anthropic, and xAI. He later ran business engineering at the hedge fund Citadel. That’s three separate companies where he’s had to define what this specific role is supposed to accomplish, which is the direct basis for his critique.

What he gets right, and where it’s incomplete

Ganesh’s distinction between an FDE and a consultant is concrete enough to actually check against a real hire: does the work only ever solve the customer in front of you, or does it change what the product can do for every customer after that. That’s a useful test, and it explains a real pattern builders can watch for: teams that add headcount for “customer-facing engineering” without any process for feeding what those engineers learn back into the core product.

His other structural point, that FDEs should report into product rather than sales, is a stronger claim than the essay fully defends. It follows logically from his generalization argument: a function measured on deal-closing will optimize for the specific customer in the room, not for what should ship broadly. But it’s also a prescription drawn from his own three companies, not a comparison against firms that route FDEs through sales and still generalize the work well. Readers should treat it as a strong, experience-based recommendation rather than a demonstrated rule.

Why it’s notable

The FDE title has spread fast across AI labs and AI infrastructure startups over the past two years, largely because AI systems now need more hands-on tuning against messy, real-world customer data than a typical software sale requires. Ganesh’s essay is less about that trend and more about a warning that the label is being used loosely enough to cover very different jobs, which makes it a bad signal for job seekers and hiring managers trying to compare roles across companies.

What it means for builders

If you’re hiring for this role, Ganesh’s test is worth applying literally: ask what the last three FDE engagements changed in the actual product, not just what they delivered to the customer. If the answer is “nothing changed upstream,” clarify whether the role is meant to deliver customer services or improve the product. Align its reporting, measures and staffing with that purpose.

If you’re a builder considering an FDE role yourself, ask the hiring team directly who the function reports to and how its work gets fed back into the product roadmap. That answer can reveal whether the job includes platform development or mainly customer-specific delivery. The title alone does not establish the scope.

End of article