# How Forward Deployed Engineering is done at Kepler Vinoo Ganesh, Kepler | AI Engineer World's Fair 2026 | 22:20 Source: https://www.youtube.com/watch?v=1OMHGsUZiqA Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/how-forward-deployed-engineering-is-done-at-kepler Published: 2026-07-28 Tags: deployment, engineering-culture, enterprise, product-strategy ## TL;DR - Forward deployed engineering is a product strategy, because engineers discover problems in the customer's environment and generalize fixes into the product. - A small solution shipped in hours can reveal the real problem and earn access to larger product opportunities. - FDEs must define the customer's language and treat every useful hack as production software that may need support for years. ## Summary Vinoo Ganesh argues that forward deployed engineering should belong to product strategy rather than sales or customer success. The engineer works inside the customer's environment, identifies the real problem behind a requested solution, ships a small fix quickly, and then turns the learning into a reusable product capability. He describes a shipping company that requested a large BI system but needed a Slack alert, and a data quality engineer who rejected Parquet because she needed to open CSV files manually. Ganesh also explains why FDEs need to define the nouns and verbs used across an enterprise. Different teams may describe the same entity as a customer, client, billing entity, or org ID, which creates integration and data quality problems. The talk ends with a warning about temporary scripts. If a hack makes someone's work easier, it will probably reach production, so FDEs must decide what belongs in the core product and what should be discarded. ## Key ideas ### Forward deployed engineering is a product strategy rather than a job title [02:05](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=125s) Ganesh says the first fundamental truth of FDE is that it is a product strategy. The engineer is judged by the ability to act as an extension of the product team, identify opportunities, and generalize solutions. He traces this approach to Palantir's work on Foundry in 2013, after a data platform called Phoenix had been built in isolation and failed on real financial data. A blank date became January 1, 1970, which created 2.3 million time buckets and would have required 14 terabytes of RAM. Ganesh says the failure came from building without being embedded with a customer. The FDE's job is to own the problem, define the solution, and connect field work to the product. ### The first customer solution should answer the real operational need [04:51](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=291s) A shipping and dispatch customer supplied a 47-page requirements document asking for a custom dashboard, 14 metrics, drill-down alerts, a large BI tool, and a three-month development project. When an engineer asked what the dispatcher did first on Monday morning, the answer was checking whether trucks were late and calling someone to arrange new inventory. The actual need became a Slack alert, built in four hours. Ganesh says FDEs should ask what the customer is trying to accomplish, what happens after the solution, and how the work is done today. If the problem can be solved in under a day, the engineer should build it, ship it, and close the loop instead of expanding the product plan. ### Small fixes earn access to the larger problem [06:56](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=416s) Ganesh says whoever defines the problem owns the solution. By solving the dispatcher's immediate issue, the FDE team controlled the next questions and could explain what later solutions should look like. This is why he says FDEs create value early in a customer relationship. The value comes from solving concrete problems in small, bite-sized ways, which builds trust and gives the engineer access to the underlying problem. He connects Foundry's general product capabilities to the many hours spent doing this kind of work in the field. The engineer is not simply collecting requirements. The engineer is deciding which observed problem can become a reusable product capability. ### Watching users exposes needs that interviews miss [08:33](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=513s) A data quality engineer resisted moving a customer's large daily CSV export to Parquet. The team initially could not understand the resistance, since Parquet would reduce pressure on the pipelines and lower data costs. On site, they watched her download CSV files from S3 onto a Windows computer, double-click them, and inspect the data manually. She could not do the same with Parquet because there was no native viewer. That night, the team built a Parquet viewer, and she approved the migration two days later. Ganesh says repeated tasks, copying between tools, switching tabs, visible frustration, and pulling out a phone during a workflow are all signs of product problems. ### Physical presence gives FDEs access to problems missing from documentation [10:41](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=641s) Ganesh says the most valuable information about a customer's work is usually not in documentation. The team only saw the data quality engineer's problem because they were badged into the customer's building and watched the workflow directly. He argues that surveys cannot replace being present where the work happens. A forward deployed engineer sitting in a conference room far from the customer's operations will miss important details. His advice is to get into the room where work actually happens, because residents get the truth. The purpose of that presence is to make tomorrow different from today by finding and fixing an annoying, repeated task. ### Defining shared language prevents product and integration failures [12:33](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=753s) Different teams may use different terms for the same entity. Sales may say customers, operations may say clients, finance may say billing entities, and developers may say org IDs. Ganesh links this ambiguity to broken integrations, data quality issues, and unreliable pipelines. He describes an ontology as the nouns and verbs that define an organization's entities and operations. FDEs need to identify overloaded terms, find where systems connect, understand translation layers, and locate systems of record. When users adopt a product, they also adopt its language. Ganesh says an FDE who defines the vocabulary and codifies it in the platform can become the linguistic foundation for later solutions. ### Temporary scripts become products when they solve a real problem [16:51](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=1011s) Ganesh describes a Groovy script written as a quick fix for a customer's data retention problem. It was not designed for production, but twelve months later it was running in many places at a customer with almost 100,000 people. The script became known as venue.groovy, and the team had to support it for years even though they never productized it properly. Ganesh uses this story to distinguish FDE work from simply making customers successful. A solution can fix an immediate problem while creating long-term product debt. FDEs need to decide whether a solution should enter the core offering or be discarded before it spreads. ### FDEs should ship quickly while planning for long support lives [18:09](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=1089s) Ganesh calls calibration the most important FDE skill. Before shipping, the engineer should ask whether the solution will generate a 2 a.m. call in six months, what trade-off the quick fix creates for the wider product, who will own it later, and what happens when it breaks. He warns that every useful hack tends to enter production. The phrase 'this is just temporary' is especially dangerous because a solution that makes someone's life easier may remain in use for years. His operating rule is to ship everything as if it will run for 18 months. FDEs still need to solve problems fast, but they must understand the cost of letting each solution persist. ### The FDE owns the fix and turns field work into product leverage [20:08](https://www.youtube.com/watch?v=1OMHGsUZiqA&t=1208s) Ganesh contrasts an FDE function built around requirements, user research, and customer success with one that steers the product from what engineers learn. Strong FDEs get on site, ship a fix before leaving, own that fix through the product ecosystem, and translate the problem into reusable nouns and verbs. They also remain responsible when systems break. He says the relevant measure is what the engineer shipped from a product perspective, not simply what was learned during the engagement. At Kepler, he is applying this model by using FDEs as an extension of the product function. The goal is to build products that solve real problems and become sticky through repeated product leverage. ## Notable quotes - "The first fundamental truth of FDE is that this is not a role, this is a product strategy." (02:05) - "If solving the problem is under a day of work, just build it and ship it and close the loop." (06:56) - "Residents get the truth. Go on site." (12:18) - "Every hack goes into production." (18:50) - "Ship everything like it's going to run for 18 months because it probably will." (19:29) ## Tools & references mentioned - Palantir - Kepler - Project Frontline - Foundry - Phoenix - Citadel - OpenAI - Anthropic - xAI - Cassandra - Amazon S3 - Parquet - Groovy - Snowflake - Databricks - Tableau - SAP - MCPs ## Who should watch - You are building an FDE team and need to decide whether it belongs with sales, customer success, or product. - Your customers send detailed requirements, but you suspect their first real need is much smaller and more immediate. - Your field engineers write scripts that work today, and you need a way to decide which fixes become product features.