FDE Is Not a Product Strategy
English
FDE is buzzing. Forward Deployment Engineer — an engineer who embeds in customer environments, solves real business problems using a product, and takes ownership of outcomes end to end. Used correctly, it's a machine for validating product hypotheses at speed. Used incorrectly, it becomes an expensive system integrator. What to standardize and what to cut is product's responsibility — FDE doesn't substitute for that.
The role itself is formidable: understand and define the customer's business problem, design how the product addresses it, implement and integrate hands-on, put it into operation, and iterate until results emerge. Sales, solution design, PM, and engineering fused into one senior role. The origin is Palantir, a US company that in the 2000s began deploying engineers into government and military environments to build data integration and analytics infrastructure until it actually worked.
But Palantir's model is not one normal startups can reference. They had no product at the start, which meant custom implementations for each customer's unique data environment. Assigning top engineers to a single customer is an extraordinarily expensive model — viable only because Palantir had high-value, long-term government and military contracts. They spent more than a decade reaching meaningful product standardization. Palantir is the origin of FDE, but as a success story to emulate, it is an extreme outlier.
So why is FDE back in the spotlight? The answer is LLM. Traditional enterprise SaaS scaled by taking high-volume workflows, standardizing them, and fitting people to the standard. Twenty years of this left little left to commoditize. What remained was the ambiguous work humans had always handled by reading context. LLM made it possible to handle some of that ambiguity in software — processing context-dependent, implicit-rule-governed work, without locking in a fixed data model or workflow.
Here is the irony. LLM is the technology that made FDE necessary, and simultaneously the technology that will make FDE unnecessary. As LLM matures, the contextual bridging that FDEs do in the field can increasingly be handled by the product itself. This is precisely why the condition for FDE to work — having a strong product core — matters more than ever.
After ChatGPT launched, the world became a PoC paradise. I was on the Azure AI team at the time; the exponential growth in revenue and customer count is still vivid. But then came the wave of PoCs that went nowhere. The pattern was consistent: teams went in technology-first, LLM API in hand, and never got deep enough into the business problem or workflow improvement that would actually make it matter. Understandable in the early days — but the conclusion was clear. API alone doesn't generate value. Value requires adapting to real data and real operations until customer outcomes actually emerge. That is where FDE re-entered the picture.
FDE and traditional on-site system integrators look nearly identical from the outside. Both embed in customer environments, understand requirements, implement, and drive outcomes. The essential difference is this: SI pursues individual optimization, with no obligation to generalize. FDE is optimized to solve customer problems while feeding results back into product standardization. FDE is the role for running the loop between solving customer problems and turning those solutions into product — fast.
So when should FDE be used? There are two phases. The first is the hypothesis validation phase. When the product is still immature, FDE goes into the field to learn what should be standardized. Not to compensate for product weakness — to validate product hypotheses in real environments. The second is the standardized delivery phase. Once the product core is solid, FDE's role shifts to adapting and delivering it within each customer's specific context.
What keeps FDE from collapsing into SI? A strong product core that doesn't flex for customers — API, data model, execution infrastructure held firm. A clear definition of what is non-competitive territory, and the discipline not to enter it. A management-level commitment to taking what individual engagements teach and building it back into the product. And the most overlooked condition: FDEs are extraordinarily rare people. Someone who can define problems, design solutions, implement, operate, and drive outcomes is nearly nonexistent. Scaling by adding FDE headcount doesn't scale. FDE dependency must be treated as a temporary state, with a roadmap for the product to take over.
The contrast that clarifies this is Databricks. They never used the title FDE, but they are the best example of the standardization cycle done right. They started by provisioning Spark clusters for individual customers, kept their problem domain narrowly focused on data processing, and locked their core technology to Spark. Three years after founding, product standardization had advanced dramatically. Compare that to Palantir spending a decade-plus with too broad a problem domain. Whether FDE works or not comes down to defining what you will not do.
The word FDE is taking on a life of its own. Some companies announce FDE programs while actually abandoning product standardization and converting to an SI model. Using FDE as a buzzword reveals a fundamental misunderstanding of what it is. FDE is not a fallback strategy for companies without a product. It is a tool for making the product stronger.
Three things for founders and PMs considering FDE: articulate your product hypothesis before you hire. Design the loop from field learning back to the product before you make the hire. Define what "FDE no longer needed" looks like, and build a roadmap toward it.
Is your FDE making your product stronger? Or is it hiding its weakness?
日本語 {#japanese}
FDEという言葉がバズっている。Forward Deployment Engineer、顧客の現場に入り、プロダクトで業務課題を解決し、成果まで責任を持つエンジニアだ。正しく機能すればプロダクト仮説を高速に検証する装置になる。間違えれば、高コストなSIになる。何を標準化し、何を捨てるかを決めるのはプロダクトの責任だ——FDEはその責任を代替しない。
FDEは、顧客の業務課題を理解し課題を定義する。課題解決のためにプロダクトの利用方法を設計する。実際に手を動かして実装・統合し、運用に乗せ、成果が出るまで改善する。営業・ソリューション設計・PM・エンジニアリングを一体化した上級職である。このロールを確立したのはパランティアという米国企業で、2000年代に政府機関や軍向けのデータ統合・分析基盤を現場で作り込むアプローチを取ったことに起源がある。
ただし、パランティアのモデルは普通のスタートアップが参照できるものではない。当初パランティアにはプロダクトがなく、顧客ごとに個別実装を繰り返すことになった。高度なエンジニアを1社にアサインする極めてコストの高いモデルで、政府・軍の高単価かつ長期契約があったから成立した。プロダクト標準化まで10年以上を費やしている。パランティアはFDEの起源ではあるが、参考にすべき成功例としてはあまりにも特殊なケースだ。
それでもFDEが再び注目されているのはLLMの登場によるものだ。従来のエンタープライズSaaSは、十分なボリュームがある業務を標準化し、その標準に人を合わせることでスケールしてきた。20年続けてきたことで、標準化して切り出せるところが少なくなってきた。人間が文脈で処理してきた曖昧な仕事が残されていた。LLMはその曖昧な領域をある程度扱えるようにした。文脈依存で暗黙ルールが適用される業務をソフトウェアで捌く可能性が生まれ、データモデルやワークフローを固定しなくても処理できる可能性が出てきた。
ここに皮肉がある。LLMはFDEを必要にした技術であり、同時にFDEを不要にしていく技術でもある。LLMが成熟するにつれて、FDEが現場で担っていた文脈の橋渡しをプロダクト自体が担えるようになる。だからこそ、FDEが機能する条件——強いプロダクトコアを持つこと——が今まで以上に重要なのだ。
ChatGPT登場後、世の中はLLM PoC天国となった。Azure AI開発チームに在籍していたころ、売上と顧客数の指数関数的な伸びを目の当たりにした。しかしその後、PoCはやったが結果が出ずに終わる案件が大量発生した。原因は明確で、技術ありきで入り、解くべき顧客課題や業務フローの改善まで踏み込めていなかった。LLM初期の段階では仕方がなかった面もある。しかし結局、APIだけでは価値は出ない。社内データや業務に適応し、顧客価値が生まれないと意味がない。そこでFDEが再び必要とされることになった。
FDEと常駐SIはよく似ている。顧客現場に入り、要件を理解し、実装し、成果を出す。しかし本質的な違いがある。常駐SIは個別最適を突き詰めることであり、再利用は必須ではない。FDEは顧客課題を解きながら、プロダクトの標準化に還元することに最適化されている。顧客課題の解決とプロダクト化のループを高速に回すための役割なのである。
ではFDEをいつ使うべきか。二つのフェーズがある。一つ目は仮説検証フェーズ。プロダクトがまだ弱い時期に、何を標準化すべきかを学ぶためにFDEを現場に入れる。FDEはプロダクトの弱さを補うためではなく、プロダクト仮説を現場で検証するために存在する。二つ目は標準化デリバリーフェーズ。プロダクトコアが固まった段階で、FDEはそれを顧客環境に適応させながら届ける役割になる。
FDEがSIに堕ちないための条件がある。顧客に合わせない強いプロダクトコアを持っていること。APIやデータモデル、実行基盤などはここには含まれ、顧客ごとに変えない。自社にとって非競争領域を定義し、そこに手を出さないこと。個別案件の成果をプロダクトに組み込んでいくという経営レベルでの方針があること。そして、見落とされがちだが最も重要な点として、FDEは極めて希少な人材であることを認識すること。課題定義・設計・実装・運用・成果出しを担えるエンジニアはほぼ存在しない。FDEを増やすことでスケールしない。FDEが必要な状態を一時的なものと定義し、プロダクトがその役割を引き継ぐロードマップを持っていなければならない。
この点で参考になるのがDatabricksだ。彼らはFDEというロールを設けていたわけではないが、標準化のサイクルを最もうまく実践した会社だ。個別顧客向けのSpark Cluster提供からスタートし、問題領域をデータ処理に絞り、コアテクノロジーをSparkに固定した。その結果、創業後3年でプロダクト標準化が大きく進んだ。パランティアが問題領域を広くとりすぎて10年以上かかったのとは対照的だ。FDEが機能するか否かは、「何をやらないか」の定義にかかっている。
FDEという言葉が独り歩きしている。「FDEを導入します」と言いながら、実態はプロダクト標準化を諦めてSIモデルに転換しているケースが見受けられる。FDEというバズワードを使うこと自体が、プロダクト仮説なきFDEへの誤解を示している。FDEはプロダクトを持たない会社の代替戦略ではない。プロダクトを強くするための手段だ。
FDEを導入しようとしている経営者・PMに三つのことを伝えたい。FDEを雇う前に、プロダクト仮説を言語化すること。FDEが現場で得た知見をプロダクトに還元するループを、採用より先に設計すること。そしてFDEが不要になる状態を定義し、そこへ向かうロードマップを持つこと。
あなたの会社のFDEは、プロダクトを強くしていますか？それともプロダクトの弱さを隠していますか？