AMA z Marcinem Zarembą

Za nami pierwsze spotkanie w formule Ask-Me-Anything z Marcinem Zarembą, jednym z najlepszych polskich produktowców. Marcin to aktualnie Head of Product w DobryMechanik, wcześniej Chief Product Officer w Synerise oraz iTaxi, Head of Product w PizzaPortal.pl. Autor kursu on-line Warsztat Produktowca.

Z Marcinem rozmawialiśmy w formie wideokonferencji na żywo (Facebook Live) w niedzielę 29 marca o godzinie 21:00 na naszej grupie FB. Jeśli jeszcze Ciebie brakuje – dołącz do grupy 🙂 Możesz tam zadać męczące Cię pytanie lub wziąć udział w dyskusjach z innymi produktowcami.

Jeżeli nie udało Ci się wziąć udziału w naszym wydarzeniu, a chciałbyś je odsłuchać, mamy dla Ciebie dobrą informację – zostało nagrane!

Dodatkowo, poniżej znajdziecie aż 32 odpowiedzi Marcina, na pytania, które nie zdążyły zostać odpowiedziane w trakcie transmisji live. Pytania zostały pogrupowane w następujące kategorie:

Produkt w Polsce
Warsztat Produktowca
Praca
Porady

Przeczytaj koniecznie – odpowiedzi zawierają mnóstwo praktycznych rad i wskazówek dla produktowców.

Produkt w Polsce

1. W jednej z pierwszych lekcji kursu mówisz, że niezależnie co firma wytwarza, to produkt zawsze boryka się z tymi samymi problemami. Jakie są to problemy?

Każda organizacja składa się z ludzi. Ludzie muszą się ze sobą komunikować, aby być produktywnymi. Niemniej im więcej komunikacji tym więcej w niej szumu… więc więcej komunikacji, aby przez ten szum się przebić. Ten szum – niedokładność, niedecyzyjność, rozproszona odpowiedzialność – skupiają się na tym jak dobrze lub źle działa produkt.

2. Jak oceniasz kulturę produktowa w firmach w Polsce? Jakich kompetencji / umiejętności najbardziej brakuje polskim produktowcom?

Nie potrafię postawić tutaj wspólnego mianownika, nie mam danych, aby coś twierdzić.

3. Czy jest jakiś kierunek, w którym idzie produkt w naszym kraju?

Nie wiem, nie chcę wyrokować, nie mam danych.

4. Jakie są w Polsce firmy, które do product managementu podchodzą wzorowo i mają ludzi od których można dużo się nauczyć?

Jest ich dużo, znacznie więcej niż nam się wydaje, ale wymiana kilku byłaby niesprawiedliwością dla pominiętej reszty. Jeśli jest produkt technologiczny, który naprawdę lubisz i widzisz, że jest przemyślany to nie ma innej drogi: zrobił go dobrze poukładany zespół, któremu warto się przyglądać.

Warsztat Produktowca

5. Skąd się wziął pomysł na Warsztat Produktowca?

Z frustracji, że nie potrafię napisać drugiej książki.

6. Skąd taki pomysł na formułę – w każdy odcinku opowiadasz i rysujesz?

Zauważyłem, że dopiero jak coś narysuje to jestem w stanie to wytłumaczyć – działało na spotkaniach wewnętrznych, konsultacjach i konferencjach więc pomyślałem, że także zadziała tutaj. Taka forma daje większą „przepustowość” i stymuluje lepiej mózg. Bezpośrednią inspiracją była natomiast prezentacja Jeffa Pattona podczas Product Campu 2019 w Gdyni (tutaj nagranie tego samego ale z innej konferencji).

7. Czy przeprowadzałeś jakieś testy/eksperymenty przed uruchomieniem kursu?

Tak, wypuściłem pierwszy fatalny odcinek od razu online, żeby zobaczyć jak ludzie zareagują. To mi pomogło zrozumieć jak bardzo technicznie nie jestem przygotowany.

8. Czy Warsztat Produktowca ma już zamknięty format? Czy planujesz jakieś aktualizację/rozszerzanie formuły?

Pierwotnie zakładałem, że format będzie całkowicie otwarty i będę dodawał następne odcinki w równych odstępach czasu. Jednak po 45 lekcjach poczułem, że musiałbym nagrywać na siłę, zmuszając się do zaangażowania. W takim wypadku wolę prokrastynować.

Natomiast… nagrywam dodatek strategiczny – krótszy, ale o znacznie innej perspektywie. Dla osób, które podstawowe narzędzia mają w małym palcu i zauważyły, że produkt to nie wszystko.

9. Czy planujesz wydanie kolejnej książki?

Na razie mi się nie chce.

Praca

10. Co zrobić na początku nowej pracy jako Product Owner? 

Źródło: Warsztat Produktowca

11. Zaczynając pracę w nowym miejscu – jak układasz sobie Zespół? Jak wygląda taki „wymarzony” Team?

Wszystko zależy od kontekstu biznesowego i produktowego. Gdybym budował zespół od zera to wydaje mi się, że idealny format to jeden zespół odpowiedzialny za rozwój produktu i jeden zespół odpowiedzialny za monetyzację, bo ostatecznie to są dwie ścierające się w produkcie siły. Mam poczucie, że na tarciu motywacji tych dwóch zespołów powstają najciekawsze rzeczy.

Każdy zespół powinien być maksymalnie samodzielny – w rozumieniu być w stanie przeprowadzić i wdrożyć funkcję z minimalną pomocą osób spoza niego. To oznacza, że taki zespół powinien mieć product managera, programistę frontendowego, programistę backendowego, mieć blisko siebie UXa, grafika i analityka. Te role mogą być współdzielone, ale dla mnie ważne jest żeby zespół był mały. Im większy zespół, tym szybciej traci swój wewnętrzny „sens”.

12. Z kim w pracy spędzasz najwięcej czasu / najwięcej współpracujesz?

Ciężko mi ocenić, bo z każdym, kto wnosi coś do produktu. Na bieżąco, codziennie z zespołem, raz na jakiś czas mam tematyczne spotkania z działami sprzedaży, marketingu, obsługi klienta. Raz w tygodniu mamy management meeting, aby także zrozumieć trajektorię całego biznesu.

13. W jednym z odcinków kursu mówisz o etapie ZBIERANIA, gdy zapisujesz sobie wszystkie zasłyszane pomysły. Czy da się nad tym zapanować w jakikolwiek sposób? Pomysły i zgłoszenia przychodzą zewsząd.

Jest to kłopotliwe. Na samym początku pracy (pierwsze miesiące) zawsze staram się być otwarty na wszystkie możliwe pomysły, aż do momentu „bankructwa” – gdy nie mam już czasu, ani przestrzeni w głowie na więcej. Wtedy jest czas na wyszukiwanie podobieństw w pomysłach (np. dwie osoby z różnych działów mają taki sam pomysł, ale z dwóch perspektyw – to super ciekawy trop!) i pogłębiania najciekawszych z nich.
Na pewnym etapie jednak poczucie tego bankructwa jest ciągłe.

Mam na to sposób, ale nie polecam go innym: po prostu ignoruje pierwsze zapytania, które do mnie przychodzą. Jeśli ktoś odezwie się po raz drugi, to znaczy, że faktycznie mu zależy.

14. Co w przypadku, gdy ktoś z Organizacji nie zgadza się ze stanem faktycznym? Na przykład ktoś z Zespołu Deweloperskiego nie zgadza się z budową danej funkcjonalności bądź ktoś wysoko postawiony ma inne zdanie dotyczące wizji?

Nie istnieje coś takiego jak stan faktyczny, zarządzanie opiera się na opiniach. Każdy ma swoją perspektywę do której dołączone są jego interpretacje, motywacje, emocje. Zrozumienie ich pozwala na zrozumienie faktycznego celu, który chce osiągnąć osobą z odmiennym zdaniem. Warto to odkryć, żeby zrozumieć czego sami nie widzimy.
Jeśli jednak nie ma na to czasu, albo brakuje energii na kopanie się z koniem to trzeba zadać pytanie: kto ponosi odpowiedzialność. Ta osoba powinna decydować. Jeśli odpowiedzialność jest rozparowana z decyzyjnością to coś bardzo jest nie tak w organizacji.

15. Otrzymujesz trzy zgłoszenia z zupełnie innej bajki: fix UXowy, mały projekt optymalizujący konwersję, poprawka SEO. Każdy o podobnej czasochłonności. Jak radzić sobie z priorytetyzacją elementów, których output finansowy to raczej zgadywanie.

Każdy output finansowy ficzera to zgadywanie. Zapytałbym się najpierw jakie wartości produktowe nas interesują: czy na tym etapie rozwoju bardziej nam zależy na łatwości korzystania, monetyzacji, łatwości znalezienia? A może zaangażowaniu, wiralowości, średniej wielkości koszyka? Lub awaryjności, skalowalności, automatyzacji? Zadania które w oczach zespołu i produktowca wniosą najwięcej do największej liczby wartości powinny być robione pierwsze.

16. Co sądzisz o sytuacji, gdy zespół rozwija więcej niż jeden duży produkt. Jeśli miałeś takie doświadczenie – jak to wpływało na pracę, jak sobie z tym radziłeś?

Jak się jest startupem to nie ma innego wyjścia. Natomiast im większa organizacja tym szybciej trzeba się specjalizować i skupiać na jednym produkcie per zespół. Inaczej nastąpi rozdwojenie jaźni, walka o zasoby i coraz większy kognitywny koszt context switchingu.

17. Jeden zespół wytwórczy pracujący w Scrumie. Trzy produkty, trzech product ownerów. Jeden backlog. Priorytety na backlogu ustalane drogą konsensusu między product ownerami. Norma czy patologia?

Jeden produkt, jeden zespół, jeden backlog. Jeszcze nie widziałem przypadku, aby w dłuższym okresie ustabilizowała się inna wariacja tak, aby dawała wysokie velocity.

18. Jak radzić sobie gdy dwaj PO wchodzą sobie w drogę? Na przykład funkcjonalność jednego PO nachodzi na pracę drugiego PO?

To jest pożądane i musi się zdarzać. Inaczej ich prace byłyby zbyt odizolowane, co nie jest dobre pracując na dwóch obszarach tego samego produktu (lub dwóch synergicznych produktach). Tych dwóch PO musi dojść do porozumienia operując na poziomie wartości produktowych wiedząc, że gra w którą grają jest bardzo długa, a krótkookresowe zyski kosztem drugiej strony odbiją się negatywnie na całej firmie.

19. Jak radzić sobie z ewentualnymi problemami z integracją kodów dwóch Zespołów Technologicznych?

To pytanie do CTO lub architekta systemowego.

Iloma zespołami na raz zarządzałeś i kiedy Twoim zdaniem to jest maksimum?

Maksymalnie byłem w stanie zarządzać 2.5 zespołami (a więc 2.5 produktami). Im jestem starszy tym wydaje mi się, że mniej jest lepiej.

20. Kanban vs SCRUM – kiedy wykorzystywać dany framework?

Każdemu według potrzeb 🙂 Jak wole Scrum bo buduje mi dobre taktowanie przez powtarzalność rutyn. Kanban jest bardziej płynny, ale w związku z tym bardziej (dla mnie) stresujący.

21. W business case’ach które można znaleźć na Twoim blogu, przedstawiasz głównie prace związane z rozwojem platform? Co z utrzymaniem i bieżącą obsługą business as usual? Czy w organizacji, jeżeli zdecydujemy się na taki podział, takie zespoły powinny działać rozłącznie?

Nie, uważam, że zespół, który tworzy, to zespół który utrzymuje bo wtedy bierze odpowiedzialność za swoją pracę. To jednak jest też funkcja wielkości organizacji (im większa tym większa specjalizacja zespołów).

22. W jaki sposób najlepiej rozkładać pracę zespołów frontendu i backendu? Zdarza się u nas czasem, że frontend oczekuje na api i nie może ruszyć z kolejnymi zadaniami, więc zbieramy zadania z niższych części backlogu. Jest to jednak trochę na siłę. Ostatnio frontend zaczął więc developowac na mockach API i podłączamy się jak backend jest gotowy. Myślę, że jednak można to robić lepiej. Czy zetknąłeś się z tym w swojej karierze? Co byś doradził?

Diabeł tkwi w szczegółach. Uogólniając taktowanie pracy frontendu i backendu jest inne. Pierwsze jest szybsze i szybciej widać inkrementalną różnicę. Drugie ma więcej zależności, dzieje się wolniej, ale wpływ na biznes jest większy. Wniosek jest jednak taki, że ciężko jest zsynchronizować ich pracę. Najlepszą metodą jaką na to znalazłem to przybliżanie do siebie tych światów udrażniając ich komunikację. Jeśli frontend i backend pracuje w jednym zespole to wtedy szansa na to jest największa.

23. Czy zdarzyło Ci się, że kryterium akceptacji zdania, mimo, że wg Ciebie dobrze opisane i zrozumiane przez dewelopera, pod koniec prac okazało się niewystarczające (zadanie nie spełnia naszych wyobrażeń)? Jak temu zapobiegać?

Rzadko się zdarzyło inaczej! Wracamy do mojej pierwszej odpowiedzi. Problemem zawsze jest komunikacja. Co innego myślimy, coś innego komunikujemy, przez nieprecyzyjność języka druga strona widzi jeszcze coś innego i dodatkowo filtruje to przez swój kontekst i doświadczenie. Dopóki nie będziemy w stanie czytać sobie w myślach musimy się pogodzić, że ciągłe nieporozumienia będą naszą rzeczywistością.

Ale jak ktoś się z tym pogodzi to może zacząć budować metody ograniczenia negatywnego wpływu nieporozumień – Scrum z jego daily standupami czy Agile deprecjonujący spisaną dokumentację są tutaj najlepszymi przykładami.

24. Czy masz jakieś dobre praktyki na przechowywanie dokumentacji?

Nie mam. Nie fetyszyzuje dokumentacji, bo jedyna, która jest wierna produktowi to ta, która powstaje po stworzeniu produktu

25. Czy sam tworzysz tickety/historie, opisujesz dokumentację nawet podstawową? Jeśli nie, to kto zazwyczaj wykonuje tą pracę?

Tak, bo tylko tak mogę być blisko produktu za który odpowiadam. Przekazuje ten obowiązek innym osobom, ale tylko wtedy, kiedy mam do nich absolutnie najwyższe zaufanie.

26. Jak podszedłbyś do redesignu (wizualnego i nawigacyjnego) aplikacji?

Najpierw upewniłbym się, że redesign jest potrzebny a nie wynika tylko z ego redesignującego.

Jeśli jest potrzebny to zacząłbym od zdefiniowania jednej jedynej najważniejszej ścieżki użytkownika i zrobił tzw. Happy Path – hipotetyczny scenariusz, w którym wszystko jest najprostsze i zawsze się udaje.

Następnie obudowałbym ten scenariusz nawigacją wzmacniającą prawdopodobieństwo przejścia przez Happy Path oraz wymaganiami technologicznymi i biznesowymi.

27. Jakie wymieniłbyś najważniejsze wnioski z rozwijania produktu dla klientów enterprise?

Jeśli masz mało dużych klientów, to oni są właścicielami Twojego backlogu. Lepiej mieć dużo małych klientów, bo wtedy jest większe pole do eksperymentów.

28. Na jakie metryki produktowe zwracałeś największą uwagę w każdym z produktów, za które byłeś odpowiedzialny?

Najważniejsze: relacja między CAC a CLTV. Czyli ile kosztuje nas pozyskanie jednego klienta w relacji do tego ile ten klient w ciągu całej relacji z produktem u nas zostawi pieniędzy.

Wszystkie inne metryki z tego wynikają: Liczba zamówień w tygodniu, średnia konwersja w tygodniu, czas/liczba kroków potrzebnych do konwersji. Wielkość koszyka, Powracalność, Kohorty 3M.

W zależności od biznesu było jeszcze sporo kompozytowych metryk.

29. W jaki sposób zachęcasz klientów do wywiadów pogłębionych? Jak podchodzisz do potencjalnych użytkowników, którzy jeszcze nie są klientami? Ciekawi mnie co ich przekonuje do poświęcenia np. 45 minut

W większości przypadków ludzie po prostu lubią mówić o swoich doświadczeniach. Nie lubię im mówić, że będziemy robić Badania przez duże B, nie chcę obiecywać nagród za poświęcony czas, ani zwabiać ich pieniędzmi. To powoduje zakrzywienie wyników.
Lubię zapraszać ludzi na kawę, na rozmowę o tym co ich boli, co im przeszkadza w robieniu X, albo korzystaniu z Y. Zazwyczaj nawet nie nagrywam naszych rozmów.

Porady

30. Jakie były Twoje początki? Z jakimi umiejętnościami zaczynałeś karierę produktowca?

Z zerowymi. Uczyłem się wszystkiego w biegu licząc na wyrozumiałość moich szefów. Miałem szczęście trafić na falę wznoszącą mobile’a, która u mnie poniosła, więc jedyny atut jaki miałem to głęboka fascynacja smartfonami i aplikacjami mobilnymi.

31. Skąd czerpiesz swoją wiedzę? Jakie blogi i ludzi warto śledzić? Skąd dowiadujesz się „co w trawie piszczy”?

W sumie to nikogo nie śledzę i nie mam pojęcia co jest teraz modne. Strata czasu.

32. Jakie rady mógłbyś dać początkującym, jak i bardziej zaawansowanym produktowcom? Co robić, by stale się rozwijać?

Czytać dobre papierowe książki.

33. Czy coś ciekawego ostatnio czytałeś? W którym kierunku zmierzają aktualnie Twoje zainteresowania?

Tutaj jest mój Goodreads. W kontekście zarządzania produktami to nic ciekawego do tej pory nie przykuło mojej uwagi.