How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh

It's kind of an emotional thing to hear a series of folks who've kind of been talking about how Palantir used to do things. It's funny, in the olden days—and what this talk will be about is largely—Palantir's focus of FDE became a go-to-market strategy, but it wasn't that in the beginning.

How we were figuring out how to build Foundry was through the lens of a product strategy. And so my talk is going to be how we used FDE as a product strategy in 2013 to make the data platform that enabled Palantir to then become the thing that Kevin, Nat, and all these folks were able to build on.

And it ultimately comes from, like, the background of something pretty simple. So my background is: I started my career at Palantir as a software engineer, really focused on horizontally scalable and storage solutions at a high level. When we say "forward deployed," I forward deployed to places like Iraq and Afghanistan—that's me and Bagram, he's no longer there anymore—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?

So "forward deployed" is actually a military term, and we took it very seriously.

My claim to fame from Palantir is I built something called Project Frontline, which was the rotation program that took our software engineers and made them forward deployed engineers. So the folks that you see at OpenAI, Anthropic, xAI, a lot of the FDEs—about 350 of them—went through a training program for how we got them to understand what we needed out of forward deployed product-focused individuals.

I built the same program at Citadel afterwards, so across the hedge fund, how do we build theright data products and software products to help portfolio managers generate alpha? This is a quote from the guy who named forward deployed engineering at Palantir.

It's from a couple days ago, and Sean is the CTO of Palantirright 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 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 at market caps of companies for how do we actually evaluate what contract size this is, that wasn't how it actually happened. 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.

And so this is the story of how we actually made Project Frontline at Palantir, and what I'm using to build this function out at Kepler, along with Susanna here as one of our founding engineers. Back in the days, Palantir was first trying to get into big data.

So around 2013, we had this idea that we wanted to store transaction information. And the product that came out of that was something called Phoenix. Phoenix was built totally in isolation. We didn't talk to customers, we didn't understand our financial banks or 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. And the situation was simple: we had a large-scale financial customer, and the idea was, we're going to store your information in bucketed key spaces.

This is going to enable easy rolloff and easy retention. 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 1st, 1970.

Our retention strategy made it such that what we wanted to do was actually take each 10-minute increment between January 1st, 1970, and 2013, and spin up a time-bucketed window. The problem is Cassandra requires 5 megabytes per file handle, which means with the 2.3 million key spaces we generated, to start up our server would require 14 terabytes of RAM, and we were dead on arrival.

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.

It came from the ownership about co-building a piece of software without being directly embedded with a customer. 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.

So what I'm going to do is walk through four things and four real stories that I learned at Palantir and other places, what we learned from those experiences, and how they informed building FDE at every other institution. The first starts from something fairly simple.

Palantir was onboarding a large-scale dispatching and shipping company. We sat down with the VP of Operations, who generated a 47-page requirements doc. What they wanted was a custom dashboard: 14 metrics, drill-down alerts, this massive BI tool, a dev project that was estimated at three months.

The kind of hilarious thing that happened in this process is we took them at face value. 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?"

The dispatcher said, "I check if trucks are late, and then I call the dispatcher to ship a new inventory or new institution." The whole thing could have been simplified to a trivial Slack alert, which is what we ended up building.

In four hours, we were able to solve this problem cradle to grave. 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.

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.

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? Every single one of these OpenAI or FDE deployment companies are all approaching it in a slightly different way than how Palantir did, which is: we have the people who are going to go on-site and build things, 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. 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. 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 at Palantir, and that's how we started. 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 at 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 solutions looked like.

By controlling what we're going to 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. It's not because they are really good at 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 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.

Cool. Actions speak louder than words. This is a real situation, also in Palantir days. We had a data quality engineer who was viscerally adamant about how to solve a pipeline stability issue. Every day, we were dropping about a terabyte of information into someone's S3 bucket, and it was putting a lot of pressure on our own data pipelines.

We had an easy solution. Instead of dropping huge numbers of CSVs, we can migrate everything to Parquet. It makes it easier for our pipelines, it makes it easier for, like, your cost, it makes it easier from a compute perspective.

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. 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 at this customer and watch her use our tool and do this workflow end-to-end. 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. 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. She approved the migration in the next two days, massively reducing data costs. I think the pipeline execution time went from 17 hours to about 2. And what this teaches us is actually something pretty simple.

When you are working with a user, you are effectively an observer of what happens on-site, and actions speak significantly louder than words. 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 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.

Any time a user copies and pastes between tools, meaning if they're moving from one tool to another, any time they're reacting this way, if the first thing you say is, "Hey, how do you feel about this problem?" and their reaction is, "Ugh, well, I have to," and this visceral exasperation, you know you have an opportunity there.

Any time a user switches tools or tabs, it's an opportunity. And any time 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.

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, every morning we all have something we need to solve.

This all goes back to, again, FDE is informing your product strategy. You earn theright to extract user pain and define product strategy by solving small, repetitive problems. Now, the most valuable intel here is never going to be in documentation.

We only saw Maria's challenge because we were badged onto their building. We were physically present. We were in Afghanistan, we were in Iraq, we were running around SoHo, we were here in Palo Alto or in San Francisco. The vast majority of stuff that matters is only going to happen live inside of the walls of the office.

Your badge on-site at 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.

Everything lives in that environment. 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.

And the way I've heard this put, and the way we threw it around at Palantir, is residents get the truth. Go on-site. 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. Sales members call 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.

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. 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. And so this idea of an ontology was kind of an accidental thing that Palantir 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.

It came from this 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.

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. 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. I think in this case we called them, I think we canonicalize on customers. In other situations you canonicalize on IDs.

Something like DAU, daily active users, can mean something very different to different people. 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.

And so when a user adopts your product, they also adopt your language. How many people are calling things skillsright now? How many people are calling things MCPs that are function calls with prompts? 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? 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 Palantir to Tableau? 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? What are the systems of record you're never going to 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?

Like, we can't even define FDE. We're trying to define agents,right? Are they prompts? Are they, like, a series of steps? Understanding that viscerally becomes important. Your job is to define the terms. 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 secret here is: if you become the linguistic foundation, you're locked in. 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 ecosystem.

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. 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. We had to learn this the hard way when we were actually building it for the first time.

Last thing here: ship fast but build for production. This is a true story. They all are, I guess. But we had a customer that needed to run data retention. I decided to build a very quick script. It was in Groovy, if anyone knows that language, as a temporary fix.

It wasn't designed for prod by any means. 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 an almost 100,000-person customer.

It was running in a number of places. My nickname at Palantir, Nat's not here anymore, but she can attest to this, became vinoo.groovy. At my wedding, people showed up wearing a name like shirt vinoo.groovy. And so 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.

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. And so, again, when people say 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. 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 whose jobs are making customers successful.

They're solutions architects. So calibrating what you ship becomes the last, most important skill here as an FDE. First, am I going to get a 2:00 a.m. phone call about this in six months? If you are, you probably shouldn't ship that thing.

Second, what is my trade-off for solving this problem quickly? Am I making theright decision for the product as a whole, or am I just solving this customer's pain point in a way that's going to have potentially small wins but negative compounding challenges later on?

Who do I hand this off 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? And what happens when this breaks? Am I going to be held responsible for that?

Am I building something so mission-critical that if something breaks, I'm going to be hated? What happens there? 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.

Here's the actual reality: every hack goes into production. If you make someone's life easier, it will go into production, and you will be responsible to support that hack in perpetuity. The most dangerous words in forward deployed engineering or engineering are "this is just temporary."

Anyone here who's been at a software company knows this is not just temporary. And we know that we're still writing and running on 40-year-old Cobalt code at some IBM mainframe because of a hack that was put in place.

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 going to run for 18 months because it probably will. And through the lens of, again, the product-building focus, this 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 through, rather, is the following: most people who are trying to develop an FDE function treat it like a product management task and a customer success operational task. They take requirements, they schedule user research, they add insights, they run the processes without actually figuring out how you steer the product from the insights.

Theright FDEs who enabled the creation of something like Foundry redefined the problem, 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 have a friend who was spending time on an oil rig in the middle of the ocean. 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.

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. 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. The goal here is actually fairly simple.

I'm going to 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. It's the only thing that backs every decision being made in the warfighter ecosystem at Palantir or in customer ecosystems at Palantir.

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 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 Palantir and have 20 years and unlimited money. 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.