Bob McGrew: How Palantir FDE Model Became the AI Playbook

1. 0:00 – 0:29

   Intro

   1. BMBob McGrew0: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.

   2. SPSpeaker0:21

      (Intro music)

2. 0:29 – 2:19

   From PayPal to Palantir to OpenAI

   1. DHDiana Hu0:29

      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.

   2. BMBob McGrew0:55

      Great to be here.

   3. JFJared Friedman0:56

      So Bob, I've been particularly excited to sit down with you to talk about the forward 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. Y- you were actually telling me a, a funny story. Uh, you were at an AI conference that Y- 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 (laughs) and instead what all of these AI startup founders wanted to talk to you about was the Palantir forward deployed engineer model.

   4. BMBob McGrew1:36

      Well, and it, it's really true. It hasn't, hasn't just been that one conference. Uh, 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.

   5. JFJared Friedman1:47

      Yeah, so there's, it's this 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 forward 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 forward deployed engineer is and how it's relevant today?

   6. BMBob McGrew2:18

      So a forward

3. 2:19 – 3:19

   The Role of a Forward Deployed Engineer

   1. BMBob McGrew2:19

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

   2. JFJared Friedman2:30

      And how does this play out in practice?

   3. BMBob McGrew2:32

      You'll have a product and you go to a new customer site. You, you start working with a new customer and y- 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 the 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.

   4. JFJared Friedman3:10

      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?

4. 3:19 – 7:56

   How Palantir Invented It

   1. BMBob McGrew3:19

      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 community, 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.

   2. JFJared Friedman3:36

      (laughs)

   3. BMBob McGrew3:37

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

   4. JFJared Friedman3:42

      (laughs)

   5. BMBob McGrew3:43

      Um, they're not usually going to tell you. And so, um, 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 uh, you know, Stefan 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 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.

   6. JFJared Friedman4:41

      (laughs)

   7. BMBob McGrew4:42

      But the thing that changes, uh, and that really causes the FDE strategy is that what you expect and the, 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 class, 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, 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, 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.

   8. DHDiana Hu5:33

      (laughs)

   9. BMBob McGrew5:33

      Uh, if you have the opportunity to just scale, treat all the customers the same, go ahead and do that. Um, but it didn't work for us. And I think this is where, uh, Shyam Shankar, who's very early employee, you know, now 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 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 Sham realized was that you can actually flip this around 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- 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 ten customers and then turn that, you know, gravel road into like a paved superhighway.

   10. DHDiana Hu7:18

       I feel like sales as product discovery is a concept that's not new, certainly 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 it 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-

   11. JFJared Friedman7:47

       Some like Don Draper like-

   12. BMBob McGrew7:48

       Yeah, yeah. (laughs)

   13. JFJared Friedman7:48

       ... figure who wears a suit and-

   14. BMBob McGrew7:49

       Yeah.

   15. JFJared Friedman7:50

       ... has worked in the DoD for 20 years.

   16. BMBob McGrew7:51

       Has credibility. (laughs)

   17. JFJared Friedman7:51

       ... and does, like takes generals out to steak dinners and things like that, and that's actually not what you guys did, right?

5. 7:56 – 9:51

   Product Discovery in the Field vs. Sales

   1. BMBob McGrew7:56

      Well, I mean there's two angles to this. 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..."

   2. DHDiana Hu8:03

      (laughs)

   3. JFJared Friedman8:03

      (laughs)

   4. BMBob McGrew8:03

      "... when I could work with, you know, a Big Five defense prime?" Uh, 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 that 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 l- led product discovery where you're solving these problems from the inside.

   5. JFJared Friedman8:39

      Mm.

   6. BMBob McGrew8:40

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

   7. JFJared Friedman9:24

      Hm.

   8. BMBob McGrew9:24

      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. JFJared Friedman9:41

      Bob, can you lay out sort of exactly how the FDE model works at Palantir, like if you were giving people almost like an- an- an instruction manual, like- like here's

6. 9:51 – 13:34

   Echo and Delta Teams Explained

   1. JFJared Friedman9:51

      how we did it.

   2. BMBob McGrew9:52

      Yeah. So I think a starting point is to think about how the team was structured, um, and of course there's many different iterations, but I think this is- this is the- 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, uh, try to figure out what demo or what use case, uh, 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, uh, the deployed engineers were effectively software engineers, typically very good at writing code extremely quickly, eating a lot of pain, as we put it.

   3. JFJared Friedman10:42

      Mm.

   4. BMBob McGrew10:43

      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, uh, for the customer. And all of this would come in a very short period of time. So you know, you go in with an idea for what you're going to work on. You set up, you know, a few months in that you're going to, you know, 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, you know, organization wide.

   5. SPSpeaker11:20

      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 a FDE, 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 did Palantir build this early team?

   6. BMBob McGrew11:43

      Yeah. So the Echo team, you know, a classic profile for someone to join your Echo team would be someone from the domain you're working in. So you know, 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.

   7. SPSpeaker12:02

      Mm.

   8. BMBob McGrew12:03

      Or Sham 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, if their perspective is, you know, 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. Because if you can't make some sort of, you know, 3X or 10X change within that organization, then you know, there was no reason to go through all the effort of doing this. Um, you might as well have sold some sort of like very simple piece of software. So that's, that's the key profile for the echoes. And then for your deltas, um, 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-

   9. SPSpeaker12:59

      Mm-hmm.

   10. BMBob McGrew12:59

       ... 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. Sometimes that code is beautiful if you get the right person, right? But usually not. That, 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.

   11. SPSpeaker13:32

       It does sound a lot like a founding team.

7. 13:34 – 14:35

   Training Ground for Founders

   1. BMBob McGrew13:34

      Yes.

   2. SPSpeaker13:34

      It sounds a lot like a founder.

   3. BMBob McGrew13:35

      Yeah.

   4. SPSpeaker13:36

      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 FDE training, this is like exactly the training to be ... become a startup founder. You're learning all, all the startup founder skills, right? But did you go in the other direction too?

   5. BMBob McGrew13:53

      You know, back in the day when we were getting this started, uh, there was not a, a huge supply of founders for us to pull from.

   6. SPSpeaker13:58

      (laughs)

   7. BMBob McGrew13:59

      Uh, I, I think, you know, maybe they ... Maybe that's the opposite now. But, but I think it's ... I, 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.

   8. SPSpeaker14:24

      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?

8. 14:35 – 17:54

   Consulting or Real Software?

   1. BMBob McGrew14:35

      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. Um, but the second thing you would 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 f- ... The f- ... When you go into ... You do a new deployment at a customer, that you're actually losing money early on. 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, r- ... 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.

   2. SPSpeaker15:38

      Mm-hmm.

   3. BMBob McGrew15:39

      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.

   4. SPSpeaker16:02

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

   5. BMBob McGrew16:08

      Yes.

   6. SPSpeaker16:08

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

   7. BMBob McGrew16:13

      I think on the engineering side, uh, it actually ... You know, it, it feels my, 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? Um, but the roles that were really different are, um, the, the FDE team, but then also the product management team. And so, um, the product that you're building, uh, 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, is really to hold the product vision. And so you have to think, when I see those new problem that we're seeing at a customer site, what is the generalizable version of this that applies to the next ten customers? Because if you ... You know, there's a, 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, 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.

   8. SPSpeaker17:40

      So there was some wisdom to figure out which bucket it filled, 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

9. 17:54 – 23:04

   The Birth of Palantir’s Ontology

   1. SPSpeaker17:54

      the other one?

   2. BMBob McGrew17:54

      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 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 it's 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, um, we should allow that to be defined per customer by the forward deployed engineering team. And so that's the, the sort of origin story of where Palantir famously got its ontology.

   3. JFJared Friedman18:42

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

   4. BMBob McGrew18:52

      Well just, I mean, the database schema 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, uh, product, um, which was our first product. But the ontology is what encodes all of the specialized information that's per customer. And you know, that says, oh, well this is, you know, a person, this is a ship. This is a money flow. And again, this is, this is I think really the very most basic example, but you know, if you build something for just one customer, then you're going to be thinking in, you know, 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, I would interview people who were amazing product managers at, you know, other companies. And I would ask them to, 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, that was the wrong thing to do here. And they needed to, 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, you know, this specialized thing works across customers? And of course there's many other examples that don't have anything to do with the ontology.

   5. DHDiana Hu20:26

      I mean, did 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, like the generalizable ontology. I want to kind of like do it this way."

   6. BMBob McGrew20:54

      Well, I mean absolutely there was, there was always a lot of tension and I, and I, I would not frame this so much in terms of like the skills that different people had, because it was also very c- 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, I can really fix these products." And then come in and do an amazing job, you know, 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-

   7. DHDiana Hu21:20

      Maybe the incentives are different.

   8. BMBob McGrew21:21

      Yeah.

   9. DHDiana Hu21:21

      Versus the skills are different.

   10. BMBob McGrew21:22

       The incentives are different. And so, you know, you're solving one very particular problem and it makes a lot of sense to just take the simplest approach to solve that problem. Um, and, 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 paved 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, they'd see something at one customer, we'd bring it back to the product team in Palo Alto and we'd say, "Okay, what's the right generalized version of this?" 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. And then I think that really, that really melds the incentives.

   11. JFJared Friedman22:53

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

10. 23:04 – 36:17

    Why AI Companies Adopt It

    1. BMBob McGrew23:04

       Yes. Uh, you absolutely have to focus on this. Um, and I, I think one of the other failures, by the way, that's even prior to that and, and more 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... 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 levels down from the CEO who 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.

    2. SPSpeaker23:49

       Going back to the opening from Jared, what's going on with all these AI companies really now ramping up and hiring tons of FDEs? 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?

    3. DHDiana Hu24:07

       Especially because I feel like even as Palantir became successful and the FDE model became well-known, it was still seen as...

    4. BMBob McGrew24:13

       Well, you could- that's a one-off thing because Palantir is a unique company. Company that like- And selling to the government is just like a- Government, yeah. Like a, like a, like a, like a really weird thing. Yeah. (laughs) Yeah. But you wouldn't ... Don't try this at home. (laughs)

    5. SPSpeaker24:24

       (laughs) Exactly.

    6. BMBob McGrew24:24

       Like the mindset, right? (laughs)

    7. SPSpeaker24:26

       Exactly.

    8. BMBob McGrew24:26

       Like now everyone sort of ... It's become ... Like Diana said, it's become very commonplace. Has that ... One, has that surprised you? And then two, like why do you think that's happened? 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 FDE strategy is like don't, don't do this at home. (laughs) 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, uh, 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. 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 the 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 this segment. You know, you can deploy the people that are doing this kind of workflow. 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 f- in other market segments. And then like, like I'm sort of saying here, a segment is not the same as a customer necessarily, um, 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 FDE strategy matters because you're doing thi- You know, it's like you're doing things that don't scale, 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 users 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 an, a small change on top of the, the work they were doing, 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- Mm-hmm. ... 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 segmentate- 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, um, also I would say what it is to build AI agents is actually probably a lot of different things, 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. Okay. Well, well, how does this relate to, um, some of the classic YC advice, which is do things that don't scale? 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.

    9. SPSpeaker28:45

       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.

    10. BMBob McGrew28:59

        Since you see a lot of people, uh, trying to apply the f- FDE model now to their new startups, including a lot of people who didn't work at Palantir (laughs) 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? 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. (laughs) The startups that are, that I've talked to who are switching to the FDE model gained a lot of benefit by bringing on someone from Palantir in, you know, one of the core roles. As I said, the engineering team is often fairly similar, you know, but maybe, you know, continues to be fun for a long time. Uh, but the actual mechanics of how the FDEs work, how you build these accounts, how you find the outcomes, those are, those are actually quite different from a standard software f- uh, firm. And so one of the, the key differences, uh, and, and something that I think is actually quite difficult for people to understand, is, uh, how you choose a problem and then how you price that problem. And fundamentally what you're selling with the FDE 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 valuing g- you know, delivering some value to the users, how do you price that? Right?

    11. SPSpeaker30:27

        That's a very common question we get from all these AI startups-

    12. BMBob McGrew30:30

        Yeah.

    13. SPSpeaker30:30

        ... because in the age of SaaS, you would do it based on usage or subscription or seats.

    14. BMBob McGrew30:37

        Yep.

    15. SPSpeaker30:37

        And this is completely different as outcomes. How do you even price it? How should all these AI founders price their solution?

    16. BMBob McGrew30:46

        Yeah. And I think one of the, the, 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 the SaaS model in, you know, product market fit, you're going towards, you know, very simple repeatable contracts, very simple repeatable pricing that makes sense across all of your customers. And, you know, often you're, you're going to be quite comfortable with small contracts because the cost, the marginal cost to deploy is very low. With the FD model, you're going to get pushed towards larger and larger contracts. Um, 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.

    17. SPSpeaker31:25

        I think this is what the AI startups that we work with discover on their own. I have this company called Castle that does, uh, AI voice agent for mortgage servicing. So they work with very large banks and the way they 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 like stipulations when it goes to scale, it would be this much and that, and they kind of figured out on their own. And other startups as well, uh, like Happy Robot, that's another YC company as well doing AI voice agents for logistics. They're working with large companies like DHL, similar thing.

    18. BMBob McGrew32:03

        There's an asymmetry here between you, the startup, and the business that you're selling to.

    19. SPSpeaker32:08

        Mm-hmm.

    20. BMBob McGrew32:08

        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.

    21. SPSpeaker32:20

        (laughs) Yeah.

    22. BMBob McGrew32:20

        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?

    23. SPSpeaker32:31

        (laughs)

    24. BMBob McGrew32:31

        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 going to take on the risk and you pay us if it works or you pay us when you know we're actually able to expand." Uh, the one place this can go wrong is that particularly if you're doing a s- something that needs to be deployed into the enterprise, uh, you know, on premise-

    25. SPSpeaker32:58

        Mm-hmm.

    26. BMBob McGrew32:59

        ... uh, or any piece of it needs to be on premise rather than in the cloud, you do have to fight the IT team who-

    27. SPSpeaker33:04

        Yeah, I actually seen that too- (laughs)

    28. BMBob McGrew33:06

        Yeah.

    29. SPSpeaker33:06

        ... with some of these companies.

    30. BMBob McGrew33:07

        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 going to 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 spec- very specific organizational things 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.
11. 36:17 – 41:14

    What Success Metrics Look Like

    1. BMBob McGrew36:17

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

    2. DHDiana Hu36:30

       Yeah.

    3. BMBob McGrew36:31

       In the FD 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, uh, leave the amount of customization you do per customer the same.

    4. DHDiana Hu36:47

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

    5. BMBob McGrew36:53

       There's two useful things here. So one, the thing you can measure, yes, contract size. Um, I would even be a little bit more general than that and say the value of the outcome you're delivering.

    6. DHDiana Hu37:05

       Mm-hmm.

    7. BMBob McGrew37:05

       Because that's- that's actually the true thing, you know, and- 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- we didn't talk about yet is, uh, 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. 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- 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 and that- that amount of product leverage should be going up over time.

    8. DHDiana Hu38:22

       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.

    9. BMBob McGrew38:29

       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 or you will find that your FDEs, if it's a really- if it's really good, you'll find your FDEs can f-figure out some new way to use that technique you built to solve something completely different.

    10. DHDiana Hu39:16

        Yeah, there's- 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.

    11. BMBob McGrew39:28

        Yes. Um, although I will just note this is a very painful process for everyone involved.

    12. DHDiana Hu39:34

        Mm-hmm.

    13. BMBob McGrew39:34

        Uh, I- I probably can't use the word pain often enough-

    14. DHDiana Hu39:36

        (laughs)

    15. BMBob McGrew39:37

        ... uh, in the FDE. You know, there are many times where I built something, I thought it 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.

    16. DHDiana Hu39:47

        (laughs)

    17. BMBob McGrew39:47

        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, uh, 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- I hadn't done enough to make it easy for the FDEs to use. 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.

    18. DHDiana Hu40:16

        Are the FDEs always right in that case, or is like should the founders sometimes be just top down and say like, "Actually, I just want you to do th- do it this way?"

    19. BMBob McGrew40:25

        I- 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. Um, 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.

    20. SPSpeaker40:52

        So in the context of how all these FDE companies price very differently based on outcome, how does that fit in with now the culture doing demos? Because there's just 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?

12. 41:14 – 44:56

    Building with Demo-Driven Development

    1. BMBob McGrew41:14

       One of the interesting things that happens there is because you have to go repeatably show this to new customers, you're forced to give these new demos. But- but actually I think demo-driven development works really well if you have the right kind of product. So, you know, in the early days of Palantir, we actually had one demo. It was a flow where you are, you know, stopping a terrorist plot. And we started this with, you know, 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? You know, 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, you know, we integrated a map and we had the same question. And if you think about the world from what am I building, then you know, you're thinking about your capabilities, you might think of each of these features individually and how to build the be- 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? Um, 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- 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, 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, am I solving that pain point for the customer?"

    2. SPSpeaker43:10

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

    3. BMBob McGrew43:20

       Yeah, yeah. I, 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. You know, if you're just out of college, you want a young company that is, uh, 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, 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?

    4. SPSpeaker44:31

       (laughs) .

    5. BMBob McGrew44:31

       That is like probably like the canonical part of the YC experience is that, uh, 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.

    6. JFJared Friedman44:42

       Obviously, I mean, a monster success for Palantir. They're now a super big company, huge organization. We heard that you're joining another large organization, (laughs) -

    7. BMBob McGrew44:50

       (laughs) .

    8. JFJared Friedman44:50

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

13. 44:56 – 47:43

    Joining the US Army Reserve

    1. JFJared Friedman44:56

       apply there?

    2. BMBob McGrew44:56

       Yeah, absolutely. I've recently joined, uh, 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.

    3. JFJared Friedman45:27

       Hm.

    4. BMBob McGrew45:27

       So, you know, we took the oath. I'm a lieutenant colonel in the US Army.

    5. JFJared Friedman45:32

       I heard you went through basic training too.

    6. BMBob McGrew45:33

       I, I, uh, yeah, we, we went through the direct commissioning course. We've been trained by military academics, uh, often at 5:00 in the morning because that's the time that works for people on the East Coast-

    7. JFJared Friedman45:42

       (laughs) .

    8. BMBob McGrew45:43

       ... and doesn't conflict with our day jobs. We've learned from officers. Uh, I had to take the Army fitness test, uh, which since I am not very fit, uh-

    9. JFJared Friedman45:51

       (laughs) .

    10. BMBob McGrew45:51

        ... you know, was something that I had to train for for nine months.

    11. JFJared Friedman45:53

        (laughs) .

    12. BMBob McGrew45:54

        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. General, uh, Randy George, the Chief of Staff of the Army, Secretary of the Army, Driscoll, um, they have articulated a plan for the transformation of the army.

    13. JFJared Friedman46:23

        Hm.

    14. BMBob McGrew46:23

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

    15. JFJared Friedman47:37

        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

14. 47:43 – 50:42

    Opportunities for Founders

    1. JFJared Friedman47:43

       work on right now?

    2. BMBob McGrew47:43

       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-

    3. JFJared Friedman47:59

       (laughs) .

    4. SPSpeaker47:59

       (laughs) .

    5. BMBob McGrew48:00

       ... I think what we've seen is that, that capability improvements are actually extremely fast. Um, 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-4.0 and April 2025 and the release of 03, that's an extremely fast rate of progress. And I, 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 capability to just race ahead and race ahead and race ahead, and somehow the world feels increasingly banal. 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, "Ugh, traffic."

    6. JFJared Friedman48:52

       (laughs) .

    7. BMBob McGrew48:52

       "It's really slow."

    8. JFJared Friedman48:53

       Yeah.

    9. BMBob McGrew48:53

       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 going to, it's going to c- maybe, maybe over the weekend it's going to come alive and it's going to 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. 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?

    10. JFJared Friedman49:57

        There, 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 FDEs (laughs) out figuring out how to get adoption of, of, of the, like, research that OpenAI is cooking up back at the home office.

    11. BMBob McGrew50:13

        I, I think that's not a bad analogy at all.

    12. SPSpeaker50:14

        (laughs) .

    13. BMBob McGrew50:15

        I think that, I think that is, that is maybe the underlying truth of what's making this whole FDE strategy exciting again.

    14. JFJared Friedman50:22

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

Episode duration: 50:42