# How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh

## Executive summary

Forward Deployed Engineering (FDE) should be viewed not as a go-to-market function, but fundamentally as a product strategy. FDE engineers act as extensions of the core product team, solving concrete, small-scale customer problems in their live environment to identify generalized product opportunities. The process involves observing user workflows, defining the underlying domain language (ontology), and ensuring that temporary fixes are built with production readiness in mind.

## Key takeaways

- FDE is a Product Strategy, Not a Role: The core insight of FDE is that it must function as an extension of the product team to identify areas for generalization. The goal is to define and solve the underlying problem, not just implement the requested solution.
- Solve Small Problems First: When a customer presents a massive requirement (e.g., a custom BI tool), focus on solving the most immediate, trivial problem first (like a Slack alert). This builds trust and allows the product team to gain ownership of the solution narrative.
- Observe User Pain Points: The most valuable intelligence is found by observing user behavior (e.g., repetitive tasks, copying/pasting between tools, or using a phone during workflow). These actions indicate missing features or bugs that documentation will never reveal.
- Define the Ontology and Language: FDE must define the domain's terminology (the ontology) to standardize ambiguous terms. By canonicalizing nouns (entities, e.g., 'clients') and verbs (operations), the engineer controls the language that the entire system is built upon.

## Technical details

- Data Format Migration: The speaker recounts a case where migrating data from CSV files to Parquet format significantly reduced data costs and improved pipeline execution time (from 17 hours to two). However, the initial resistance was due to the lack of a native viewer for Parquet.
- System Architecture Failure: Early systems like Phoenix failed when encountering real-world data imperfections. A specific example involved Cassandra requiring excessive RAM (14 terabytes) due to time-bucketed key spaces generated from imperfect financial data.
- Scripting and Production Readiness: A temporary fix, such as a Groovy script, can solve an immediate problem but must be treated with extreme care. The principle is that any hack or solution that makes someone's life easier will eventually be integrated into the core product offering.

## Practical implications

- When scoping a solution, prioritize solving the most immediate pain point (the 'Slack alert') over building comprehensive dashboards or full-scale software.
- Always assume that temporary fixes will become permanent features; design for production scale and maintainability from day one.
- Systematically map out all ambiguous terms within an enterprise to define a canonical ontology, especially in complex domains like AI (e.g., defining 'agent' or 'skill').
- Focus on the *product leverage* gained from field observations rather than just customer goodwill.

## Topics

Forward Deployed Engineering (FDE), Product Strategy, Data Ontology, Software Development Lifecycle, Customer Experience Design, Vinoo Ganesh, Palantir

Source: https://www.youtube.com/watch?v=1OMHGsUZiqA