How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh
Vinoo Ganesh, formerly of Palantir, details how Forward Deployed Engineering (FDE) functions as a critical product strategy rather than a sales role. He shares insights from Palantir's Foundry development, emphasizing how FDEs embed with customers to uncover true problems, observe user behavior, define a common linguistic ontology, and build production-ready solutions from temporary fixes, ultimately driving core product leverage.
Vinoo Ganesh emphasizes that Forward Deployed Engineering (FDE) at Palantir was fundamentally a product strategy, not a go-to-market or sales function. This approach was crucial in building Palantir’s Foundry data platform, leveraging engineers embedded in critical customer environments to understand and solve real-world problems. Ganesh, who created “Project Frontline” to train software engineers into FDEs, highlights that an FDE’s primary role is to be an extension of the product team, identifying opportunities and generalizing solutions into core product offerings.
He outlines four key lessons derived from his experience:
1. Detect the Real Problem and Ship the Real Thing
Customers often describe desired solutions, not their underlying problems. A key FDE skill is discerning the actual need. Ganesh recounts a shipping company that initially requested a complex, 47-page BI tool. Upon deeper investigation by an FDE on-site, it was discovered that their immediate Monday morning need was a simple Slack alert to check for late trucks. This trivial solution, built in four hours, demonstrated that users frequently require quick fixes to pressing issues rather than extensive software.
The lesson for FDEs is to:
- Understand the core goal and what happens after a solution is implemented.
- Observe how customers currently solve the problem.
- If a solution can be built and shipped in less than a day, do it. This builds trust and grants access to larger, systemic problems that can inform product strategy.
- “Whoever defines the problem actually owns the solution.” By providing immediate, tangible value, FDEs control the narrative and direction of subsequent product development. Foundry itself is a generalized solution born from thousands of hours of such field engagements.
2. Watch What Users Actually Do
User actions provide invaluable insights that formal documentation or interviews often miss. Ganesh shares the story of a data quality engineer who resisted migrating from CSVs to Parquet for a year. On-site observation revealed her daily workflow involved manually downloading CSVs to her Windows computer and double-clicking them for spot checks—a workflow impossible with Parquet due to the lack of a native viewer. An FDE promptly built a Parquet viewer, leading to rapid adoption and significant cost/time savings.
FDEs should look for:
- Repeated tasks: Any action performed multiple times a day or week indicates a potential feature opportunity.
- Copy-pasting between tools: A sign of fragmented workflows and integration gaps.
- Visceral reactions or exasperation: When users say, “I have to,” about a task, it flags a significant pain point.
- Switching tools or tabs: Often points to workflow inefficiencies.
- Pulling out a phone mid-task: Indicates frustration, delay, or a bug in the current software.
The critical takeaway is that “actions speak significantly louder than words.” FDEs must be physically present at customer sites (“residents get the truth”) to uncover these unspoken truths, as “the most valuable intel here is never going to be in documentation.”
3. Own the Language: Defining the Ontology
Ambiguity in terminology across different departments within a customer organization (e.g., “clients” for ops, “billing” for finance, “org IDs” for dev, “customers” for sales) leads to broken integrations, data quality issues, and financial costs. Palantir accidentally stumbled upon the concept of an ontology to define common nouns (entities) and verbs (operations).
An FDE’s role in this context is to:
- Identify “overloaded” terms that mean different things to different people.
- Map integration points and translation layers between systems (e.g., Snowflake to Databricks, Palantir to Tableau).
- Understand system boundaries and irreplaceable “systems of record.”
- Clarify user-specific language, such as defining “agent” in an AI context.
By defining these terms and creating a consistent linguistic foundation, FDEs enable customers to adopt the product’s vocabulary. This “linguistic foundation” makes the FDE’s platform indispensable, as it becomes the common language upon which all other solutions are built. This was crucial for Foundry, allowing it to serve as an ontological bedrock.
4. Ship Fast, But Build for Production
A “temporary” Groovy script for data retention, initially a quick fix, unexpectedly scaled across a 100,000-person organization and became a long-term support burden (“vinoo.groovy”). This illustrates the danger of shipping hacks without considering long-term implications.
FDEs must calibrate what they ship by asking:
- Will this require a 2 AM phone call in six months?
- What are the trade-offs for the overall product, beyond a quick win for one customer?
- Who will maintain this when I leave the customer site?
- What happens if this breaks, and how critical is it?
“Every hack goes into production… If it solves a problem, it’s not temporary. It will live forever.” Therefore, FDEs must “ship everything like it’s going to run for 18 months” and focus on productizing solutions that drive the core offering forward, rather than merely solving immediate customer success issues. Solutions Architects handle customer success; FDEs focus on product strategy.
Conclusion
FDEs redefine problems, embed themselves with customers to gain true insights, ship immediate fixes to build goodwill, and then leverage those fixes to create product-wide solutions. They translate real-world pain into foundational nouns and verbs for the product ecosystem. The ultimate goal is product leverage — building sticky products that solve problems and drive the company’s core offering. FDE is not a go-to-market tool but an essential extension of the product function, especially for early-stage companies seeking to define and build impactful products.