Twój produkt potrzebuje Forward Deployed Engineera
Nowa rola, w której... pracowałem 5 lat temu ;)
Kilka dni temu LinkedIn zalało dyskusjami o Forward Deployed Engineerze - nowej roli, która aktywnie wdrażania Twój produkt w organizacji klienta. Rozumie kontekst biznesowy, procesy, ludzi, ograniczenia.
ElevenLabs pokazał ten model na swoim warszawskim Summit, tego podejścia aktywnie używają tego OpenAI, Palantir, Anthropic, a temat w Polsce promuje jeszcze Tomek Karwatka z Open Mercato.
Czytałem to z dziwnym poczuciem déjà vu.
6 lat temu zderzyliśmy się z tym w SentiOne i w bojach wypracowywaliśmy tę rolę - nie wiedzieliśmy tylko, że to tak się nazywa. Sam pełniłem właściwie taką funkcję. Dlatego dzisiaj rozłożymy ja na czynniki pierwsze i podzielę się tym, czego się wtedy nauczyłem.
W dzisiejszym wydaniu:
Czym jest Forward Deployed Engineer?
Dlaczego to ważne? Przecież nie buduję nowego ElevenLabs / OpenAI
Moja historia z SentiOne, gdy zajmowałem się FDE zanim miało nazwę
Co to oznacza dla produktu?
Pułapka we wdrożeniu FDE
1. Czym jest Forward Deployed Engineer?
Zacznijmy od podstaw - bo dopiero niedawno trend stał się popularny i większość osób w Polsce jeszcze tego terminu nie spotkała.
Forward Deployed Engineer (FDE) to rola, która pochodzi z Palantira. Prosta koncepcja, ale zrewolucjonizowała sposób wdrażania produktów w B2B.
Klasyczne wdrożenie wygląda tak: firma kupuje produkt, dostaje dokumentację, dział IT klienta wdraża, konsultanci robią kilka sesji szkoleniowych. I wszyscy mają nadzieję, że “jakoś zadziała”.
FDE działa inaczej - inżynier jedzie do klienta i wdraża rozwiązanie na miejscu. Nie wysyła dokumentacji. Nie robi handoffu do działu IT. Jest tam - rozumie kontekst biznesowy, procesy, ludzi, ograniczenia. I dowozi działający system w strukturze klienta.
Role FDE różnią się w zależności od firmy (niektóre kładą większy nacisk na wsparcie sprzedaży, inne na rozwijanie produktu), ale zazwyczaj opierają się na 5 filarach:
Solidne inżynierskie fundamenty
Współpraca ze sprzedażą w domykaniu kontraktów - Wielu FDE aktywnie pomaga w pozyskaniu klienta. To połączenie produktu z Go-To-Market.
Praca bezpośrednio w zespole klienta: Często FDE “osadza się” (embed) u klienta, żeby dobrze zrozumieć jego domenę. W Palantirze to około 25% czasu pracy (onsite), w innych organizacjach nawet 50%.
Wpływ na główny produkt (core): FDE podejmuje też kluczowe decyzje o priorytetach: kiedy budować coś specjalnie pod danego klienta, a kiedy zainwestować te siły w rozwój bazowego produktu firmy. Często FDE są bezpośrednio zintegrowani z głównymi zespołami inżynieryjnymi.
Obsesja na punkcie sukcesu klienta: Prawdziwym celem nie jest wdrożenie samo w sobie, ale znalezienie najwyżej wycenianego problemu klienta i upewnienie się, że nasze rozwiązanie go likwiduje.
FDE ma już nawet swoją stronę na Wikipedii.
1.1. Co robi FDE?
The Pragmatic Engineer przeanalizował rolę FDE i zapytał FDE jak wygląda ich typowy tydzień. Poniżej cytat świetnie oddający istotę tej roli:
„Większość tygodni spędzam pracując kilka dni w siedzibie klienta. Część tego czasu to spotkania z interesariuszami technicznymi lub biznesowymi, a reszta to monitorowanie, debugowanie, wdrażanie lub konfigurowanie naszego oprogramowania dla tego klienta.
Po powrocie do biura spędzam czas na pisaniu drobnych zmian w kodzie, robieniu code review i badaniu lub planowaniu rozwiązań dla klientów.
Pozostały czas przeznaczam na komunikację z naszymi wewnętrznymi zespołami wsparcia i rozwoju produktu”.
Ogólnie rzecz biorąc, typowy tydzień FDE to mieszanka:
Pracy projektowo-wdrożeniowe dla klienta: to absolutny priorytet.
Ulepszania produktu: kiedy główna platforma ogranicza budowanie funkcjonalności dla klienta, FDE np. konfigurują nowe modele danych, wprowadzają poprawki stabilności lub dodają rozwiązania (commitują fixy) prosto do rdzenia systemu.
Zadań wewnętrznych: bieżąca komunikacja, maile, spotkania, daily, wymienianie się wiedzą i współdzielenie projektów.
1.2. Podejście ElevenLabs
W modelu wykorzystującym FDE działa z sukcesami polski unicorn – ElevenLabs. Pokazała go 1 września na swoim ElevenLabs Summit w bardzo konkretnej formie (tzw. Double Loop).
Zamiast klasycznego, liniowego “głuchego telefonu” (gdzie Produkt tworzy rozwiązanie, Sprzedaż je handluje, a dział IT klienta próbuje je jakoś wdrożyć), ElevenLabs stawia FDE dokładnie w centrum dwóch kluczowych obiegów informacji:
Pętla lewa: Research & Product → FDE → dane wracają do Research & Product.
Główny zespół badawczo-produktowy buduje rdzeń systemu, modele AI i udostępnia zaawansowane API.
FDE bierze ten rdzeń i wynosi go “na zewnątrz”.
Co jednak najważniejsze – pętla ta działa w dwie strony. FDE nieustannie wraca do zespołu produktowego / researchu z twardymi danymi o tym, jak technologia zachowuje się w starciu ze środowiskami produkcyjnymi.
Dzięki temu Product Managerowie nie muszą zgadywać, co budować. Ich backlog zasilają prawdziwe problemy napotkane podczas gigantycznych wdrożeń u klientów.
Pętla prawa: FDE wdraża u klienta → feedback od klientów wraca do FDE.
FDE wchodzi “w teren” i wdraża rozwiązanie bezpośrednio w infrastrukturze firmy kupującej produkt.
Zamiast czekać tygodniami na raporty od supportu, inżynier na żywo zbiera feedback od użytkowników końcowych i interesariuszy biznesowych.
Jeśli integracja wymaga napisania niestandardowego kodu (np. specyficznego konektora do archaicznego systemu klienta), FDE pisze go na miejscu. Pętla zamyka się natychmiastowo.
Kluczowe tu jest to, że FDE siedzi wewnątrz organizacji klienta. Jest najaktywniejszym punktem styku między tym, co powstaje w R&D, a tym, z czym fizycznie mierzy się organizacja klienta.
Eliminuje to nieporozumienia na linii “nietechniczna sprzedaż – bardzo techniczny produkt” i drastycznie przyspiesza dowożenie wartości.
2. Dlaczego to ważne? Przecież nie buduję nowego ElevenLabs / OpenAI
Trend jest bardzo mocny, bardzo mocno tez rośnie w bańce najszybciej rozwijających się firm AI:
OpenAI buduje własne zespoły FDE.
Anthropic robi to samo.
SAP, Cognizant, ServiceNow idą w tym kierunku.
Możesz pomyśleć: “Okej, Palantir, OpenAI, Anthropic – to giganci z Doliny Krzemowej. Jak to się ma do mojej pracy w Polsce?”.
Ma się bardzo konkretnie. Podejście FDE to odpowiedź na problem, z którym jako produktowiec mierzysz się na co dzień:
Gigantyczna przepaść między „kupiliśmy dostęp do produktu” a „produkt realnie rozwiązuje nasze problemy”. A produkty z AI jeszcze bardziej to napędziły.
2.1. To dotyczy każdego złożonego produktu B2B
Jeśli budujesz produkt B2B, który wymaga integracji, zmiany procesów u klienta lub dostosowania do jego specyfiki, masz ten sam problem.
Ile razy twój produkt nie dowiózł biznesowej wartości, bo klient “źle go wdrożył”, “nie czytał dokumentacji API” albo “nie zrozumiał, jak z niego korzystać”?
Klasyczny proces – gdzie sprzedaż obiecuje złote góry, produkt dowozi ficzery, a wsparcie IT klienta zostaje samo z instrukcją – w skomplikowanym B2B po prostu przestaje działać.
2.2. Produkty AI drastycznie przyspieszyły ten trend
Dlaczego o FDE mówi się teraz tak głośno? Bo w przypadku wykorzystania sztucznej inteligencji trudność wdrożenia i zrozumienia klienta wystrzeliła w kosmos.
W tradycyjnym SaaS-ie klient musiał nauczyć się klikać w nowy interfejs. W produktach AI – klient musi często zmienić całą filozofię swojej pracy.
Pomiędzy „kupiliśmy dostęp do AI” a „AI realnie rozwiązuje nasze problemy i daje ROI” mamy gigantyczną przepaść. Wdrożenie tak skomplikowanej i niedeterministycznej technologii wymaga kogoś, który wejdzie głęboko w biznes klienta, zrozumie jego ograniczenia.
Tomasz Karwatka, który mocno działa w produktach B2B dla dużych graczy - podsumował to tak:
Produkty AI w Enterprise to nie jest problem software’owy. To problem wdrożeniowy.
Przepaść między “kupiliśmy dostęp do AI” a “AI realnie nam pomaga” ma niewiele wspólnego z samą technologią. To kwestia kontekstu, integracji, procesów, governance i odpowiedzialności za wynik.
2.3. Mid-market też w to wchodzi
Zaczynają to zauważać nie tylko firmy sprzedające kontrakty za dziesiątki milionów dolarów. Organizacje celujące w średni rynek (mid-market) – jak ClickUp, Webflow, Lindy.ai, Clay czy Zapier – również z sukcesem sięgają po ten model.
Największym wyzwaniem dla mid-marketu są jednak koszty. Budowanie potężnego, wewnętrznego zespołu FDE(jak robi to Palantir) jest dla nich po prostu za drogie. Dlatego firmy te znalazły świetny hack: mocno stawiają na programy partnerskie z wyspecjalizowanymi agencjami wdrożeniowymi.
Zewnętrzne agencje i eksperci pełnią tam de facto rolę zewnętrznych, wynajętych FDE. Biorą na siebie ciężar zrozumienia biznesu klienta, zintegrowania u niego produktu i wzięcia odpowiedzialności za biznesowy wynik.
Z kolei do samego twórcy SaaS-a (np. Zapiera) odesłany zostaje potężny, przyspieszony *feedback loop* z rynku. To idealna alternatywa, która pozwala na luksusowe wdrożenia u klientów bez przepalania budżetu własnego działu R&D.
3. Zajmowałem się FDE zanim miało nazwę
Od 2018 roku budowaliśmy SentiOne Automate - platformę do tworzenia botów automatyzujących obsługę klienta (głosową i tekstową). Nie był to wrapper na Open AI, ale własne modele, własny research AI. Doszliśmy z tym do 6,5 mln PLN ARR.
Mieliśmy dwie wersje produktu: klasyczny SaaS oraz potężne wdrożenia on-premise dla Enterprise. I zderzyliśmy się z problemami, które FDE potrafi rozwiązywać:
3.1. Problemy wdrożeń produktów AI
Pierwotnie zakładaliśmy klasyczne podejście B2B: klient kupuje, my pomagamy stworzyć pierwszą wersję bota, po czym klient przejmuje produkt i rozwija go sam, posiłkując się naszą dokumentacją.
Przy pierwszym wdrożeniu dla ogromnego banku boleśnie zderzyliśmy się z murem. I nie były to problemy techniczne. Klient kompletnie nie rozumiał niedeterminizmu AI. Przychodzili do nas z żądaniem: “Bot się wczoraj pomylił w tej jednej rozmowie, naprawcie to”. Z ich perspektywy, skoro to “błąd” w sofcie, to da się go usunąć.
Tylko że sztuczna inteligencja to nie jest normalny software. Przy obsługiwaniu setek tysięcy rozmów miesięcznie, statystycznie bot zawsze gdzieś się pomyli. To natura modeli probabilistycznych, a nie bug.
Samo wytłumaczenie klientowi tej koncepcji i zmuszenie go do przebudowania procesów biznesowych (np. wprowadzenia weryfikacji *human-in-the-loop*) zajmowały nam miesiące.
3.2. Zrozumienie technologii i narodziny Double Loop
Szybko zderzyliśmy się z faktem, że takie wdrożenia miały gigantyczne problemy, jeśli po obu stronach przypisana do nich osoba była mało techniczna i nie chciała wejść naprawdę w głąb naszego produktu. Większa szansa na biznesowy sukces pojawiała się dopiero wtedy, kiedy wdrożeniowiec miał pełne, głębokie zrozumienie technologii pod maską.
Dlatego na początku drogi naszego produktu - poniekąd sam wszedłem w rolę takiego wdrożeniowca dla największych klientów Enterprise. Tylko nie nazywaliśmy tego wtedy Forward Deployed Engineer.
Dzięki temu doświadczyłem siły obu pętli, które przedstawił model ElevenLabs na własnej skórze:
Z jednej strony pracowałem bezpośrednio z klientem, “osadzałem się” w jego środowisku, zderzałem się z realiami jego biznesu i tłumaczyłem mu koncepcje sztucznej inteligencji (pętla prawa).
Z drugiej strony natychmiast wracałem z twardym, bardzo technicznym feedbackiem prosto do naszego zespołu badawczego i inżynierów z R&D, bezpośrednio wpływając na to, jak rzeźbimy rdzeń całego systemu (pętla lewa).
Nie nazywaliśmy nas wtedy Forward Deployed Engineers. Byliśmy taką dziwną hybrydą produktu, inżynierii i konsultingu. Ale patrząc na to z dzisiejszej perspektywy, to był czysty FDE i główny powód naszych pierwszych sukcesów komercyjnych.
3.3. Skalowanie
Dopóki cała ta wiedza i specyficzny typ pracy pozostawały bezpośrednio w zespole produktowym – nasza podwójna pętla działała doskonale, dając dokładnie ten sam obieg informacji, którym dzisiaj chwali się ElevenLabs.
Jednak przy skalowaniu konieczne i całkowicie naturalne było wydzielenie ostatecznie osobnego, dedykowanego zespołu wdrożeniowego. Na początku mieliśmy z nim potężne problemy. Naiwnie wierzyliśmy, że ten nowy dział można zbudować klasycznie: Sales sprzedaje, a Project Manager “zarządza wdrożeniem”.
Nasze obserwacje brutalnie to zweryfikowały. Kiedy przypisana do wdrożenia osoba była mało techniczna i nie chciała wejść głęboko pod maskę naszego produktu, projekt po prostu stawał w miejscu. Czysty “project management” i pilnowanie harmonogramu przy wdrażaniu AI absolutnie nie działały.
Co ciekawe, nie każdy inżynier chciał rozmawiać z klientem. Nie każdy PM był wystarczająco techniczny, żeby działać przy wdrożeniu.
Zaczęło to lepiej działać dopiero po czasie, gdy zmieniliśmy profil zatrudnianych tam ludzi. Najlepiej sprawdzały się osoby, które nie miały silnej tożsamości zawodowej do obrony - “trochę inżynier, trochę product, trochę research”. Takie osoby naturalnie żyły na przecięciu i były ciekawe obu stron.
4. Co to oznacza dla produktu?
Coraz bardziej “Shipped” nie znaczy “done”.
Jako PM-owie jesteśmy wytrenowani do myślenia w cyklach: zdefiniuj problem → zbuilduj rozwiązanie → wydaj → zmierz → iteruj. Ale w tym modelu jest ukryte założenie: że kiedy wysyłamy feature lub produkt, klient jakoś sobie z nim poradzi.
W SaaS B2C to często prawda. W produktach B2B, szczególnie gdy coraz więcej jest w nich AI - NIEKONIECZNIE.
Rozjazd między “wdrożyliśmy” a “klient realnie korzysta” jest często większy niż cały czas który poświęciłeś na budowanie. I ta przepaść to nie jest problem inżynierski. To problem produktowy.
Kilka pytań, które warto sobie zadać 👇
Czy twój produkt ma mechanizm zbierania feedbacku z “dziedzińca klienta”? Nie z ankiet po onboardingu - z realnego użycia, z problemów które pojawiają się miesiąc po wdrożeniu.
Kto w twoim teamie jest odpowiedzialny za to, co dzieje się PO wysyłce? Jeśli odpowiedź brzmi “customer success” i nie rozmawiasz z nimi regularnie - masz lukę.
Czy rozumiesz kontekst operacyjny klienta? Nie jego wymagania z RFP. Jak naprawdę działa jego organizacja, kto faktycznie używa produktu, jakie ma ograniczenia.
5. Pułapka we wdrożeniu FDE
Na koniec, nie byłbym sobą, gdyby wrzucił niepopularnego gorącego kartofelka ;)
Większość firm, które teraz kopiują model FDE, zbuduje pustą pętlę.
Spójrz jeszcze raz na diagram ElevenLabs. Działa, bo po lewej stronie jest prawdziwy R&D - własne praca nad AI, własne badania, prawdziwy silnik który może przetworzyć feedback z wdrożeń. Dane zbierane przez FDE mają gdzie trafić.
ElevenLabs ma tę platformę. Palantir ma tę platformę. My w SentiOne też to mieliśmy - feedback z wdrożeń wracał do zespołu produktowego i R&D.
Firma która buduje tylko wrapper na GPT, nie pracuje aktywnie nad AI, nie wykonuje produktowej pracy i zbuduje zespół FDE… - co robi z tym feedbackiem? Prawdopodobnie nic. Będą mieli tylko prawą część pętlu.
“Copy the embedded-engineer part without the real platform underneath and you get a pile of bespoke deployments nobody can maintain.” - a16z
6. Podsumowanie
Można powiedzieć, ze FDE to kolejna modena nazwa na to samo. Trochę na pewno tak - tylko chodzi o to, żeby rzeczywiście pracować z mindsetem, ze klienci potrzebuję aktywnego wsparcia przy wdrożeniu Twojego produktu. Bo bez tego, każdy bardziej złożony produkt B2B będzie miał duże problemy.
Trzy rzeczy do zabrania z tego wydania 👇
✅ Shipped ≠ done. Twoja odpowiedzialność jako PM-a nie kończy się na release. Szczególnie jeśli budujesz produkt dla enterprise.
✅ Problem wdrożeniowy to Twój problem produktowy. Nie customer success, nie inżynierów. Twój - jak sprawić żeby ludzie realnie korzystali z tego co zbudowałeś.
✅ Zanim zaczniecie kopiować model FDE - sprawdź czy masz pętlę zwrotną. FDE bez silnika który przetworzy feedback to koszt bez wartości.
Mi ta koncepcja uświadomiła, że to co robiliśmy w SentiOne - to nie był przypadek.