The FDE Playbook for AI Startups with Bob McGrew

Bob McGrew helped build some of the most influential technologies of the past two decades. Bob was an early engineer at PayPal, an early executive at Palantir, and was recently Chief Research Officer at OpenAI - where he led the development of ChatGPT, GPT-4 ,and the o1 reasoning model. During his time at Palantir, he was a pioneer of the Forward Deployed Engineer (FDE) model, a strategy that is at the heart of the AI boom today. On this episode of The Lightcone, he explains how FDEs became central to today's startups, why "doing things that don't scale at scale" works, and where he sees the biggest opportunities for founders working in AI.

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  With AI agents, there is no incumbent product. And so that, I think, is why you're seeing the FDE model taking off, because there's so much product discovery to do. You want to drive the contract size up. So you're doing more and more valuable work for this customer and also for future customers. The FDE model effectively is doing things that don't scale at scale.

• 0:29Harj Taggar?

  Hello and welcome back to another episode of The Light Cone. Gary wasn't feeling great today and couldn't be here, but we're thrilled to be joined by Bob McGrew. Bob was an early engineer at PayPal, an early executive at Palantir, and was recently chief research officer at OpenAI, where he led the development of ChatGPT, GPT-4, and the O1 reasoning model. Now, he's exploring the future of AI and has an exciting new role with the US Army that we'll get to in a bit. Bob, thanks so much for being here.

• 0:55Speaker 00

  Great to be here.

• 0:56Jared Friedman?

  So Bob, I've been particularly excited to sit down with you to talk about the four deployed engineer model, because this is a topic that keeps coming up in our lives. It is a really hot topic in Silicon Valley right now, and especially among the AI agent companies that we've talked about on this podcast a lot. You were in the room when it all got started, and so you know, like, you're exactly the right person to explain it. You were actually telling me of a funny story. You were at an AI conference that YC organized a few months ago, and you expected that all the founders would come up to you to talk to you about, you know, inventing ChatGPT. And instead, what all of these AI startup founders wanted to talk to you about was the Palantir four deployed engineer model.

• 1:36Speaker 00

  Well, and it's really true. It hasn't just been that one conference. As I've been advising startups this last year, I would say that a lot of them are pretty much exclusively trying to learn how the FDE strategy works.

• 1:47Jared Friedman?

  Yeah, so this is an intense topic of fascination, and it's super timely because it's actually become, I think, the dominant way that the AI agent startups are organizing themselves. I was looking earlier today, and if you look at the YC job board, there's over 100 YC startups that are hiring for a job with the title four deployed engineer, and up from basically zero three years ago. Perhaps, before we get really into it, for anybody who doesn't already understand, can you just explain what a four deployed engineer is and how it's relevant today?

• 2:18Speaker 00

  So a forward deployed engineer is someone typically technical and engineer who sits at the customer site and fills the gap between what the product does and what the customer needs.

• 2:30Jared Friedman?

  And how does this play out in practice?

• 2:32Speaker 00

  You'll have a product and you go to a new customer site, you, you start working with a new customer and the, the problem that they want you to solve is not a problem that you've ever solved before, but you believe that it's one that with a little bit of work, maybe a lot of work, you can solve for this particular customer and you'd be making a huge impact for them. You'd be delivering an outcome to them that would be extremely valuable for them. So you take the product that you have and FDE with help from the product team, figures out how to deliver that outcome, how to build that use case, how to, you know, deliver the piece of software that you've built in a way that actually works for the customer.

• 3:10Jared Friedman?

  To go all the way back to the beginning, you were there at Palantir when this whole model that is now like exploding in Silicon Valley was invented. Can you talk about how it all got started?

• 3:19Speaker 00

  The interesting way to think about the beginning of Palantir is that when we got started, the focus of our company was to build software for the intelligence communities, specifically software for spies. And so one of the challenges in building software for spies is that I don't know any spies. You probably don't know any spies either.

• 3:36Jared Friedman?

  Nope.

• 3:37Speaker 00

  And if you happen to find a spy and you go and ask them, so what is it exactly that you do?

• 3:44Speaker 00

  They're not usually going to tell you. And so we had to take an approach that was sort of very unusual at the time, but effectively we started by building a demo and we took that demo to potential customers in the intelligence community. And, you know, Stephen Cohen very famously did this, one of the founders of Palantir. And he showed them the demo and he said, you know, well, what do you, what do you think? And they said, well, this is terrible. This isn't related to what we do at all. And he said, oh, well, how would you like it to be different? And then, you know, they would say, oh, well, could you make this change and this change? He's like sitting there writing all of this down. So far, this story feels very much like you would, the, the standard advice you would give to founders today, right? That you have to go, you have to make something

• 4:28Speaker 00

  that people want. You have to get out of the building. You have to go talk to customers. I think we were, we were doing this back in the, in like the mid 2000s. And so, you know, there's a little bit of that meme where like, I spent years mastering this technique and Paul Graham just tweeted it out for everybody. But the thing that changes and that really causes the FDE strategy is that what you expect and the standard thing that you expect is that you spend a lot of time early on, you know, doing things that don't scale, going out and visiting customers, getting very close to the customers, and then you discover product market fit. And once you discover product market fit, you know, if you, and this is classic, you know, if you read Crossing the Chasm or any of these books, once you discover product market fit, you do something entirely different. So, you know, instead of going, you know, staying deep with the customers,

• 5:13Speaker 00

  doing as much as you can to really understand the customer, instead you want to embrace distance from your customer. And all you want to focus on is scaling. How do you sell more? How do you treat all customers exactly the same? And, you know, I think I want to say that if you're in a business where this is working for you, that's great. Don't do the FDE strategy. You have been given an amazing gift. If you have the opportunity to just scale, treat all the customers the same, go ahead and do that. But it didn't work for us. And I think this is where Sean Senkar, who's very early employee, you know, now that I think the president and CTO of Palantir, he really invented the FDE strategy. And the, the basic thing we found was that the customers that we had, the product that

• 5:57Speaker 00

  they needed was slightly different at every place. And so we moved from one customer, building a product for them. We went to the next customer, we saw they had something that was slightly different. And instead of sort of building two products or building the exact right feature for each of them at each, at each site, we built something that was more a platform than a product, that had the a lot, a lot of ability to be customized at each site. So when you do that, well, okay, you need to bring someone to the site to understand what the users are, are doing and, you know, build customization. And historically, that's been understood as services, right? So that's something you want to minimize. You don't want to be doing a lot of work per customer in this, you know, product market fit. And what Sean realized was that you can actually flip this around

• 6:42Speaker 00

  and make it valuable. So what he realized we needed was for the FDEs to act as product discovery. So they would go to the site, they would take the product as it was. And they would fill the gap between what the product did and what the users needed. So you know, the FDE goes and builds like a gravel road to where the product needs to go. And then the role of my team of the, the product and engineering team was to look at that and basically figure out how that should generalize to the next five customers or the next 10 customers and then turn that, you know, gravel road into like a paved superhighway.

• 7:18Harj Taggar?

  I feel like sales is product discovery is a concept that's not new, selling around before Palantir. But typically the view used to be like, you had your salespeople that went out and did like the sales and talked to the customers and they came back and reported to the engineers. But it seems like at Palantir was like the engineers were doing that work. Was that like a conscious decision or how did that come about? Especially when you're selling into like the government and defense, like you would imagine the natural inclination is to go hire some like experienced salesperson who's got a history of selling into the government and like.

• 7:47Jared Friedman?

  Some like Don Draper, like who wears a suit and has worked in the DOD for 20 years and like takes generals out to steak dinners and things like that. And that's actually not what you guys did, right?

• 7:56Speaker 00

  Well, I mean, there's two angles as one is, uh, we talked to a lot of those people early on and they said, why the hell would I work with a Silicon Valley company? When I could work with, you know, a big five defense prime. And then even when we talked to people who, you know, seemed like they might be successful in this role. It was just very clear to us that they wouldn't mesh with our culture and they wouldn't actually be successful. And when we tried doing something like this, it almost never worked. And so what we found was very different. And, and I think the difference between sales led product discovery and FDE led product discovery is it's sales led product discovery. You're talking to people from the outside. And again, this is important very early on, but it's not as effective as the FDE led product discovery where you're solving these problems from the inside.

• 8:40Speaker 00

  So, you know, the scope of a, of a traditional implementation might be, you start with something that's pretty close to what the product does. But you want to be solving one of the key problems that leadership has identified. If you're not solving one of the top five priorities for the CEO, it's probably not going to work. They probably won't have the energy to persist through the much more challenging route. Of getting effectively a new piece of the product built in a way that worked for them. Then, once you've solved that first problem, then the FDEs can, you know, identify other key problems in the enterprise, sometimes much more valuable problems than the ones that you were first targeting, that maybe it's not obvious that Palantir could have solved those

• 9:23Speaker 00

  problems, or that your company could solve those problems. But once you're there, you can see through Product Insight that you can actually do this. And then you go and solve those problems. And so it switches from, you know, how do I sell the same thing to each customer to how do I land and expand?

• 9:41Jared Friedman?

  Bob, can you lay out sort of exactly how the FDU bottle works at Palantir? Like, if you were giving people almost like an instruction manual, like, here's how we did it?

• 9:51Speaker 00

  Yeah. So I think a starting point is to think about how the team was structured. And of course, there's many different iterations, but I think this is, this is the key thing that remains constant, is that the two key roles are those of what we call the Echo Team and the Delta Team. The Echo Team were embedded analysts. So they would go to the customer site, they would speak to the users, they would try to figure out what demo or what use case really made sense for the users at this site. What was the key problem that could be solved? And they would also be the account managers. So they would also be the people managing the relationships at the customer site. And the Delta Team, the deployed engineers, were effectively

• 10:35Speaker 00

  software engineers, typically very good at writing code extremely quickly, eating a lot of pain, as we put it. And they would be the ones who sort of took those ideas and brought them into the real world and built a solution, a prototype, but something that could actually work. And then deploy that for the customer. And all of this would come in a very short period of time. So you go in with an idea for what you're going to work on. You set up a few months in that you're going to have a presentation with leadership to show them your progress. And then if that presentation goes well, then you're going to actually deploy and go organization wide.

• 11:20Diana Hu?

  The interesting thing about these two roles is very different kinds of people and profile. How would you even go about finding the right person to be in these roles? Because it's not just a regular engineer that could fit FTE. They needed to have more of that talking to users. Or the echo team also had to be more technical. It wasn't just an account manager. How do you Palantir build this early team?

• 11:43Speaker 00

  Yeah, so the echo team, a classic profile for someone to join your echo team would be someone from the domain you're working in. So possibly a former army officer or someone who worked deeply in healthcare. So they have deep domain knowledge. But, and this is really important, they need to be rebels. Or Sean would probably call them heretics. They need to be someone who understands how things are done right now and recognizes that it's insufficient, that it doesn't work. Because if their perspective is they come from this world, it's great. Then they're never going to be able to figure out the step function change that the new software has to be able to make.

• 12:24Speaker 00

  Because if you can't make some sort of 3X or 10X change within that organization, then there was no reason to go through all the effort of doing this. You might as well have sold some sort of like very simple piece of software. So that's the key profile for the echoes. And then for your deltas, you want someone who's really good at prototyping. So the wrong profile for a Delta would be someone who's a craftsman, who really loves, you know, making sure the abstractions are exactly right, that, you know, they're building software that's going to be maintainable for, you know, a dozen years, right? Because that's not the role. That's not the job. And what you want is someone who can go in, you know, figure out, write some rough and ready code.

• 13:08Speaker 00

  Sometimes that code is beautiful if you get the right person, right? But usually not. Again, that's not the key portion of the job. But someone who can, who can go actually deliver that outcome in the form of software on a timeline. And then it may be the case that the first version they write has to be thrown away. And maybe they write a complete second version. Maybe someone else writes a second version, depending on that person. But those are, those are the key sets of skills.

• 13:31Diana Hu?

  It does sound a lot like a founding team.

• 13:34Speaker 00

  Yes.

• 13:34Jared Friedman?

  It sounds a lot like a founder.

• 13:35Speaker 00

  Yeah.

• 13:36Jared Friedman?

  Would you hire former startup founders and turn them into these roles? Or did it go mostly the other way? I mean, I think it's no coincidence that Palantir has spun off like an incredible number of startups because this FDU training, this is like exactly the training to become a startup founder. You're learning all, all the startup founder skills, right? But did it go in the other direction too?

• 13:53Speaker 00

  You know, back in the day when we were getting this started, there was not a huge supply of founders for us to pull from. I, I think, you know, maybe they, maybe that's the opposite now. But, but I think it's, I think you're actually quite right. What you're doing, uh, you know, in each of these new environments at each of these customer sites is a little bit like being a startup founder. But you're a startup founder where you have access to some very powerful piece of product leverage that makes your job easier. This is, I think, great training. And like you said, this is why you see so many startups from Palantir founders.

• 14:24Jared Friedman?

  So the, the common knock that you hear on this from people who don't really know what they're talking about is like, oh, it's just consulting dressed up with fancy marketing speak. Why is that wrong?

• 14:35Speaker 00

  I think before I say, I don't want to tell you glibly why that's wrong. Because I think there's actually a real risk that it's right. Right? And I think, you know, if you, if you go back to 2015 and you talk to people about Palantir, maybe you would hear two things. One, that Palantir is evil. But the second thing you hear is that it's a consulting business that is never going to scale, you know, that it's actually like a bad business. It's not a software business. And we spent a lot of time trying to understand whether that was a correct characterization or not. From a business model perspective, one of the key things that you will see, that you should see, is that it may be the case that you're, when you go into, you do a new deployment at a customer, that you're actually losing money early on.

• 15:16Speaker 00

  As the longer you're at the customer, first thing is your product, because of the product discovery, gets better suited to what the customer does. And so you no longer need a large team of people at the customer site figuring out what the customer is doing, you know, paving, you know, writing that code. The second thing is that you should be earning the right, as Sean would put it, to have access to more important problems at the customer site. And so you should see, basically, that your cost per value of the outcome you're delivering is going down. And so your profit margins start off negative, but then ultimately become positive after some period of time, maybe a year, maybe multiple years at the customer site. And if you look at it from that perspective, you can see that you're actually delivering, you know, real repeatable value.

• 16:02Diana Hu?

  I guess one fascinating piece to make this work and drive the cost down is really the product team.

• 16:07Speaker 00

  Yes.

• 16:08Diana Hu?

  So how does the product team fit in and work with the FDE team?

• 16:13Speaker 00

  I think on the engineering side, it actually, you know, it feels, my job on the, as an engineer, was actually not so bad because early on, in the early days of Palantir, you know, we were, you know, doing this founder-led discovery and we were, you know, building new products. And later on, at the later days of Palantir, we were still doing that. We were still building new products. This felt great, right? But the roles that were really different are the FDE team, but then also the product management team. And so the product that you're building, instead of being highly verticalized, and you know, this is one flow that millions of people are going to be going through, like if you're building Airbnb, right? Instead, the role of the product team is really to hold the product vision.

• 16:54Speaker 00

  And so you have to think, when I see those new problem that we're seeing on a customer site, what is the generalizable version of this that applies to the next 10 customers? Because if you, you know, there's a classic failure mode here where, you know, the FDE implements something for one customer and you say, great, well, that's how you should do it. And you bring it directly into the product. And it turns out, if you do that, you're building something that's over-specialized for one customer. And so the part of the magic here is being able to build the kind of product and with the kind of product people that can look at that and sort of guess the correct problem that you're solving, which is always a little bit more general than the problem that the customer is coming in with.

• 17:40Diana Hu?

  So there was some wisdom to figure out which bucket it fit. Is this just for this vertical or it could be generalized? So could you give us like an example of what that looked like in terms of the products and verticals and what fit in one bucket versus the other one?

• 17:54Speaker 00

  Yeah, I mean, probably the, the sort of like most basic example here is, is sort of the invention of the Palantir ontology itself. And so when we first started talking about working with, you know, the US government and specifically working in intelligence, you know, should we have a database table for people and a different database table for money and a different database table for this? And this is super obvious, I think, at this point, if you, if you go down that route and you try to deploy to multiple people, your, your database doesn't make any sense. And so, you know, the, the change here was say, well, we need to pull this up to a higher level of generalization. And instead of thinking about specific types of objects, we should allow that to be defined per customer by

• 18:36Speaker 00

  the forward deployed engineering team. And so that's the, the sort of origin story of where Palantir famously got its ontology.

• 18:42Jared Friedman?

  So how does that work today? Is there like a base database schema that has common reusable objects like people and money that then gets customized per site?

• 18:52Speaker 00

  Well, just, I mean, the database scheme is extremely general. There's just this notion of objects, properties, media, and links between objects. And here I'm talking about Palantir's government product, which was our first product. But the ontology is what includes all of the specialized information that's per customer.

• 19:10Speaker 00

  And that says, oh, well, this is a person. This is a ship. This is a money flow. And again, this is, I think, really the very most basic example. But if you build something for just one customer, then you're going to be thinking in the description that applies to that customer. But instead of saying, okay, well, for people, we do this. You want to be able to pull it up a level and say, okay, well, there's this common operation that we want to apply to things that have this property, like people have this property, but maybe also ships have this property. But let's be honest, money payments do not have this property. And so you have to think at a higher level of abstraction. We didn't hire product managers for a long time. And when it did come time for me to hire product managers,

• 19:56Speaker 00

  I would interview people who were amazing product managers at other companies. And I would ask them to think at this level of abstraction. They were very, they couldn't really think at this level of abstraction. They would say, okay, well, this is the flow. This is what it should look like for this customer. But that was the wrong thing to do here. And they needed to pop up a level and think at the level of like, how does this work in the context of the ontology? How do we change the ontology so that this specialized thing works across customers? And of course, there's many other examples that don't have anything to do with it.

• 20:26Harj Taggar?

  I mean, does that create any sort of cultural tension at Palantir itself? Because it sounds like you're describing like the FDEs are sort of these like heretics. They like, don't want to generalize. They want to do what's best for the customer and build specialized solutions. But presumably for your own internal product team, you do actually want to hire the people who can think at some level of abstraction and want to build like maintainable code that lasts for a while. Surely that must have created tension somewhere where there's an FDE who's like, no, I don't want to use like the generalizable ontology. I want to kind of like do it this way.

• 20:54Speaker 00

  Well, I mean, absolutely, there was always a lot of tension. And I would not frame this so much in terms of like the skills that different people had. Because it was also very, you know, I think it's a lot about the environment, what people do in the environment they're placed in. It was also very common for FDEs to work in the field for a long time and then say, hey, I can really fix these products and then come in and do an amazing job on the product side and think at that level of abstraction. But when you're at the customer site, you are faced with one very specific problem.

• 21:20Harj Taggar?

  Maybe the incentives are different versus the skills are different.

• 21:22Speaker 00

  The incentives are different. And so you're solving one very particular problem. And it makes a lot of sense to just take the simplest approach to solve that problem. And that is in fact what the FDE should do. That's what the gravel road looks like. And then the paved road, though, you know, has to, has to go by not just this one customer, but like a bunch of other customers that are further down the road. So the paid road often looks a little bit different. But the flip side of this, though, is, you know, imagine you said, well, clearly this FDE approach is just wrong, like the FDE is building the wrong thing. What if the product team just thinks really hard about what to build? And then they go build that. They're absolutely going to build the wrong thing. In fact, the, the way that we would often build features early on is that, you know, first, the FDE team would build something, see something at one customer.

• 22:05Speaker 00

  We'd bring it back to the product team in Palo Alto and we'd say, okay, what's the right generalized versions? And that those FDEs would participate in those discussions, right? That was incredibly important. And then we'd identify several other customers. Well, if it worked for this customer, we think it could work for this other customer. So let's bring the FDEs from those customers in as well and help them design. And they, they can help us design this feature so that when we build something, we know it'll work for, you know, the customer it was initially prototyped and we know it will work for these others. And then, of course, you know, if you're, once you've built that context where everybody can see here are three different workflows that are subtly different, then suddenly you're not having this argument about like, well, you know, we think it should be general and we think it should be specific, but everybody is solving the same problem.

• 22:50Speaker 00

  And then I think that really, that really melds the incentives.

• 22:53Jared Friedman?

  Do you feel like it requires a lot of organizational discipline to keep this model from devolving into peer consulting where the FDE teams are just off building like whatever product the customer needs?

• 23:04Speaker 00

  Yes. You absolutely have to focus on this. And I, I think one of the other failures, by the way, that's even prior to that and more, the, the easier failure to become a consulting firm. It's where you build the product in the field that the customers are asking for, rather than the one that's actually valuable to them. Because it's often the case that the customer, right? You don't actually, the customer is like a whole organization, you don't talk to the customer, you talk to maybe the CIO, right? Or you talk to one sponsor, usually a couple of levels down from the CEO you only get to see every once in a while. And it's often the case that they would rather just have you solve some problem that's easy. For them to have you solve, rather than one that's really impactful and improves the business.

• 23:49Diana Hu?

  Going back to the opening from Jared, what's going on with all these AI companies really now ramping up and hiring tons of FTEs? What had, what had caused them to really adopt this model, which was not the case for the previous generation of companies with SaaS? What happened?

• 24:07Harj Taggar?

  Especially because I feel like even as Palantir became successful and the FTE model became well-known, it was still seen as, well, that's a one-off thing because Palantir is a unique company and like selling to the government is just like a-

• 24:18Speaker 00

  Like a, like a, like a really weird thing.

• 24:20Harj Taggar?

  Yeah, but you wouldn't, don't try this at home.

• 24:24Harj Taggar?

  Mindset, right? Like now everyone's sort of, it's become, like Diana says, it's become very commonplace. Has that, one, has that surprised you? And then two, like, why do you think that's happened?

• 24:33Speaker 00

  This was absolutely a surprise to me, that, you know, my first, second and third pieces of advice to people who are thinking about trying an FTE strategy is like, don't, don't do this at home. If you can avoid it, like, it's, it's probably bad for you. Probably you're going to end up doing services. And then only if you really try hard not to do it and fail. Then, well, then maybe actually it's a moat for you. If it's the only thing that can possibly work in your market. So what's special about this market, right? Why does the AI agents market work this way? Maybe the, the starting place is why did Palantir have to adopt this? The Palantir market is not one coherent market, right? So we were working with national intelligence agencies, with national law enforcement, with the military.

• 25:16Speaker 00

  All of these organizations had some similar projects, right? But even, you know, the difference between a counter-proliferation workflow and a counter-terrorism workflow. One, you're trying to figure out, you know, who's building bombs. And the other one, well, who's building nuclear bombs and who's building IEDs? And those are actually quite different in terms of how they work. And so there's this incredible heterogeneity. And the market, you should really think of the market as different segments. Inside each segment, you can build something. And, you know, the crossing chasm story a little bit applies. So, you know, you're, you're starting off, you know, nothing seems to work. Suddenly you find product market fit in the segment. You know, you can deploy the people that are doing this kind of workflow.

• 25:59Speaker 00

  And then, you know, at the next customer, you find the same people doing a similar workflow. And you can deploy with very little customization. But then there's a natural limit to that. And so now you want to go tackle a different market segment. And you have to, you know, develop a new piece of technology. And then that can be referenced in, in other market segments. And like, like I'm sort of saying here, a segment is not the same as a customer necessarily. Especially in an enterprise or a very large enterprise like the government, where a customer is, you know, tens of thousands of users potentially. In that case, that's where, you know, the FD strategy matters because you're doing, you know, it's like you're doing things that don't scale,

• 26:41Speaker 00

  but you're doing it scalably over and over again for every market segment that you enter. Why do we see this with AI agents? I think the other thing that's unique about Palantir is that we were building a completely new type of product. The product that the user saw, well, you know, they were used to basically, you know, tracking, doing their analysis and tracking people in a tool that looked like PowerPoint. And they would collaborate by sending these files back and forth with each other. But the product we built was tied, basically said, hey, when you're, you know, drawing out that link diagram, you're not just editing a file, you're actually changing a database and everybody has the same database. And so while to the user, it looked like a small change on top of the, the work they were doing.

• 27:26Speaker 00

  To the enterprise, to the organization we were selling to, it was a completely different market category. And that, I think, is what's happening with AI agents. Where, you know, this is a completely new market category. If you are implementing, you know, a standard SaaS product and you're replacing one way of paying bills with a different way of paying bills, everybody understands what that market is. And so, you know, the, the segment, you know, there's not all this little segmentation. There's not a lot of, there's not the same kind of product discovery. You can then, you know, make a product that's better than the incumbent product and scale by replacing that product. With AI agents, there is no incumbent product. And so also, I would say what it is to build AI agents is actually probably a lot of different things.

• 28:11Speaker 00

  And we don't know what those are yet. We've got to figure them out. Probably in five years, we'll look back, we'll be like, well, AI agents, there wasn't even a thing at all, right? We were actually doing all these different things. And so that, I think, is why you're seeing the FDE model taking off, because there's so much product discovery to do, and you can only do it from inside the enterprise.

• 28:30Harj Taggar?

  Okay, well, how does this relate to some of the classic YC advice, which is do things that don't scale?

• 28:36Speaker 00

  Well, that's the advice that you give to an early-stage founder. And the FDE model effectively is doing things that don't scale at scale.

• 28:45Garry Tan?

  YC's next batch is now taking applications. Got a startup in you? Apply at ycombinator.com/apply. It's never too early, and filling out the app will level up your idea. Okay, back to the video.

• 28:59Jared Friedman?

  Since you see a lot of people trying to apply the FDE model now to their new startups, including a lot of people who didn't work at Palantir and are sort of doing it like second or third hand, what are ways you see people getting it wrong or misconceptions that you'd like to dispel?

• 29:13Speaker 00

  Maybe I will start by saying, as I've advised a few different startups who are doing this, I think the startups, the most successful startups doing the FDE model have people from Palantir running the FDE model. The startups that I've talked to who are switching to the FDE model gained a lot of benefit by bringing on someone from Palantir in one of the core roles. As I said, the engineering team is often fairly similar, but maybe continues to be fun for a long time. But the actual mechanics of how the FDEs work, how you build these accounts, how you find the outcomes, those are actually quite different from a standard software firm. And so one of the key differences, and something that I think is actually quite difficult

• 29:57Speaker 00

  for people to understand, is how you choose a problem.

• 30:03Speaker 00

  And then how you price that problem? And fundamentally, what you're selling with the FD model is that you're not selling the installation of software, you're selling an outcome, as Sean would say, you're selling that you have solved a problem. The next question then is if you've now solved a problem that is value and delivering some value to the users, how do you price that?

• 30:27Diana Hu?

  That's a very common question we get from all these AI startups because in the age of SaaS, you would do it based on usage or subscription or seats. And this is completely different as outcomes. How do you even price it? How should all these AI founders price their solution?

• 30:46Speaker 00

  Yeah, I think one of the really important things that is differentiated between the FD model and your sort of standard SaaS model is that with the FD model, with a SaaS model in product market, you're going towards very simple, repeatable contracts, very simple, repeatable pricing that makes sense across all of your customers. And often, you're going to be quite comfortable with small contracts because the cost, the marginal cost of play is very low. With the FD model, you're going to get pushed towards larger and larger contracts. Like we talked about, you're going to be growing contracts per customer over time. The contracts, because they're complex, are going to be more flexible.

• 31:25Diana Hu?

  I think this is what the AI startups that we work with discover on their own. I have this company called Castle that does AI voice agent for mortgage servicing. So they work with very large banks. And the way they've actually been able to go live with large banks is exactly that model of ramping up, is the number of successful calls that we're handling all these mortgage requests. Then they had stipulations, when it goes to scale, it would be this much and that. And they kind of figured it out on their own and other startups as well, like Happy Robot is another YC company as well, doing AI voice agents for logistics. They're working with large companies like DHL, similar thing.

• 32:03Speaker 00

  There's an asymmetry here between you, the startup, and the business that you're selling to, which is typically when you're selling to a large enterprise, they don't believe they can actually accomplish anything. And that's because oftentimes they've had many large projects that have failed. They also don't believe you can accomplish anything, right? Because they think that you, the startup, are just like them. You, on the other hand, know that you can actually execute, right? And if you can't, well, you should go into a different line of business anyway, right? And so, early on, it makes sense for the startup to just take on all the risk and say, "We're gonna just believe in our own execution. And, you know, we're gonna take on the risk and you pay us if it works,

• 32:45Speaker 00

  or you pay us when, you know, we're actually able to expand." The one place this can go wrong is that particularly if you're doing something that needs to be deployed into the enterprise, you know, on-premise, or any piece of it needs to be on-premise rather than in the cloud, you do have to fight the IT team.

• 33:04Diana Hu?

  Yeah, I've actually seen that too.

• 33:06Speaker 00

  Yeah.

• 33:06Diana Hu?

  With some of these companies.

• 33:07Speaker 00

  And more generally, who needs to say yes inside the organization you're deploying into in order for you to succeed? Because those people do not think like startups. They are not aligned with the end user. And so, you're gonna have to figure out a way past them. And, you know, this is part of why it matters that you're working on one of the CEO's top five problems. Because you need to be able to bring in someone from the top to say, "Yes, give them authority to operate. Give them, you know, the ability to use, yes, you use this particular type of database. They need to use a different type of database. They, you know, you have all these very specific organizational things

• 33:50Speaker 00

  that are meant to apply to your IT staff who are building things in-house. But they don't apply to the startup. Let them do what they need to do.

• 33:58Diana Hu?

  How did Palantir get that executive buy-in? I think this is sort of what's happening with all these AI startups that are taking off and going from zero to seven, eight figures in revenue within a year. They figure out the executive buy-in, but it's all very haphazard, I would say, from all the stories I know of.

• 34:17Speaker 00

  That's how it felt early on, too.

• 34:19Diana Hu?

  Okay.

• 34:20Speaker 00

  It's a discipline, it's a skill. You know, you need really amazing leadership on the FDU team to be able to have that kind of discipline and, you know, to share what works, you know, and just get the practice of doing it at one customer. I mean, I think it's not surprising. I think Palantir is extremely good at this now, probably better than any other company. And that's, that's why, you know, the companies I've seen that have done this the best have sort of pulled that from people who've done it before. But it can be learned. We learned it.

• 34:49Harj Taggar?

  Jared pointed out earlier that the, I think the Palantir Forward deployed engineer model is not that different to sort of like classic YC advice around doing things that don't scale. We have this concept of like the Collison install, which is essentially we boil it down to don't wait for people to turn up to your website. Like go to them and get them to like install the software.

• 35:07Speaker 00

  And like physically go to them, like go to their office and like sit next to them.

• 35:12Harj Taggar?

  And I feel like it's always been a great starting strategy, but most startups aren't getting big contracts off the bat. So actually the reason they have to stop doing sort of like this sort of manual high touch process is you just can't get the growth rates to sustain without at some point having a product that scales. And it's kind of like what we were talking about earlier, like at some point you hopefully you build a product so good that people can figure it out themselves and then all of your problems are just scaling it. With AI, what's different is because these contracts are so big now, you can actually go quite far by doing like the high touch thing. And maybe something you could help us out with actually is like probably a common office hour question I get is like, how far can I keep pushing this? And my advice is largely like, well, like it's okay to be doing custom work per customer.

• 35:56Harj Taggar?

  You just want to get less custom per every customer. Maybe you could give like more specific, like higher resolution advice, like how do you know if it's okay to like keep adding new customers in this sort of like high touch, like I'm doing lots of custom work way versus, oh no, actually I need to be like abstracting out and building like an actual product here.

• 36:16Speaker 00

  Yeah. And I, and I think this, this is actually really encapsulates the, the key difference between, you know, the, the product market fit strategy and the FDE strategy. In the product market fit strategy, you want to be doing less work for every customer. You want to be driving down costs. You want to keep the contract size the same.

• 36:30Harj Taggar?

  Yep.

• 36:31Speaker 00

  In the FDE strategy, you want to drive the contract size up. So you're doing more and more valuable work for this customer and also for future customers. And because you're doing more valuable work, it's okay. You can leave the amount of customization you do per customer the same.

• 36:47Harj Taggar?

  So the KPI or the internal metric is like contract size, not necessarily like how much custom work they're doing per customer.

• 36:53Speaker 00

  There's two useful things here. So one, the thing you can measure. Yes. Contract size, I would even be a little bit more general than that and say the value of the outcome you're delivering. Because that's, that's actually the true thing, you know, and do you yet have the muscle in order to be able to monetize that and price that and capture that? Maybe not, but if you're able to deliver more and more valuable outcomes to the customer, then you know, you're, you're doing something right. The second piece that we haven't, that we didn't talk about yet is the value of the product. And so the other thing you want to measure is are you getting more and more product leverage against that outcome? This is all extremely counterintuitive when you're in it.

• 37:35Speaker 00

  It's very hard if you're an FDE or if you're leading an FDE team, there's a lot of things you have to do that, that seem very counterintuitive. You have to, you know, build for the customer things they're not asking for, but that they actually want. On the product side, you often think to yourself, how do I make a product that's just really easy for every customer to use? It's very easy and, and look, I, I struggled with this myself quite a bit, leading product early on. Like you want to focus on, on the user experience and you have to do that. But you also have to remember your other key customer is the FDE. Your product should be, you know, ultimately delivering a good thing to the user after FDE customization. But it should be delivering leverage to the FDE who's delivering that outcome at the customer site.

• 38:18Speaker 00

  And that, that amount of product leverage should be going up over time.

• 38:22Harj Taggar?

  Like they should be able to use your product to deliver more value to the customer without them having to go and like pull in three more engineers in order to do it.

• 38:29Speaker 00

  That's right. If, you know, the first customer you deploy at takes a lot of work. If you want to then go sell that same outcome to a different customer, then that should be a lot easier at the second customer. And it should get easier still as you go customer by customer. But then if you, if you really get it to work, remember that you're building a platform. So you're doing more than just, you know, a stack of vertical use cases on top of each other. If you've correctly abstracted away what the core concept is that you're really building, then you should also have an easier time. You should have more product leverage, even when you're not doing that use case, when you're doing something that's sort of similar.

• 39:07Speaker 00

  Or you will find that your FDEs, if it's really, if it's really good, you'll find your FDEs can figure out some new way to use that technique you built to solve something completely differently.

• 39:16Harj Taggar?

  There's almost like an internal market dynamic going on where like if you've built it really well, then the FDE should like choose to use it and you should see demand from the FDEs to use your sort of like abstracted product versus just like hacking a one-off solution themselves.

• 39:28Speaker 00

  Yes. Although I will just note, this is a very painful process for everyone involved. I probably can't use the word pain often enough in the FDE. You know, there are many times where I built something I thought was amazing and I thought it was beautiful and not, not there yet, right? But it would, it really would help the FDEs as soon if they just had the, the ability to see it. And I'd be like, please use my product. And they'd be like, no, it's just, this is way more work. It's like not helpful. And I will say, let's be honest, most of the time I was probably wrong and I was building the wrong product for them and you know, I should see that. But sometimes also I was on the right track, but you know, I hadn't done enough to make it easy for the FDEs to use.

• 40:05Speaker 00

  And so, you know, I would send, you know, the developers out into the field to deploy the, those early solutions and get them over the line, even to the point where the FDEs could use them profitably.

• 40:16Harj Taggar?

  Are the FDEs always right in that case? Whereas like, should the founders sometimes be just top down and say like, actually I just want you to do that, do it this way?

• 40:24Speaker 00

  I mean, the, the answer is like yes to all, all of these things. The other thing that comes up over and over again is just how much the right answer here is a matter of judgment. And I think, I think going back to this question about product vision, right? Like what is the right product that generalizes from, you know, this customer to the next three, to the next 10? You, you very literally do not have the, the information needed to answer that when you see that first customer. And so it's just, it, it becomes a judgment call.

• 40:52Diana Hu?

  So in the context of how all these FDE companies price very differently based on outcome.

• 40:59Diana Hu?

  How does that fit in with now the culture doing demos? Because there's this thing in, at least in SaaS, or I used to get this pushback from my engineers, demo-driven product development, it would be sort of looked down upon. But in this case, it's different for FDEs, right?

• 41:14Speaker 00

  One of the interesting things that happens there is because you have to go repeatedly show this to new customers, you're forced to give these new demos. But actually, I think demo-driven development works really well if you have the right kind of product. So in the early days of Palantir, we actually had one demo. It was a flow where you're stopping a terrorist plot. And we started this with just one of our features. And every time we integrated a new feature, we had to think to ourselves, how do I show that this new feature is actually helpful for the analyst who's going through this demo, who's stopping this plot? When we integrated a histogram, we had to say, well, how do we actually use this? How does that work with the existing features that we already had? And we went this, we integrated a map and we had the same question.

• 41:57Speaker 00

  And if you think about the world from what am I building? Then you're thinking about your capabilities. You might think of each of these features individually and how to build the best version of these features. But when you're building a demo, you're thinking about it from the customer's perspective. And a really good demo is something where you show it to the customer and you are creating desire in that customer for what you're doing. They have to see what you're doing and just want to reach out and grab it and bring it into their life. And if you see that, then you know that you've identified a real pain for the customer. And by doing that, that also forces you to develop a better product. Because not only are you thinking, okay, do each of these features make sense in isolation? But how do they work together?

• 42:41Speaker 00

  If I'm going to be showing this demo over and over again, even just simple things like moving from one feature to another, that part of the path has to be very straightforward. And those are all the kinds of product pain points that you would often see, but only later, after you've actually deployed to the customer. So what the demo does is it changes the locus of what you're thinking about from thinking about what can I build to what is it that the customer wants? And am I solving that pain point for the customer?

• 43:10Diana Hu?

  So it sounds like it's sort of this, you have to keep. Doing the gradient ascent in this very, very highly dimensional, multi-dimensional space and you keep changing the variables.

• 43:20Speaker 00

  Yeah, yeah, I think, yeah, maybe, maybe that's a really key point here is that the kind of company you have to build is a learning company. And I think everybody wants to build a learning company. But if you're a company like Google or Meta, it's very easy not to learn because what you're doing right now was working. And if you just keep doing it, the market is growing, you know, everybody wants to do what you're doing, you can, you can just sort of keep coasting on the same strategy and it's paying off for you. My advice to people, if they're thinking about where to join a company is I tell them to join a young company, not necessarily a small company, right? But a young company, because a young company is still figuring things out, it's still learning, it hasn't succeeded yet.

• 44:02Speaker 00

  You know, if you're just out of college, you want a young company that is growing really fast and then you'll be, you'll see what success looks like. That positions you exactly to be a founder of your own company later. This is why Palantir has birthed so many other startups is because even as a very large company, it is still a company where everybody all the time is learning, focused on learning and, you know, always doing that same grinding motion that it is to be a new startup. Because, you know, yes, you know, new startups, a lot of pain there too, right? That is like probably like the canonical part of the YC experience is that it's, it's not coasting. It's working really, really hard on something that you're not quite sure if it's going to succeed.

• 44:42Harj Taggar?

  Obviously, I mean, a monster's success for Palantir, then now a super big company, huge organization. We heard that you're joining another large organization, the US Army Reserve. Maybe you could tell us a bit about that and are there any lessons from the Palantir experience you're planning to apply there?

• 44:56Speaker 00

  Yeah, absolutely. I've recently joined the US Army Reserve as part of Detachment 201. And so, you know, one, one thing just to get out of the way is to say that what, everything I'm talking about here, these are my opinions, these are not the opinions of the US Army, the Defense Department, the US government. But I think it's this, it's been this absolutely intense experience and it's a really interesting story. So we are part of a unit that's advising the Army on technology and we are not just civilian advisors, we are actual officers. So, you know, we took the oath, I'm a lieutenant colonel in the US Army.

• 45:31Jared Friedman?

  I heard you went through basic training, too.

• 45:33Speaker 00

  I, I, uh, yeah, we, we went through the direct commissioning course. We've been trained by military academics, uh, often at five in the morning. That's the time that works for people on the East Coast and doesn't conflict with our day jobs. We learn from officers. Uh, I had to take the Army Fitness Test, uh, which, since I am not very fit, uh, you know, was something that I had to train for, for nine months. But it really matters because we're not just giving advice on the side. We have skin in the game. We are actually part of the organization that we're advising. And the Army itself, the leadership is very different from what it felt like, or in the early days of Palantir, when we were working with them back in 2005 or 2010.

• 46:15Speaker 00

  General Randy George, the Chief of Staff of the Army, Secretary of the Army, Driscoll, they have articulated a plan for the transformation of the Army. They know that the Army needs to change from, you know, the kind of, from fighting the kinds of wars we fought in Iraq and Afghanistan to fighting the kind of wars that are being fought today in Ukraine, or what it would look like if we face large-scale combat operations in the Pacific. They know the Army needs to move faster. They know the Army needs to change, and we are a part of that strategy that they're executing. As they've brought us in, they, you know, they have given us, they've outlined the priorities for the Army. They've given us each an area in which we're supposed to operate, but they've also given us the freedom to, you know, go around, look for problems, work directly with the officers

• 46:58Speaker 00

  on the ground to solve those problems, or if need be, to escalate that to leadership and get that fixed. And so I think one of the things that's, that's really interesting about it is, you know, in many ways, it does feel a lot like running the FDE strategy, you know, on the Army. We, we get to see, you know, what is the, what are the CEOs? What are the leadership's top five priorities? Can we make progress against those? But also in a world where you see that there's a disconnect between what the leadership wants and 20 years of how things have been implemented. And it takes a long time to change that. And so, you know, we are helping them make that change. I'm really eager to have the opportunity to make a difference.

• 47:36Jared Friedman?

  There's a question that we love to ask people on, on this podcast, which is, what do you think are the best opportunities for startup founders to work on right now?

• 47:43Speaker 00

  Well, you know, I think this really goes back to exactly this question of why is it that AI agents are pursuing the FDE strategy? And, you know, if you, if you zoom out and I put on my AI research hat, uh, for once in this podcast.

• 48:00Speaker 00

  I think what we've seen is that capability improvements are actually extremely fast. If you, you know, yes, I heard people, you know, after GPT-5, people feel like things are plateauing. But actually, if you look at this time period between April 2024, when the best model, you know, the release of GPT-4O, and April 2025 and the release of O3, that's an extremely fast rate of progress. And I think that's just going to continue. I think we're going to see capabilities continue to move quickly. But what's, what's really shocking, actually, is that the adoption is not anywhere near what you would expect from the speed of these capabilities. What the world is going to look like over the next five years is that the capabilities just race ahead and race ahead and race ahead. And somehow, the world feels increasingly banal.

• 48:45Speaker 00

  You know, you're like, you're in your Waymo and you, you aren't thinking, oh my God, it's not, you know, no one's driving this. You're like, ah, traffic, it's really slow.

• 48:52Harj Taggar?

  Yeah.

• 48:53Speaker 00

  And so, you know, just like with the world of the FDEs, where you have, you know, the FDEs filling the gap between this product and what the customers need. I think, you know, the, this is a time where there's so much availability to fill the gap between what the capabilities can actually do and what the customers are able to adopt. And in the early days of AI, if we, we sat around a table in 2018 and talked about what it looked like when AGI was built. People thought, oh, well, you know, it's, it's gonna, it's gonna, maybe, maybe over the weekend, it's gonna come alive and it's gonna take over the world. And, you know, one of the things that I think people missed in that was that, you know, AI needs to be adopted.

• 49:35Speaker 00

  It's something that doesn't just happen by itself, but you need human ingenuity and exploration and, well, dealing with a lot of pain in order to make that happen. And so I think there's just a huge amount of opportunity out there, looking at what are the capabilities that are there? But what does it take to make them really genuinely useful to people?

• 49:56Jared Friedman?

  There's an analogy that occurs to me. This might be a little bit forced, but it's almost like OpenAI is the home product team and the startups are the FTEs out figuring out how to get adoption of the like research that OpenAI is cooking up back at the home office.

• 50:13Speaker 00

  I think that's not a bad analogy at all. I think that is maybe the underlying truth of what's making this whole FTE strategy exciting again.

• 50:22Harj Taggar?

  Okay, that's all we have time for here today. Bob, thanks so much for joining us. That was really, really interesting. We all learned a lot and we'll see you all here next time.