The FDE Playbook for AI Startups

Introduction

The Lightcone podcast, Bob McGrew—former Chief Research Officer at OpenAI and early executive at Palantir—shares the definitive guide to the Forward Deployed Engineer (FDE) model that’s revolutionizing how AI startups operate. With over 100 Y Combinator companies now hiring for FDE roles compared to virtually zero three years ago, this model has become the dominant organizational strategy for AI agent startups. McGrew, who was instrumental in developing ChatGPT, GPT-4, and the O1 reasoning model, provides an insider’s perspective on why this Palantir-originated approach is perfectly suited for today’s AI landscape.

Complete Guide to Forward Deployed Engineers

What is FDE?

Forward Deployed Engineer (FDE) is a technical role where engineers work directly at customer sites to bridge the gap between what your product does and what the customer needs. Unlike traditional sales or implementation consultants, FDEs:

• Are actual software engineers who write code
• Sit embedded within customer organizations
• Build customized solutions on top of your core platform
• Serve as product discovery engines, not just service providers
• Focus on delivering measurable business outcomes

Key Distinction from Consulting: FDEs build temporary solutions that inform permanent product improvements, rather than building one-off custom implementations that never generalize.

When Should You Use the FDE Model?

✅ Use FDE When:

1. You’re in a new product category with no incumbent solutions
2. Customer needs are highly heterogeneous across different sites
3. You need to solve top-tier business problems requiring deep customization
4. Your product requires significant adaptation to deliver value
5. Contract values can be large enough to justify high-touch engagement ($100K+ annually)
6. You’re building AI agents or novel technology where use cases aren’t yet clear

❌ Don’t Use FDE When:

1. You have clear product-market fit with repeatable sales
2. Your product works well out-of-box with minimal customization
3. You’re selling to SMBs with low contract values
4. Traditional SaaS scaling is working fine
5. Customer needs are uniform across your market

How to Create an FDE Team

Step 1: Define Your Team Structure

You need two core roles working together:

Echo Team (Embedded Analysts)

Role: Customer-facing domain experts who manage relationships and identify problems

Profile to hire:

• Deep domain expertise in your target industry (former army officer, healthcare administrator, logistics manager, etc.)
• Must be “heretics” – people who understand how things work but believe they’re broken
• Strong communication and relationship-building skills
• Able to identify high-value problems (top 5 CEO priorities)
• Technical enough to understand product capabilities

Responsibilities:

• Act as account managers
• Identify valuable use cases at customer sites
• Speak to users and understand workflows
• Define what success looks like for each deployment
• Prepare demos and presentations for leadership

Where to find them:

• Industry veterans looking for innovation roles
• Ex-consultants from your target industry
• Former startup founders in the space
• People who’ve left corporate roles due to frustration with status quo

Delta Team (Deployed Engineers)

Role: Software engineers who rapidly build solutions at customer sites

Profile to hire:

• Excellent at rapid prototyping, not perfect abstractions
• Comfortable with ambiguity and constant change
• Can “eat a lot of pain” without complaining
• Startup founder mentality
• Strong communication skills (they work with customers daily)

What NOT to look for:

• Engineers who love perfect, maintainable code
• People who need clear specifications before starting
• Backend-only engineers who avoid customer interaction
• Those focused on scalability over speed

Responsibilities:

• Write code that fills product-customer gap
• Deploy solutions on short timelines (weeks, not months)
• Iterate based on user feedback
• Document what works for product team
• Sometimes their code gets thrown away – they’re okay with this

Where to find them:

• Early startup employees (especially failed startups)
• Former Palantir FDEs
• Hackathon winners
• Engineers from consulting backgrounds
• People leaving big tech seeking impact

Step 2: Build Your Product Team

Your internal product/engineering team has a specialized role in the FDE model:

Key Responsibilities:

• Review FDE implementations and identify patterns
• Abstract customer-specific solutions into generalizable features
• Build platform capabilities that give FDEs more leverage
• Think at higher levels of abstraction than individual deployments
• Turn “gravel roads” into “paved superhighways”

Required Skills:

• Ability to see patterns across 5-10 customer implementations
• Platform thinking over feature thinking
• Comfortable with ambiguity and evolving requirements
• Can resist over-generalizing from single customer

How to Build the FDE Model

Phase 1: First Customer (Months 1-6)

Goal: Prove you can deliver transformational outcomes

1. Target Selection
   1. Choose a customer where you can solve a top-5 CEO priority
   2. Must have executive sponsorship from high level
   3. Willing to give you access and feedback
   4. Large enough to demonstrate significant impact
2. Initial Deployment
   1. Week 1-2: Discovery
   2. Echo team interviews users
   3. Identifies key pain points
   4. Selects specific problem to solve
   5. Gets buy-in from leadership
   6. Week 3-8: Build
   7. Delta team builds prototype
   8. Echo team validates with users
   9. Iterate rapidly based on feedback
   10. Don’t worry about perfect code
   11. Week 9-12: Deploy & Prove Value
   12. Roll out to subset of users
   13. Measure impact metrics
   14. Present results to leadership
   15. Get testimonial/reference
3. Success Criteria
   1. Delivered measurable business outcome (cost savings, revenue increase, time saved)
   2. Users actually adopt the solution daily
   3. Leadership sees value and wants to expand
   4. You understand what worked and why

Expected: You’ll lose money on this deployment. That’s okay.

Phase 2: Customers 2-5 (Months 6-18)

Goal: Find patterns and start building platform

1. Deploy Similar Use Cases
   1. Find 2-3 more customers with similar problems
   2. Use learnings from Customer 1
   3. Should be faster than first deployment (but probably won’t be)
2. Product Team Involvement
   1. Review all FDE implementations
   2. Identify common patterns
   3. Start building platform features
   4. Create internal tools for FDEs
3. Develop Pricing Model
   1. Start with outcome-based pricing
   2. Expect contracts to grow over time at same customer
   3. Initial deployment: $100K-$500K
   4. Target growth: 2-3x after year 1
4. Build Playbooks
   1. Document what works across customers
   2. Create deployment templates
   3. Identify common objections and solutions
   4. Train new FDEs on patterns

Phase 3: Scaling (Months 18+)

Goal: Increase product leverage and efficiency

1. Measure Product Leverage
   Key Metrics:
   1. Time to deploy at new customer (should decrease)
   2. FDE hours per $1M contract value (should decrease)
   3. Margin per customer (should become positive by month 12-18)
   4. Second use case time at same customer (should be faster)
2. Generalize Solutions
   1. Build platform features that eliminate common FDE work
   2. Create configuration tools instead of custom code
   3. Enable self-service for simple customizations
3. Expand to New Segments
   1. Use FDE model to enter adjacent markets
   2. Each new segment requires product discovery
   3. Leverage platform built for previous segments
4. Organizational Structure
   For every 10 FDEs, you need:
- 1 Product Manager (specialized in abstraction)
- 2-3 Platform Engineers
- 1 FDE Manager/Lead

Implementation Roadmap

Before Launch (Preparation Phase)

Month -3 to 0:

1. Build Demo
   1. Create compelling demo of your vision
   2. Should show end-to-end workflow
   3. Make it real enough to get customer reactions
   4. Be prepared to hear “this is terrible”
2. Hire First FDEs
   1. Start with 2-person team (1 echo, 1 delta)
   2. Or hire Palantir alumni who know the model
   3. Don’t scale team until you prove model works
3. Develop Product Platform
   1. Build core product with high customizability
   2. Think “LEGO blocks” not “finished product”
   3. Over-invest in APIs and configuration
4. Set Expectations
   1. With investors: This will look inefficient at first
   2. With team: We’ll lose money on early customers
   3. With yourself: This is painful but necessary

Launch Phase (Months 1-12)

Month 1-3: First Deployment

1. Focus 100% of FDE team on single customer
2. Product team supports FDE needs
3. Measure everything
4. Get concrete outcome delivered

Month 4-6: Second Deployment

1. Start second customer with lessons learned
2. Product team begins generalizing
3. Document what’s working

Month 7-9: Hire More FDEs

1. Add 1-2 more FDEs only after proving model
2. Train them on what you’ve learned
3. Maintain quality over speed

Month 10-12: Evaluate Model

1. Are margins improving?
2. Is time-to-deploy decreasing?
3. Can you see path to profitability?
4. If no to any: iterate before scaling

Growth Phase (Year 2+)

Quarterly Goals:

1. Hire FDEs in cohorts (2-4 at a time)
2. Release major platform improvements each quarter
3. Enter new market segment every 6 months
4. Achieve positive unit economics by Q4 of Year 2

Critical Implementation Details

Pricing Structure

Early Stage (Customers 1-5):

Initial Engagement: $150K - $300K
- 3-6 month initial deployment
- Fixed outcome-based milestone
- Risk: You might lose money
- Goal: Learn and prove value

Year 1 Expansion: $300K - $800K
- Add 2-3 more use cases
- Demonstrate ROI from initial deployment
- Get to breakeven or slight profit

Growth Stage (Customers 6+):

Initial Engagement: $250K - $500K
- Faster deployment (6-12 weeks)
- Proven playbook
- Profitable from start

Multi-Year Contracts: $1M+
- Multiple use cases planned
- Platform licensing component
- Expanding throughout organization

Customer Engagement Process

Phase 1: Discovery (Week 1-2)

Echo Team Activities:
□ Interview 10-15 users across levels
□ Shadow users doing current workflows
□ Identify top 3 pain points
□ Map current process flow
□ Estimate business impact of solving each problem
□ Get executive sponsor commitment
□ Define success metrics

Deliverable: One-page problem statement with impact estimate

Phase 2: Prototype (Week 3-6)

Delta Team Activities:
□ Build minimal working prototype
□ Use existing product + custom code
□ Deploy to 2-3 pilot users
□ Daily check-ins with users
□ Rapid iteration based on feedback
□ Track what product features are used vs. custom code

Deliverable: Working prototype with 3 active daily users

Phase 3: Deployment (Week 7-12)

Combined Team Activities:
□ Expand to 10-20 users
□ Refine based on expanded feedback
□ Document custom code built
□ Measure business impact
□ Prepare leadership presentation
□ Plan next use case

Deliverable: Full deployment + impact report

Phase 4: Expansion (Quarter 2+)

Account Growth:
□ Identify next high-value problem
□ Leverage existing relationships
□ Reuse platform components
□ Faster deployment (4-8 weeks)
□ Increase contract value

Deliverable: Multi-use case roadmap

Demo-Driven Development Process

1. Build Core Demo Flow
   1. Show complete user journey
   2. Solve real problem end-to-end
   3. Make it feel polished (even if backend is messy)
2. Test Demo with Customers
   1. Show to 5-10 potential customers
   2. Ask: “What would make this 10x better for you?”
   3. Note what they get excited about
   4. Ignore features they’re lukewarm on
3. Iterate Demo Based on Feedback
   1. Add features that get “wow” reactions
   2. Remove features that confuse people
   3. Demo should create desire to use product
4. Build Product to Support Demo
   1. Product team makes demo actually work at scale
   2. Abstract demo-specific code into platform
   3. Demo becomes deployment template

Managing Product-FDE Tension

Common Conflicts:

FDE Perspective	Product Perspective	Resolution
“Customer needs X by next week”	“That’s too specific to one customer”	Product team sits with FDE at customer site to understand
“Just let me hardcode it”	“That creates technical debt”	FDE builds quickly, product refactors later if pattern emerges
“Product doesn’t understand customer”	“FDEs don’t understand scale”	Weekly sync where FDEs present 3 customer examples before requesting feature

Best Practices:

1. Have FDEs rotate into product team for 3-6 months
2. Product managers spend 1 week per quarter at customer sites
3. Joint planning sessions with both teams
4. FDEs participate in product abstraction discussions

Avoiding the Consulting Trap

Warning Signs You’re Becoming Consulting:

1. ❌ Margins aren’t improving after 12+ months
2. ❌ Customer 10 takes as long as Customer 1
3. ❌ Product team isn’t building platform features
4. ❌ FDEs solve completely different problems at each customer
5. ❌ No recurring revenue, only one-time projects
6. ❌ Contract sizes aren’t growing at existing customers

How to Course-Correct:

1. Freeze new customer acquisition temporarily
2. Review all FDE implementations
3. Force product team to generalize top 3 patterns
4. Only take customers in proven segments
5. Measure product leverage explicitly
6. Set hard timeline for positive unit economics

Scaling Hiring

Team Ratios at Different Stages:

10 Total People (Seed Stage):
- 2 FDEs (1 echo, 1 delta)
- 5 Product/Engineering
- 1 Product Manager
- 1 Founder (wearing multiple hats)
- 1 Operations/Sales

25 Total People (Series A):
- 8 FDEs (4 echo, 4 delta)
- 12 Product/Engineering
- 2 Product Managers
- 2 FDE Managers
- 1 Head of Product

50 Total People (Series B):
- 20 FDEs (10 echo, 10 delta)
- 20 Product/Engineering
- 4 Product Managers
- 3 FDE Managers
- 2 Platform Architects
- 1 Head of FDE Org

Measuring Success

Key Performance Indicators

Customer-Level Metrics:

1. Time to first deployment (target: 12 weeks → 6 weeks)
2. Contract value at month 12 vs. initial contract (target: 2-3x)
3. Number of use cases deployed (target: 3+ in Year 1)
4. Customer satisfaction score (target: 9+/10)
5. Reference-ability (target: 80%+ willing to be references)

FDE Efficiency Metrics:

1. FDE hours per $100K in contract value (target: decreasing)
2. Time to second use case vs. first (target: 50% faster)
3. Percentage of FDE work that’s custom code (target: decreasing)
4. FDE utilization rate (target: 70-80%)

Product Leverage Metrics:

1. Percentage of features used across 3+ customers (target: increasing)
2. Platform API usage by FDEs (target: increasing)
3. Time to build new platform feature (should stay stable or decrease)
4. Ratio of platform code to customer-specific code (target: 80/20)

Financial Metrics:

1. Gross margin per customer (target: -50% → +50% over 18 months)
2. Customer Acquisition Cost (will be high, but should decrease)
3. Lifetime Value to CAC ratio (target: 3:1 by Year 3)
4. Path to positive unit economics (target: visible by Month 18)

Common Mistakes and Solutions

Mistake 1: Hiring Wrong Personality Types

Problem: Engineers who need perfect specifications or resist customer interaction

Solution:

1. Use trial projects before hiring
2. Look for startup founder characteristics
3. Prioritize adaptability over pure technical skill
4. Ask in interviews: “Tell me about a time you built something ugly that worked”

Mistake 2: Trying to Scale Too Fast

Problem: Hiring 10 FDEs before proving model with 2

Solution:

1. Max 4 FDEs until you have 3+ successful deployments
2. Prove unit economics before scaling
3. Better to go deep with few customers than shallow with many

Mistake 3: Product Team Too Detached

Problem: Building products FDEs can’t use or don’t want

Solution:

1. Co-locate product team with FDEs monthly
2. FDEs vote on product roadmap priorities
3. Product managers deploy alongside FDEs quarterly
4. Track product feature adoption by FDEs

Mistake 4: Not Solving Important Enough Problems

Problem: Working on nice-to-have features instead of must-have transformations

Solution:

1. Only engage if solving top-5 CEO priority
2. Measure business impact in dollars, not features
3. Get executive sponsor before starting
4. If impact isn’t 3-10x, stop and pivot

Mistake 5: Inconsistent Pricing

Problem: Every customer pays different amounts with no rationale

Solution:

1. Create outcome-based pricing tiers
2. Define what “small/medium/large” deployment means
3. Standardize expansion pricing
4. Track contract value growth patterns

Getting Started: First 90 Days

Week 1-2: Foundation

□ Define your ideal customer profile
□ Create initial demo (even if partially fake)
□ Write FDE job descriptions
□ Set up product infrastructure for customization
□ Identify 10 target customers

Week 3-6: First Hire

□ Interview 20+ FDE candidates
□ Hire first echo-delta pair (or 1 person who can do both)
□ Give them trial project to prove model
□ Document everything they do
□ Adjust product based on their needs

Week 7-12: First Customer

□ Get meeting with target customer executive
□ Show demo and gauge reaction
□ If positive, define engagement scope
□ Start discovery process
□ Deploy FDEs full-time
□ Product team in support mode

Month 4-6: Prove Value

□ Complete first deployment
□ Measure business impact
□ Get customer testimonial
□ Document what worked/didn't
□ Decide: iterate or scale

Resources and Next Steps

Essential Reading:

1. Palantir case studies and press releases
2. “Crossing the Chasm” (to understand what you’re NOT doing)
3. YC’s “Do Things That Don’t Scale”

Key Hires to Make:

1. First FDE pair (echo + delta)
2. Product Manager who understands abstraction
3. Palantir alumni as advisor or hire

Tools to Build:

1. Internal dashboard for FDE deployments
2. Customer impact measurement system
3. Product feature request tracking from FDEs
4. Demo environment that’s easy to customize

Immediate Action Items:

1. Assess if FDE model fits your situation (checklist above)
2. Build compelling demo of your product
3. Write job descriptions for echo and delta roles
4. Identify 3 target customers with top-tier problems
5. Budget for negative margins on first 5 customers

---

Note: The FDE model is counterintuitive, painful, and expensive upfront—but for AI startups in emerging categories, it may be the only path to product-market fit. Success requires patience, discipline, and willingness to do things that don’t scale for longer than feels comfortable. The payoff is deep customer relationships, defensible moats, and the ability to discover and dominate new markets before competitors even understand what you’re building.

Video about FDE:

The Origins of the Forward Deployed Engineer Model – Extract from above Podcast :

Birth at Palantir

The FDE model emerged from necessity at Palantir in the mid-2000s when the company faced a unique challenge: building software for intelligence community users they couldn’t access or understand. Traditional customer discovery methods failed because potential users—spies and intelligence analysts—couldn’t discuss their work openly.

Palantir’s solution, pioneered by co-founder Stefan Cohen and formalized by early employee Shyam Sankar, involved bringing technical engineers directly to customer sites. These engineers would bridge the gap between product capabilities and customer needs, essentially doing product discovery from inside the organization rather than from the outside.

Key Innovation: Services as Product Discovery

What distinguished Palantir’s approach from traditional consulting was treating customization work not as a cost center but as a product discovery engine. Forward deployed engineers would build “gravel roads”—rough but functional solutions—while the core product team would analyze these implementations to build “paved superhighways” that generalized across multiple customers.

How the FDE Model Works

Team Structure

The model relies on two core roles working in tandem:

Echo Team (Embedded Analysts)

• Domain experts with deep industry knowledge
• “Heretics” who understand current processes but recognize their insufficiency
• Serve as account managers and user advocates
• Identify high-value problems that can deliver 3-10x improvements

Delta Team (Deployed Engineers)

• Exceptional at rapid prototyping and “eating pain”
• Write rough-and-ready code quickly
• Deploy solutions directly at customer sites
• Focus on outcomes rather than perfect abstractions

The Product Team’s Critical Role

The product management function in an FDE organization requires unique skills—thinking at higher levels of abstraction to generalize customer-specific solutions. Product managers must identify patterns across deployments and build platforms rather than vertical solutions, enabling FDEs to customize for each site while maintaining product leverage.

Why AI Startups Are Embracing the FDE Model

Market Heterogeneity

Unlike established SaaS categories where incumbent products exist, AI agents represent entirely new product categories. There’s no clear playbook, and customer needs vary dramatically across implementations. This mirrors Palantir’s early days working across counterterrorism, counterproliferation, and military workflows—each requiring different approaches despite superficial similarities.

Rapid Capability Evolution

AI capabilities are advancing faster than organizational adoption. The gap between what models can do and what customers can implement creates enormous opportunity for those who can bridge it. As McGrew notes, while GPT-4 to O3 represented explosive progress, real-world adoption remains surprisingly limited—creating perfect conditions for the FDE model.

In today’s B2B landscape, AI increasingly participates in early discovery processes, making structured clarity in product information crucial for both machine and human decision-makers, which aligns with why FDEs need to deeply understand and shape how customers interact with AI products.

No Incumbent Products

When there’s no existing category leader, customers don’t know what they need. FDEs can identify valuable use cases that weren’t obvious from the outside, then land and expand within organizations by solving increasingly important problems.

Critical Success Factors

1. Solve Top-Five CEO Problems

FDE engagements must address one of leadership’s highest priorities. Without executive sponsorship, implementations will stall against organizational inertia and IT bureaucracy.

2. Price on Outcomes, Not Seats

The fundamental shift is from selling software installation to selling problem resolution. Contract sizes should grow over time as FDEs deliver increasingly valuable outcomes, even if per-customer customization remains constant.

3. Increase Product Leverage

The key metric isn’t reducing customization per customer—it’s enabling FDEs to deliver more value using the same effort. Second and third customers in a segment should require less work than the first, and the platform should enable solving adjacent problems more easily.

4. Demo-Driven Development

Creating compelling demos forces product teams to think from the customer’s perspective. Good demos create desire in customers and ensure features work together coherently, not just in isolation.

Common Pitfalls to Avoid

The Consulting Trap

The model fails if costs per customer don’t decline over time or if profit margins remain negative beyond the initial year. Successful FDE organizations start with negative margins but achieve profitability as product-market fit improves and product leverage increases.

Over-Specialization

Building solutions too specific to one customer creates technical debt. Product teams must abstract implementations to work across the next 5-10 customers, requiring judgment about the right level of generalization.

Wrong Personnel

FDEs require founder-like qualities—not craftsmen focused on perfect code, but problem-solvers who can deliver outcomes rapidly. Similarly, echo team members must be domain experts who question the status quo rather than defenders of existing processes.

Early-stage startups benefit from founders doing sales-like work directly—running one-on-one onboarding calls and treating every conversation as discovery for positioning and product clarity, which mirrors the hands-on approach FDEs take with customers.

Scaling Challenges and Solutions

Organizational Discipline

Maintaining the FDE model requires constant vigilance against devolving into pure services. Leadership must focus on:

• Measuring contract value growth
• Tracking product leverage improvements
• Ensuring FDE work generalizes appropriately
• Maintaining tension between field customization and product generalization

Cultural Balance

The model creates inherent tension between FDEs (who want customer-specific solutions) and product teams (who need abstraction). Success requires recognizing these as different incentive structures rather than skill gaps, and creating forums where both sides collaborate on generalization decisions.

Hiring Strategy

The best FDE practitioners often come from Palantir itself, having internalized the model’s nuances. Startups switching to FDE approaches gain significant advantage by bringing in Palantir alumni for key roles, particularly in structuring accounts and finding valuable outcomes.

The Broader Implications

AI Adoption Gap

McGrew identifies a crucial insight: despite rapid AI capability improvements, adoption lags dramatically. The world where AGI seemed likely to “take over overnight” has given way to reality—AI requires human ingenuity, exploration, and patience to become genuinely useful. This adoption gap represents massive opportunity for FDE-model startups.

OpenAI as Product Team, Startups as FDEs

An elegant analogy emerged: OpenAI functions as the “home product team” building core capabilities, while AI startups act as “FDEs” figuring out how to deploy and customize those capabilities for specific use cases and customers. This symbiotic relationship accelerates both capability development and real-world adoption.

Founder Training Ground

The FDE model provides exceptional training for future founders—combining customer discovery, rapid prototyping, outcome-driven thinking, and cross-functional collaboration. This explains Palantir’s outsized contribution to the startup ecosystem and suggests current FDE roles will spawn tomorrow’s successful founders.

Conclusion

The Forward Deployed Engineer model represents more than a go-to-market strategy—it’s a comprehensive approach to building and scaling products in emerging categories where customer needs are unclear and product-market fit must be discovered through iteration. For AI agent startups facing market heterogeneity, rapid capability evolution, and no incumbent products, the FDE model offers a proven path from early experiments to sustainable businesses.

The model’s counterintuitive aspects—embracing customization rather than minimizing it, measuring contract growth rather than efficiency, treating engineers as customer-facing rather than backend—require organizational discipline and cultural buy-in. But for companies willing to invest in this approach, the rewards are substantial: deep customer relationships, defensible moats through specialized knowledge, and the ability to discover and dominate new market segments.

As AI capabilities continue racing ahead of adoption, the gap between potential and practice will only grow. Forward deployed engineers serve as the crucial bridge, translating raw AI power into tangible business value while feeding real-world learnings back into product development. The next generation of successful AI companies will likely be those that master this balance between customer intimacy and product leverage.

Key Takeaways

1. The FDE Model is “Doing Things That Don’t Scale” at Scale – It maintains intense customer focus while building generalizable platforms underneath
2. Outcome-Based Pricing is Fundamental – Sell problem resolution, not software installation, with contracts growing as value delivered increases
3. Product Leverage is the Critical Metric – FDEs should deliver more value per effort over time, not necessarily less customization per customer
4. Hire Heretics, Not Experts – Domain knowledge matters less than willingness to reimagine how things work
5. Top-Five CEO Problems Only – Without executive sponsorship, FDE implementations will fail against organizational resistance
6. The Gap Between AI Capability and Adoption is Enormous – This represents the primary opportunity for FDE-model startups in coming years
7. Palantir Alumni Have Competitive Advantage – Having lived the model provides invaluable tacit knowledge for implementing it successfully
8. Demo-Driven Development Forces Customer Thinking – Building compelling demos ensures features work together from user perspective
9. Platform Over Product – Build abstractions that enable customization rather than trying to build perfect vertical solutions
10. Learning Organizations Win – The FDE model only works for companies committed to continuous discovery and evolution rather than scaling a fixed playbook

Related References

• Palantir’s Ontology System: The canonical example of abstracting customer-specific needs into generalizable platform capabilities
• “Crossing the Chasm” by Geoffrey Moore: Traditional framework the FDE model explicitly contradicts for heterogeneous markets
• Y Combinator’s “Do Things That Don’t Scale”: Foundational advice that the FDE model extends to growth-stage companies
• Sean Sankar: Palantir president/CTO who formalized the FDE strategy and coined the “heretics” concept
• The Collison Install: Stripe’s high-touch onboarding approach, a conceptual cousin to the FDE model
• OpenAI’s GPT-4 and O3 Models: Examples of rapid capability advancement that outpaces organizational adoption
• YC Company Job Board: Shows 100+ companies now hiring FDEs versus near-zero three years ago
• Castle (AI Voice Agents for Mortgage): \Example YC companies successfully implementing FDE approaches
• Happy Robot (AI for Logistics): Example YC companies successfully implementing FDE approaches