The most radical model
Forward
Deployed
Engineering
Engineers embedded directly with customers. The field as the product lab. Customer deployments treated as R&D, not delivery. Field innovations migrating back to the core platform.
Read this before going further
Barry McCardel (former Palantir, co-founder of Hex) has written candidly about why FDE is the wrong model for most organizations. His three conditions for true FDE:
- —Engineers who combine top-tier technical skill with customer-facing charisma, creative problem-solving under pressure, and independent product judgment — a profile that is exceptionally rare and expensive.
- —Acceptance that field teams will overlap, duplicate, and sometimes contradict each other's work. Many builds will fail. Most organizations and investors cannot stomach the waste.
- —Genuine subordination of the central product roadmap to field team discoveries. An organization with a planning function that controls what gets built cannot do true FDE.
“FDE is not Forward Deployed Engineering unless all three of these are true. Otherwise it is sparkling Sales Engineering.” — Barry McCardel
The operating model
Four movements, one continuous cycle
Select a movement on the loop to explore its objective, key activities, and the question it forces you to answer.
Every other innovation model translates customer problems. FDE eliminates the translation entirely.
Most organizations build products from offices, developing solutions based on market research, user interviews, roadmap planning sessions, and requirements documents. The people who understand the user’s world most deeply — field teams, account managers, implementation consultants — are separated from the people who build the product by organizational structure, geography, and process.
FDE collapses this separation entirely. The engineers are in the field. The field is the product lab. The customer’s real problems — not a distilled, translated, and deprioritized version of them — drive what gets built next. Understanding FDE is valuable even for organizations that will never implement it, because it exposes the assumptions embedded in every other innovation model.
The question FDE asks every other model
What would your organization build differently if engineers were in the room when the problem occurred, rather than receiving a report about it three months later?
The Auftragstaktik principle
Palantir’s FDE model is built on Auftragstaktik — a military doctrine in which senior leaders set high-level objectives and leave all other decisions to people in the field. Senior leadership defines the mission. FDEs decide how to achieve it. There is no central approval process for field decisions. This doctrine is what makes FDE genuinely different from professional services or implementation consulting — and what makes it genuinely hard to run.
When to consider it
Genuine FDE may be worth exploring when
- →Your market consists of large complex organizations (Fortune 500 or government) willing to pay premium prices for context-specific solutions
- →You do not yet know what the right product is and believe field discovery is the fastest way to find out
- →You can hire engineers who are simultaneously world-class at building and at customer engagement
- →Your leadership can genuinely tolerate the chaos and unpredictability of bottoms-up product discovery
- →You are building a platform designed for extensibility from day one
FDE is almost certainly wrong for you when
- ×You are a SaaS business selling one standardized product
- ×Your unit economics depend on low cost-to-serve
- ×Your investors require predictable product roadmaps
- ×Your engineering team is measured on story points, velocity, or feature shipping rate
- ×Your definition of success is a Gantt chart on slide 71 of a quarterly deck
FDE is a spectrum, not a binary choice
Select a variant on the commitment spectrum to see what FDE looks like at that level of commitment — from the full Palantir model to Commitment Engineering, which delivers most of FDE’s core benefit at a fraction of the cost.
Four variants, one core insight
FDE has not evolved through official versioning the way Design Sprint 2.0 emerged from the original. It has evolved through practitioners leaving Palantir, founding new companies, and either replicating, adapting, or explicitly rejecting the model based on what they learned. The result is not a sequence of dated releases but a spectrum of related approaches — some fully committed to the Palantir ethos, others that distill specific FDE principles into more accessible forms. The four variants below are ordered from highest commitment to lowest. Select a variant to see how it works and what it trades off.
Is FDE right for you?
Where this connects
FDE is an extreme version of the customer-proximity principle that runs through every framework in this library. These are the frameworks and methods that FDE relates to most directly.
Sources & Further Reading
Understanding Forward Deployed Engineering
Barry McCardel — barry.ooo (primary source)
Reflections on Palantir
Nabeel Qureshi — nabeelqu.co
Zero to One
Peter Thiel with Blake Masters, 2014
Team Topologies
Matthew Skelton and Manuel Pais, 2019 (on organizational design for fast flow)