Video summary

The FDE Playbook for AI Startups with Bob McGrew

Main summary

Key takeaways

Business

FDE (Forward Deployed Engineer) strategy for AI startups (what it is + why it’s taking off)

  • Core idea: An FDE is a technical engineer embedded at the customer who closes the gap between what the startup’s product can do and what the customer actually needs.
  • Why it’s popular in AI agents: AI agent companies face high product discovery requirements because there’s often no dominant incumbent product to adapt from—so startups must learn and iterate inside customer environments.

Market/product-market-fit implication

  • In standard SaaS, once you find product-market fit, you tend to scale with repeatable contracts and less per-customer customization.
  • In FDE, you continue to grow contract size and increase delivered value via repeated on-site discovery, which enables generalization into a platform product over time.

The “gravel road → paved superhighway” playbook (Palantir’s version)

Gravel road (customer-specific build)

  • FDEs deploy quickly to solve the current highest-priority problem for that customer.
  • The implementation is intentionally non-scalable at first, because customer workflows differ.

Paved road (product generalization)

  • Product + engineering teams analyze what worked across customers and turn it into generalizable abstractions (a platform, not a bespoke tool).
  • The goal is that future deployments become easier and require less field work.

Operating model at Palantir: “Echo” vs “Delta” teams

Team structure

  • Echo team (embedded analysts + account management)

    • Embedded at the customer site.
    • Understands users, selects the key use case/demo, and identifies which problem to solve.
    • Also functions as the relationship manager.

  • Delta team (deployed engineers / rapid prototypers)

    • Fast prototyping and deployment of the solution prototype into a working system.
    • Writes “rough and ready” code quickly; throwaway iterations are acceptable.

Hiring profiles

  • Echo: domain knowledge + “rebellious/heretic” mindset (recognizes current workflows are insufficient and can drive step-change).
  • Delta: prioritizes rapid prototyping and outcome delivery over long-term “craftsmanship/abstractions for 10+ years” (those abstractions come later through generalization).

Cadence / process

  • FDE workflow includes a tight timeline:
    • Visit/start with an idea → few months progress → leadership presentation → if approved → deploy more broadly.

Sales motion difference: “sales-led discovery” vs “FDE-led product discovery”

Sales-led discovery (traditional)

  • More “external” conversations; often results in misalignment because customer asks for what’s easy, not what’s most impactful.

FDE-led product discovery (Palantir’s approach)

  • Start from problems that are top CEO priorities (explicitly: top ~5).
  • FDEs solve one key problem first, then use insight to land and expand.
  • The startup’s advantage: it can execute faster than the enterprise’s internal org that is constrained by IT/process.

How Palantir avoids devolving into consulting (the discipline)

Common failure modes

  • Building what customers ask for (easy problems) vs what leadership/business needs.
  • Building non-generalizable field-specific features that never become a scalable product.

Mechanisms to prevent it

  • Focus on choosing problems tied to executive priorities.
  • Product team must constantly determine:
    • What’s the generalizable version that applies to the next 5–10 customers?
  • Require feedback loops where FDEs participate in generalization discussions so platform abstractions reflect real field reality.

Product strategy: platform/generalization via abstraction (ontology example)

  • Palantir’s example of generalizing:
    • Instead of customer-specific database tables (e.g., people vs money vs other entities per site),
    • Palantir developed the ontology approach:
      • A general object model (objects/properties/media/links)
      • Customer-specific specialization encoded via the ontology

Key principle

  • FDEs can define the “specialized” elements per site, but product teams build the higher-level abstraction that allows reuse across customers.

Pricing + commercial model: selling outcomes, not installation

What changes vs SaaS

  • SAS/product-market-fit path often drives:
    • repeatable contracts
    • marginal scaling as usage/seat/subscription pricing
  • FDE/outcome model:
    • contracts start smaller, then grow over time
    • pricing must reflect outcome value, not usage/seat alone

Case examples mentioned (AI agents)

  • Castle (AI voice agent for mortgage servicing)
    • Achieved enterprise go-live by ramping on successful calls handled.
    • Included scaling stipulations (e.g., later stage scaling targets).
  • Happy Robot (AI voice agents for logistics, e.g., DHL)
    • Similar enterprise deployment approach via ramping successful operations.

Risk allocation

  • Enterprises often assume internal programs fail and doubt startups can execute.
  • Early on, startups may need to take more implementation risk (e.g., pay conditional on performance/expansion) until trust is earned.

IT/on-prem constraints

  • One place this breaks: deployments requiring on-prem or deep integration can trigger internal IT resistance, requiring executive sponsorship and internal approvals.

KPI/KR guidance (what to measure internally)

Primary KPI

  • Contract size and, more fundamentally, the value of the outcome delivered.

Secondary KPI

  • Product leverage over time:
    • Measure whether the FDE can deliver more value with less incremental engineering headcount (i.e., solution delivery gets easier per new customer).

Expected dynamics over time

  • Early deployments:
    • profit margins may be negative (costly discovery + build)
  • Over time (as platform generalization improves):
    • margins move toward positive
    • contract size increases as the company earns access to bigger problems

Why AI agents specifically amplify the FDE model

  • AI agent capability is improving fast, but adoption and deployment lag.
  • There’s a mismatch:
    • models/concepts advance rapidly
    • enterprises need on-the-ground help to make them genuinely useful in real workflows
  • Additionally:
    • AI agent work is highly heterogeneous and not yet standardized—so startups must discover “what works” per segment from inside enterprises.

Executive buy-in requirement (operational necessity)

To succeed inside large enterprises, startups need leadership alignment so they can:

  • get authority to operate
  • make architecture/database choices the startup needs (e.g., platform integration constraints)
  • avoid being blocked by legacy IT processes that don’t align with startup execution speed

Leadership + learning organization principles

  • The model requires an ongoing learning loop across customers (a “learning company”).
  • Demo-driven development is used because:
    • repeated deployment to new customers forces better and more unified messaging/product flows
    • high-quality demos create “desire” and reveal real customer painpoints earlier
  • Advice on company selection:
    • join a young, fast-growing company rather than a coasting winner—because learning pressure is higher.

Bob McGrew’s transition to US Army Reserve (execution analogy)

  • He joined a unit advising the Army on technology as an actual commissioned officer.
  • Framed similarly to FDE:
    • leadership provides top priorities
    • he/they help drive transformation through “field” problem-solving and escalation when needed.

Frameworks / playbooks explicitly referenced or implied

  • Gravel road → paved superhighway (field discovery → product generalization)
  • Land and expand (shift from initial priority problem to broader enterprise problems)
  • Outcome-based selling (pricing and contracts based on value delivered)
  • Crossing the Chasm (product-market-fit segmentation; scaling after finding repeatable segment fit)
  • “Doing things that don’t scale at scale” (YC-style early tradeoff, but operationalized through FDE to increase contract size)
  • Ontology / abstraction layer (general data model + customer-specialized semantics)

Presenters / sources

  • Presenter / guest: Bob McGrew
  • Host: Gary (not present) and Jared (speaker referring to “Jared” questions and YC references)
  • Referenced sources (books/concepts): Paul Graham (“get out of the building” meme), Crossing the Chasm, YC job board / YC advice (e.g., “do things that don’t scale”), Seans/Sham Sankar (credited with inventing the FDE strategy at Palantir in the discussion), Sham Sankar and Sean (mentioned as key Palantir leadership/figures).

Original video