FDE Unpacked: 9 Critical Questions on AI Delivery Roles, Org Design & China's Unique Path

Note: All topics/questions were prepared by the host; personal views only, not representing any company or team.

Question 1: Real FDE Deployment Extent and Mainstream Scenarios in Chinese Enterprises

The author examines two layers: observed FDE team building across major companies, and first-hand experience.

Observed: Large firms have formed FDE teams evolved from delivery or product R&D teams. Core problem: making LLMs land in specific domains. Typical scenarios: finance, autonomous driving, enterprise customer service, enterprise office — essentially "using new technology to solve old problems," with titles simply changed to FDE.

First-hand: Alibaba Cloud intelligent customer service system for complex large-customer scenarios, exploring how to ground general LLMs, domain LLMs, and supporting products into specific clients. Digital employee construction: requirements differ per industry/enterprise beyond basic capabilities, involving permission management, risk control; architectural paths include self-built on LLMs, building on Anthropic/ChatGPT, or on coding-agent platforms like Alibaba QoderWake.

Overall judgment: Current cases still solve old problems with stronger tech foundations. No exciting attempts yet at solving previously undefinable/unsolvable new problems. If FDE value is only faster/better old-problem solving, its ceiling is limited; whether FDE becomes a new species depends on when "new problem" cases emerge.

Question 2: Pitfalls in Actual FDE Delivery

Pitfalls form a progressive chain:

1. Wrong problem selection. Two cases: forced by signed contracts with no flexibility; or team lacks rigorous judgment and dives in without validating true pain points — the latter is avoidable, a judgment/process failure.

2. Decision bias + value quantification gap + expectation-capability gap. Customer expectations vs. actual technical boundaries have huge gaps. Gap identification/management determines success. Compounding issue: no clear value assessment standards — after delivery, unclear how much problem was solved, ROI, etc. This exists in traditional AI too but amplified now. Direct consequence: massive acceptance disputes — no shared criteria for "done."

3. Lack of "bidirectional working" capability. Core criterion: can the person solve customer problems with product/tech while abstracting practical experience back to product team? In China, almost no individuals/teams truly have this bidirectional ability — not intelligence, but org design, role division, and capability models don't connect. Result: broken loop — customer problems solved but experience not沉淀, no product feedback, no scale economies, high cost, eventual doubt on viability.

These pits chain: wrong problem amplifies gap; quantification gap + vague gap cause scope creep until acceptance explosion; missing bidirectional ability prevents lessons from becoming experience.

Question 3: Capability Gap-Filling vs. Redefining Enterprise Division of Labor

Gap-filling: Yes. Palantir ex-exec Bob McGrew defines FDE as "on-site filling gap between product capability and customer need." Gap is real; FDE is capability补齐.

But deeper: division-of-labor rules changed. Traditional project "iron triangle": PM (schedule/resources), BA (business understanding → specs), TM (tech implementation). Handoff via BA docs → TM build → periodic reviews for alignment. Hidden premise: requirement-tech deviation can be caught by periodic alignment rhythm.

AI projects break this premise. Requirements surface only via collision with real systems/data. Customer-stated pain points? Model actual capability? Answers emerge only during hands-on, not from BA docs. Deviation between requirement judgment and tech judgment changes faster than weekly reviews. "BA thinks → TM builds → meeting corrects" chain too slow.

New logic: Consolidate requirement judgment, tech judgment, schedule judgment into one person on-site, adjusting in real time, no meeting-dependent alignment. This person does BA, TM, PM work simultaneously — not willingness but necessity because three judgments inseparable; splitting them + process alignment loses to reality speed.

Palantir's Sankar emphasizes "Total Ownership of Implementation." Not "one person does three jobs" but in real-time shifting requirement-tech deviation scenarios, judgment authority must sit whole in one person; once split across roles + process alignment, feedback loop breaks due to latency. Iron triangle dissolution → FDE fusion is just organizational shadow; real change: "can three judgments be pre-split across roles and aligned via process" no longer works.

Combined answer: Gap-filling is surface; division-of-labor redefinition is deeper. McGrew explains why FDE appears; Sankar explains why FDE must take this shape — not FDE forcing rule change, but rules failing first, FDE emerging under new logic.

Question 4: Internal FDE Role Setup and Boundaries

Three dimensions: capability model, org affiliation, boundaries with SA/delivery/PM/R&D.

Capability model: Many FDEs converted from traditional delivery; if work style, capability matrix, product-team relationship don't fundamentally change, conversion fails. Three-layer "engineering perspective": (1) understand customer/business needs — hear real pain points, not just execute vague requests; (2) hands-on problem solving — customize code on models/products, independently deliver, not just draw diagrams/write PRDs; (3) abstraction capability — productization mindset during delivery, distinguish client-specific vs. cross-client common needs, abstract latter. These three layers = bidirectional working capability at individual level.

Org affiliation: Prefer placing FDE in product-tech R&D system, at least engineering line. Logic: FDE core value = "fill gap + feedback product"; under sales/delivery → old delivery renamed; under product R&D → connects "discover problem → abstract → feedback product" chain. References Palantir's Echo/Delta modes: traditional iron triangle (BA/TM/PM) specialized; today roles must fuse, not mechanically split. Echo/Delta need not be strict; can have emphasis, many-to-many. Two archetypes: (a) domain experts in high-professionalism scenarios — may not master tech, acceptable; (b) "full-stack special forces" — strong engineering hands-on, background in engineering/algorithm (e.g., model tuning), fuzzy boundaries, core ask: "one vs ten."

Boundaries: Real clarity is responsibility boundaries — who owns what outcomes. Role capability overlap grows (fusion trend); but outcome ownership must be clear. vs SA: SA owns top-level architecture design (often not landing); FDE owns making solution run on-site — capability overlap in design, different result ownership. vs traditional delivery: delivery owns contract fulfillment/acceptance end; FDE owns "delivery is start" + experience feedback loop. vs PM: PM owns global product definition/roadmap/commercialization; FDE owns first-hand scenario signals + local abstraction — overlap in demand discovery, but global judgment responsibility stays PM. vs R&D: R&D owns product core code/system architecture; FDE owns client-side integration/adaptation — both write code, but one for product core, one for client landing.

Ideal FDE team: strong engineering-perspective special forces: clear capability model (3-layer engineering view), clear org home (product-tech R&D/engineering line), flexible role setup (no mechanical Echo/Delta split, many-to-many), roles fusing but responsibilities clear (overlap with SA/delivery/PM/R&D but distinct outcome ownership). Reality challenge: such talent scarce; how many engineering-perspective people willing to do frontline delivery? Confirms "talent gap not fillable by training programs quickly."

Question 5: Avoiding Project-Mode Slide & Solving Heavy Labor Cost

1. Avoiding project-mode slide: Admit most FDE work today is project-mode. Causes: (a) vague customer needs, scope creep, high customization → hard to沉淀 reusable productized assets; (b) team lacks abstraction/engineering capability → passively slides. Natural breakout: productization/platformization for reuse/scale. Reference Palantir product matrix: Foundry (data integration/ontology modeling platform) — FDE models business rules per client, heavy labor; once validated general, productized into platform standard capability, next same-industry client only needs "configuration" not redevelopment. AIP (AI platform) connects structured ontology capabilities with LLMs, letting FDE orchestrate on deterministic structures instead of hand-coding agents from scratch, drastically cutting labor to put LLM into production. Apollo (private deployment platform) enables software stack continuous updates/auto-scaling in diverse private envs. These three solve "repeated modeling," "agent orchestration," "repeated ops" costs. Real FDE labor cost reduction comes from platform infra — what Chinese companies lack most.

2. Solving heavy labor cost/low marginal returns: Root: high customization, scope creep, high investment, no沉淀 → low marginal returns. Two core views: (a) Increase productization ratio — raise product/platform capability share, reuse via asset沉淀, cut repeat investment. Two metrics: unit FDE standardized asset output rising? later-client customization ratio falling? If improving, flywheel turning; else just premium outsourcing repackaged. (b) Individual tool efficiency — how FDE individuals leverage AI tools for daily efficiency, directly cutting labor-time cost. Difference from early Palantir: past FDE relied on human labor; today FDE should be special forces equipped with advanced AI tools, fewer people doing more. Special note: Palantir's AIP includes AIFDE — AI Agent doing FDE work. Can reverse-supplement human FDE: human FDE not just uses scattered AI tools but invokes AIFDE-type AI FDE capabilities, becoming "super FDE individual" — one human + AI FDE, still individual efficiency but leverage amplified. Key variable for China to compress Palantir's 20-year flywheel to 3-5 years.

3. Key execution capabilities: (a) Clear boundaries, learn to say no — judge what cannot be done today, timely Say No; survival pressure often prevents refusal, but this gate cannot be skipped — entry control. (b) Abstraction capability — without abstraction no沉淀; starting point of productization. During delivery with productization mindset, extract common capabilities from concrete projects, separate client-specific vs. cross-client common needs — process conversion. Both levers needed: entry control + process conversion.

Question 6: AI PM Capabilities to Strengthen When FDE Becomes Mainstream

Framework: "Three-stage convergence" — problem→tech, tech→product, product→commodity. Entire AI landing value chain splits into three segments with different nature:

Segment 1: problem-oriented — deep on-site, understand real problems.

Segments 1+2: product-oriented — turn solutions into reusable product capabilities.

Segment 3: business-oriented — scale, go-to-market, marketing.

FDE and AI PM focus differently across segments.

FDE focuses on first two, especially segment 1. Segment 1 "problem→tech convergence" — identify true business problems on-site, judge which solvable with today's models/how — FDE's core battlefield; knows best where models work/fail. Segment 2 "tech→product convergence" — abstract field-validated tech solutions into product capabilities — FDE contributes importantly, holds first-hand scenario signals, distinguishes client-specific vs. cross-client common needs.

AI PM focuses on last two. Segment 2: PM reviews from global product definition/roadmap — multiple FDEs find inconsistent signals across clients, PM makes unified judgment/trade-offs globally. Segment 3 "product→commodity convergence" — tests not product capability but commercialization — scale, GTM, marketing — PM's most irreplaceable decisions. Segment 1 PM participates (early product definition needs customer/scene understanding) but not main battlefield.

Key: segment 2 "tech→product convergence" is overlap. FDE abstracts bottom-up from field; PM defines top-down globally. Overlap not a problem, necessary — without FDE first-hand signals, PM definitions detach from reality; without PM global judgment, FDE abstractions fragment, lack direction.

If FDE becomes mainstream and excels in first two segments, AI PM focus sharpens to segment 3 "product→commodity convergence." Not that PM exits first two, but core value shifts backward — FDE already pushed demand-product capability conversion far; PM must strengthen business-oriented capabilities: scale formed product, design GTM strategy, execute marketing. This differentiates PM from generic "judgment/abstraction" talk — true PM irreplaceability lies in segment 3 commercial capability.

Question 7: How FDE Team Analyzes Own Capability Maturity

Team maturity ≠ sum of individual capabilities. Strong individuals without org沉淀/reuse/scale = immature team, just strong individuals temporarily together. Two dimensions from org granularity:

Dimension 1: Organizational Leverage Rate. Key maturity judgment, two layers:

Individual level: each FTE truly leverages current AI tools to boost personal productivity — same person with AI tools/agents covers more clients/scenarios continuously expanding. Not simple headcount stacking, but same headcount with amplified AI leverage covers wider range.

Team level: team converts field experience into productized/asset沉淀 capabilities, generates scale effects via product/platform leverage, raising org leverage rate. Two angles: "product conversion" — turn single-client experience into reusable product capabilities; "asset沉淀" — do converted things become org-level standardized assets? Concrete criteria: not headcount, not client count — only two external signals: unit FDE standardized asset output rising? subsequent client customization ratio falling? If improving, productization conversion real, flywheel turning; no improvement, scale however large = premium outsourcing repackaged.

Individual + team together = complete org leverage picture — individuals not using AI to amplify themselves makes team scale talk empty; team not沉淀 product/assets traps individuals in single points, no org-level leverage.

Dimension 2: Capability Maturity. Critical in AI era, manifests in real/valid/effective evaluation across scenarios, two layers:

Layer 1: Overall evaluation capability — evaluation data, methodology, tools/platforms — team accumulated evaluation data, built frameworks/technical means across industry scenarios. Foundation. Without this, team cannot answer "can today's model actually do this task" — direction judgment becomes guesswork.

Layer 2: Iteration improvement plans based on evaluation results — evaluation-surfaced problems, bad cases, baseline comparisons truly digested into next-round solution iteration inputs, not evaluated then shelved, next project starts from zero. This layer closes evaluation loop: evaluation not purpose, purpose is letting team continuously correct/iterate along evaluation results, forming a "North Star" mechanism — with it, team judges direction correctness from project start at lower cost, avoids detours.

Both layers together = complete capability maturity: evaluation without iteration = decoration; iteration without real evaluation = blind tuning.

Two dimensions together = org capability maturity: org leverage rate measures "individual+team truly turned AI+productization into scale effects"; capability maturity measures "mechanism won't drift, can self-correct." Missing either makes maturity judgment incomplete.

Question 8: AI-Native Organization Collaboration Model Transformation

Answer not limited to FDE role; all AI-native orgs will experience this collaboration transformation — FDE just first pushed to front, most observable sample.

AI-native org shape judgment: Future AI-native orgs resemble lean "special forces squads" not hierarchical large armies. Four traits: extremely high talent density, extremely strong judgment (decision insight), extremely short decision chains, extremely low coordination costs. Causal order: high talent density → strong individual judgment → org dares shorten decision chains (no layers of approval for safety) → shortened chains → coordination costs drop. Why org reliance on individual judgment grows: short chains, few approvals, no one to catch/correct deviations — everything points to "does this person judge accurately." Ideal FDE team = AI-native org shape instantiated in "frontline delivery" scenario.

Two concrete forms: "Super-individual" and "Super-organization."

Super-individual: natural person, leverages extreme AI tools/tech, brings agent matrix to work — compresses past team-level output into one person + their agent matrix.

Super-organization: many people + many agents forming complex collaboration. At least four collaboration layers: human-human, human-own-agent, human-other's-agent, own-agent-other's-agent. Latter three are new, AI-era-specific org forms — past org design assumed unit always "human," at most "human+tool"; super-org must simultaneously design human-own-agent, human-other's-agent, agent-agent three new collaboration interfaces — more complex than any past org transformation.

Structure change is surface; core change = two points: org composition, collaboration mode.

1. Org composition changed. Past: only human employees. Today: two unit types — human employees and digital employees (agents). Not just "added efficiency tools" — agents become new member type counted in org composition — they undertake specific tasks, produce specific results, may get decision rights — different from past "human uses tool" relationship.

2. Collaboration mode/relationships reconstructed. Past: only human-human collaboration via meetings/processes/reporting lines. Today: two coexisting — human-human, and new human-agent collaboration — every person brings own agent to work, collaboration object not just another human but "human+agent" composite, even composite collaborates with another's composite. This collaboration relationship didn't exist, needs redesign — not just give everyone a tool, but redefine "who interfaces with whom, who reports to whom, who can invoke whom" interfaces.

Org composition change enables collaboration reconstruction; collaboration reconstruction is inevitable result of composition change. Together they map to super-individual vs super-org: super-individual = "human+agent" new collaboration at individual extreme compression; super-org = many "human+agent" composites rewoven into network containing both human-human and human-agent collaboration relationships.

Question 9: Will Domestic/International FDE Landing Models Converge? Localization Challenges

Clear judgment: won't fully converge, but forms will differ.

Why not converge? Three structural differences in China prevent Palantir-style heavy model:

1. Payment inertia — Chinese enterprises' willingness/habit for pure-service payment differs from Silicon Valley.

2. Career hierarchy stigma — "on-site deployment" ranks bottom in traditional career ladders, directly affects talent flow.

3. Platform maturity gap — Palantir spent 20 years building Foundry/Ontology/AIP platform infra; China has no counterpart.

These three differences combine → China forms several distinct FDE ecosystems, not single heavy-model replication:

Type 1: Big-tech FDE teams. Core positioning: FDE as model capability validation ground — verify own models/products on frontier clients. This part converges with Silicon Valley.

Type 2: Vertical industry boutique firms. Can't do platform route, but go deep in specific industries, trade industry depth for client LTV — moat from single-industry understanding, not scale.

Type 3: AI-armed individual FDEs. AI-era unique — one person with AI tool matrix drives delivery cost near zero, essentially ultra-light model.

Only Type 1 converges with Silicon Valley; Types 2-3 are China-specific paths. Judgment: China may not wait for a Palantir that can sustain FDE teams for 20 years — like skipping credit cards to mobile payments, China likely jumps straight to light models.

Top localization challenges to prioritize:

1. Talent challenge (possibly biggest). Ideal/excellent FDE demands extremely high individual capability — engineering hands-on + business understanding + abstraction. Such composite talent scarce whether internal cultivation or external hire; needs high cost, long time; not solvable by job postings + training programs.

2. Voice & deep participation challenge. Problems/signals FDEs discover on-site — can they truly convert into product voice? Can they deeply participate in product evolution, feature iteration, roadmap formulation, not just deliver existing product then drop suggestions with no follow-through? If not, FDE remains one-way delivery mode, same as "bidirectional working capability" — talent cultivation solves "supply of people who can do it"; voice solves "whether org takes what this person does seriously" — one supply, one mechanism; missing either stalls China FDE localization.