Palantir did it so it must be good
Expensive engineers working as embedded consultants, focused on holding customers’ hands to implement existing tech as well as possible and create custom tech when necessary. It works best for 7+ figure contracts, when the customer isn’t technologically savvy, and when learnings from deployment can be integrated into core product.
Palantir, Epic Systems
Quickly becoming one of the hottest job titles after being popularized by Palantir, FDEs fill the gap between what the product does and what the customer needs.
They are embedded within a customer's organization to address complicated, critical challenges using the company's AI and software tools. Unlike conventional engineers who develop broad-use products, this model mixes consulting with implementation where engineers spend months onsite to deeply understanding the client's unique requirements to design and implement a customized solution.
Because of how expensive quality engineers are, this model generally only works for 7+ figure contracts. It’s most useful when the customer themself doesn’t have the technical chops to deploy the product and when the learnings from each client implementation can be translated to the core product team to build universal products/tooling.
In the traditional software strategy, before PMF you spend a lot of time early on doing things that don't scale, going out and visiting customers, getting very close to the customers. And then once you discover PMF, you change your behavior entirely. You now want to embrace distance from your customer. All you focus on is scaling. How do you to sell more? How do you treat all customers exactly the same? I want to say that if you're in a business where this is working for you, that's great. Don't do the FDA 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. So, with traditional post-PMF SaaS, you want to be doing less work for every customer, driving down costs while keeping the contract size the same. Whereas, in the FDE strategy, you want to drive the contract size up where you're doing ever-more valuable work for this customer and also for future customers. Because you're doing more valuable work, you can leave the amount of customization per customer the same. So that the KPIs are: contract size (not how much custom work they're doing per customer) and are you getting more and more product leverage against that outcome.
Not only does the FDE model make sure that the tech is maximally useful for customers, but that accountability and being that embedded with the client informs in far more fine-grained and tangible ways future product direction.
The core flywheel of Palantir and Epic has been translating learnings from implementations into core, broad-based products. Indeed, Foundry sprouted from this process. Its creators turned their experience struggling to implement collaborative data integration for our customers into Foundry’s core features such as branching, provenance, and co-versioning of data and code.
Getting this client-specific consulting —> core product development flywheel correct is essential to make the model work profitably at scale. Over the last five years, Palantir has transitioned from -100% EBITDA margins to +17% and climbing. Moreover, their S-1 claimed that the time required to setup a customer has decreased more than five-fold since Q2 2019, to an average of 14 days in Q2 2020. Read this great breakdown of the company’s process.
Likewise, Epic (aided by their position of strength) pushes their customers to use as much standardized products as possible:
A lot of times when people are setting up Cerner, every implementation looks completely different. Epic is highly opinionated. Please use as much standard stuff as you can so that we can easily push out updates, or we can easily add-in new modules for you, or interoperability all works exactly the way that we’re thinking it should. I believe the only way that you can get discounts on pricing with Epic is by doing either fully or mostly standard. I think there probably are some tiers based on how standard your implementation is, and the more you deviate from it, the more you have to pay.
Lastly, making this model core to your company requires thoughtful crafting of culture:
https://www.youtube.com/watch?v=Zyw-YA0k3xo
https://nabeelqu.substack.com/p/reflections-on-palantir?ref=mackenziemorehead.com
https://seekingalpha.com/article/4547259-palantir-service-heavy-business-model
https://www.acquired.fm/episodes/epic-systems-mychart
https://www.piratewires.com/p/primacy-of-winning-shyam-sankar-palantir?ref=mackenziemorehead.com
https://www.michaeldempsey.me/blog/2025/10/03/sequencing-vs-equal-odds-applied-research/
Former CFO of Palantir:
“The FD model is great in certain markets, terrible in others… you’ve got to be solving a hard enough problem.”
“A world-class engineer plus their equity dilution is an expensive check. You have to be a capital allocator to pursue this model.” That’s why it doesn’t make sense for SMB contracts in the $20k–$100k range, unless it’s essentially R&D you plan to productize.
At scale, though, it can pay off: “Seven-figure contracts can support it; eight or nine figures definitely can.”
The key, he says, is mindset. Too many founders think of FD as a sales or customer success function. “If you’re looking at the FD model through pre/post-sales org charts, you’ve lost the plot. Start from first principles.”
https://x.com/tbpn/status/1960129883377709267
FDEs fill the gap between what the product does and what the customer needs
You start working with a new customer and the the problem that they want you to solve is not a problem that you've ever solved before, but you believe that it's one that with a little bit of work, maybe a lot of work, you can solve for this particular customer and you'd be making a huge impact for them.
The standard startup pedagogy is that you spend a lot of time early on doing things that don't scale, going out and visiting customers, getting very close to the customers. And then you discover product market fit.
Once you discover product market fit, you do something entirely different. 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 to sell more? How do you treat all customers exactly the same?
I want to say that if you're in a business where this is working for you, that's great.
Don't do the FDA 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. The customers that we had, the product that they needed was slightly different at every place. Instead of sort of building 2 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 of ability to be customized at each site.
FDE Lead Product Discovery vs Sales Lead
Typically the view used to be like you had your sales people that went out and did like the sales and talked to the customers and they came back and reported to the engineers.
The difference between sales lead product discovery and FDA lead product discovery is it sales lead 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 FDA lead product discovery where you're solving these problems from the inside.
So, you know, the scope of a of a traditional implementation might be you start with something that's pretty close to what the product does, but you want to be solving one of the key problems that leadership has identified. If you're not solving one of the top five priorities for the CEO, it's probably not going to work.
They probably won't have the energy to persist through the much more challenging route of getting effectively a new piece of the product built in a way that work for them. Then once you've solved that first problem, then the FDEs can identify other key problems in the enterprise, sometimes much more valuable problems than the ones that you were first targeting. 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 how do I sell the same thing to each customer to how do I land and expand?
Roles at Palantir
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 the site, what was the key problem that could be solved. They would also be the account managers. So they would also be the people managing the relationships at the customer site.
The Delta team the deployed engineers. Effectively, software engineers typically very good at writing code extremely quickly, eating a lot of pain as we put it.
So, you go in with an idea for what you're going to work on. You set up a few months in that you're going to, 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.
A classic profile for someone to join your echo team would be someone from the domain you're working in with domain knowledge. But it’s crucial that they’re a rebel or a heretic. They need to be someone who understands how things are done right now and recognizes that it's insufficient.
The product role is very different too. The product that you're building instead of being highly verticalized where this is 1 flow that millions of people are going to be going through, like if you're building Airbnb, right?
Instead the role of the product team is really to hold the product vision. 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 there's a classic failure mode here where the FD 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.
The way that we would often build features early on is that first the FDA team would build something that see something at 1 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 that those FDEs would participate in those discussions. 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 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.
Do you feel like it requires a lot of organizational discipline to keep this bottle from devolving into pure consulting where the FDE teams are just off building like whatever product the customer needs?
Yes, you absolutely have to focus on this. I think one of the other failures by the way that's even prior to that and 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 customers like a whole organization. You don't talk to the customer. You talk to maybe the CIO, right?Or you talk to 1 sponsor, usually a couple levels down from the CEO. You only get to see the CEO 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.
Business model
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 OK, you can leave the amount of customization you do per customer the same. So that the KPIs are: contract size (not how much custom work they're doing per customer) and are you getting more and more product leverage against that outcome.
A common Palantir critique is that it’s just consulting dressed up with fancy marketing speak. Why is that wrong?
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.
One of the key things that you will see, that you should see is that it may be the case that you're the when you go into, you do a new deployment at a customer that you're actually losing money early on.
The longer you're at the customer site, first thing is 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 to 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 time, maybe a year, maybe multiple years at the customer site.
A key difference between the FDE model and the standard SaaS model is that with a SaaS model you're going towards very simple repeatable contracts and pricing that makes sense across all of your customers. Often you're going to be quite comfortable with small contracts because the cost, the marginal cost deploy is very low.
With the FDE 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.
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 often times 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 going to just believe in our own execution and we're going to take on the risk and you pay us if it works or you pay us when 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 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. 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 CE OS top five problems because you need to be able to bring in someone from the top to say, yes, give them authority to operate.
We at YC have this concept of like the collision in store, which is essentially would 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. And I feel like it's always been a great starting strategy, but most startups aren't getting big contracts off the bat. So actually the reason they have to stop doing sort of like this sort of manual high touch process is you just can't get the growth rates to sustain without at some point having a product that scales.
It's kind of like what we were talking about earlier.Like at some point you hopefully you build a product that's 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.
When it makes sense
When it’s an entirely new product or workflow that no one really knows how to use or implement. High diversity of tasks, market fractals.
The startups that I've talked to who are switching to the FDA model gained a lot of benefit by bringing on someone from Palantir in, you know, one of the core roles.
https://www.youtube.com/watch?v=Zyw-YA0k3xo
Implementations managers are one of just three job titles at Epic Systems.
They have wedding bells that will play campus-wide when a new client is signed. Just showing that that’s the type of commitment that this is. It’s a, we’ve now married this client for the rest of our lives.
Every single one of their 600+ hospital system customers has their own technical specialist teams for every single product that they use. They have their own technical specialist team for their EpicCare, EMR, MyChart, Resolute, Cosmos, for you name it, anything you use, you have your own dedicated team for that. Then on top of that, every customer has their own dedicated BFF (best friend forever) who is a single person within Epic, and their sole job, their only job is to make sure that you as a customer are successful with their products.
This means they do things like they grade you as a customer every year, benchmarked relative to what other customers are doing and how you’re doing with the Epic tools. They will send separate report cards every year to your CEO, CIO, and CFO, and they will grade you one through five on a bunch of dimensions. Then they will show you benchmark data against other customers at your peer set of relatively similar sized hospital systems, how you’re doing.
Well, they have a lot of leverage in the customer relationship. I think at this point in history, 2025, when the customer wants to do something a certain way and Epic wants to do something a certain way, ultimately Epic is customer-focused, so they will do whatever the customer wants, but they’re going to lay out very compelling convincing arguments why their way is the correct way. What this leads to are things like a standard package. A lot of times when people are setting up Cerner, every implementation looks completely different. Epic is highly opinionated. Please use as much standard stuff as you can so that we can easily push out updates, or we can easily add-in new modules for you, or interoperability all works exactly the way that we’re thinking it should. They have a strong negotiating position with customers when they’re saying, ah, I think you should do it this way. Because at some point they may choose to just say, you know what? I don’t think you’re ready to be a customer yet. I think we’re going to focus elsewhere this year. We’re going to pick up only 10–20, maybe 30 new customers. David: And we’re happy to wait. Ben: We’re happy to wait until you’re ready to work with us. And they actually have the leverage to pull that off now. David: To your point about the standard implementations, I believe this is the only way that you can get discounts on pricing with Epic, is by doing either fully or mostly standard. I think there probably are some tiers based on how standard your implementation is, and the more you deviate from it, the more you have to pay. Ben: I could see that. I know if you stay up-to-date on things like database maintenance and versioning and all that, then they give you discounts.
https://www.acquired.fm/episodes/epic-systems-mychart
Palantir also does a full implementation team ranging from 1-12 people for every customer
You have to get software engineers who have the alternative of working in Silicon Valley in a pleasured experience to deploy down range into a Fortune 500 institution defined by giant bureaucracies and data rights access and all these different things. So one, you got to motivate really talented people to do that, that’s really hard.
How do I get the FDE to work with the dev who has a different accountability function? How do I put the devs work on my critical path to solve the critical need of the customer, when that dev is accountable to solving things for 350 different customers? This is very hard, we don’t always get it right internally. I would say that I think we’re the best in the world at doing this, and we suck at it, because it’s so hard
According to the expert, $PLTR's pricing and commercial terms are highly transparent, with contracts clearly structured to separate the software license from any additional implementation services. He explains that customers typically start on a usage-based model, where charges scale with storage, compute, and user tiers, but this quickly becomes expensive as adoption grows, prompting most to shift to multi-year enterprise agreements with fixed grid pricing.
Figure 5: Average Revenue of Top 20 Palantir Customers (source)
Palantir's profit margins have shown consistent improvement as the business scales. Palantir attributes this to a significant decrease in the time and number of software engineers required to install and deploy their software platforms. The S-1 claimed that the time required to setup a customer has decreased more than five-fold since Q2 2019, to an average of 14 days in Q2 2020. This is still a relatively long time though and indicates the complexity of the software and the service heavy nature of the business. Palantir has also invested in infrastructure to deliver software updates, which has more than doubled the number of upgrades their engineers can manage.
Figure 8: Palantir Profit Margins
Palantir is currently realizing operating leverage across R&D, sales and marketing and general and administrative expenses. Palantir is targeting profitability and 4.5 billion USD revenue in 2025. Margin expectations are inline with the company's current trajectory, but the growth target appears optimistic.
Figure 9: Palantir Operating Expenses
https://seekingalpha.com/article/4547259-palantir-service-heavy-business-model
So you mentioned, Shyam, that in 2017 was the critical year for Palantir and you said that was despite the fact that from a financial perspective that was arguably the worst year in the company’s history. Why was that? Tell me about the 2017 pivot point as far as Palantir is concerned.
SS: Well, that was the point where Foundry had really come to market and we were able to transition our customers in the commercial world, transition that revenue to run on top of Foundry.
So before it was just a bunch of custom integrations, custom deployments across all these different customers?
SS: Yeah. There was a period of experimenting with what the product was and where it sat in the stack. And I’d say the things that we’d built would subsequently become apps within Foundry. So Foundry gave us the infrastructure to really scale what we were doing, not only across the commercial world but across all of our government customers and it gave us the ability to go fast.
TM: And I think also critically just the ability to go fast, but also still be accountable to the same outcomes. So 2017 we were able to consolidate on Foundry, but also deliver the 33% ramp up in the acceleration of the [Airbus] A350 production. So how do you push out the efficient frontier of building exactly what people need to solve their exact critical problem, but on the same common foundation where there’s commonalities where you can use it for Airbus, or PB, or Swiss Re, or whoever it might be?
The primary role for FDEs is that providing accountability to us that aligns us with our customers to say, “Is the software doing what the customer actually needs?” Not just as someone using it, but have we delivered the feature in a way that matches what the software industrial complex would want out of this feature and the current understanding of the stack, but is it actually working? And how do we walk a mile in our customer’s shoes?
You’ve just accumulated so much experience of installing these, you feel you can walk into any company and get it done pretty quickly.
TM: So median time-to-production, median time of our POCs (Proof of Concepts), and POCs at the end of you don’t have a POC, you have a production application that’s used by users in six to eight weeks, and so that allows us to start with an individual problem. It does oftentimes require that our customer says, “I recognize that I have a problem that my existing software stack does not solve,” without that we’re challenged. But that problem can be very specific and something that we can solve on the order of weeks.
Do you only solve problems? If your problem solving involves integrating lots of different software, are you effectively installing an operating system just to solve one problem? Maybe it’s only manifesting in one way, or can you go in and say, “Look, we just have a CRM problem,” “We just have…,” whatever problem might be like. What does this proof of concept bit look like? Because how do you do what you do without putting in the whole thing?
TM: Oftentimes what these things are is they start with, “What version of the problem that Palantir can solve do I realize that I have?” And that often manifests itself in a very specific way. I have a huge amount of challenge with volatility in my supply chain, so I’m either blowing OTIF or I have exploding inventory and with high interest rates, I can’t manage that, that’s the problem I know I have. Now, in order to solve that, I have to integrate probably several different systems underneath that. But I can bring that and approach that in a software-defined way where I can say, “I can start to address your excess inventory problem with an application that is in production on the order of weeks.”
Then oftentimes what they do is they’ll see that and say, “Okay, well now that I have that, I’d also like to integrate what my pricing strategy is, how I’m doing my contract management as a function of creating these problems for myself, how I do my production planning, how I deal with managing supplier shortages.” But that classic-land-and-expand strategy of horizontal data integration, very focused, very accountable, what is the ROI on the end user production application? That’s how most of these things start.
Got it. So if you can solve that first problem in the order of weeks, is it fair to say you can often solve a second or third problem almost in the order of days, because you’ve already got all the data there?
TM: Exactly. And this is where it gets fun and where really we end up being bound by the ambition of our customers, of seeing that and saying, “Okay, once I have this, what’s the next thing that I can do? What’s the next thing that I can do? What’s the next thing that I can do?”
It’s almost like an analogy of Palantir, the company, where because you start out with this grand ambition and once you realize you’re solving all the problems, now you can go into customers, you can basically install your grand ambition by default, because that’s the way you solve a singular problem and then as they just appreciate the opportunity goes from there.
In the hands of an FDE, Palantir’s products, Foundry and Gotham, are ready-built playgrounds that empower us to be flexible and efficient in how we solve problems. Unlike consultants, we can pull most of the pieces together out-of-the-box, meaning we don’t need to reinvent the wheel for each customer and spend years creating a patchwork solution. Instead, we can focus on composing the right architecture of features or whipping up a new secret sauce to supercharge users.
Day in the life of an FDE:
I am currently working on a project for one of our DoD customers, where I’m creating new functionality on top of our Gotham platform. Typically, a chunk of my day is spent designing, writing and testing workflows. Another portion is spent configuring Gotham to unlock new functionality within the platform. This could involve configuring new data models or working on stability improvements and upgrades. I also reserve some time each day for comms, emails, meetings and stand-ups.
What are some of the technical challenges you encounter?
40% of Palantir’s current 5k employees are FDEs per LinkedIn