The FDE Playbook for AI Startups with Bob McGrew

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

Hello, and welcome back to another episode of The Lightcomb. 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.

Great to be here. 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 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 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 chat GPT.

And instead, what all of these AI started founders wanted to talk to you about was the Palantir 4 deployed engineer model.

Well, and 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 FD strategy works.

Yeah. So there's is 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 where there's over 100 YC startups that are hiring for a job with the title for 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?

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. And how does this play out in practice? You'll have a product, and you go to a new customer site, you start working with a new customer, and 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 deliver the piece of software that you've built in a way that actually works for the customer.

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

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. And if you happen to find a spy and you go and ask them, so what is it exactly that you do? 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 in this change?

He's like sitting there writing all of this down so far. this story feels very much like you would, 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 doing this back 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 in this is class, you know, if we're 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 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 FD 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 Shamsankar, who's very early employee, now I think the president and CTO of Palantir, he really invented the FD strategy. And 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 site, we built something that was more a platform than a product. that had a lot of ability to be customized at each site. So when you do that, well, OK, you need to bring someone to the site to understand what the users are doing and 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 product market fit. And what Sean 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 the FD goes and builds a gravel road to where the product needs to go.

And then the role of my team, of 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 gravel road into a paved superhighway.

I feel like sales is product discovery is a concept that's not new, certainly around before Palantir, but typically the view used to be like you had your sales people that went out and did like the sales and talk 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 the government and defense. You would imagine the natural inclination is to go hire some experienced salesperson who's got a history of selling into the government.

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

Well, I mean, there's two angles. One is 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 a big five defense prime? And then even when we talked to people who 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 I think the difference between sales led product discovery and FDE-led product discovery, is it 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 FD-led product discovery where you're solving these problems from the inside. So the scope 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 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?

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, like, here's how we did it.

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

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

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 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, 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 there was no reason to go through all the effort of doing this. You might as well have sold some sort of 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 Figure out, write some rough and ready code. 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 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 the key sets of skills.

It does sound a lot like a founding team.

Yes. It sounds a lot like a founder. Yeah. 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 FD training, this is like exactly the training to be. comma startup founder, you're learning all all the startup founder skills, right?

But it is going the other direction to, 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 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 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.

So 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?

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 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 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, 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 real repeatable value.

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

Yes.

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

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 doing this founder led discovery and we were you know, building new products. And later on, at the later days of Poundtree, we were still doing that. We were still building new products. This felt great, right? But the roles that were really different are the FDA 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 gonna be going through, like if you're building Airbnb, right?

Instead, the role of the product team 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 10 customers? Because if you, you know, there's a classic failure mode here where, you know, the FD implement 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, they 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.

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

Yeah. I mean, probably the most basic example here is the invention of the Palantir ontology itself. And so when we first started talking about working with the US government and specifically working in intelligence, 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 go down that route and you try to deploy to multiple people, your database doesn't make any sense. And so, you know, 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 the forward deployed engineering team. And so that's the sort of origin story of where Palantir famously got its ontology.

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?

Well, 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 encodes all of the specialized information that's per customer. 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. 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 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, OK, 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 the ontology.

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 heretics. They 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 maintainable code that lasts for a while. Surely that must have created tension somewhere where there's an FTE who's like, no, I don't want to use the generalizable ontology.

I want to do it this way.

Absolutely. There was always a lot of tension. I would not frame this so much in terms of the skills that different people had, because it was also very... 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 FTEs 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.

Maybe the incentives are different versus the skills are different.

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 FD 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 Pedro often looks a little bit different. But the flip side of this, though, is, you know, imagine you said, well, clearly, this FD approach is just wrong.

Like if he's building one 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 way that we would often build features early on is that, you know, first, the FD team would build something, see something at one customer. We'd bring it back to the product team in Palo Alto, and we'd say, OK, what's the right generalized versions? And those FDs 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 FDs from those customers in as well and help them design. And they can help us design this feature so that when we build something, we know it'll work for the customer it was initially prototyped. and we know will work for these others. And then of course, you know, if you're once you 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.

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 whatever product the customer needs? Yes.

You absolutely have to focus on this. And I think one of the other failures, by the way, that's even prior to that and 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 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.

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 caused them to really adopt this model, which was not the case for the previous generation of companies with SaaS? What happened?

Especially because I feel like even as Palantir became successful and the FTE model became more 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. Like a really weird thing. But you wouldn't, don't try this at home. Now everyone's sort of it's become like dinosaurs become very commonplace as that one has that surprised you and then to 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 FD 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 gonna 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 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 counterproliferation workflow and a counterterrorism 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 IDs, 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 the crossing chasm story a little bit applies. So you're starting off, nothing seems to work. Suddenly, you find product market fit in the segment. You can deploy the people that are doing this kind of workflow. And then 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 other market segments. And 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 things, 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, they were used to basically 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 basically said, hey, when you're 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 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, where this is a completely new market category. If you are implementing 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 there's not all this little segmentation. There's not the same kind of product discovery. You can then 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. 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.

How does this relate to 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.

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

Since you see a lot of people trying to apply the FTE 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?

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 FD model have people from Palantir running the FD model. The startups that I've talked to who are switching to the FD 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 FDs 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 for people to understand is how you choose a problem. 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 get, you know, delivering some value to the users, how do you price that?

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?

Yeah. And 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 marginal cost of deploy 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.

I think this is what the AI startups that we work with discover on their own. I have this company called CASL 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.

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

Yeah, I've seen that too.

Yeah.

With some of these companies.

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

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.

That's how it felt early on, too.

Okay.

It's a discipline. It's a skill. You need really amazing leadership on the FDA team to be able to have that kind of discipline. 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 super. I think Palantir is extremely good at this now, probably better than any other company. And that's, that's why I, you know, I have the cost of 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.

Jared pointed out earlier that the I think this is 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 coliseum in store, 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 and like physically go to them like go to their office and like sit next to them. 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 what we were talking about earlier. Like at some point you hopefully you build a product so good that people can figure 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. 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.

Yeah. And I think this is actually really encapsulates the key difference between 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. In the FDA 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.

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

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 actually the true thing. 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're doing something right. The second piece 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. It's very hard if you're an FTE or if you're leading an FTE team, there's a lot of things you have to do. 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 look, I struggled with this myself quite a bit leading product early on. Like you wanna focus on the user experience and you have to do that, but you also have to remember your other key customer is the FTE.

Your product should be, you know, ultimately delivering a good thing to the user after FTE customization, but it should be delivering leverage to the FTE who's delivering that outcome at the customer site. And that amount of product leverage should be going up over time.

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.

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

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

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 FDA. You know, there are many times where I built something I thought it was amazing and I thought it was beautiful. Not not there yet. Right. But it would really would help the FDs as soon as they just had the the ability to see it. And I'd be like, please use my product. I'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 I hadn't done enough to make it easy for the FDEs to use. And so I would send the developers out into the field to deploy those early solutions and get them over the line, even to the point where the FDEs could use them profitably. The FT is always right in that case whereas they should the founders sometimes be just top-down and say like actually I just want you to Do that do it this way I mean the answer is like yes to all all of these things The other thing it 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 ten and you very literally do not have the information needed to answer that when you see that first customer. And so it becomes a judgment call.

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 this thing, at least in SaaS, where 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?

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 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, you know, when we integrated 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 have the same question. 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? 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?

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.

Yeah, yeah. I think, yeah, 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 off 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 always doing that same grinding motion that it is to be a new startup.

Because yes, new startups, a lot of pain there too, right? That is probably the canonical part of the YC experience, is that it's not coasting. It's working really, really hard on something that you're not quite sure if it's going to succeed.

Obviously a monster successful Palantir, they're now a super big company, huge organization. We heard that you're joining another large organization, the U.S. 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?

Yeah, absolutely. I've recently joined the U.S. 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 U S army, the defense department, the U S 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 and the U S army.

I heard you went through basic training, too.

Yeah, we went through the direct commissioning course. We've been trained by military academics, often at five in the morning, because that's the time that works for people on the East Coast and doesn't conflict with our day jobs. We learned from officers. I had to take the Army fitness test. which, since I am not very fit, 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 in the early days of Palantir when we were working with them back in 2005 or 2010.

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, 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'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 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 really interesting about it is in many ways it does feel a lot like running the FDA strategy on the Army. We get to see 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 we're helping them make that change. I'm really eager to have the opportunity to make a difference.

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

Well, I think this really goes back to exactly this question of why is it that AI agents are pursuing the FDE strategy? And if you zoom out and I put on my AI research hat for once in this podcast, I think what we've seen is that capability improvements are actually extremely fast. Yes, I heard 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, the release of GPT-4.0, and April 2025, and the release of 03, 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. 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 traffic. It's really slow.

Yeah.

And so, you know, just like with the world of the FTEs where you have, you know, the FTEs 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, we sat around a table in 2018 and talked about what it looked like when AGI was built. People thought, oh, well, maybe over the weekend it's going to come alive and it's going to take over the world.

And one of the things that I think people missed in that was that AI needs to be adopted. It's something that doesn't just happen by itself, but you need human ingenuity and exploration while 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?

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 research that OpenAI is cooking up back at the home office.

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.

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.