Y CombinatorBob McGrew: How Palantir FDE Model Became the AI Playbook
Through Palantir echo and delta teams embedded on-site as FDEs; the model turns product discovery into the dominant go-to-market for AI agent startups.
CHAPTERS
- 0:00 – 0:29
Why FDEs are booming in AI: product discovery with no incumbent
Bob frames the forward deployed engineer (FDE) model as a response to AI agents entering a market with no established incumbent product. Because the solution shape is still being discovered, startups need people who can do “things that don’t scale” repeatedly—at scale—inside customer environments.
- •AI agents lack an incumbent workflow to copy/replace, increasing product discovery needs
- •FDEs bridge the gap between current product capability and real customer needs
- •Goal is to increase value delivered (often reflected in larger contract sizes)
- •Core idea: doing non-scalable work in a repeatable way across customers
- 0:29 – 1:47
Bob’s background and why founders keep asking about Palantir (not ChatGPT)
The hosts introduce Bob McGrew’s path through PayPal, Palantir, and OpenAI, and set up why the conversation is centered on Palantir’s FDE model. Bob notes that many AI founders now seek tactical guidance on executing this strategy.
- •Bob’s roles: early PayPal engineer, Palantir exec, OpenAI CRO (ChatGPT/GPT-4/o1)
- •AI startup founders are intensely focused on the Palantir deployment playbook
- •FDE hiring has surged across YC startups
- •Motivation: practical go-to-market and product discovery challenges in AI
- 1:47 – 3:10
What a forward deployed engineer actually does (in practice)
Bob defines an FDE as an engineer embedded with the customer to close the gap between product and need. The job is to take an unsolved, customer-specific problem and deliver a working outcome using the product plus targeted build/customization.
- •FDEs are technical staff who work at/with customer teams directly
- •They translate ambiguous needs into a deployable, working solution
- •Often solving problems the company has never solved before
- •Collaboration with product/engineering to turn field learnings into capability
- 3:10 – 4:42
How Palantir invented the model: demos, secrecy, and iterative learning in intelligence
Palantir couldn’t rely on typical customer interviews because intelligence workflows were hard to access and hard to describe. They started with a demo, used it to provoke concrete feedback, and iterated rapidly—an early version of “get out of the building,” but under extreme constraints.
- •Building for spies meant limited access to requirements and users
- •A demo-first approach elicited actionable critique and real needs
- •Iterative cycles resembled modern startup customer development
- •Traditional post-PMF scaling assumptions didn’t hold for Palantir’s market
- 4:42 – 7:18
Why classic scale playbooks failed: heterogeneous customers and the platform pivot
Bob explains that after early traction, Palantir found each customer needed something slightly different, preventing a single uniform product rollout. Shyam Shankar’s insight was to embrace customization as structured product discovery: field teams build “gravel roads,” HQ turns them into “paved highways.”
- •Customer needs varied enough that a one-size-fits-all product didn’t work
- •Palantir built a customizable platform rather than separate products per customer
- •FDEs create tactical solutions; central team generalizes for future customers
- •Metaphor: field prototypes are gravel roads; productization is paving highways
- 7:18 – 9:41
FDE-led discovery vs sales-led discovery: solving from the inside
Instead of sales relaying requirements from the outside, Palantir used embedded technical teams to solve operational problems within the organization. Success depended on choosing a top-priority executive problem first, then expanding to additional, often higher-value problems once credibility was earned.
- •Traditional defense/government sales hires didn’t fit Palantir’s culture or needs
- •Embedded teams discover needs through day-to-day workflow proximity
- •Must solve a CEO’s top priorities to sustain organizational energy and access
- •Model shifts from “sell the same thing” to “land and expand”
- 9:41 – 11:20
The Echo and Delta team structure: analysts/account owners plus rapid builders
Bob lays out Palantir’s canonical structure: Echo teams embedded with users and owning the relationship, and Delta teams as fast, pain-tolerant engineers who prototype and deploy. The operating cadence centers on short timelines, leadership check-ins, and expansion after proving value.
- •Echo: embedded analysts + account management + use-case selection
- •Delta: fast-moving engineers who prototype and deploy under real constraints
- •Operate with a near-term milestone demo to leadership followed by scale-out
- •Designed for speed, iteration, and operational outcomes rather than features
- 11:20 – 14:24
Hiring for the field: heretic domain experts and prototypers (not craftsmen)
The team profiles were distinct: Echo hires needed deep domain context but also a “rebel/heretic” mindset to challenge the status quo. Delta hires needed rapid prototyping ability and resilience, not long-horizon craftsmanship, because early versions are often rewritten.
- •Echo: domain expertise + willingness to reject “how it’s always done”
- •Echo must find step-function improvements (3x–10x), not incremental tweaks
- •Delta: high-velocity prototypers who can ship under ambiguity and pressure
- •Expect rewrites; maintainability is secondary during early deployment cycles
- 14:24 – 16:02
Is it consulting? The scaling risk—and the margin test for real software
Bob acknowledges the critique is valid if discipline slips, and explains how Palantir evaluated whether it was becoming a services business. Healthy FDE economics often start with negative margins but improve as product leverage increases and access expands to more valuable problems.
- •Risk: devolving into consulting if deployments don’t productize
- •Early deployments can lose money; margins should improve over time
- •Costs drop as product fits better and requires fewer people onsite
- •Success also means earning access to higher-value, higher-impact problems
- 16:02 – 17:40
Product management’s hard job: generalize without overfitting to one customer
Palantir’s product team had to maintain a platform vision, extracting the general problem behind a specific customer request. The common failure mode is directly importing a one-customer solution into the product, producing brittle, over-specialized software.
- •Product team holds the long-term platform vision across customers
- •Avoid the trap of shipping one-customer customizations as core product
- •The ‘right’ problem is usually more general than the customer’s stated need
- •Effective collaboration includes bringing multiple customer-context FDEs into design
- 17:40 – 20:26
The birth of Palantir’s ontology: abstraction as the unlock for customization
Bob uses the ontology as the clearest example of generalization: rather than fixed tables (people, money, etc.), Palantir built a highly general object/property/link model. Customer-specific meaning lives in the ontology layer, enabling reuse while preserving per-site specificity.
- •Fixed schemas don’t generalize across heterogeneous intelligence workflows
- •Core model: objects, properties, media, and links—extremely general schema
- •Ontology encodes customer-specific semantics (person, ship, money flow, etc.)
- •Product managers had to think at abstraction layers uncommon in typical SaaS PM roles
- 20:26 – 23:49
Managing tension between field incentives and platform incentives
Field teams optimize for the quickest path to solve the immediate problem; product teams optimize for reusable platforms. Palantir reduced friction by ensuring field prototypes informed platform design and by comparing multiple similar-but-different workflows to converge on shared abstractions.
- •Tension is primarily incentive-driven, not purely skill-based
- •FDEs should take the simplest approach for the customer (‘gravel road’)
- •Product must incorporate field input plus multi-customer validation
- •Design sessions that include multiple site perspectives align everyone on the same problem
- 23:49 – 28:59
Why AI startups are adopting FDEs now: heterogeneity + new market category
Bob explains that Palantir’s world resembled many sub-segments with limits to reuse, requiring repeated ‘things that don’t scale’ across segments. AI agents face a similar dynamic: no incumbent category, lots of unknown workflow shapes, and discovery that can only happen inside enterprises.
- •Palantir’s market was many segments, each with different workflows and limits
- •AI agents similarly represent a new category with unclear best practices
- •Without incumbents, discovery can’t be purely top-down or purely product-led
- •FDE model becomes a repeatable mechanism for learning inside organizations
- 28:59 – 34:50
Common mistakes: picking/pricing outcomes, taking on risk, and clearing IT blockers
Bob highlights where second-hand implementations fail: choosing the wrong problem, misunderstanding that you sell outcomes (not software installs), and pricing accordingly. Early on, startups often must absorb execution risk, while also securing executive sponsorship to overcome IT and compliance friction.
- •Best-performing FDE startups often import experienced Palantir operators
- •Core sale is an outcome; pricing must reflect delivered value, not seats/usage
- •Startups may need to assume risk because enterprises expect failure
- •Executive sponsorship is critical to bypass misaligned IT processes and constraints
- 34:50 – 40:52
Success metrics and scaling: drive outcome value, contract size, and product leverage
Bob contrasts classic PMF scaling (less work per customer) with the FDE strategy (more valuable outcomes, larger contracts). The key is increasing product leverage over time so each new customer (or new use case) becomes easier to deliver, even if customization per customer remains steady.
- •FD strategy aims to increase contract size/value delivered, not keep it constant
- •Track outcome value and how well you can monetize/capture it
- •Measure rising product leverage: fewer engineers needed to deliver more value
- •A strong platform helps with adjacent use cases, not just repeat repeats
- 40:52 – 44:42
Demo-driven development and building a learning company
Demos force teams to think from the user’s perspective and integrate features into coherent workflows that create desire. Bob argues the FDE model requires a learning culture—continuous iteration under uncertainty—which is why Palantir (and young companies generally) can be strong founder training grounds.
- •Demos reveal whether features actually relieve a customer’s real pain
- •A single narrative demo can guide feature integration and usability
- •FDE organizations must learn constantly; judgment calls are unavoidable
- •Young, learning-oriented companies are strong environments for future founders
- 44:42 – 47:37
Joining the US Army Reserve (Detachment 201): applying the FDE mindset to transformation
Bob describes joining the Army Reserve as an officer advising on technology as part of an official transformation effort. He draws parallels to FDE work: align to leadership priorities, identify gaps between intent and implementation, work with operators, and escalate when needed.
- •Bob joined the US Army Reserve as part of Detachment 201 (direct commissioning)
- •Role: advise on technology with ‘skin in the game’ as officers
- •Army leadership has articulated transformation priorities for modern conflict
- •Approach mirrors FDE strategy: on-the-ground problem finding + leadership alignment
- 47:37 – 50:42
Opportunities for founders: bridging fast AI capability gains and slow adoption
Bob argues AI capabilities are improving faster than adoption, creating a large opportunity to close the ‘capability-to-utility’ gap. Startups can function like FDEs for the AI research frontier—turning raw capability into dependable, adopted workflows amid real-world constraints.
- •Capabilities are accelerating, but adoption lags significantly
- •Real progress requires human ingenuity, workflow redesign, and persistence through ‘pain’
- •Massive opportunity: make frontier AI genuinely useful in specific contexts
- •Analogy: research labs are the ‘home product team’; startups are the ‘FDEs’ driving adoption
