AI Engineer World's Fair 2026
How Forward Deployed Engineering is done Kepler
Read the talk
Forward Deployed Engineering Starts with the Product
A failed storage system, an oversized dashboard request, and a blocked Parquet migration show how field engineering turns customer problems into reusable products.
From a talk by Vinoo Ganesh
Before you start: Familiarity with data pipelines, storage formats, and customer-facing software work is helpful; no Palantir experience is required.
What product should the field team help build?
What should forward deployed engineers do when the product they are supposed to deploy does not yet exist? In Ganesh’s account of Palantir around 2013, that was the starting problem. Forward deployed engineering later became a go-to-market strategy, but the work that led to Foundry began as a way to discover and build the product itself.
Ganesh came to that work through horizontally scalable storage systems and deployments to Iraq and Afghanistan, including Bagram. The question was how to make software work for people operating in critical environments. He created Project Frontline, a rotation program that moved software engineers into forward deployed work. Ganesh reports that about 350 engineers passed through the program, including people who later worked at OpenAI, Anthropic, and xAI. He subsequently built a similar program at Citadel, where the objective was to build data and software products that helped portfolio managers generate alpha.
A post he presents from Shyam Sankar frames FDE as a product strategy rather than a role. The practical distinction is the evaluation criterion: an FDE should identify opportunities and generalize customer solutions into product capabilities, not merely qualify an account by its market capitalization or contract size. That is the approach Ganesh is applying at Kepler with founding engineer Susanna.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A blank date becomes a storage catastrophe
Palantir’s internal Phoenix project was intended to store transaction information as the company moved into big data. The team designed it in isolation, without understanding the financial customers whose data it would ingest. For a large financial institution, the design used time-bucketed keyspaces to make retention and roll-off easy: old data could be removed by retiring its bucket. The design worked under its assumed conditions. Real data broke those assumptions.
A blank date defaulted to the Unix epoch, January 1, 1970. The retention logic then attempted to create a window for every ten-minute interval between that date and 2013. A missing value had become an instruction to allocate decades of storage structures. Ganesh recalls 2.3 million keyspaces, a five-megabyte cost per Cassandra file handle, and a startup requirement of 14 terabytes of RAM. Those figures are his incident recollection, not a general Cassandra sizing rule; the stated count and per-handle cost alone multiply to 11.5 decimal terabytes, leaving the rest of the reported total unexplained.
There was no other team to call to make the deployment work. The failure exposed more than a missing piece of customer research: the engineers had designed the system without sharing responsibility for building it inside the customer’s environment. Embedded ownership changes what a product team learns and what it must fix. The four field lessons that follow develop that distinction.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find the decision behind the dashboard
At a shipping and dispatch company, the VP of operations supplied a 47-page requirements document for a custom dashboard with 14 metrics and drill-down alerts. Development was estimated at three months. The team spent four months scoping the engagement before an engineer happened to visit the site while near family and asked: “What's the first thing you do with this information Monday morning?”
The operational sequence was much smaller than the requested BI system: check whether trucks were late, then call dispatch to arrange a response. A Slack alert could provide the signal that triggered that work. Ganesh reports that the team solved the dispatch problem end to end in four hours. The intervention changed the scope by identifying what the information was for.
Before building, establish three things:
- The goal: What is the customer trying to accomplish?
- The next action: What happens after the customer receives the answer or solution?
- The current method: How does the customer solve the problem today?
A dashboard is one possible implementation. The operational goal determines whether it is necessary.
This is the XY problem in field engineering: the customer describes a proposed solution, and the engineer must recover the underlying problem. Ganesh’s working heuristic is to build, ship, and close the loop when the actual fix takes less than a day. A bounded fix does not need to become an expanded product vision or a new round of product-management coordination.
Defining the problem also gives the team ownership of the solution and a basis for deciding what should come next. This explains the value of FDEs in early sales: small, successful fixes win trust and access to deeper problems. Their usefulness does not depend on being unusually sociable engineers. Ganesh traces Foundry’s ability to generalize across verticals to tens of thousands of hours of this field work—solving specific problems, then extracting capabilities that belong in a shared product.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The migration was missing a viewer
Another customer received about a terabyte of data each day in an S3 bucket, putting pressure on the delivery pipelines. The engineering team proposed replacing large CSV deliveries with Apache Parquet to reduce pipeline, compute, and data costs. One data quality engineer opposed the migration for about a year. Repeated explanations of the technical benefits did not resolve her objection.
An on-site visit made the missing requirement visible. She downloaded CSV files from S3 to her Windows computer, double-clicked them, and spot-checked the data. In her existing workflow, Parquet had no equivalent reader she could simply open. Changing the format would remove an essential inspection step. The team built a Parquet viewer that night.
Ganesh says the migration was approved within the next two days and recalls, tentatively, that pipeline execution fell from 17 hours to about two. He also reports lower data costs without quantifying them. The enabling change was a viewer that preserved the user’s ability to inspect data; the pipeline optimization could proceed once that workflow survived the migration.
Watching the work produces a different kind of evidence from asking whether someone likes a proposed feature. Look for:
- Repetition: The same task performed repeatedly within an hour, day, or week.
- Manual transfers: Copying and pasting between tools.
- Exasperation: A user describing a step as something they reluctantly have to do.
- Context switching: Moving between tools or tabs to finish one job.
- Waiting: Pulling out a phone mid-task, which can signal slow or annoying software.
These are prompts to investigate the workflow, not automatic proof of a particular solution.
A useful opening question is: “What's the most annoying part of your morning?” Solving a small, repeated irritation changes the user’s next working day and earns access to the pain that should shape the product. Maria’s inspection workflow became visible because the team was inside the customer’s building. Ganesh describes the on-site badge and contractor email address as permits to discover how work actually happens. His insistence on physical presence comes from deployments ranging from Iraq and Afghanistan to offices in Soho, Palo Alto, and San Francisco: scheduled surveys and remote conference rooms do not expose everything that a resident sees.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn conflicting vocabulary into an ontology
Inside a logistics organization, different teams used different names for the same entity:
| Team | Term |
|---|---|
| Sales | Customer |
| Operations | Client |
| Finance | Billing entity |
| Developers | Org ID |
Those differences became integration failures, data quality problems, and broken pipelines. Each team’s language made sense within its own environment; the difficulty appeared when information crossed between them.
Ganesh describes the ontology as a response to this human coordination problem, rather than the result of putting everything into Elasticsearch and imposing schemas. Nouns define entities; verbs define operations. Field engineers had to discover both and decide how the software would express them. In his recollection, this customer settled on “customers”; other organizations might canonicalize around IDs. Even an apparently established metric such as daily active users can mean high-quality activity to a product team and simply the number of people who logged in to InfoSec.
Product adoption also spreads vocabulary. Ganesh points to the uptake of terms such as skills and MCPs, including loose uses of MCP terminology for function calls with prompts. The engineering task is to identify which phrases are overloaded and where the meanings change. Trace integration paths—Snowflake to Databricks, Palantir to Tableau, or Anthropic to SAP—and locate the translation layers. Then establish the system boundaries and the systems of record that cannot simply be replaced.
The same discipline applies to an AI failure report. If a customer says an agent keeps failing, first establish what “agent” names in that system: a prompt, a sequence of steps, or some other unit of behavior. Defining the terms makes the problem concrete enough to model. Once those definitions are codified in the platform, users can reason about subsequent problems through the same vocabulary. That is the basis of Ganesh’s lock-in argument: the product becomes the language in which the organization describes its work.
The Foundry ontology made those definitions part of a reusable platform. In Ganesh’s historical account, that foundation enabled a later generation of go-to-market FDEs to integrate customer data and sell an existing product. The engineers building the foundation had first needed to discover the entities, operations, and boundaries through deployment work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The retention script that would not go away
A customer needed data retention, so Ganesh wrote a quick Groovy script as a temporary fix. It solved the immediate issue without being designed for production. Ganesh says that 12 months later, the script had spread across multiple deployments inside a customer with almost 100,000 people. The association became so durable that his Palantir nickname was Vinoo.groovy; guests even wore shirts bearing it at his wedding.
The team had fixed a problem without deciding the end state or turning the solution into a product capability. It consequently supported the hack for years. This is the failure mode hidden inside a definition of FDE as simply making the customer successful: a customer can benefit while the product accumulates obligations and gains little reusable capability.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Ship quickly with an explicit support boundary
Ganesh assigns customer-success work to solutions architects and holds FDEs to an additional product-building obligation. Before shipping, make the support boundary explicit:
- Future incidents: Is this likely to produce a 2:00 AM call six months from now?
- Product trade-offs: Does immediate relief create maintenance costs that compound across the product?
- Handoff: Who receives the system when the engineer leaves—the customer, another institution, or another FDE?
- Failure ownership: Who responds when it breaks, and what mission-critical work depends on it?
- Disposition: Should the fix enter the core offering, or should it be discarded?
A quick implementation still needs a decision about its lifetime and owner.
For a retention tool, one useful implementation boundary is to separate selecting expired records from deleting them. The following Groovy example makes a retention proposal visible without performing deletion. It uses a fixed cutoff and rejects missing dates rather than silently treating them as ancient data:
groovy
import java.time.Instant
List<Map> proposeRetention(List<Map> records, Instant cutoff) {
records.collect { record ->
if (!(record.createdAt instanceof Instant)) {
throw new IllegalArgumentException(
"Missing or invalid createdAt for ${record.id}"
)
}
[
id: record.id,
createdAt: record.createdAt,
proposedAction: record.createdAt.isBefore(cutoff)
? 'DELETE'
: 'KEEP'
]
}
}
def records = [
[id: 'tx-1', createdAt: Instant.parse('2025-01-01T00:00:00Z')],
[id: 'tx-2', createdAt: Instant.parse('2025-07-01T00:00:00Z')]
]
def cutoff = Instant.parse('2025-06-01T00:00:00Z')
def proposal = proposeRetention(records, cutoff)
proposal.each { println "${it.id}: ${it.proposedAction}" }
Here, tx-1 is proposed for deletion and tx-2 for preservation; neither record is deleted. The separation creates something an owner can inspect and hand off. It does not replace the decisions about authorization, execution, and failure handling that a deployed retention system needs.
The dangerous assumption is that usefulness will expire because the code was called temporary. Ganesh invokes decades-old COBOL running on IBM mainframes as a reminder of how long software can outlive its original intent. His planning rule is to ship as though the solution will run for 18 months. That horizon forces a distinction between a fix that earns customer goodwill and a capability that belongs in the core product.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Evaluate what reaches the product
Requirements intake, scheduled research, and recorded insights are not enough if none of them changes the product. The Frontline standard joined discovery to delivery: redefine the problem, get access to the customer’s workplace, and go wherever the work happens. Ganesh’s examples include Afghanistan, Iraq, Somalia, and a colleague working on an oil rig. Physical deployment was a means of reaching the operational reality the software had to support.
The engineer then shipped a fix before leaving, owned it within the product ecosystem, and translated the observed problem into reusable nouns and verbs. Ownership included taking the call when something broke and traveling when necessary. The evaluation question is what shipped into the product, not merely what the engineer learned. This closes the loop between field access and a stronger shared platform.
Ganesh grounds the value of that shared platform in the decisions it supports: Citadel portfolio managers trading hundreds of millions of dollars, Palantir’s warfighter environments, and commercial customer operations. At Kepler, he is applying FDE as an extension of product development to build products customers continue to use because they solve consequential problems.
The company’s stage matters. An established Palantir can deploy engineers around a product foundation built over many years. An early-stage company must first discover the product that will make those deployments effective. Treating FDE primarily as a go-to-market extension before that foundation exists risks scaling customer-specific work without building the reusable product underneath it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Overview of Parquet’s column-oriented format, compression, specification, and reader/writer libraries.
Current documentation explaining objects, relationships, actions, and functions in Foundry’s operational model.
Further reading
The speaker’s introduction to a course on field deployment, context engineering, and turning AI prototypes into production systems.
Read the complete timestamped transcript
- 0:00
[upbeat music] It's kind of an emotional thing to hear a, a series of folks who've kind of been talking about how [REDACTED:username] used to do things.
- 0:18
Um, it's funny, in the olden days, and, and this-- what this talk will be about is largely, uh, [REDACTED:username]'s focus of FDE became a go-to-market strategy. But it wasn't that in the beginning.
- 0:31
How we were figuring out how to build Foundry was through the lens of a product strategy. And so my talk is gonna be how we used FDE as a product strategy in twenty thirteen to make the data platform that enabled [REDACTED:username] to then become the thing that Kevin, Nat, and all these folks were able to build on.
- 0:49
And it ultimately comes from, like, the background is something pretty simple. So my background is, uh, I started my career [REDACTED:username] [REDACTED:username] as a software engineer, um, really focused on horizontally scalable and storage solutions [REDACTED:username] a high level.
- 1:02
Uh, when we say forward deployed, um, I forward deployed to places like Iraq and Afghanistan. That's me in Bagram. It's no longer there anymore. Uh, but the idea was: how do we take software and build it in the most critical environments to make it actually work for people that needed it the most?
- 1:20
So forward deployed is actually a military term, and we took it very seriously. Um, my claim to fame from [REDACTED:username] is I built something called Project Frontline, which was the rotation program that took our software engineers and made them forward deployed engineers.
- 1:34
So the folks that you see [REDACTED:username] OpenAI, Anthropic, xAI, a lot of the FDEs, there's about three hundred and fifty of them, went through a training program for how we got them to understand what we needed out of forward deployed, product-focused individuals.
- 1:49
Uh, built the same program [REDACTED:username] Citadel afterwards. So across the hedge fund, how do we build the right data products and software products to help portfolio managers generate alpha?
- 1:59
Um, this is a quote from the guy who named, uh, forward deployed engineering [REDACTED:username] [REDACTED:username]. It's from a couple days ago, and, um, Shyam is the CTO of [REDACTED:username] right now, and I think this captures the entire essence of where my difficulty came from in the last talk, which is the first fundamental truth of FDE is that
- 2:17
this is not a role, this is a product strategy. How we discover the things to build are through the lens of forward deployed engineering. So looking [REDACTED:username] market caps of companies for how do we actually evaluate what contract size this is, that wasn't how it actually happened.
- 2:32
But the core tenet and the core insight was an FDE is judged by their ability to be an extension of the product team, to identify areas of opportunity and generalize product solutions out of it.
- 2:44
And so this is the story of how we actually made Project Frontline [REDACTED:username] [REDACTED:username] and what I'm using to build this function out [REDACTED:username] Kepler, uh, along with Susanna here, who's one of our founding engineers.
- 2:54
Um, back in the days, [REDACTED:username] was first trying to get into big data. So around twenty thirteen, uh, we had this idea that we wanted to store transaction information, and the product that came out of that was something called Phoenix.
- 3:08
Phoenix was built totally in isolation. We didn't talk to customers. We didn't understand our financial banks or any-anything else. What we did is we designed a system in perfect isolation that worked perfectly under certain circumstances and crashed and burned when we hit actual real data.
- 3:25
The situation was simple. We had a large-scale financial customer, and the idea was, we're gonna store your information in bucketed key spaces. Uh, this is gonna enable easy roll-off and easy retention.
- 3:37
Now, what we hit fairly quickly is a lot of banks and financial institutions have data that's not perfect. So when we hit a blank data value, it defaulted to the epoch, January first, nineteen seventy.
- 3:50
Our retention strategy made it such that what we wanted to do was actually ch-- take each ten-minute increment between January first, nineteen seventy and twenty thirteen and spin up a time-bucketed window.
- 4:03
The problem is Cassandra requires five megabytes per file handle, which means with the two point three million key spaces we generated, to start up our server would require fourteen terabytes of RAM, and we were dead on arrival.
- 4:17
There was no one else we could call. We were the only individuals and only institutions in the room, and we realized something fairly simple. The gap wasn't the fact that we had not looked for information about how customers use our product.
- 4:29
It came from the ownership about co-building a piece of software without being directly embedded with a customer.
- 4:37
The whole purpose of this talk is to convince you of one thing. Forward deployed engineering is a product strategy. Being an FDE is an extension of the product function, not the go-to-market function.
- 4:48
So what I'm gonna do is walk through four things and four real stories that I learned [REDACTED:username] [REDACTED:username] and other places, what we learned from those experiences, and how they informed building FDE [REDACTED:username] every other institution.
- 5:00
The first starts from something fairly simple. [REDACTED:username] was onboarding, uh, a large-scale dispatching and shipping company. We sat down with the VP of operations, who generated a forty-seven-page requirements doc.
- 5:13
What they wanted was a custom dashboard. Fourteen metrics, drill-down alerts, this massive BI tool, a dev project that was estimated [REDACTED:username] three months. The kinda hilarious thing that happened in this process is we took them [REDACTED:username] face value.
- 5:28
We spent four months scoping this engagement, trying to understand exactly what this customer wanted before one of us actually showed up on-site just by virtue of the fact that their family happened to live there and asked, "What's the first thing you do with this information Monday morning?"
- 5:43
The dispatcher said, "I check if trust are-- trucks are late, and then I call the dispatcher to ship a new inventory or new institution." The whole thing could've been simplified to a trivial Slack alert, which is what we ended up building.
- 5:58
In four hours, we were able to solve this problem cradle to grave.
- 6:02
The first move that we learned from forward deployed perspective is detect the real problem and ship the real thing. The vast majority of the time, people don't need massive BI dashboards.
- 6:12
They don't need fully scaled design pieces of software cradle to grave. They have a problem, and they need that problem actually solved. And so the first thing that we learned is before you build anything, you, as an extension of the product team, need to understand three things.
- 6:28
First, what are you trying to accomplish? Meaning, what's the core goal in actually solving this problem? What happens after you have the solution? And how is the customer actually solving it today?
- 6:40
Every single one of these open, uh, AI or FDE deployment companies are all approaching it in a slightly different way than how [REDACTED:username] did, which is we have the people who are gonna go on-site and build things.
- 6:51
What do we build? So I think of this in terms of an XY situation. Customers describe solutions, not problems. Your job as the FDE is to understand what the problem is.
- 7:03
Customers don't know what happens next, and your job as the FDE is to define it. My simple solution and takeaway is if solving the problem is under a day of work, just build it and ship it and close the loop.
- 7:15
Don't make it a product strategy. Don't expand your product vision and bring in your PMs and everything else. If you can solve this problem in a short, curtailed way, that's the first thing we did [REDACTED:username] [REDACTED:username], and it's how we started.
- 7:28
The secret here is whoever defines the problem actually owns the solution. If we were able-- The virtue of the fact that we were able to look [REDACTED:username] the problem this shipping operator had, define the solution, and ship the actual solution, meant that we were always the owners of that system, and we were able to articulate what subsequent
- 7:45
solutions looked like. By controlling what we're gonna build and by controlling the narrative around the solution, you end up in a really powerful position. And this is why FDEs actually become valuable in early sales.
- 7:57
It's not because they are really good [REDACTED:username] talking to customers or we're not socially awkward software engineers, as people seem to claim. It is because we actually solve the customer's problems in small, bite-sized ways that wins us trust and that gets us access to the real problem that we can then use from a product strategy perspective to
- 8:16
generalize. Foundry is a general product solution that we can use across a number of verticals that was informed by tens of thousands of hours of doing things like this in the field.
- 8:28
Cool. Actions speak louder than words. This is a real situation also in [REDACTED:username] days. Um, we had a data quality engineer who was viscerally adamant to a pipeline-- adamant about how to solve a pipeline stability issue.
- 8:43
Every day, we were dropping about a terabyte of information to someone's S3 bucket, and it was putting a lot of pressure on, on, on our, on our own data pipelines.
- 8:52
We had an easy solution. Instead of dropping huge numbers of CSVs, we can migrate everything to Parquet. Makes it easier for our pipelines, makes it easier for, like, your cost, makes it easier from a compute perspective.
- 9:04
But we had one engineer who was viscerally against this. We couldn't figure out why. Every time we'd bring this up over the course of about a year, she would push back.
- 9:14
Whenever I'd ask, she'd say, "Parquet is way worse. It doesn't work. It doesn't make sense to me." We decided to actually go on-site [REDACTED:username] this customer and watch her use our tool and do this workflow end to end.
- 9:27
What we saw is she was downloading CSVs from S3 manually onto her Windows computer, double-clicking them to open it up, and doing a spot check of data quality. She could not do that with Parquet files because Parquet didn't have a native reader that you could just open and view.
- 9:43
It's kind of a hilarious problem if you think about it because she was so viscerally opposed to this without really understanding the benefit it would give her. That night, we built a Parquet viewer.
- 9:53
She approved the migration the next two days, massively reducing data costs. I think the pipeline execution time went from seventeen hours to about two.
- 10:01
And what this teaches us is actually something pretty simple. Uh, when you are working with a user, you are effectively an observer of what happens on-site. An action speaks significantly louder than words.
- 10:14
So you as an FDE should be looking for any task a user does more than once, meaning if they're doing something the same day, same, same time multiple times a day, or they're doing something multiple times a week or multiple times an hour, that is a pattern and a hint that there's a problem and an opportunity.
- 10:31
Anytime a user copies and pastes between tools, meaning if they're moving from one tool to another. Anytime they're reacting this way, if the first thing you say is, "Hey, how do you feel about this problem?"
- 10:41
And their reaction is, "Ugh, well, I have to," and this visceral exasperation, you know you have an opportunity there. Anytime a user switches tools or tabs, it's an opportunity.
- 10:52
And anytime a user pulls out their phone in the middle of a task, meaning they're going through a workflow using your software or anything else and pull out their phone, it becomes pretty easy that this is an annoying problem or this software is taking too long.
- 11:06
Your goal as an FDE is to make tomorrow, their tomorrow, different from their today. And it starts with a question: What's the most annoying part of your morning? Every morning, we all come into work.
- 11:16
Every morning, we all have something we need to solve. This all goes back to, again, FDE is informing your product strategy. You earn the right to extract user pain and define product strategy by solving small, repetitive problems.
- 11:31
Now, the most valuable intel here is never gonna be in documentation. We only saw Maria's, uh, challenge because we were badged onto their building. We were physically present. We were in Afghanistan.
- 11:42
We were in Iraq. We were running around [REDACTED:location]. We were here in Palo Alto or in San Francisco. The vast majority of stuff that matters is only gonna happen live inside of the walls of the office.
- 11:54
Your badge on-site [REDACTED:username] a customer site and your email address, your contractor email address, those are your data mining permits. The first thing every FDE should do is get access to customer information by getting in the room where things actually happen.
- 12:09
Everything lives in that environment. And you can't survey your way to this. You have to be physically present. It's very easy to be a forward-deployed engineer in name sitting in a nice conference room in New York, but that's not where the actual problems are, and that's not where the solutions are.
- 12:23
And the way I've heard this put, and the way we threw it around [REDACTED:username] [REDACTED:username], is residents get the truth. Go on-site.
- 12:30
Third, when you define the language, you control the narrative. We had a customer where... I'm sure this occurs across pretty much everyone's company here. From a logistics perspective, everyone defines customers slightly differently.
- 12:44
Sales members calls them customers. Ops calls them clients. Finance calls them billing entities. Devs call them org IDs. The way that we talk about the same entity in a customer is fundamentally different depending on what team you're in.
- 12:58
That results in a huge amount of pain. It generally means integrations break, it means there's data quality issues, it means pipelines are constantly not working, and it ultimately comes back to a simple fact: We're all human.
- 13:10
We define things differently because we operate in our environments, and we understand how to talk about topics with people that are similar to us. It's a feature, not a bug.
- 13:21
And so, this idea of an ontology was kind of an accidental thing that [REDACTED:username] tripped into, and what it came from was not this understanding that by making everyone stick everything in Elasticsearch and, you know, schemifying everything, we can solve every problem.
- 13:35
Came from the simple idea that we need to enable humans to operate in the domain that they understand best. And so, when I say define the language, every organization is made up of two things: nouns and verbs.
- 13:49
The nouns define the entities. The verbs define the operations. What FDEs started eventually doing was building those nouns and verbs and figuring out what the terminology to use was in a lot of these enterprises.
- 14:03
Users don't just adopt your product, they actually adopt your language. And what we were able to do is we were able to start defining the languages that we wanted people to use.
- 14:12
I think in this case, we called them, um, uh, cust- I think we d- canonicalized on customers. In other situations, you canonicalize on IDs. Something like DAU, daily active users, can mean something very different to different people.
- 14:26
For product teams, high-quality DAUs. For anyone logging in from InfoSec, just the number of people that logged in. All these phrases that we take for granted are ill-defined by nature.
- 14:37
And so, when a user adopts your product, they also adopt your language. How many people are calling things skills right now? How many people are calling things MCPs that are function calls with prompts?
- 14:47
And that matters. So third piece here, defining the ontology. Your job as an FDE is to understand what the ontology is. What phrases, nouns, and terms in an enterprise are overloaded?
- 15:00
Meaning, what words are people using to describe the same concepts? Second, where do the integration points exist in the system? Are things going from Snowflake to Databricks? Are they going from [REDACTED:username] to Tableau?
- 15:12
Are they going from Anthropic to SAP? Where do these integration points actually exist, and what are the translation layers where it goes from one term to the other? Naturally, what are the system boundaries?
- 15:23
What are the systems of record you're never gonna be able to switch out? And what words do people use when they're describing their issues? If someone is saying, "Well, in AI, my agent keeps failing," what is an agent?
- 15:34
Like, we can't even define FDE. We're trying to define agents, right? Are they prompts? Are they, like, series of steps? Understanding that viscerally becomes important. Your job is to define the terms.
- 15:46
If you can define the terms in your own solution, you can build the ontology, and you can have customers answer questions and think through things in your terms. So the, the secret here is if you become the linguistic foundation, you're locked in.
- 16:02
And simple examples are things like skills, things like MCPs, things like any of the terms that weren't a big deal a year ago but are now day to day in our entire econ- entire ecosystem.
- 16:13
And so, when you are able to define the vocabulary that users use and codify that in your platform, you become the foundation under which every solution and tool is built on top of.
- 16:23
Foundry enabled that ontology to be constructed and built. That then enabled the next generation of FDEs, the go-to-market FDEs, to go out there and just do data integrations and sell the product.
- 16:35
We had to learn this the hard way when we were actually building it for the first time.
- 16:40
Last thing here. Ship fast, but build for production. This is a true story. Um, they all are, I guess. But, uh, we had a customer that needed to run data retention.
- 16:49
I decided to build a very quick script. It was in [REDACTED:username], if anyone knows that language, as a temporary fix. Um, it wasn't designed for prod by any means.
- 16:59
Like, I just randomly hacked this thing together to solve an initial problem, but it made it there. Twelve months later, this thing was all over the place. It was a almost 100,000-person customer.
- 17:09
Uh, it was running in a number of places for my... And my nickname [REDACTED:username] [REDACTED:username], Nat's not here anymore, but she can attest to this, became [REDACTED:username].[REDACTED:username]. [REDACTED:username] my wedding, people showed up wearing a name- the shirt [REDACTED:username].[REDACTED:username].
- 17:22
And so, the, the kind of funny thing here is we solved a problem in a very hacky way that did fix an issue, but we didn't actually productize it.
- 17:32
We didn't think through the end state. So we ended up in a situation where we were forced to support a very hacky product for years that was never actually productized.
- 17:41
And so, again, when people say customer-- FDEs are forward deployed software engineers or customer-facing software engineers, and your job is to make the customer successful, that's not true. When you do that, things like this happen.
- 17:54
So scripts and hacks can fix problems, but they're not driving your product strategy forward, meaning you're not doing your job successfully as an FDE. We have people that its jobs are making customers successful.
- 18:04
They're solutions architects. So calibrating what you ship becomes the last mo- most important skill here as an FDE. First, am I gonna get a 2:00 AM phone call about this in six months?
- 18:16
If you are, you probably shouldn't ship that thing. Second, what is my trade-off for solving this problem quickly? Am I making the right decision for the product as a whole, or am I just solving this customer's pain point in a way that's gonna have potentially small wins, but negative compounding challenges later on?
- 18:34
Who do I hand this off, uh, to when I actually leave the customer site? Is it going to a customer? Is it going to another institution? Is it going to another FDE?
- 18:42
And what happens when this breaks? Am I gonna be held responsible for that? Am I building something so mission-critical that if something breaks, I'm gonna be hated? What happens there?
- 18:52
So we need to solve problems, but we need to be aware of when we fold those solutions into the core offering and when we should just discard those solutions quickly.
- 19:02
Here's the actual reality. Every hack goes into production. If you make someone's life easier, it will go into production, and you'll be responsible to support that hack in perpetuity.
- 19:14
The most dangerous words in forward deployed engineering or engineering is, "This is just temporary." Anyone here who's been [REDACTED:username] a software company knows this is not just temporary, and we know that we're still writing, you know, running on forty-year-old COBOL code [REDACTED:username] some IBM mainframe because of a hack that was put in place.
- 19:31
If it solves a problem, it's not temporary. It will live forever. So as you're thinking from an FDE perspective, ship everything like it's gonna run for eighteen months because it probably will.
- 19:42
And through the lens of, again, the product-building focus should tell you a lot about what goes into the core product offering versus what wins you customer goodwill. So the cheat sheet that we all ran frontline people to, uh, through rather, is the following.
- 19:58
Most people who are trying to develop an FDE function treat it like a product management task and a customer success, uh, operational task. They take requirements. They schedule user research.
- 20:10
They add insights. They run the processes without actually figuring out how you steer the product from the insights. The right FDEs who enabled the creation of something like Foundry redefined the problem.
- 20:23
They got badged on-site, and they flew to places like Afghanistan, like Iraq, like Somalia, like any of these places where we had to be where our customers were. I, I have a friend who was spending time on an oil rig in the middle of the ocean.
- 20:36
They ship the fix before leaving the customer site to win the goodwill, but they own the fix end to end in the product ecosystem, and they took those fixes and created product leverage from it.
- 20:48
They were able to translate the problems they saw into nouns and verbs that they were then able to use to define the foundation of every subsequent problem that was solved.
- 20:58
And finally, they were the ones who got the call when things actually broke. They were the ones who got in the airplane to fly everywhere else. The question is not what did they learn in the process, but what did they ship from the product perspective?
- 21:10
The goal here is actually fairly simple. I'm gonna wrap up with this. Product leverage is the only thing that wins you customers. It's the only thing that backs every Citadel portfolio manager trading hundreds of millions of dollars.
- 21:22
It's the only thing that backs every decision being made in the war fighter ecosystem [REDACTED:username] [REDACTED:username] or in customer ecosystems [REDACTED:username] [REDACTED:username]. Your job as an FDE, and what we learned and what Kepler is doing, is using FDE as an extension of the product function to enable us to build products that are actually sticky and that solve
- 21:42
problems. And if you were to take one thing away, please don't treat FDEs as go-to-market extensions. You can do that when you're [REDACTED:username] and have twenty years and unlimited money.
- 21:52
You don't do that when you're an early-stage company, and you need to figure out what product will allow you to use those FDEs to maximum degree. Thank you so much. [audience applauding] [upbeat music]