How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh
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
3:35
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
8:11
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
17:12
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
20:33
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
833s
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
230s
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.
Mentioned resources
- Vinoo Ganesh
- Palantir
Channel & topics
Watch on YouTube · Back to latest
This independent, AI-assisted summary is provided for commentary and informational purposes. It may contain errors or omit important context. Please watch the original video for the creator's complete presentation. Video, thumbnail, and related copyrights belong to their respective owners.