In early May, Anthropic and OpenAI each announced the formation of enterprise services companies on the same day. Anthropic, partnering with Blackstone, Goldman Sachs, and others, established an enterprise services joint venture valued at $1.5 billion; OpenAI was also reported to be setting up a new company called The Development Company, planning to raise $4 billion from 19 investors at a $10 billion valuation.
The two companies have different directions and no overlapping investors, but the core organizational model supporting both is the Forward Deployed Engineer (FDE) model popularized by Palantir.
Similarly, according to Business Insider, FDE-related positions surged from 643 in April 2025 to 5,330 in April 2026, a year-over-year increase of nearly 729%. Anthropic, OpenAI, Palantir, Stripe, and Google Cloud are all competing for talent.
Recently, the FDE has almost become the most sought-after job in the tech industry, and the most critical role in AI implementation.
Why is everyone scrambling for FDEs in the agent era?
Because customers aren't buying software—they're buying an "agent that can get work done." PMF increasingly happens at the customer's real business site. FDEs are stationed directly on-site, understanding the customer's data, processes, and pain points, then polishing general-purpose models into concrete solutions that can run the business. They are engineers, but also product managers, Solutions Architects, and even half consultants.
How was the FDE role designed? How does Palantir select people, build teams, and drive products internally?
This article is an in-depth retrospective on the FDE model by Bob McGrew, former Palantir executive and former Chief Research Officer at OpenAI. As Palantir's second engineer, Bob experienced the FDE model's birth from 0 to 1, and personally participated in every step of product building, talent screening, and team assembly.
In this piece, he systematically breaks down what Palantir's FDE model actually is, and why, in today's AI agent era, it has become an organizational template worth re-examining for startups.
Founder Park is continuously looking for AI teams and projects worth being seen.
Through our "AI Product Marketplace," content coverage, and community distribution, we can help you reach early users, get real feedback, and build key connections.
If you're working on something AI-related, we'd love to chat with you.
01
What exactly is an FDE?
Host: A few months ago, Bob attended an AI conference organized by YC. An interesting phenomenon was that he originally expected all the founders to come talk to him about ChatGPT, but instead, all of these founders wanted to talk to him about Palantir's FDE. What exactly is an FDE, and why have FDEs become so important today?
Bob: It wasn't just that one conference. Over the past year, when I've consulted for AI startups, many of them cared almost exclusively about how the FDE strategy works.
An FDE is typically a technical person who is stationed at the customer's site, filling the gap between product capabilities and customer needs.
As a startup, you first have a product, then you approach a new customer and try to work with them, and the problem they want you to solve is one you've never solved before.
In this process, you believe that through hard work you can solve this specific problem for this specific customer, and you will deliver a highly valuable outcome for them.
So the FDE takes the existing product, and with the help of the product team, figures out how to deliver that outcome, building a use case that's valuable to the customer, delivering the software you've already built in a way that truly works for the customer.
Host: Let's look back at how Palantir invented the FDE strategy model.
Bob: When Palantir was first founded, the company's focus was building software systems for the intelligence community. The challenge was that we didn't know anyone in intelligence—almost nobody in real life does—and even if we found such a person, if you asked them, "What exactly does your work involve?" they couldn't tell you. This forced us to adopt an approach that was very unusual at the time.
We started this task by building a demo, then trying to show that demo to potential customers in the intelligence community and collecting feedback.
One of Palantir's founders, Stefan Cohen, did exactly this. He would show the demo to potential customers and ask them, "What do you think?" They would say, "This product is terrible, it has nothing to do with what we do." Cohen would then ask, "How would you want it to be different?" And they would say, "Could you make this change and that change?" So Cohen would write all of that down.
Ideally, in the early days of a startup, you have to do a lot of things that don't scale—going out to visit customers and studying users. Once you find PMF, your strategy changes: you pull back from users, focus on scaling, and treat all customers the same.
If a founder's industry allows for such smooth scaling, then they don't need FDEs at all. But for Palantir at the time, that wasn't possible.
The FDE approach was actually proposed by Shyam Sankar (an early Palantir member, now President and CTO).
We found that every customer wanted something different. Rather than making a separate version for each customer, or patching in a bunch of features that only applied to one specific customer, it was better to make the product a highly customizable platform. But doing so meant you had to send employees on-site to deeply understand users and make local adaptations.
By conventional thinking, all of this counts as Services, which in the PMF paradigm framework is best minimized.
But Shyam flipped this logic: let the FDE serve as the process of product discovery.
The FDE comes in with the existing product, fills the gap between product capabilities and actual needs, and lays the route first as a "gravel road." The product and engineering teams at headquarters then abstract and generalize these on-site practices, paving them into a "paved superhighway" that can serve the next five to ten customers.
Host: At Palantir, it's the engineers who face enterprise customers directly rather than professional salespeople. How did this come about? Especially when the customers are government and defense agencies—most people would tend to hire a group of experienced salespeople who have long-standing relationships with government officials, but Palantir didn't do that?
Bob: There were two reasons:
On one hand, we had early contact with many people like that, and their reaction was: "Why would I work with a Silicon Valley company instead of one of the five major defense contractors?"
On the other hand, while these people's backgrounds seemed qualified for the job, we actually knew very well that they couldn't fit into our culture and wouldn't truly succeed. When we tried that approach, it almost never worked.
So we discovered a very different way. I think the difference between sales-led product discovery and FDE-led product discovery is that sales-led product discovery means talking to people from the outside. FDE-led product discovery is more effective because FDEs solve these problems from the inside.
You need to focus on solving the key problems identified by leadership. If what you're solving isn't one of the CEO's top five priorities, it probably won't succeed—they won't have the energy to persist through that more challenging path, which is truly landing a brand-new product capability in their specific context.
Once you've solved the first key problem, the FDE can then discover other key problems within the enterprise—sometimes problems even more valuable than your original target. It may not be obvious whether Palantir or your company can solve them, but once you're there, you can see through product insight that you actually can. Then you go solve those problems.
So this shifts from "how do I sell the same thing to every customer" to "land and expand."
Host: Can you elaborate on how Palantir's FDE model works?
Bob: The first thing to think about is how the FDE team is structured. There are two key roles, which we call the Echo team and the Delta team.
The Echo team, specifically, are embedded analysts. They go on-site with the customer, talk to users, and try to figure out what kind of demo or use case would be genuinely valuable to the users in that scenario, and what the key problems to solve are. At the same time, they also serve as account managers, so they are the ones managing the customer relationship.
The Delta team, as deployment engineers, are essentially software engineers. These people are usually very good at writing code quickly—they're the ones who bring those ideas into the real world. They build solutions and prototypes, then land them as products that actually run, and ultimately deploy them for the customer.
All of this gets done in a very short time. The FDE team goes in with an idea for a project to build, and sets a date a few months out to demo their progress to leadership. If that demo goes well, it gets truly deployed and rolled out across the customer's entire organization.
02
How to Build an FDE Team
Host: What's interesting about these two roles is that they are completely different types of people with different backgrounds. How do you find the right people for these roles? Because not just any ordinary engineer can be an FDE—they need to be better at talking to users, or the Echo team also needs a stronger technical background rather than just being account managers. How does Palantir build its FDE teams?
Bob: The ideal talent profile for the Echo team is a domain expert. For example, it might be a former Army officer, or someone with deep work experience in healthcare. They have deep domain knowledge. Beyond that, one thing that's very important: Echo team members need to have a "rebel" quality—Sham even calls them "heretics." These are people who not only understand the existing way of doing things, but can also recognize where that way falls short. Because if you can't see the problem, you'll never come up with new software or the kind of step-change it can bring.
For the Delta team, we need people who are extremely good at prototyping.
The wrong hire for Delta is the perfectionist craftsman type—someone who is great at writing code, loves being absolutely correct at the level of abstractions, and wants the software they build to be maintainable for the next decade or more.
What we actually want is the kind of person who can figure out how to get a product implemented, even if the code they write is rough. Sometimes, if you find the right person, their code is also beautiful, but most of the time it isn't—and that's not the core of what the Delta team is about. The Delta team is made up of people who can actually deliver results in the form of software within a given timeline. Even if the first version they write isn't high quality and has to be torn down and rebuilt, they're very good at prototyping—that's the key skill for this team.
Host: The talent profiles for Echo and Delta sound a lot like a startup team. Does Palantir recruit former startup founders to fill these roles? Or is it mostly the other way around?
Bob: Palantir has incubated a surprising number of startups, and it's no coincidence, because FDE training is training to become a startup founder—you're essentially learning all the skills of a startup founder. Back when we first started doing this, there weren't a lot of founders available for us to choose from.
The Palantir Mafia: Palantir alumni, early collaborators, and investors have formed a tight-knit alumni network. They share recruiting and fundraising information in private groups (like Palantir Pals), and organize in-person events (like the Russian River camping trip in Sonoma), forming a powerful network of connections and capital. Luba Lesiva, Palantir's former head of investor relations, also founded Palumni VC, which invests exclusively in alumni companies.
Palantir alumni have founded or run 350+ tech companies, at least a dozen of which have reached unicorn status. Representative companies and people include:
• Defense tech company Anduril (founders Trae Stephens, Matt Grimm, and Brian Schimpf are all Palantir alumni), valued at roughly $30.5 billion as of June 2025
• Data analysis and collaboration platform Hex (founders Barry McCardel, Caitlin Colgrove, and Glen Takahashi are all Palantir alumni)
• Public safety data platform Peregrine (founder Nick Noone previously led Palantir's special operations business; valued at roughly $2.5 billion after a March 2025 funding round)
• Medicare navigation and brokerage platform Chapter (founder Cobi Blumenfeld-Gantz is a Palantir alumnus)
• AI voice company ElevenLabs (co-founder Mati/Mateusz Staniszewski is a former Palantir FDE)
• Digital contracting platform Ironclad (co-founder Cai GoGwilt is a former Palantir engineer)
• Digital health insurance company Angle Health (founder Ty Wang and CTO Anirban Gangopadhyay both came from Palantir engineering)
• Fintech company Blend (founder Nima Ghamsari worked at Palantir early in his career)
• Developer tools company Sourcegraph (CTO Beyang Liu was an engineer at Palantir)
• Sales intelligence company RelateIQ (co-founder Adam Evans built the healthcare business at Palantir)
You're absolutely right—what the FDE team does at each customer site is indeed a bit like being a founder. But the difference for FDE members is that they're founders with access to some very powerful product leverage, which makes your job easier. I think it's great training, and that may be why we're now seeing so many founders come out of Palantir.
03
FDE Is Not Consulting—
Building General Products Matters Just as Much
Host: People who don't know much about FDE often say: "This is just consulting dressed up in fancy marketing language." Why is that claim wrong?
Bob: Objectively speaking, there is indeed a risk of FDE becoming exactly that. If you talked to people about Palantir in 2015, you would likely have heard two main things:
• First, Palantir is evil (note: Palantir worked with intelligence agencies early on, doing spy-related work),
• Second, it's a consulting business that could never scale—it's not a software company, it's a consulting firm.
In the past, we actually spent a lot of time trying to understand whether that criticism was correct.
From a business model perspective, one key trend we would see is this: when we went to a new customer to do a new project deployment, at the beginning we might actually be losing money. But as we spent more time with the customer, our product became better suited to the customer's needs through product exploration, so we no longer needed a large team on-site at the customer to figure out what they needed. And, as Sham would say, we would gradually earn the right to work on the more important problems at the customer site.
So the end result is that we'll see the cost per value of delivered outcomes declining. In other words, our profit margins start out negative, but eventually, after some period of time—maybe a year, maybe several years—they turn positive.
If you look at it from this angle, you'll realize that we're actually delivering genuinely repeatable value. The product team is key to making this model work and driving costs down.
Host: How does the product team work with the FDE team?
Bob: Palantir has two core teams: one is the FDE team, and the other is the product management team.
The products we build are not highly verticalized—they're not standard workflows like Airbnb's that can simultaneously support the needs of millions of people. The product team's role is to truly own the product vision. So they have to think: when you see a new problem at a customer site, what would its generalized form look like? What version could be applied to the next 10 customers?
A classic failure example is when an FDE builds something for one customer and then directly pulls it into the product. The result is that what the FDE built is too specialized for other customers. The key here is having product people who are capable of building more generalized products.
Host: So you need some know-how to judge whether something only applies to that vertical or can be generalized. Can you give us a concrete example?
Bob: Probably the best example is the invention of Palantir Ontology.
When we first considered working with the US government, especially the intelligence agencies, the instinctive approach was: create a table for "people," create another table for "funds"...
But we quickly discovered that going down this path, once you tried to deploy across different agencies and customers, you'd run into problems that couldn't be generalized. So we raised the level of abstraction—instead of presupposing specific object types, we let FDEs define them according to each customer's context. The underlying layer only provides generic objects, properties, and so on. Palantir Ontology was born out of this way of thinking.
Host: How does the Ontology work now? Is there a base database schema containing generic, reusable objects like people and money, which is then customized per site?
Bob: The database schema itself is extremely generic, keeping only: objects, properties, media, and links between objects.
I'm referring here to Palantir's government product (which was also our first product). As for the specific semantics in each customer scenario, those are encoded by the Ontology—for example, labeling a certain entity as a "person," labeling a certain entity as a "vessel," or labeling a set of relationships as a "money flow."
If we only built features for a single customer, we'd be held hostage by that customer's way of expressing things—for example, we'd start thinking "this is how we'll handle people." The right approach is to raise the level of abstraction further: ask "do we have a generic operation that applies to all objects with a certain property?" For instance, "people" and "vessels" might both have a certain property, but payment records don't, so the processing logic can't be one-size-fits-all. This requires you to always think at a higher level of abstraction.
We went a long time without hiring product managers. When it finally came time to hire them, I interviewed quite a few people who were excellent at other companies, but getting them to think at this level of abstraction was not easy. Many would immediately fall into "designing a specific workflow for this customer," but in Palantir's model, that's the wrong move. They need to lift their perspective to the ontology level and think about how to adjust the modeling within the ontology framework so that a specialized feature can be reused across customers.
04
Why FDE Is the PMF of the Agent Era
Host: Today almost all these AI companies are hiring FDEs at scale. What do you think is the reason behind this? Why didn't the previous generation of SaaS companies do this? Even after Palantir succeeded and the FDE model became better known, FDE was still seen as an outlier, because people believed Palantir was a unique company—a company selling to the government.
Bob: I'm also surprised by this trend. But my advice to those considering trying the FDE strategy is: if you don't absolutely need FDE, don't actually try it yourself, because you might end up doing services. If, after a series of attempts, you find that you'll definitely fail without FDE, then FDE may be the only viable way in your market, and it may well be a moat for you.
As for why the FDE trend is emerging in today's AI agent market, perhaps we can return to the question of why Palantir had to adopt this model.
Palantir's market is not a single, coherent market. We work with national intelligence agencies, national law enforcement agencies, and the military. Although all of these organizations have some similar projects, even between the counterproliferation workflow and the counterterrorism workflow there are significant differences—one is figuring out who is building nuclear bombs, the other is figuring out who is building IEDs—and they actually operate in very different ways.
So there is enormous heterogeneity here. We should think of the market as different segments, and within each segment, you can build something where the Crossing the Chasm story applies to some extent.
At first it seems like nothing works, then suddenly you find PMF in a certain segment, and you can deploy to the people doing that kind of workflow. Then at the next customer, you find the same kind of people doing similar workflows, and you can deploy with very little customization.
So now you want to go after a different segment, and you have to develop a new technology, which can then be referenced in other segments. A segment doesn't necessarily equal a customer—especially in enterprises, or in very large organizations like governments, one customer can mean tens of thousands of users. In that case, the FDE strategy matters, because you're doing things that don't scale, but you're doing them scalably, over and over again, for each segment you enter.
I think another thing unique about Palantir is that we were building an entirely new type of product.
Users were accustomed to using a tool that looked like PowerPoint to do analysis and track people, collaborating by sending these files back and forth to each other. But the product we built essentially said: "When you're drawing that link chart, you're not just editing a file—you're actually changing a database, and everyone shares the same database." While to users this looks like a small change layered on top of the work they were already doing, for the enterprises and organizations we sell to, it's a completely different market category.
I think this is what's happening with AI agents—it's a brand-new market category.
If you're implementing a standard SaaS product, you're replacing one way of paying bills with another way of paying bills, and everyone understands what that market is. Such segments don't have that many fine-grained divisions, nor that much exploration of like-for-like products—you try to build a product better than the existing one and scale by displacing it.
With AI agents, there's no existing product. Building an AI agent could actually mean many different things, and we don't yet know what those are—we have to figure it out. It's even possible that five years from now, looking back, we'll feel that AI agents were never one thing at all, and that we were actually doing all these different things.
So that's why I think you're seeing the FDE model rise: there's too much product exploration work to be done, and you can only do it from inside the enterprise.
Host: How does this relate to the classic YC advice to "do things that don't scale"?
Bob: That's advice YC gives to early-stage founders, whereas the FDE model is actually about doing things that don't scale at massive scale.
Host: A lot of people are now trying to adopt the FDE model, including many who never worked at Palantir. Have you seen where people are getting it wrong?
Bob: The most successful startups I've seen doing the FDE model all have people from Palantir running their FDE operations.
Like I said, engineering teams tend to be very similar, but the actual FDE operating mechanics—how you establish these customers, how you define outcomes, and so on—are actually very different from a standard software company.
One key difference, and I think the thing people struggle to understand, is: how to pick a problem, and then how to price for that problem. Fundamentally, with the FDE model, you're not selling the installation of a specific piece of software—you're selling an outcome. As Sham would say, you're selling the fact that you solved a problem.
Host: In the SaaS era, you'd price based on usage, subscriptions, or seats. FDE is completely different—it's outcome-based. How should all these AI founders price their solutions?
Bob: Yes. I think one very important difference between the FDE model and the standard SaaS model is that with the SaaS model and PMF, people tend toward very simple, repeatable contracts and very simple, repeatable pricing that makes sense across all customers, and usually SaaS teams are happy with small-dollar contracts because the marginal cost of deployment is very low.
With the FDE model, the business interactions get pushed toward larger and larger contracts. As we discussed earlier, the contract value per customer grows over time. Because the product requirements are complex, the contracts are complex too, and both the product and the contracts need to be more flexible and elastic to accommodate that complexity.
Host: Some YC companies are starting to do this too. For example, Kastle is an AI voice agent serving mortgage services for banking customers; they measure the outcome by the number of calls that successfully handle all these mortgage requests, and their contract sizes are gradually increasing. Happy Robot mainly builds AI voice agents for the logistics space, working with big companies like DHL—a similar situation.
Bob: There's an asymmetry here between the startup and the party they're selling to—usually large enterprises.
When startups sell to large enterprises, first, the enterprise customers often don't believe they can actually get anything done themselves, because they've had many failed large-scale projects. And they don't believe the startup team can get anything done either, because they assume your startup is just like them.
But the startup knows it can actually execute and deliver. So early on, it makes sense for the startup to take on all the risk and say, "We believe in our own execution. We'll take the risk—you pay us if we succeed, or pay us when we're able to scale."
Host: Where this can go wrong is if what the startup builds needs to be deployed inside the enterprise—on-premise, or even if just any part of it needs to run locally. Then you get arguments and coordination with the enterprise's internal IT team.
Bob: We've seen this at some companies too. The question might be: whose support inside the organization does an FDE project need to win over? Because those people don't think like the startup, and their interests aren't aligned with the end users. So you have to find ways to work around them.
That's why it's important that if a startup wants to do FDE, it must focus on solving one of the CEO's top five problems—because when you hit internal organizational blockers, you need to be able to bring in someone from the top who says: "Yes, give them access to operate, they need to use this specific type of database..."
Host: How did Palantir get executive buy-in from the enterprises it worked with?
Bob: The core is that you need truly outstanding leadership within the FDE team to have that discipline, and to share the effective methods, practicing that discipline and those methods at one customer.
I don't think this is particularly magical or hard to do. The best companies I've seen doing it learned from people who had done it before. It can be learned—we learned it.
Host: YC has a concept called the Collison install. We basically boil it down to: don't wait for people to come to your website—go find them, get them to install the software, go to them in person, go to their offices, sit next to them. I've always thought that's a great starting strategy.
But most startups can't land big contracts at the beginning. So in practice, the reason they eventually have to stop this manual, high-touch process is that without a product that can scale, you simply can't sustain your growth rate. It's a bit like what we discussed earlier: at some point, you want the product you've built to be good enough that people can handle it themselves, and then all your problems are just scaling problems.
With AI, the difference is that because these contracts are now so large, you can actually go quite far doing this high-touch stuff. A question I get asked a lot is: "How far can I push this?" My advice is broadly: "It's fine to do custom work for each customer—you just want the degree of customization per customer to keep decreasing."
What's your take on this? How do you know whether it's still fine to keep adding new customers in this high-touch way, or whether I actually need to start abstracting and building a real product—and when do I need to change strategy?
Bob: Yes. I think this actually captures the key difference between the PMF strategy and the FDE strategy.
With the PMF strategy, the team wants to do less and less work for each customer, reduce costs, and keep contract sizes flat.
But with the FDE strategy, the expectation becomes increasing the contract size, and increasing the contract size means you're doing increasingly valuable work for that customer and for future customers. Because you're doing more valuable work, it's fine—you can keep the degree of customization per customer constant.
Host: So the KPI is contract size, not necessarily how much custom work they do per customer?
Bob: There are two useful things here.
First, the thing you can measure is contract size. I'd even put it more generally: the value of the outcomes you deliver, because that's the real thing. If you can deliver increasingly valuable outcomes for customers, then you're doing it right.
The second part is the value of the product. So the other thing to measure is whether you're gaining more and more product leverage to amplify that outcome.
When you're in the middle of it, all of this is very counterintuitive.
If you're doing the FDE model, or leading an FDE team, there are many things you must do that look very counterintuitive, and it's very hard, because you have to build for customers things they didn't ask for but actually want.
And on the product side, you need to think about how to make a product that's very easy for every customer to use. Because if you care about user experience, you have to do that—but at the same time you must remember that your other key customer is the FDE. Your product should ultimately deliver good things to users after the FDE customizes it; the product should provide leverage for the FDE delivering that outcome in the field, and the amount of product leverage should increase over time.
Host: Like the FDE should be able to deliver more value to the customer with your product, without having to pull in three more engineers to do it.
Bob: Yes. If the first customer you deploy for takes a lot of work, then if you want to sell the same outcome to another customer, it should be much easier. As you go customer by customer, it should get easier and easier.
But remember, an FDE should be building a platform, so what you're doing isn't just a pile of vertical use cases stacked on top of each other. You need to correctly abstract out the core concepts you're actually building, which makes your work easier and gives you more product leverage—even when you're not working on that specific use case, but on something similar. Or you may find that if your product is really good, your FDEs will come up with new ways to use the technology you've built to solve completely different problems.
Host: It's almost like an internal market dynamic at work. If you build something really well, FDEs should choose to use it, and you should see FDEs demanding to use your kind of abstraction rather than building their own one-off solutions.
Bob: Yes. But I want to point out that this is an extremely painful process for everyone involved. In the world of FDEs, I can't use the word "painful" enough.
There have been many times when I built something I thought was great and beautiful—not quite there yet, but I believed it could genuinely help the FDEs, if only they had the ability to see it. I'd say, "Please use my product." And they'd say, "No, it's too much work, it's completely useless."
Honestly, most of the time I was probably wrong—I had built the wrong product for them, and I should have seen that. But sometimes I was on the right track and just hadn't done enough to make it easier for the FDEs to use. So I would send developers into the field to deploy those early solutions and help them get over the hump.
Host: Is FDE always effective? Or should founders sometimes make a top-down decision and say, "This is what I want you to do"?
Bob: Both approaches can be right in different situations. The right answer here is largely a matter of judgment.
Going back to the question of product vision—from one customer to the next three, to the next ten—what is the right general-purpose product? When you're looking at your first customer, you really don't have the information needed to answer that question. So it purely becomes a matter of judgment.
Host: In the SaaS world, engineers resist demo-driven product development, but in the FDE context, demo-driven is important?
Bob: Actually, I think if you have the right type of product, demo-driven development works extremely well.
In Palantir's early days, we really only had one demo—a workflow where you were stopping a terrorist plot. We started with just one feature, and every time we integrated a new feature, we had to think: how do I demonstrate this new feature in a way that's genuinely helpful to the analyst going through the demo, stopping the plot? When we integrated histograms, we had to ask: how do we actually use this, and how does it work with the features we already have? Same question when we integrated maps.
If you look at the world through the lens of "what am I building," you're thinking about your capabilities, and you might consider each feature in isolation and how to build the best version of each. But when you're building a demo, you're thinking from the customer's perspective.
A good demo is one you show to a customer where you create desire in the customer's mind for what you've done. They have to see what you've built and just want to reach out and grab it, bring it into their lives. If you see that, then you know you've discovered a real pain point for the customer. Doing this also forces you to build a better product, because you're not just thinking about whether each feature makes sense on its own, but also about how they work together.
If I'm going to show this demo over and over again, even something as simple as moving from one feature to the next has to be very smooth. These are product pain points you often see, but usually only after you've actually deployed to customers. So the role of the demo is that it shifts your focus from thinking "what can I build" to "what does the customer want," and "am I solving that pain point for the customer?"
Host: It sounds a bit like you have to continuously do gradient ascent in this very high-dimensional, multi-dimensional space, constantly changing the variables (a math metaphor).
Bob: Yes. Perhaps a really crucial point here is that the type of company you have to build is a learning company—and I think everyone wants to build a learning company.
But if you're a company like Google or Meta, it's easy not to learn, because what you're doing now is working. If you just keep doing it, the market is growing, everyone wants to do what you're doing, and you can just coast on the same strategy while it keeps paying off.
My advice to people considering which company to join is: join a young company—not necessarily a small one, but a young one. Because a young company is still figuring things out, still learning; it hasn't succeeded yet. If you've just graduated from college, you should join a young company that's growing very fast, and then you'll see what success looks like—which positions you to be a founder of your own company later.
That's why Palantir has spawned so many other startups—because even as a very large company, it's still a company where everyone is constantly learning and focused on learning, and always working as hard as a startup.
Host: You recently joined another huge organization, the U.S. Army Reserve. What lessons from Palantir can be applied to that experience?
Bob: The Army leadership feels very different from when we worked with them in Palantir's early days. Back then (around 2005 or 2010), the Army leadership had already articulated a plan for Army transformation—they knew clearly that the military needed to shift from the warfare of Iraq and Afghanistan to the warfare we see today in Ukraine, or what it would look like if we faced large-scale combat operations in the Pacific.
When they brought in Palantir, they pointed us toward the Army's priorities and assigned each of us a domain in which we should operate, but they also gave us the freedom to go find problems, work directly with officers at the grassroots level to solve them, or, if necessary, escalate them to leadership and get them solved.
So I think one of the really interesting things is that, in many ways, this really is like running the FDE strategy on the Army. We get to see: what are the leadership's top five priorities? Can we make progress on them? But at the same time, in a world where there's a disconnect between what leadership wants and how things have been implemented for 20 years, change takes a long time. So we're helping them make that change. I'm really eager for the opportunity to contribute there.
Host: What do you think are the best opportunities for startup founders right now?
Bob: I think this really comes back to the question of why AI agents are adopting the FDE strategy.
The trend we're seeing today is that AI capability is actually improving very fast. Some say people feel AI has somewhat plateaued after GPT-5, but if you look at the period between the best model in April 2024, the release of GPT-4o, and the release of o3 in April 2025, that was actually a very fast pace of progress. I think this trend will continue, and we'll see AI model capabilities keep developing rapidly.
But what's truly striking is that AI adoption is nowhere near as fast as capability progress. Most likely, over the next 5 years, the world's AI capabilities will keep advancing at breakneck speed, yet we'll feel increasingly mediocre in the real world. It's like sitting in a Waymo now—we don't think "Wow, self-driving is here!" but rather "Traffic is so congested, so slow."
The FDE opportunity lies in the timing—right now is a great moment to bridge the gap between what AI capabilities can actually do and what customers can adopt. Large-scale application of AI requires a methodology; it doesn't just happen on its own. It demands human creativity, exploration, and dealing with a huge number of problems to achieve. So I think there's a huge opportunity in looking at what capabilities exist now, and how to make them genuinely useful to people.
Host: I thought of an analogy—it may be a bit of a stretch—but it's as if OpenAI is the headquarters product team, while the startups are the FDEs, out in the field figuring out how to get the research OpenAI develops at its headquarters office adopted.
Bob: I think that analogy isn't bad at all. In fact, I think this may be what's making the entire FDE strategy popular again.
更多阅读
Product Hunt Monthly Rankings Roundup: Building an AI agent alone is no longer enough—you need to break into real, high-frequency workflows
After ByteDance, Kuaishou, and Xiaohongshu, Aban is betting that the next generation of product discovery will move from "spectating" to "experiencing"
To repost original articles, please add us on WeChat: founderparker
If any images in this content involve copyright issues, please contact us promptly for removal.