W nowym odcinku Dodanego do Backlogu startujemy z nowym formatem -Refinementem, w którym zamiast backlogu zadań, refinementujemy nasze produktowe tematy, którymi aktualnie żyjemy w naszych organizacjach.
Na dzisiejszym refinemencie omawiamy:
Forward Deployed Engineer (i PM) - nowa rola czy stary wdrożeniowiec, co daje siedzenie u klienta, jak to wygląda w naszych firmach
Wpływ akwizycji na produkt - rola PMa przy “przejmowaniu produktu”, co robi z produktem szykowanie się do exitu, kiedy przejęcia się udają
Nasz stack AI - czego realnie używamy na co dzień i co udało się zautomatyzować
Zrobił nam się z tego fajny (publiczny) mastermind 👇
lub Apple Podcast.
Po więcej produktowych treści → sprawdź najnowsze wpisy, najpopularniejsze wśród czytelników, posłuchaj podcastu Dodane do Backlogu, albo skorzystaj z moich szkoleń.
Z odcinka dowiesz się:
(02:40) - Temat #1: Forward Deployed Engineer, a może też i PM. Skąd się wzięła ta rola i dlaczego nagle wszyscy jej szukają
(04:02) - Jak wygląda to od środka w Celonis, który konkuruje z Palantirem na europejskim rynku - i dlaczego mieli tę rolę wcześniej, tylko pod nazwą Value Engineer
(06:42) - Nowa rola czy nowa nazwa na starą funkcję? Czy dziesięć lat temu nie nazywaliśmy tego po prostu inżynierem wdrożeniowym
(10:26) - Moje doświadczenie jako forward deployed PM przy wdrożeniach automatyzacji obsługi klienta - i co się stało z pętlą zwrotną, kiedy firma rozdzieliła wdrożenia od produktu
(14:30) - Kuba rozszerza definicję: „forward” jako enablement, „deploy” jako zdejmowanie ograniczeń procesowych. Czy to w ogóle powinno być stanowisko, czy raczej zasada dla całej organizacji
(16:38) - Kiedy rola zmienia architekturę produktu - Celonis przestawia interfejs wdrożeniowy z UI na agenta, żeby demokratyzować tę rolę
(17:46) - Principal PM z Monachium, który przeszedł na applied AI engineer, bo uznał, że z roli produktowej nie dostanie się do OpenAI ani Anthropica
(18:42) - Pody zamiast stałych zespołów w Mixmaxie. Jak wygląda dowożenie funkcjonalności end to end, kiedy na podzie jesteś sam
(23:42) - Temat #2: Akwizycje i ich wpływ na produkt
(25:51) - Dlaczego w polskim scale-upie warto od pierwszego dnia wiedzieć, jaki jest twój exit - i jak rozwodniona spółka potrafi zabić gotową transakcję
(28:10) - Dwie akwizycje w Celonis okiem PM-a: udana i ta… druga, gdzie technologia się zgadzała, ale nie dało się zintegrować kultury
(32:28) - Founderzy na earn-oucie. Co się dzieje z produktem, kiedy człowiek, który go zbudował, ma przed sobą dwa lata do odbębnienia
(35:11) - Jak przygotowanie do exitu zmienia priorytety PM-a i jaki dług produktowy zostaje po kwartale ustawionym pod revenue
(37:00) - Druga strona modelu: co czuje produktowiec, którego obszar firma postanowiła kupić zamiast zbudować - i dlaczego sygnalizowanie takiej potrzeby to część roboty na poziomie principala
(40:42) - Temat #3: Nasze AI setupy.
(40:42) Kuba i Cursor z MCP wpiętym w bazę danych i Slacka
(43:18) - Marcin: firmowy Claude ze skillami do prototypów i ChatGPT do myślenia, bo lepiej trafia w jego sposób pracy
(44:27) - Poranna rutyna PMa: podsumowanie eksperymentów, health checki świeżych funkcji, trzydzieści tasków odpalanych jedną komendą. Plus produktowe repo jako „product OS”.
Moje najważniejsze insighty z rozmowy:
Rola potrafi zmienić architekturę produktu.
Najciekawszy fragment rozmowy z Marcinem - w Celonis Value Engineerzy stali się na tyle kluczowi, że firma zaczęła budować produkt pod nich - interfejsem wdrożeniowym przestało być UI, a stał się agent wpięty w funkcjonalności platformy.
Cel jest prosty - im mniej technicznych skilli potrzeba do wdrożenia, tym szybciej i taniej się je robi.
Nazwa roli FDE to nie tylko kosmetyka/marketing, ale też zestaw uprawnień.
Przez pół odcinka spieraliśmy się, czy Forward Deployed Engineer to cokolwiek nowego. Wniosek, do którego doszliśmy: mechanika jest znana od dekady, ale nowa nazwa niesie ze sobą coś, czego stary „inżynier wdrożeniowy" zwykle nie miał - mandat do zmiany produktu bez czekania na roadmapę.
Kuba ujął to najlepiej: „forward" znaczy, że ktoś jest “enabled” do zrobienia więcej, niż normalnie mógłby w swojej roli, a „deploy" to zdjęcie z niego wszystkich zaszłych procesów, przez które musiał konsultować każdą zmianę z trzema zespołami dookoła.
Pętla zwrotna w produkcie pogarsza się się proporcjonalnie do dystansu w organizacji.
W SentiOne mieliśmy bot designerów wewnątrz zespołu produktowego i to działało rewelacyjnie - informacja z wdrożenia wracała do nas w kilka dni. Potem, wraz ze skalą, zrobiliśmy naturalny rozdział na wdrożeniowców i produkt. Im dalej byli od zespołu, tym gorsza była ta pętla.
I nie chodziło o złą wolę, tylko o rozjeżdżające się cele: wdrożeniowcowi zależy na stuprocentowym sukcesie u jednego klienta, produktowcowi na produkcie dla wszystkich.
Nie mam gotowej odpowiedzi, gdzie wdrożeniowe role powinny być, ale mam pewność, że o lepszą pętlę zwrotną trzeba świadomie walczyć.
W akwizycji kupujesz zespół, nie kod.
Marcin przeszedł przez due diligence, integrację i post-integrację kilku przejęć i jego wniosek to… nawet przy udanej akwizycji większość rzeczy i tak przepisujecie od nowa.
To, co zostaje, to ludzie - jeśli potrafią wejść w nową organizacje - to zadziała. Jeśli founderzy siedzą na earn-oucie i negocjują jak najniższe cele, żeby po dwóch latach zniknąć, to będzie problem
Exit to decyzja produktowa, nie tylko finansowa.
Z polskiego scale-upa w 99% przypadków nie zrobisz sam globalnego unicorna. Wybór sposobu exitu jest kluczowy - budujesz pod przejęcie przez dużego gracza czy idziesz w stronę samodzielnego wzrostu - determinuje, na jakim problemie się skupiasz i ile inwestujesz w warstwę użytkową względem technicznej.
Byłem w spółce, gdzie technologia była świetna, kupujący realnie zainteresowani, a transakcja rozbiła się o strukturę właścicielską po zbyt wielu rundach.
