Zwei Drittel unserer Deployment-Arbeit wird inzwischen autonom von unserem eigenen Produkt erledigt (über Duet).
In diesem Beitrag geht es darum, warum das so ist, um unsere Philosophie zum Aufbau eines Produkt- und Deployment-Ansatzes und darum, wie sich das im Laufe der Zeit entwickelt hat.
Etwas, auf das wir früher herabgesehen haben, ist heute die Standardantwort
„Forward deployed engineer“ ist inzwischen zur Antwort auf fast jede schwierige Frage im KI-Go-to-Market geworden. Deployments sind schmerzhaft? Stell FDEs ein. Kunden können sich nicht selbst bedienen? FDEs. Produkt nicht fertig? FDEs. Anthropic und OpenAI haben beide Enterprise-Deployment-Abteilungen aufgebaut, die ausdrücklich Palantir als Vorbild haben, und jedes Seed-Startup, mit dem ich spreche, hat inzwischen eine FDE-Stellenausschreibung. Die Zahl der Stellenausschreibungen für diese Position soll im letzten Jahr um mehrere hundert Prozent gestiegen sein.
Was seltsam ist: Bis vor Kurzem war das etwas, wofür man kritisiert wurde. Ingenieure zu Kunden zu schicken, galt als Zeichen dafür, dass man kein echtes Produkt hatte: Der Umsatz war minderwertiger und die Margen strukturell gedeckelt. An der zugrunde liegenden Ökonomie hat sich nichts geändert.
Der entscheidende Punkt bei FDEs ist, dass sie Ergebnisse liefern. Im Zeitalter der KI ist das großartig, denn Unternehmen wissen vielleicht nicht genau, wie der Weg zum Ergebnis aussieht, aber es ist klar, dass KI überzeugende Ergebnisse liefert.
Gleichzeitig wird die Rolle zunehmend überstrapaziert und sollte nicht als Krücke dienen, um ein strukturelles Problem zu verstecken.
„FDEs fressen Schmerz und scheiden Produkt aus“
Palantir (von dem mein Mitgründer @AshwinSreenivas stammt) machte die Rolle Mitte der 2000er-Jahre populär, als es Gotham an die CIA, die NSA und Geheimdiensteinheiten der Armee verkaufte. Und sie haben die Kritik lange Zeit eingesteckt. Joe Lonsdale, einer der Mitgründer, hat geschrieben, dass die vorherrschende Meinung über Palantir über den Großteil von zwei Jahrzehnten hinweg war, dass es ein verherrlichtes Beratungsunternehmen und kein echtes Technologieunternehmen sei, und dass diese Ansicht auf einer wahren Beobachtung beruhte: Viele ihrer Ingenieure verbrachten viel Zeit dabei, bei Kunden zu sitzen.
Aber Shyam Sankar, Palantirs CTO, hatte einen Satz, den er ständig wiederholte: FDEs fressen Schmerz und scheiden Produkt aus.
Palantirs frühe Gotham-Deployments waren stark maßgeschneidert und darauf ausgelegt, eine einzige Geheimdienstfrage für eine einzige Einheit zu beantworten. Palantir kodierte die Probleme, die sie sahen, als Plattform-Primitive: die Ontologie, Objektmodelle, Berechtigungen, Workflow-Engines, Herkunftsverfolgung. Aus diesen Primitiven wurde Foundry. Foundry wurde zu dem, was man kommerziell verkaufen konnte. Apollo und AIP folgten demselben Weg.
Nichts davon hätte existiert ohne Ingenieure, die zuerst im Feld Schmerz gefressen haben. Der Schmerz war der Input für das Produkt, keine Vertriebskosten.
Als Foundry reifte, reduzierten standardisierte Deployments den Bedarf an kundenspezifischer Arbeit dramatisch, die Bruttomargen stiegen in den 80-Prozent-Bereich, und Palantir wechselte von einem FDE-getriebenen Ansatz zu Account-basiertem Verkaufen. Viele dieser FDEs wechselten in die Kernentwicklung. Sie lehnten bekanntermaßen auch Verträge ab, bei denen der Kunde nur ein Accenture mit besserer Software wollte.
Das FDE-Team war nicht das Geschäftsmodell. Es war der Weg, das richtige Produkt zu bauen.
Warum einige KI-Startups jetzt wirklich FDEs brauchen
Wenn du 2015 ein SaaS-CRM gebaut hättest, hättest du den Workflow nicht entdecken müssen. Zwanzig Jahre lang hatten Menschen bereits durchdacht, was eine Pipeline ist, was eine Stufe ist, wie eine Lead-Übergabe aussieht.
Wenn du 2026 einen KI-Agenten für die Buchhaltung baust, gibt es keinen etablierten Workflow, weil buchstäblich niemand so etwas je benutzt hat. Niemand weiß, wie die User Journey aussieht – nicht du und, was wichtig ist, auch nicht dein Kunde. Sie können dir nicht sagen, was sie wollen, weil das, was sie wollen würden, noch keine Form hat.
Das ist dieselbe Situation, in der Palantir gestartet ist. Lonsdale formulierte es so, dass sie aus Notwendigkeit forward-deployed waren: Sie hatten starke Technologie und keine Ahnung, wie ihre frühen Verteidigungs- und Geheimdienstkunden tatsächlich arbeiteten.
Also ja, schick Ingenieure. Setz dich in den Raum. Sieh zu, wie dein Produkt auf Arten kaputtgeht, die sich deine Tests nie vorgestellt haben. In einer wirklich neuen Kategorie ist die letzte Meile kein Lieferproblem, sondern ein Entdeckungsproblem, und es gibt keinen Ersatz für das Vor-Ort-Sein.
Die Falle ist nicht das Anfangen. Sondern das Nicht-Aufhören.
Sobald du weißt, was die User Journeys tatsächlich sind, solltest du anfangen, die FDEs herauszuziehen.
Du wirst das nicht wollen. Nicht weil jemand eine falsche Entscheidung trifft, sondern weil es in jedem einzelnen Sprint einfacher ist, sie zu behalten.
FDEs lassen dich jeden harten Produkt-Kompromiss vermeiden. Du musst nie entscheiden, was das Produkt tut, welche von zwei Kundenanfragen gewinnt oder wo die Konfigurationsoberfläche endet. Es fühlt sich frei an. Niemand muss irgendjemandem eine Absage erteilen. Keine schmerzhafte Architekturentscheidung wird getroffen. Der Kunde ist begeistert.
Und jetzt hast du alle Nachteile des Modells und keinen der Entdeckungsvorteile. Dein Cost-to-Serve sinkt nicht. Deine Margen bleiben gedeckelt. Dein Wachstum ist durch Einstellungen begrenzt. Jede maßgeschneiderte Lösung im Feld ist eine Produktentscheidung, die du bewusst nicht getroffen hast. Jedes Deployment sollte das nächste einfacher machen.
Hinzu kommt, dass nur sehr wenige Startups von Anfang an die achtstelligen Deals abschließen können, die Palantir an Land zog, was es noch schwieriger macht, die Wirtschaftlichkeit aufrechtzuerhalten.
Noch etwas, das man nicht verwechseln sollte
FDE ist auch nicht dasselbe wie Implementierung. „Baue diese Integration in ihr Ticketsystem“ ist echte, notwendige Arbeit, aber es ist die Umsetzung einer bekannten Spezifikation und nicht die Entdeckung einer unbekannten. Beides unter einem Titel zu bündeln, ist die Art und Weise, wie Unternehmen sich einreden, dass eine wachsende Service-Organisation eine Produktinvestition ist.
Modelle schreiben Code inzwischen gut genug, dass ein Großteil dessen, was ein Implementierungsteam 2023 erledigt hat, zu etwas wird, das das Produkt selbst tut. Irgendwann wirst du einen Agenten bauen können, der die gesamte Last-Mile-Arbeit End-to-End erledigen kann. Er kann Workflows beobachten und sogar Kunden befragen.
Was wir stattdessen getan haben
In unserem konkreten Fall bei @DecagonAI glauben wir grundsätzlich, dass ein produktgetriebener Ansatz die Antwort ist, eher als ein servicegetriebener oder FDE-getriebener. Kundenservice ist mengenintensiv, wiederholbar und zerlegbar, und wenn wir mit Unternehmen sprechen, sind zwei Dinge immer konsistent:
- Iterationsgeschwindigkeit ist entscheidend. Einen KI-Agenten auszuliefern ist keine einmalige Sache. Er muss im Laufe der Zeit ständig abgestimmt und aktualisiert werden. Wenn jede Anpassung Engineering erfordert, wird es viel zu langsam und zu teuer, um zu skalieren.
- Vendor-Lock-in und Souveränität. Angesichts der Erfahrungen von Organisationen mit SaaS will niemand an einen Anbieter gebunden sein und von dessen Ressourcen abhängen.
In den frühen Tagen haben Ashwin und ich persönlich einfach alles gebaut, was Kunden verlangten. Als das Produkt Fahrt aufnahm, trafen wir die explizite Entscheidung, dass unser zentrales Wertversprechen darin bestehen würde, das beste Produkt zu haben.
Um es klar zu sagen: Wir arbeiten immer noch mit dem Kunden zusammen, um das Ergebnis End-to-End zu liefern. Allerdings verantworten wir selbst während dieses Prozesses den Build, während wir ihr Team dazu befähigen, unser Produkt zu nutzen, und ihnen die Schlüssel übergeben. Mit der Reifung des Produkts ist die kundenspezifische Arbeit, die unser Engineering-Team erledigt hat, drastisch zurückgegangen.
Diese Entscheidung brachte Kompromisse mit sich. Es bedeutete, im Feld nichts schnell zusammenzuhacken, wenn das schneller gewesen wäre. Es bedeutete, Eskalationen aufzunehmen und sie in Anforderungen zu verwandeln statt in Patches, was kurzfristig Zeit kostet.
Der Lohn:
- Zwei Drittel der Deployment-Arbeit wird jetzt autonom über Duet erledigt: Konfiguration, Iteration, der Long Tail des Feintunings, der früher einen Menschen im Loop erforderte.
- Es dauert jetzt im Durchschnitt nur noch wenige Tage, um das erste AOP zu starten, sogar für große Banken, Fluggesellschaften, Telekommunikationsanbieter usw.
Es gibt noch viel zu tun, aber wir sind auf dem Weg.
Also: FDE oder nicht FDE?
Geh früh forward-deployed. Hol dir das Signal. Stell deine Ingenieure für immer vor Kunden.
Dann stelle die echten Fragen. Liegt die Maßschneiderei in der Umgebung deines Kunden oder in den Lücken deines eigenen Produkts? Ist die letzte Meile irreduzibel oder nur nicht gebaut? Entdecken deine FDEs etwas oder absorbieren sie etwas? Und was wurde beim letzten Mal ins Produkt eingebaut, als einer von ihnen zurückkam?
Nutze FDEs, um herauszufinden, was im Produkt existieren muss. FDEs fressen Schmerz und scheiden Produkt aus. Wenn deine FDEs Schmerz fressen und mehr Schmerz ausscheiden, hast du kein FDE-Team. Du hast ein Servicegeschäft.
