Ilona Borsos jest Senior Product Manager w WP Engine. Poznaliśmy się na szkoleniu Tech Lead - była jedną z uczestniczek. Po wszystkim rozmawialiśmy kilka razy o pracy nad produktami cyfrowymi. Ten artykuł to część naszej dyskusji - Ilona postanowiła podzielić się swoim postrzeganiem roli Product Engineer.
Rozważania o tym, kim jest inżynier produktu i jak nim zostać dobrze byłoby zacząć od tego, czym właściwie jest ten "produkt" i w jakim kontekście osadza on pracujących nad nim inżynierów.
Czym jest produkt?
To, czym jest produkt, zależy od tego, z której strony na niego spojrzymy:
Z perspektywy funkcjonalnej - produkt to rozwiązanie, które klienci 'zatrudniają', aby wykonało za nich określoną pracę. Są skłonni zapłacić zarówno za efekt tej pracy, jak i za sposób, w jaki została wykonana.
Z perspektywy biznesowej - produkt to jednostka wymiany wartości między firmą, która go tworzy, a klientem, który go kupuje.
Z perspektywy systemowej - produkt jest interfejsem pomiędzy technologią a potrzebą rynkową.
Zmiana sposobu myślenia
Przejście od „zwykłego" inżyniera do inżyniera produktu zaczyna się więc od zmiany sposobu myślenia na takie, które stawia w centrum produkt, a nie technologię.
Dobrym pierwszym krokiem jest oswojenie się z samym pojęciem produktu i pamiętanie, że tworzone rozwiązania nie istnieją w próżni. Technologia wyraża się poprzez produkt - a ten z kolei musi rozwiązywać realne problemy klientów w taki sposób, aby chcieli za niego zapłacić. Jeśli to się uda, przynosi on także zysk biznesowi, dla którego pracujemy.
Doświadczenia z prawdziwymi inżynierami produktu
W ciągu pięciu lat kariery produktowej miałam okazję współpracować z kilkoma inżynierami, których - mimo że "na papierze" ich role nazywały się inaczej - spokojnie nazwałabym inżynierami produktu.
Porównując poziom "nastawienia produktowego" z poziomem seniority widzę między nimi delikatną korelację. Jest ona jednak na tyle słaba, że dołączając do nowego zespołu nie zakładam automatycznie, że z pewnością znajdę "swoich ludzi" wśród tych najstarszych rangą. Np. jeden z najlepszych inżynierów produktowych, z którym pracowałam, był stażystą w późniejszym czasie przemianowanym na juniora.
Stąd wniosek: nastawienie produktowe nie zależy od lat doświadczenia, ale od konkretnych umiejętności.
Kluczowe umiejętności
(Nieoficjalni) inżynierowie produktu, z którymi do tej pory pracowałam, charakteryzowali się kilkoma umiejętnościami, które wyróżniały ich na tle zespołu. Choć są to głównie kompetencje „miękkie" i trudne do uchwycenia, to nadal są to umiejętności, których można się nauczyć i które można ćwiczyć i je rozwijać.
A ja postaram się podsunąć Wam kilka pomysłów, jak to robić.
Zaangażowanie
To chyba najważniejsza z umiejętności „produktowca".
Jeśli miałabym wybierać między:
bardzo utalentowanym, ale zamkniętym na rozmowę inżynierem, a
„średnim", ale ciekawym, współpracującym i podsuwającym pomysły programistą, to
zawsze lepiej będę wspominać tego drugiego.
Tworzenie dobrej, realistycznej wizji produktu i opracowywanie jego wymagań to praca zespołowa. Owszem, product manager wyznacza kierunek i bierze odpowiedzialność za cały proces, ale nie powinien tworzyć go sam.
Aby zbudować coś wartościowego, konieczne jest wyjście z funkcyjnego silosu i bliska współpraca PMa, developera, designera, a często też innych ról, jak analityk danych czy SME (o czym od dawna pisze Teresa Torres, bogini product discovery).
Dzięki takiej współpracy można:
Wyłapać ukryte założenia dotyczące zachowań użytkowników
Sprawdzić wykonalność i używalność rozwiązania
Wspólnie zaprojektować flow
Znaleźć edge case'y
Stworzyć jasne przypadki testowe
Z mojego doświadczenia największym blokerem nie jest zwykle brak wiedzy - tylko to, że ktoś po prostu nie chce angażować się w taką eksploracyjną pracę, skupioną na rozmowie o sytuacjach klientów, zanim jeszcze przejdziemy do projektowania konkretnego rozwiązania.
Jak trenować zaangażowanie?
Dobra wiadomość jest taka, że „mięsień" zaangażowania da się stosunkowo łatwo wytrenować. Często wystarczy poszukać okazji, by wejść głębiej w jakiś temat.
W zespołach, z którymi pracuję, mamy zwyczaj wyznaczania „ownera" dla danej inicjatywy lub epika. Taki owner:
Dołącza do mnie i designera w rozmowach z użytkownikami
Uczestniczy w brainstormingach i sesjach projektowych
Pilnuje dyskusji technicznych w zespole
Dba o zaprojektowanie rozwiązania od strony technicznej
Rozwiązuje z PMem oraz designerem edge case'y, które przeszły przez sito początkowego designu
Polecam spróbować takiego podejścia - nam pomogło nie tylko w sprawniejszym dowożeniu, ale też w rozwoju inżynierów, którzy pełnili rolę „właścicieli" tematów.
A nawet jeśli u Was nie ma takiej formalnej roli, jestem przekonana, że wystarczy dać PMowi znać, że chcecie wejść głębiej w dany temat - jestem przekonana, że każdy PM chętnie wciągnie Was we wcześniejsze etapy projektowania.
Empatia
Empatia to umiejętność wczuwania się w perspektywę innych ludzi - rozumienia ich emocji, potrzeb i ograniczeń - oraz brania tego pod uwagę w swoim działaniu.
Mówiąc o empatii mam na myśli empatię:
Do użytkowników
Do biznesu
Do środowiska, w którym się znajdujemy (ze szczególnym naciskiem na inne role występujące w zespole)
Istnieje specjalne miejsce w produktowym piekle dla inżynierów i designerów, którzy ze sobą nie rozmawiają.
Produkty nie istnieją dla siebie
Produkty i ich funkcjonalności nie istnieją „dla siebie". Powstają po to, by rozwiązywać konkretne problemy konkretnych osób - w taki sposób, który jednocześnie przynosi firmie realne pieniądze.
Dystans między developerami a użytkownikami sprawia, że łatwo o decyzje pozornie dobre, ale w praktyce szkodliwe:
Drobne zmiany, które psują flow użytkowników.
Overengineering funkcjonalności, które zostałyby wykonane dużo prościej.
Brak empatii działa oczywiście w obie strony (w tym miejscu przepraszam wszystkich moich współpracowników za czekające w czeluściach backlogu taski na spłacenie długu technicznego) - stąd istotne jest, aby tę przepaść we wzajemnej empatii codziennie zmniejszać.
Jak budować empatię?
Najprościej: przez częstą wymianę informacji i gotowość do mówienia językiem drugiej strony.
Sama regularnie (= kilka razy w tygodniu) dzielę się z zespołem:
Przykładami z rozmów z użytkownikami
Ich cytatami
Problemami, z którymi się mierzą
W zamian proszę ich, by tłumaczyli mi tematy techniczne w prosty sposób. Aby to jakoś uściślić proszę ich, żeby mówili do mnie tak, jak gdybym właśnie zaczęła pierwszy rok studiów z informatyki :)
Celowo kładę nacisk na częstotliwość. Dużo lepiej budują wzajemną empatię krótkie, ale bardzo częste interakcje niż rzadkie, „strategiczne" sesje, o których szybko się zapomina. Komu z nas nie zdarzyło się przeczytać kiedyś strategii firmy tylko raz i od razu o niej zapomnieć - niech pierwszy rzuci kamieniem.
Regularne obcowanie z problemami użytkowników buduje intuicję:
Udział w wywiadach
Śledzenie cytatów z nagrań
Dzięki niej naturalnie zaczynamy „czuć", które pomysły mają szansę powodzenia.
Inicjatywa
Mało co cieszy mnie tak bardzo, jak wiadomość od kogoś z zespołu zaczynająca się od:
„Ilona, myślałem/am o tym przypadku, o którym rozmawialiśmy, i mam pomysł…".
Product engineer to dla mnie ktoś, kto potrafi zaangażowanie i empatię przekuć w konkretne propozycje, na które sama bym nie wpadła. A wtedy, pracując razem, możemy je wprowadzić w życie.
Inicjatywa przyjmuje różne formy:
Dokument z propozycją rozwiązania
Draft nowej funkcjonalności
Prosta makieta interakcji
Szybki proof of concept
Cokolwiek, co pomoże zespołowi i stakeholderom zrozumieć ideę rozwiązania i zaplanować, jak przetestować ją z użytkownikami.
Steve Jobs powiedział kiedyś, że
"doers are the major thinkers"
i miał rację. To właśnie budując produkt, developerzy dostrzegają możliwości, których osoby w rolach „spajających" (takich jak PM) często nie widzą.
Jestem przekonana, że najlepsze pomysły pochodzą od ludzi pracujących najbliżej technologii - to oni wiedzą, jak przekuć ją w coś, co naprawdę zainteresuje klientów. Moja rola polega w dużej mierze na tworzeniu środowiska sprzyjającego takiej innowacji:
Dzielenie się feedbackiem od klientów
Definiowanie i badanie metryk
Analiza konkurencji
Ustalanie jasnych priorytetów biznesowych
Facylitacja dyskusji
Podsumowanie
Myślę, że rozwój w kierunku produktowym to przede wszystkim zmiana nastawienia, niż zdobywanie twardej wiedzy. Tego nowego nastawienia można się nauczyć, tak każdej innej umiejętności - zaangażowanie, empatia i inicjatywa to „mięśnie", które można wytrenować poprzez konkretne nawyki w codziennej pracy.
Wierzę, że właśnie taki sposób działania pozwala budować lepsze produkty - a ostatecznie daje też większą satysfakcję zarówno inżynierom, jak i product managerom.
 | A guest post by
|