How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh

频道: AI Engineer
视频: https://www.youtube.com/watch?v=1OMHGsUZiqA
原文语言: en
统计: 共 20 轮 · Vinoo Ganesh 19

[0:01] Vinoo Ganesh

[music] It's kind of an emotional thing to hear uh series of folks who've kind of been talking about how Palenter used to do things. Um it's funny in the olden days and this what this talk will be about is largely uh Palin's focus of FTE 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 Palunteer 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 uh I started my career at Palanteer as a software engineer um really focused on horizontally scalable and storage solutions at a high level. Uh when we say forward deployed um I forward deployed to places like Iraq and Afghanistan. That's me in Bram. 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. So forward deployed is actually a military term and we took it very seriously.

[音乐] 听前面这一串人聊 Palantir 当年是怎么做事的，说实话挺让人动情的。有意思的是，在那个老古董年代——这也正是我这场分享要讲的东西——Palantir 对 FDE 的强调，后来变成了一套 go-to-market 策略，但它一开始根本不是那么回事。我们当年摸索怎么把 Foundry 做出来，用的是产品战略这个镜头。所以我今天要讲的是：2013 年我们怎么把 FDE 当成一套产品战略来用，做出了那个数据平台，而正是这个平台，才让 Palantir 成了 Kevin、Nat 他们后来能在上面继续搭东西的底座。这一切的源头其实特别朴素。先交代下我的背景：我在 Palantir 是从软件工程师起步的，主要做水平可扩展的存储方案。我们说 forward deployed（前置部署）的时候——我本人是被前置部署到伊拉克、阿富汗那种地方的。照片里这个人是我，在 Bagram，那个基地现在已经不在了。但当时的念头很简单：怎么把软件搬进最要命的环境里去造，让它真正对最需要它的人管用。所以 forward deployed 本来就是个军事术语，我们当年是当真的。

[1:24] Vinoo Ganesh

Um my claim to fame from Palanteer is I built something called project frontline which was the rotation program that took our software engineers and made them forward deploy engineers. So the folks that you see at OpenAI, Anthropic, XAI, a lot of the FDs, 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. Uh built the same program at Citadel afterwards. So across the hedge fund, how do we build the right data products and software products to help portfolio managers generate alpha? Um this is a quote from the guy who named uh forward deploy engineering at Palanteer. It's from a couple days ago and um Sham is the CTO of Palunteer 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 FTE 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 deploy 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 tenant and the core insight was an FTE 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.

我在 Palantir 最拿得出手的一件事，是做了个叫 Project Frontline 的东西——一个轮岗计划，把我们的软件工程师变成 forward deployed engineer。你今天在 OpenAI、Anthropic、xAI 看到的那些人，很多 FDE，大概 350 号，都跑过这套培训体系；我们靠它让他们明白，一个以产品为导向的前置部署工程师到底该具备什么。后来我在 Citadel 又搭了一套同样的东西——在对冲基金这边，怎么做出对的数据产品和软件产品，帮投资经理挣到 alpha。屏幕上这句话，出自当年在 Palantir 给 forward deployed engineering 起名字的那个人，就这两天说的。Shyam 现在是 Palantir 的 CTO，我觉得这句话正好点破了我听上一场时那股别扭劲儿的来源：FDE 的第一条根本真理是——这不是一个岗位，这是一套产品战略。我们是通过 forward deployed engineering 这个镜头，去发现到底该造什么。所以那种盯着公司市值去倒推合同能签多大的打法，根本不是当年真实发生的事。真正的内核洞察是：评判一个 FDE，看的是他能不能成为产品团队的延伸，能不能识别出机会点，并把解法泛化成产品。

[2:44] Vinoo Ganesh

And so this is the story of how we actually made project Frontline at Palunteer and what I'm using to build this function out at Kepler along with Susanna here is one of our founding engineers. Um back in the days, Palenter was first trying to get into big data. So around 2013, uh 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 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. 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. Uh 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 is 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

下面就是 Palantir 当年到底怎么做出 Project Frontline 的故事，也是我现在和 Susanna——她是我们的创始工程师之一——在 Kepler 搭这套职能时所依据的东西。早些年，Palantir 刚想切进大数据。大概 2013 年，我们冒出个想法：要存交易数据。做出来的产品叫 Phoenix。Phoenix 完全是在真空里造出来的。我们没跟客户聊过，不了解我们的金融、银行客户，什么都不了解。我们干的事，是在完美隔离的条件下设计了一个系统，它在特定条件下跑得天衣无缝，一撞上真实数据就当场炸了。事情很简单：我们有个大型金融客户，思路是——把你的数据按分桶的 keyspace 存起来，这样滚动淘汰和数据留存都很省事。结果很快就撞上一个现实：很多银行和金融机构的数据并不干净。所以一碰到空值，它就默认落到 epoch，也就是 1970 年 1 月 1 日。而我们的留存策略是：把 1970 年 1 月 1 日到 2013 年之间每 10 分钟切一段，每段起一个时间分桶的窗口。问题是 Cassandra 每个文件句柄要 5 MB，也就是说按我们生成的 230 万个 keyspace 算，光把服务器启起来就要 14 TB 内存——出生即死亡。当时也没有别人可以求助，屋里就我们这一拨人、就我们这一家机构。然后我们想明白了一件挺朴素的事：真正的缺口，并不在于我们

[4:24] Vinoo Ganesh

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 FD 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 Palanteer and other places. what we learned from those experiences and how they informed building FTE at every other institution. The first starts from something fairly simple. Palenter was onboarding uh a large-scale dispatching and shipping company. We sat down with the VP of operations who generated a 47page requirements doc. What they wanted is 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.

没去打听客户是怎么用我们产品的。缺口在于：我们在没有真正嵌进客户现场的情况下，就把「和客户共同打造一个软件」这件事的所有权给认领了。这场分享的全部目的，就是想说服你一件事：forward deployed engineering 是一套产品战略。当 FDE 是产品职能的延伸，不是 go-to-market 职能的延伸。所以接下来我会讲四件事、四个我在 Palantir 和别处亲历的真实故事——我们从中学到了什么，以及这些东西又怎么反过来塑造了我后来在每一家机构里搭 FDE 的方式。第一个故事的起点很简单。Palantir 当时在导入一家大型的调度和航运公司。我们跟他们的运营 VP 坐下来谈，人家产出了一份 47 页的需求文档：要一个定制看板、14 个指标、下钻、告警，一整套庞大的 BI 工具，一个预估三个月的开发项目。这过程里挺搞笑的一点是，我们照单全收了。我们花了四个月做这个项目的范围界定，想彻底搞清楚这个客户到底要什么——直到我们中有个人真的跑到现场去了（纯粹因为他家人正好住那边），问了一句：周一早上，你拿到这些信息之后干的第一件事是什么？

[5:43] Vinoo Ganesh

The dispatcher said, "I check if trucks are 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 4 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 designed 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 open uh AI or FD deployment companies are all approaching it in a slightly different way than how Palanteer did which is we have the people are going to go on site and build things. What do we build? So I think of this in terms of an XY situation.

那个调度员说：我看看有没有车晚点，然后打电话给调度，安排把新的库存调过去、或者换一家。整件事其实可以简化成一条再普通不过的 Slack 告警——最后我们做的就是这个。4 个小时，我们就把这个问题从头到尾解决掉了。从 forward deployed 的视角学到的第一招是：识别出真正的问题，交付真正该交付的东西。绝大多数时候，人们并不需要庞大的 BI 看板，不需要一整套从头设计到尾、完整成型的软件。他们有一个问题，他们要的是这个问题真的被解决。所以我们学到的第一件事是：在你动手造任何东西之前，作为产品团队的延伸，你得先搞清三件事。第一，你到底想达成什么？也就是解决这个问题的核心目标是什么。第二，拿到解法之后会发生什么？第三，客户今天是怎么解决它的？现在这些 OpenAI 之类、或者做 FDE 交付的公司，路子都跟当年的 Palantir 稍有不同——我们当年的做法是：派人去现场造东西。那造什么？所以我把它理解成一个 XY 问题。

[6:56] Vinoo Ganesh

Customers describe solutions not problems. Your job as the FTE is to understand what the problem is. Customers don't know what happens next and your job as the FD is to define it.

客户描述的是解法，不是问题。你作为 FDE 的活儿，是搞清楚问题到底是什么。客户也不知道下一步会发生什么，你作为 FDE 的活儿，是把它定义出来。

[7:08]

[snorts]

[笑声]

[7:08] Vinoo Ganesh

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 Palunteer. 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.

我的解法和结论都很简单：如果解决这个问题的工作量不到一天，那就直接做出来、上线、把这个闭环关掉。别把它搞成什么产品战略，别急着去扩展产品愿景、把 PM 拉进来、走一整套流程。如果你能用一种短平快的方式把问题解掉，那就先这么干——这就是我们在 Palantir 最初做的事，我们就是这么起步的。这里的秘密在于：谁定义了问题，谁才真正拥有这个解法。正因为我们能亲眼看到这位航运运营人员面对的问题、能定义解法、能把真正的解法交付出去，我们就永远是那套系统的主人，也就有资格去描述后续的解法该长什么样。掌握了要造什么，也掌握了围绕这个解法的叙事，你的位置就会变得非常有力量。这也是为什么 FDE 在早期销售阶段真的很值钱。

[7:57] Vinoo Ganesh

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 Palunteer days. Um we had a data quality engineer who was viscerally adamant to a pipeline adamant about how to solve a pipeline stability issue. 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 our own data pipelines. We had an easy solution.

这不是因为他们特别擅长跟客户打交道，也不是像有些人说的那样——我们这群软件工程师并不社恐。真正的原因是：我们确实在用一小口一小口、能消化得下的方式解决客户的问题，这为我们赢得了信任，而信任让我们拿到了接触真问题的入场券——之后我们才能从产品战略的角度把它泛化出去。Foundry 是一个能横跨众多行业的通用产品解法，而它背后是我们在一线做了成千上万小时这类事情沉淀出来的东西。好，下一点：行动比嘴上说的更有说服力。这同样是 Palantir 时期真实发生过的事。我们有一位数据质量工程师，对某个管道稳定性问题该怎么解，抱着一种近乎生理性的抗拒。我们每天要往某人的 S3 bucket 里扔大约 1TB 的数据，这给我们自己的数据管道造成了很大压力。我们本来有个很简单的解法。

[8:53] Vinoo Ganesh

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. 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, "Park 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 Paret files because Parquet didn't have a native reader that you could just open and view. 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 2 days massively reducing data costs. I think the pipeline execution time went from 17 hours to about two.

与其扔一大堆 CSV，我们可以把所有东西迁到 Parquet。对我们的管道更友好，对成本更友好，从算力的角度也更划算。但就是有一位工程师本能地反对，我们怎么都想不明白为什么。这事我们前后提了差不多一年，每次她都顶回来。每次我问她，她就说：“Parquet 差多了，根本不好使，我理解不了。”于是我们决定干脆去这家客户的现场，看着她用我们的工具，把这个流程从头到尾走一遍。我们看到的是：她在手动把 CSV 从 S3 下载到自己的 Windows 电脑上，双击打开，然后肉眼抽检一下数据质量。这套动作她在 Parquet 文件上做不了，因为当时 Parquet 没有一个能双击打开直接看的原生阅读器。仔细想想这问题挺好笑的——她抗拒得那么本能，其实根本没搞清楚这件事能给她带来什么好处。那天晚上我们就写了一个 Parquet 查看器。两天之内她就批准了这次迁移，数据成本大幅下降。我记得管道的执行时间从 17 小时降到了大概 2 小时。

[10:01] Vinoo Ganesh

And what this teaches us it's 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. So you as an FTE 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. 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?" And their reaction is, "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. 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. Your goal as an FTE 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 FTE is informing your product strategy. You earn the right to extract user pain and define product strategy by solving small repetitive problems.

这件事教给我们的道理其实很朴素。当你跟用户一起工作的时候，你本质上是现场的观察者。而行动比嘴上说的有说服力得多。所以你作为 FDE，应该盯住的是：用户做了不止一次的任务。也就是说，如果他们同一天、同一个时间段里重复做某件事，或者一周做好几次、一小时做好几次，那就是一个模式，是在提示这里有问题，也有机会。任何时候用户在工具之间复制粘贴——把东西从一个工具搬到另一个工具——都是机会。任何时候他们出现这种反应：你问“你觉得这个问题怎么样？”，他们回一句“我也没办法，只能这么干”，带着那种由内而外的无奈——那里就有机会。任何时候用户切换工具或者切标签页，都是机会。还有，任何时候用户在任务做到一半时掏出手机——他们正在用你的软件或者别的什么走一个流程，然后掏出手机——那就很明显了：要么这问题很烦人，要么这软件太慢了。你作为 FDE 的目标，是让他们的明天跟今天不一样。而这一切从一个问题开始：你早上最烦的那件事是什么？我们每天早上都要来上班，每天早上都有必须解决的事。这又回到那句话：FDE 是在为你的产品战略提供输入。你是靠解决一个个小而重复的问题，才赢得了挖掘用户痛点、定义产品战略的资格。

[11:31] Vinoo Ganesh

Now the most valuable intel here is never going to 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. 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 FTE should do is get access to customer information by getting in the room where things actually happen. 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. And the way I've heard this put and the way we threw it around a palunteer is residents get the truth. Go on site.

而最有价值的情报，永远不会写在文档里。我们之所以能看到 Maria 的困境，是因为我们刷卡进了他们的办公楼，我们人就在现场。我们去过阿富汗，去过伊拉克，在 Soho 跑来跑去，在 Palo Alto、在旧金山也是这样。绝大多数真正重要的东西，只会在办公室这四面墙之内、当场发生。你在客户现场的门禁卡，还有你的邮箱地址——你那个外部合作方身份的邮箱地址——就是你的数据开采许可证。每个 FDE 要做的第一件事，就是通过进到真正发生事情的那个房间里，去拿到客户的信息。一切都活在那个环境里。这种东西你没法靠发问卷调查出来，你必须人在现场。挂个名当 forward deployed engineer 太容易了——坐在纽约一间漂亮的会议室里就行——但真正的问题不在那儿，解法也不在那儿。我听过一种说法，我们在 Palantir 内部也常这么讲：住在当地的人才拿得到真相（residents get the truth）。去现场。

[12:30] Vinoo Ganesh

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 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. 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 Palunteer tripped into. And what it came from was not this understanding that by making everyone stick everything in elastic search and you know scheming everything we can solve every problem. 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. 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

第三点：当你定义了语言，你就掌握了叙事。我们有个客户——我相信在座各位的公司里基本都会遇到同样的事。从物流的角度看，每个人对“客户”的定义都略有不同。销售管他们叫 customers，运营叫 clients，财务叫计费主体（billing entities），开发叫 org ID。同一个实体，在客户内部不同团队嘴里说出来，根本就是两回事。这会带来巨大的痛苦：集成会崩，会有数据质量问题，管道会不停出故障。而它归根到底来自一个很简单的事实：我们都是人。我们定义事物的方式不同，是因为我们各自身处不同的环境，我们习惯用跟自己同类的人能听懂的方式去谈论问题。这是特性，不是 bug。所以 ontology 这个概念，某种程度上是 Palantir 无意中撞上的。它的来源并不是“把所有东西都塞进 Elasticsearch、把一切都定好 schema 就能解决所有问题”这种想法，而是一个很朴素的念头：我们得让人能在他自己最熟悉的那套领域语言里工作。所以当我说“定义语言”时——任何一个组织都由两样东西构成：名词和动词。名词定义实体，动词定义操作。FDE 后来逐渐在做的，就是把这些名词和动词搭出来，并且弄清楚该用哪套术语。在很多这类大企业里，用户不只是采用你的产品，他们其实也在采用你的语言。

[14:07] Vinoo Ganesh

what we were able to do is we're able to start defining the languages that we wanted people to use. I think in this case, we called them um uh c like 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 infosc just the number of people that logged in. All these phrases that we take for granted are illdefined by nature. 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? And that matters. So third piece here, defining the ontology. Your job as an FTE 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?

我们做到的，是开始去定义那套我们希望大家使用的语言。这个案例里，我记得我们最后统一叫 customers。换个场景，可能就统一到 ID 上。像 DAU（日活跃用户）这种词，对不同的人意思可能差很远：对产品团队来说是高质量的 DAU；而对 InfoSec 的人来说，就只是登录过的人数而已。所有这些我们习以为常的说法，本质上都是定义不清的。所以当一个用户采用你的产品时，他同时也在采用你的语言。现在有多少人在把东西叫做 skills？又有多少人把“带 prompt 的函数调用”叫成 MCP？这件事是有分量的。所以第三块就是：定义 ontology。你作为 FDE 的工作，是搞清楚这个 ontology 到底是什么。企业里哪些短语、名词、术语是被重载的？也就是说，哪些词被不同的人拿去描述同一个概念？第二，系统里的集成点都在哪里？

[15:07] Vinoo Ganesh

Are things going from Snowflake to data bricks? Are they going from Palunteer 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 FTE. 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. 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. 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. 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 FTEEs, the go-to market FTEEs to go out there and just do data integrations and sell the product.

数据是从 Snowflake 流向 Databricks 吗？是从 Palantir 流向 Tableau 吗？是从 Anthropic 流向 SAP 吗？这些集成点到底长在哪儿？中间那层翻译层是什么——一个术语是怎么变成另一个术语的？顺着往下问：系统边界在哪里？哪些是你永远换不掉的记录系统（system of record）？还有，客户描述自己问题的时候，用的是哪些词？比如有人说「我们做 AI，我的 agent 老是失败」——那 agent 到底是什么？我们连 FDE 都定义不清楚，居然还想去定义 agent，对吧？它是一句 prompt？还是一串步骤？把这些搞到有切身体感，非常重要。你的活儿就是去定义这些词。如果你能在自己的方案里把术语定义下来，你就能搭出 ontology，就能让客户用你的词去回答问题、用你的词去思考。所以这里的秘密是：一旦你成了语言层面的地基，你就锁死了这个位置。最简单的例子就是 skills、MCP，以及所有那些一年前还没人当回事、现在却是我们整个生态日常口语的词。当你能定义用户使用的词汇，并把它固化进你的平台，你就变成了那个地基——之后所有方案和工具都建在你上面。Foundry 让这套 ontology 得以被构建出来，而这又让下一代 FDE，也就是那批偏 go-to-market 的 FDE，能出去只管做数据集成、卖产品。

[16:35] Vinoo Ganesh

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. Um, they all are, I guess. But, uh, 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. Um, 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. 12 months later, this thing was all over the place. It was a almost 100,000 person customer. Uh it was running in a number of places for my then and my nickname at Palanteer Nat's not here anymore but she can attest to this became venue.groovy. My wedding people showed up wearing a name the shirt venue.groovy. 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. 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 customer FTEES are forward deployed software engineers or customerf 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 FTE. We have people that jobs are making customers successful. They're solutions architects.

这一课我们是在真正第一次动手做的时候，用很痛的方式学会的。最后一点：交付要快，但要按生产标准来建。这是个真事——好吧，我讲的这些都是真事。当时有个客户需要做数据保留（data retention）。我决定飞快地写个脚本，用 Groovy 写的，不知道在座有没有人知道这门语言，本来只是个临时补丁。它压根就不是奔着上生产去设计的，我就是随手糊了个东西解决眼前的问题——结果它就这么上去了。12 个月后，这玩意儿到处都在跑。那是个差不多十万人规模的客户，这脚本在好多地方跑着。它后来成了我在 Palantir 的外号——Nat 今天不在，她已经离职了，但她可以作证——这东西叫 vinoo.groovy。我结婚那天，有人穿着印着 vinoo.groovy 的 T 恤来参加婚礼。好笑的地方在于：我们用一种非常糙的方式解决了问题，确实把问题解决了，但我们没有把它产品化，没有想清楚终局是什么。结果我们被迫在之后好几年里，一直去支撑一个从来没被产品化的、极其糙的东西。所以再说一次：当有人说 FDE 就是前置部署的软件工程师、或者面向客户的软件工程师，说你的工作就是让客户成功——这不对。你按那个来干，就会出现刚才这种事。脚本和 hack 能解决问题，但它们没法推动你的产品战略往前走。也就是说，作为 FDE 你并没有把本职工作干好。让客户成功这件事，我们有专门的人负责，那叫解决方案架构师（solutions architect）。

[18:07] Vinoo Ganesh

So calibrating what you ship becomes the last mo most important skill here as an FTE. First, am I going to get a 2 a.m. phone call about this in 6 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 the right decision for the product as a whole? Or am I just solving this customer's painoint in a way that's going to have potentially small wins but negative compounding challenges later on? 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? What happens when this breaks? Am I going to be held responsible for that? Am I building something so missionritical 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.

所以，作为 FDE，最后也是最重要的一项能力，就是校准「你到底交付什么」。第一，六个月后我会不会因为这东西在凌晨两点被电话叫醒？如果会，那你大概就不该交付它。第二，为了快速解决这个问题，我付出的代价是什么？我做的这个决定对整个产品是对的吗？还是说我只是在解客户这一个痛点，短期赢一点小的，长期却在不断累积负面复利？我离开客户现场的时候，这东西交接给谁？交给客户？交给另一家机构？还是交给下一个 FDE？它坏了会怎样？我要为此负责吗？我是不是在做一个关键到不能出事的东西——一旦挂了，所有人都会恨我？那时候怎么办？所以我们必须去解决问题，但同时要清楚：什么时候该把这些方案收进核心产品，什么时候该干脆利落地把它扔掉。

[19:02] Vinoo Ganesh

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 is 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 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 FTE 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 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. Most people who are trying to develop an FTE function treat it like a product management task and a customer success uh 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. The right FTEEs 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 I have a friend who was spending time on an oil rig in the middle of the ocean. They shipped the fix before leaving the

现实是这样的：每一个 hack 最后都会进生产。只要它让某个人的日子变轻松了，它就一定会进生产，而你将永远要为这个 hack 提供支持。在前置部署工程、乃至整个工程领域，最危险的一句话就是「这只是临时的」。在座只要在软件公司待过的都知道，它从来不是临时的。我们到今天还在某台 IBM 大机上跑着四十年前的 COBOL 代码，就是因为当年打了个补丁。只要它解决了问题，它就不是临时的，它会一直活下去。所以从 FDE 的视角出发：你交付的每样东西，都当作它要跑 18 个月来做——因为它大概率真会跑那么久。而再一次，用「我在建产品」这个镜头去看，你就会很清楚哪些东西该进核心产品，哪些东西只是帮你赢来客户的好感。我们让所有一线同事都过一遍的那份速查表，长这样：大多数想搭 FDE 团队的人，是把它当成产品经理的活儿加客户成功的运营活儿来做——收需求、排用户调研、加洞察、跑流程，却从来没想明白怎么把这些洞察真正转成对产品方向的操控。而那批真正做对了、催生出 Foundry 这种东西的 FDE，做的是重新定义问题。他们拿到客户现场的门禁牌驻场，飞去阿富汗、伊拉克、索马里，飞去任何客户所在、我们必须在场的地方。我有个朋友当时是在大洋中间的一座石油钻井平台上干活的。他们会在离开客户现场之前就把补丁交付出去——

[20:38] Vinoo Ganesh

customer site to win the goodwill, but they owned 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 war fighter ecosystem at Palunteer or in customer ecosystems at Palanteer. your job as an FTE and what we learned and what Kepler is doing is using FTEE as an extension of the product function to enable us to build products that are actually sticky and that solve problems.

——用这个赢下客户的好感，但同时，他们在产品生态里对这个补丁端到端负全责。然后他们把这些补丁转化成产品杠杆。他们能把自己亲眼看到的问题，翻译成一套名词和动词，再用这套名词动词去定义之后每一个问题的解决地基。最后，东西真出事的时候，接电话的也是他们；跳上飞机飞到下一个地方去的，还是他们。所以问题不是「他们在这个过程里学到了什么」，而是「从产品角度看，他们交付出了什么」。这里的目标其实相当简单，我就用这句话收尾：产品杠杆是唯一能帮你赢下客户的东西。Citadel 里每一个操盘上亿美元的组合经理，背后撑着他的只有产品杠杆；Palantir 在作战人员生态里做的每一个决策、在客户生态里做的每一个决策，背后撑着的也只有产品杠杆。作为 FDE，你的工作——也是我们学到的、也是 Kepler 正在做的——就是把 FDE 当作产品职能的延伸，用它来帮我们做出真正有黏性、真正解决问题的产品。

[21:43] Vinoo Ganesh

And if you were to take one thing away, please don't treat FTEEs as go to market extensions. You can do that when you're palunteer 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 FDs to maximum degree. Thank you so much. [applause]

如果今天只带走一件事，那就是：千万别把 FDE 当成 go-to-market 的延伸。等你成了 Palantir、攒了二十年、有花不完的钱，你可以那么干。但你是一家早期公司的时候不能这么干——你得先想明白，什么样的产品才能让你把这些 FDE 的价值榨到最大。非常感谢大家。[掌声]