„Product engineer” brzmi jak nowa nazwa starego zawodu, ale różnica jest realna. Klasycznego inżyniera mierzy się produkcją: zamkniętymi zgłoszeniami i funkcjami dostarczonymi zgodnie ze specyfikacją. Product engineera — rezultatem: czy użytkownicy naprawdę wykonali działanie, czy zmienił się wskaźnik, czy firma otrzymała to, za co zapłaciła? Kod pozostaje ten sam; inne jest pytanie zadawane przed jego napisaniem.
W praktyce product engineer działa inaczej. Najpierw pyta „dlaczego?”, potem „jak?”: jaki problem rozwiązujemy, dla kogo i po czym poznamy, że się udało? Kwestionuje specyfikację, gdy prostsza wersja dostarczy tę samą wartość w jednej trzeciej czasu. Patrzy na całą ścieżkę użytkownika, w tym stany ładowania, błędu i pustej zawartości, a nie tylko na szczęśliwy scenariusz w makiecie. Po wdrożeniu analizuje dane, zgłoszenia do pomocy i nagrania sesji, nie tylko zielony status CI.
Rola wymaga szerokich kompetencji. Nie trzeba być najlepszym ekspertem od baz danych ani najlepszym projektantem, ale trzeba swobodnie poruszać się na całej ścieżce: model danych, API, UI, wdrożenie, analityka, a teraz także AI. Dlatego wielu inżynierów full-stack staje się product engineerami — gdy odpowiadasz za funkcję od początku do końca, nie ma komu przekazać pytania „dlaczego?”. U mnie prowadzi to od schematu Postgresa przez ekran Next.js do zdarzenia, które pokaże, czy ktoś skorzystał z funkcji.
Product engineer dostarcza małe zmiany i szybko się uczy. Pierwsza wersja to jedno mierzone działanie w produkcji, za feature flagą, a nie platforma uruchamiana za pół roku. Wie, gdzie można pójść na skróty (panel administracyjny może być brzydki, ręczny krok może pozostać ręczny przez miesiąc), a gdzie nie (płatności, uprawnienia, integralność danych). Ten osąd stanowi większość pracy i pojawia się dopiero wtedy, gdy ponosisz konsekwencje własnych decyzji.
To również rola komunikacyjna. Product engineer rozmawia z założycielami o ryzyku, kosztach i czasie, a nie o frameworkach. Z projektantami ustala, co jest drogie w realizacji, i proponuje tańsze rozwiązania. Rozmawia z użytkownikami, gdy tylko może. Zapisuje też decyzje — po sześciu miesiącach krótka notatka wyjaśniająca ich powód bywa cenniejsza niż sam kod.
Nazywam się product engineerem, bo właśnie ta część pracy najbardziej mnie obchodzi: nie pull request, lecz chwila, gdy prawdziwy człowiek korzysta z tego, co zbudowaliśmy, i wszystko działa. Dlatego wolę długofalową współpracę niż przekazanie projektu po dwóch tygodniach — nie da się odpowiadać za wynik, którego skutków nie można zobaczyć. Jeśli potrzebujesz inżyniera, który zada niewygodne pytania, a potem dostarczy odpowiedź, napisz do mnie.
Daj kolejnemu produktowi kogoś, kto zostanie.
Chcesz zacząć? Napisz do mnie — mogę rozpocząć od razu i zostać na dłużej. Długoterminowa współpraca, nie przekazanie projektu po dwóch tygodniach. Omówmy projekt, wymagania i najlepszy sposób realizacji.