📣 PRODUKTOWE ROZMOWY: WYWIAD Z PIOTREM CYGANEM (część 1)

Product Manager z kilkuletnim doświadczeniem w SaaSowych startupach i scaleupach. Skupiony przede wszystkim na discovery i walidacji jako najkrótszej drodze do tworzenia produktów, które przynoszą wartość użytkownikom. Aktualnie pracuje w Tidio, narzędziu do zarządzania komunikacją z klientami w e-commerce. Prywatnie digital nomad, choć podróżuje przede wszystkim w Europie – na przestrzeni ostatniego roku mieszkał w 7 krajach.

Grzesiek: Cześć Piotrek, dzięki, że zgodziłeś się porozmawiać w ramach produktowych rozmów w Product Art. Powiedz mi kim jesteś?

Piotr:  Cześć Grzesiek, Obecnie jestem Product Managerem w Tidio, gdzie oferujemy produkt do komunikacji z klientami w e-commerce.  W skład naszego portfolio wchodzi livechat, chatboty i system ticketowy.

Ja odpowiadam właśnie za system ticketowy. Jest to produkt stosunkowo nowy, który dopiero wypuszczamy na rynek, więc moja praca związana jest z obszarem discovery, która już za niedługo zakończy się wypuszczeniem pierwszej wersji do publicznej przestrzeni.

Grzesiek: A jak wyglądała Twoja droga zanim zostałeś PMem w TIDIO?

Piotr:  Jestem już Product Managerem 5 lat czyli można powiedzieć, że 20% mojego życia.

Zacząłem pracować już na początku moich studiów. Miałem próby założenia dwóch startupów, które dość szybko upadały bo w przeciągu kilku miesięcy. Jeśli chodzi już o takie “komercyjne” doświadczenie to zacząłem od roli Customer Success Manager’a w Survicate.

Wtedy w firmie od strony produktu była jedna osoba – Head of Product. Współpracowaliśmy bardzo blisko, bo w sumie tego wymaga się od dobrego CSM – zaangażowania w produkt. Dostarczałem i organizowałem feedback od klientów. Następnie otrzymałem propozycję awansu do roli Product Managera.

Uważam, że jest to jedna z najlepszych ścieżkę przejścia do roli produktowej w SaaS (ale oczywiście nie jedyna), bo jako PM’s szczególnie potrzebujemy mieć dużo kontaktu z klientami. Dodatkowo musimy rozumieć problemy klientów, a mało jest osób w firmie, które tak blisko współpracują z klientami jak CSM.

Następnie pracowałem ponad rok w startupie Prowly, który oferuje produkt do zarządzania PR’em. Od grudnia 2021 roku jestem Product Managerem w Tidio.

Grzesiek: Ok, to opowiedz w takim razie jak wygląda Twoja praca w roli Product Managera w TIDIO?

Piotr: Moim zadaniem jest maksymalizowanie wartości oferowanej w produkcie dla naszych klientów. Z developerami pracuje bardziej w formie coacingu, inspiracji i dzielenia się z nimi wizją i strategią produktową bo wychodzę z założenia, że jesli oni będa mieli to zrozumienie to ja tak naprawdę nie jestem potrzebny do zarządzania produktem day to day. Mamy świetnych developerów, którzy nie tylko są bardzo dobrzy technicznie, ale też komunikacyjnie. Dodatkowo mogę powiedzieć, że znają klientów i są bardzo często w stanie podjąć proste decyzje produktowe. Ja w tym czasie mogę zająć się obszarem discovery i walidacją.

Walidacja jest dla mnie bardzo ważna bo jako Product Manager chcę uniknąć robienia rzeczy, które nie mają dla nas sensu (np. dla jednego lub dwóch klientów). Wykorzystujemy cały wachlarz technik walidacyjnych np. Concierge MVP, dry wallety, fake doory, itd itd.  Tak naprawdę korzystamy ze wszystkiego, co pozwala nam upewnić się, że to, co robimy ma sens i będzie używane przez użytkowników naszego produktu.

Grzesiek: Możesz pogłębić temat współpracy z zespołem developerskim?

Piotr: Oczywiście, warto dodać, że to nie wygląda w taki sposób, że ja nie mam z nimi kontaktu poza “sprzedawaniem” wizji i strategii produktowej.

Wspólnie ustalamy priorytety, przychodzę i uczestniczę w Daily SU, mamy wspólne refinementy oraz planningi. Jest duża różnica między współpracą z zespołem developerskim obecnie vs to co doświadczyłem wcześniej, gdzie dostawałem pytania praktycznie o wszystko – nawet najmniejszą, podstawową zmianę.

Obecnie staram się dzielić z nimi feedbackiem od klientów, po to, aby zrozumieli czego oczekują od nas klienci.

Przychodzę do developerów z tzw. złamanym story:

“Jest tyle i tyle klientów, którzy mają takie potrzeby i nie mogą ich zrealizować”

Ja zajmuje się problemem, a po stronie developerów jest przedstawienie np. trzech rozwiązań, po czym bardzo często wracam do klientów, aby zwalidować zaproponowane rozwiązania. Sprawdzam czy propozycja rozwiązuje ich problem i dostarcza im wartość. Jeśli tak, to idziemy w tym kierunku i developerzy są bardzo mocno zaangażowani w proces planowania featerów. W Tidio planujemy kwartalnie, a więc ustalamy backlog (z dość dużym buforem i przestrzenią na to, że coś może się zmienić) jeszcze zanim zacznie się kwartał.

Grzesiek: Z kim jeszcze współpracujesz?

Piotr: Struktura w Tidio jest dość płaska bo między mną, a CEO, jest tylko CPO.

Oczywiście mamy dział marketingu, customer support, customer experience i dopiero budujemy zespół sprzedażowy. Do tej pory klientów pozyskaliśmy za pomocą konwersji oraz inbound’u. Customer support wspiera naszych klientów, a customer experience ich onboarduje. Jest dla nas bardzo ważne, aby klienci wiedzieli już na początku, o co chodzi w naszym produkcie. Osoby z działu Customer Success są mocno zaangażowane w zbieranie feedbacku i kategoryzowanie go.

Chcemy podejmować dobre decyzje, a dostęp do dobrze przygotowanych danych, pozwala nam zmniejszyć ryzyko błędów.

Regularnie spotykam się z headem sprzedaży, który mówi mi o dealach, które straciliśmy oraz dlaczego je straciliśmy. Zastanawiamy się wspólnie jak zwiększyć konwersję w naszym lejku sprzedażowym i jak możemy pomagać jeszcze lepiej rozwiązać problemy naszych klientów.

Grzesiek: Na jakim poziomie produktu pracujesz?

Piotr: Jako Product People jesteśmy w Tidio zaangażowani w strategię produktową, która kontrybuuje do strategii firmy. Następnie dekomponujemy wizję i strategię produktową na nasze mniejsze produkty.To my przychodzimy z pomysłami i wizją, a nasz CPO wspiera nas przy podejmowaniu różnych decyzji poprzez konsultacje.

Grzesiek: Macie jakiś backlog zweryfikowanych pomysłów, które chcecie spróbować dostarczyć?

Piotr: Rozmawiając regularnie z klientami, wysłuchujesz ich opinii i pomysłów na nowe funkcjonalności. Twoim zadaniem jest zastanowienie się jak dużo ludzi skorzystałoby z tej właśnie rzeczy, którą proponuje klient X, czy Y.  Często robimy eksperymenty na zasadzie Fake Door – pokazujemy jakąś wartość i mówimy klientom “hej, jak chcesz się zintegrować z tym narzędziem to kliknij tutaj”, a potem informujemy, że jeszcze muszą trochę poczekać, zanim zbudujemy daną funkcjonalność. Korzystamy też z wielu innych technik, które pozwolą nam oszacować wartość danych funkcjonalności albo jak bardzo problem jest bolesny dla klientów. Wszystko mierzymy oczywiście w Amplitude bo pozwala nam to zobaczyć na jakim etapie “podróży” odpadają użytkownicy.

To wszystko powyżej dotyczy walidacji na poziomie potrzeby, ale mamy też walidację na poziomie rozwiązania.

Dla przykładu. Wiemy, że w produkcie będzie potrzebna analityka, ale nie wiemy do końca jeszcze jaka, więc pozwalamy naszym klientom stworzyć raporty mailowe z informacjami, o które pytają. Te wszystkie raporty, które otrzymują to jest moja manualna praca i wyciąganie danych z systemu. Wysyłając wygenerowany raport dopytuję, czy to rozwiązanie jest dopasowane do problemu, który klient chce rozwiązać i co możemy zrobić, żeby wyciągnęli z tej analityki jak największą wartość.

Czasami łatwiej jest wypuścić MVP i zadecydować co zadziałało, a co nie – jest to najbardziej kosztowne rozwiązanie, bo wymaga dużej inwestycji developmentu.

W przypadku nowego produktu (takim jak mój), staramy się pracować tylko nad zweryfikowanymi pomysłami bo (szczególnie na początku) tych hipotez jest ogrom!!! Wybieramy zawsze taką ścieżkę, która testuje tą najbardziej ryzykowną tezę.

Grzesiek: Pracujecie na jakichś metrykach?

Piotr: Nasz CEO ma konkretne metryki za które jest odpowiedzialny, następnie schodzimy w dół i np. nasz CPO ma swoje metryki, które kontrybuują do metryk firmowych. Następnie my kontrybuujemy w naszych produktowych zespołach do tego, co jest wyżej – tworzy się takie drzewko.

Nie mamy w firmie OKRów, ale pracujemy na tzw. OITach, czyli Objective, Indicator, Task.

Objective to jest opisanie wizji i strategii produktu, później mamy Indicator, czyli liczbę, którą chcemy osiągnąć w pełnej zgodzie z wizją i strategią. Mamy też Task czyli to co chcemy zrobić, żeby dojść do tego miejsca. Dzięki temu mamy połączenie między wizją, strategią a backlogiem.

Kiedy zastanawiamy się nad jakim ficzerem mamy się właśnie skupić to zawsze wracamy do metryki i do celu i zadajemy pytanie, czy ta funkcjonalność przybliży nas do osiągnięcia naszego celu i metryki. Jeśli mamy zgodność, że tak jest to idziemy w tym kierunku – w przeciwnym razie porzucamy pomysł na rzecz innego, bo backlog idei jest zawsze nieskończenie duży.

Grzesiek: W jakiej metodologii pracujecie?

Piotr: U nas każdy Product Manager działa inaczej – nie mamy zasetupowanych żadnych product ops, bo nasze zespoły są różne, każdy z nas jest zupełnie innym Product Managerem i pracujemy zupełnie inaczej. W moim zespole pracujemy w SCRUMIE, ale z tego co kojarze to Przemek pracuje w SHAPE UP.

U mnie w zespole skupiamy się na znalezieniu dopasowania do reszty klientów, dla których ten produkt jeszcze nie jest dostępny publicznie. Staramy się przygotować odpowiednią ilość ficzerów, które będziemy chcieli dostarczyć w kolejnym kwartale i wycisnąć na maxa czas podczas pracy w danym kwartale. Żeby była jasność, nie chodzi tutaj o ciśnięcie developerów, ale o to żeby zaplanować pracę nad tym co jest najbardziej wartościowe dla naszych klientów w danym czasie.

Grzesiek: Co robi zespół developerski podczas fazy discovery?

Piotr: Działamy podobnie jak w Dual Track Agile. Mamy 3 refinementy podczas jednego sprintu, które trwają po 1h. Zazwyczaj jeden z nich jest bardzo operacyjny, a pozostałe to skupienie się na wizji i na długim terminie.

Chcę wiedzieć, co się dzieje w zespole deweloperskim, żebym był w stanie przewidzieć to, kiedy będziemy w stanie wejść na produkcję lub zająć się kolejnymi problemami. Z drugiej strony chcę, aby oni wiedzieli dokładnie, o czym ja myślę, bo im bardziej oni będą w mojej głowie, tym lepsze rozwiązania mogą dostarczać tym myśleniem o przyszłości.

Developerzy nie są często w stanie uczestniczyć w procesie discovery, ale ja jestem dla nich proxy osobą, która jest w stanie odpowiedzieć na ich pytania lub je dalej przekierować.

Przykład.

Developerzy pytają mnie czy jeśli dostarczymy 10% danego rozwiązania i będzie to działać w taki sposób (tutaj opisują proces) to czy klient będzie zadowolony.

Dzięki takim rozmowom jesteśmy w stanie znaleźć złoty środek pomiędzy effortem, a impactem, który jestesmy w stanie dostarczyć. Wcześniej wyglądało to w taki sposób, że przychodziłem do zespołu developerskiego z zakresem co należy zrobić – nie było to najlepsze podejście. Teraz staramy się wspólnie zrozumieć co możemy zrobić, aby osiągnąć dany cel, a zespół developerski był wykorzystany w najlepszy możliwy sposób.

Ja w tym procesie jestem taką piłeczką ping pongową między klientami, a developerami – to jest proces, który trwa.

Jeśli zaczynamy kolejny kwartał w październiku to faza discovery zadziała się już w sierpniu. W sierpniu pojawił się już pierwszy zarys rzeczy, na których będziemy skupiać się w przyszłym kwartale. Specjalnie nie nazywam tego zestawem ficzerów, a zestawem problemów, które chcielibyśmy rozwiązać w kolejnym kwartale. Często developerzy spotykają się sami i analizują co mogą zrobić, aby dostarczyć najlepsze rozwiązanie, a później dostarczają analizy.

Mówią:

“Możemy zrobić rzecz X w ciągu 2-3 dni, ale to będzie słabe dla klientów, możemy zrobić zakres rzeczy Y w przeciągu 1-2 sprintów lub dostarczyć idealne rozwiązanie, ale będzie to trwać tyle i tyle”.

Wtedy wspólnie siadamy i podejmujemy decyzję na podstawie naszej definicji jakości – tylko po to żebyśmy byli w stanie powiedzieć, że to jest dobry i wartościowy produkt dla naszych klientów.

Zawsze zostawiamy sobie taką przestrzeń niepewności, co oznacza, że nie chcemy tworzyć idealnej specyfikacji. Oczywiście jest też czas na pisanie kodu i tworzenie rozwiązań, ale nie mamy jakiegoś podziału 80/20 czy 50/50 – ten podział jest w miarę płynny i zależy od momentu w którym obecnie jesteśmy.

Czasami jest tak, że wiemy już, że ich nie dowieziemy i prowadzimy negocjacje ze stakeholderami. Są też sytuacje, że sami obcinamy scope bo wiemy, że pewne rzeczy nie są potrzebne. Mamy w zespole Data Analysta i UX Researchera, którzy dostarczają nam dodatkowych informacji, aby potwierdzić nasze przypuszczenia.

Grzesiek: Poprzednią część skończyliśmy, gdy zacząłeś opowiadać o współpracy z Data Analystem oraz UX Researcherem. Możesz rozwinąć ten temat?

Piotr: UX Researcherka zajmuje się dwiema rzeczami. Pierwsza to praca z zespołem albo zespołami, a druga to jest bardziej praca strategiczna.

Część strategiczna zawiera pytania, które chcemy sobie zadać w obszarze produktu np. jak chcemy go rozwijać i w którym kierunku podążać. Wiąże się ona z dużą ilością rozmów z klientami.

Część, która dotyczy pracy z zespołami  (mamy przypisane UX Researcherki na half time do zespołu) wiąże się trochę bardziej z obszarem konsultingowym.

Przykład.

Przychodzę do Asi i pytam:

“Hej, widzę  problem X, chciałbym go zbadać i odpowiedzieć sobie na jakiś zestaw pytań z którym przychodzę”

UX Researcherka sugeruje mi sposób w jaki mógłbym na te pytania odpowiedzieć. Często przygotowuje scenariusz wywiadu, albo listę pytań, które spełniają podstawowe kryteria badawcze.

Podczas wywiadów wspiera mnie Designerka (nie Resercherka), która pomaga mi ustawiać User Testy (korzystamy z user testingu jako narzędzia do discovery lub weryfikacji hipotez) .

Po rozmowie wszystko dostarczam do UX Researcherki. To właśnie ona wspiera mnie  w procesie syntezy informacji, które zebraliśmy podczas rozmów z klientami.

Podsumowując UX Resercherka jest ze mną na początku i na końcu drogi, a w środkowym etapie jestem wspólnie z Designerką (lub sam).

Jeśli chodzi o  współpracę z Judytą, która jest Data Analytską to tutaj głównie skupiamy się na liczbach i metrykach. Judyta dostarcza mi zestaw metryk i danych, na które będziemy patrzeć oraz odpowiada na pytania, które zadajemy sobie podczas budowania naszego produktu np. Jacy klienci byli zainteresowani konkretnym fake doorem? Bywa też, że mamy jakiś problem, ale nie jesteśmy w stanie uświadomić sobie jego skali i tylko spojrzenie głęboko w dane jest w stanie nam coś podpowiedzieć.

Zazwyczaj proszę nie o dane, ale gotową odpowiedź w oparciu o liczby, które posiadamy. Czasami musimy zrobić kilka deep dive’ów, aby dowiedzieć się czy dobrze interpretujemy nasze dane – po prostu zadajemy coraz więcej pytań, które doprecyzowują pytanie, na którą chcemy poznać odpowiedź.

Współpracując z Judytą oraz Asią jestem w 100% pewny, że mogę polegać na ich wnioskach bo mają dużą większą wiedzę w swoich domenach niż ja.

Grzesiek: Mógłbyś opowiedzieć coś o narzędziu User Testing?

Piotr: User Testing to narzędzie, które służy do testowania prototypów i makiet. Pozwala nam dowiedzieć się czy ludzie rozumieją zaprojektowane interfejsy.Z ciekawszych badań, które robimy za pomocą user testing to badania card sortingowe, które pomagają nam zrozumieć architekturę informacji. Chodzi o to, aby content, który prezentujemy w produkcie był zrozumiały przez klientów.

User testing działa w taki sposób, że zadajmy konkretny zestaw pytań i przedstawiamy scenariusz, który jest zaprogramowany. Następnie ludzie z całego świata mogą wejść do narzędzia user testing i wykonują konkretny zestaw działań. W kolejnym kroku zadajemy listę pytań otwartych. W zależności jakie informacje otrzymujemy – dowiadujemy się czy jesteśmy usatysfakcjonowani z wyników, czy chcemy coś jeszcze zmieniać.

Warto pamiętać, że nie zawsze trafi się w swoją guropę docelowa więc trzeba brać poprawkę na wyniki tych badań, ale jest to narzędzie, które zdecydowanie ułatwia nam pracę i pozwala zbierać insighty w bardzo szybkim czasie bez skupiania się na rekrutacji osób do badań.

Grzesiek: Jak komunikujecie, gdy nie jesteście w stanie “dowieźć” rzeczy, które wcześniej ustaliliście?

Piotr: Raczej unikamy commitmentu dla klientów zewnętrznych. Czasami robimy to dla naszych wewnętrznych stakeholderów – oni wiedzą co będziemy robić w danym kwartale. Nasza roadmapa nie jest publiczna, więc klienci jej nie widzą …i nie wiedzą nad czym będziemy pracować.

Zawsze gdy przychodzi do mnie klient i chce danej funkcjonalności, a my jej nie posiadamy to mówię:

“Dziękuje, zastanowimy się jak rozwiązać Twój problem”

Nigdy nie daję bezpośrednio odpowiedzi, że daną rzecz zrobimy i uważam takie podejście za mocny anty pattern pracy Product Managera.

Nawet gdy stosujemy fake door, to po skorzystaniu klient widzi komunikat: “Dzięki, damy Ci znać jeśli pojawi się ta funkcjonalność”.  Pozwala nam to unikać irytacji klientów i odpowiednio zarządzać ich oczekiwaniami.

Jeśli chodzi o wewnętrznych stakeholderów to rozwiązujemy to po prostu komunikacją. Dobrze działająca komunikacja wewnątrz firmy jest kluczowa. Robimy regularne spotkania sprint reviews, mamy całą stronę na której trackujemy progres każdego z naszych OITów i komunikujemy regularnie gdzie jesteśmy.

Zarówno zespół sprzedażowy jak i customer support ma ogromne zrozumienie nieprzewidywalności pracy w produkcie, co daje nam bardzo duży komfort pracy.

Grzesiek: Co robisz gdy przychodzi do Ciebie dział sprzedaży i próbuje Cię zmusić do zrobienia funkcjonalności X – w przeciwnym razie klient odejdzie.

Piotr: Koszt subskrypcji TIDIO wynosi miesięcznie od 20 do 50 USD, więc jedna sprzedaż nie zmienia aż tak dużo. Mamy dużych klientów z którymi chcemy być obecni na rynku, ale nasz zespół sprzedażowy jest bardzo świadomy i wie, że robienie rzeczy typowo pod jednego klienta jest złą drogą, którą nie powinniśmy podążać.

W Tidio ogromny plusem jest to, że wszyscy gramy do jednej bramki i mamy alignment jeśli chodzi o nasze wspólne cele. Jest to wyjątkowa i komfortowa sytuacja bo często zdarza się tak, że często sprzedaż naciska zespół produktowy i wymusza wiele funkcjonalności, jeśli Product Manager nie jest wystarczająco asertywny i umocowany w firmie.

Grzesiek: Myślałem, że idealna firma nie istnieje… a jednak 🙂 Macie jakieś zależności między zespołami?

Piotr: Tak, oczywiście. Z jednej strony są to zależności produktowe, a z drugiej zależności w kodzie. Jeśli chodzi o to drugie to tutaj następuje komunikacja między developerami w różnych zespołach – wiemy kto zajmuje się konkretnym obszarem w różnych zespołach. Nie mamy ustalonego procesu, ale dość dużo komunikujemy się między sobą, gdy pojawiają się różnego rodzaju zależności.

Jeśli chodzi o zależności między produktowe to również staramy się ze sobą komunikować. Najwięcej zależności rozwiązujemy na etapie planowania kwartalnego. W przypadku planowania sprintów również staramy się komunikować cele i ustalać co będziemy robić, i od czego możemy zależeć.

Warto też wspomnieć, że w Tidio mamy pięciu Product Managerów, (cały czas szukamy więcej 🙂 ), więc nie mamy aż tak dużego problemu z komunikacją i z mapowaniem zależności. Bardzo mocno też wspiera nas Marcin, nasz CPO.

Grzesiek: Z jakich narzędzi korzystacie w różnych obszarach?

Piotr:  Z obszaru discovery to między innymi: Hotjar, User Testing, Maile oraz Zoom, aby rozmawiać z klientami. Wszystkie informacje zbieramy w Airtable, a nasze wnioski spisujemy w Notion.

Zbudowałem u siebie nawyk notowania każdej decyzję, którą podejmuję, aby później wiedzieć w jakich okolicznościach została podjęta. Wszystko po to, aby nikt nie przyszedł i nie powiedział, że coś zrobiliśmy i nagle nie działa inna funkcjonalność dla pewnych klientów. Zawsze notuję jakie mogą być konsekwencje danej decyzji, jakie podejmujemy trade-offy i dlaczego uważam, że są one do zaakceptowania.

Wracając do kolejnych narzędzi to oczywiście korzystamy z JIRA do zarządzania backlogiem. Jeśli chodzi o dokumentacja to jest ona po stronie developerów – zapisywana na Gitlabie.

Grzesiek: Przejdźmy do innego zestawu pytań. Jak zarządzasz czasem i dbasz o produktywność.

Piotr: Decyzja nad czym obecnie pracuje, jest dla mnie również decyzją produktową. Dużo rzeczy deleguję, bo zazwyczaj nie jestem najmądrzejszą osobą, aby się zajmować danym obszarem. Tak jak wspomniałem wcześniej, do UX Researchu mamy odpowiednią osobę, do analizy danych mamy też inną osobę, dokumentacja jest tworzona przez zespół developerski, itd itd.

Cały czas mam TO DO listę, którą staram się regularnie aktualizować, bo oczywiście są na niej też rzeczy, które przedawniają się. Staram się stawiać określony cel na każdy dzień – zazwyczaj jeden. Jeśli uda mi się go zrealizować to znaczy, że mój dzień był wartościowy.

Próbowałem też bookować czas na deep work, ale nie wiem czy w przypadku naszej roli jest to odpowiedni sposób bo często mi nie wychodzi. Jest dużo spotkań i rozmów z klientami, ale nie przeszkadza mi to w codziennej pracy, więc uważam że rezerwowanie kalendarze nie jest dla mnie idealnym rozwiązaniem.

Grzesiek: Co uważasz za najważniejsze umiejętności PMa?

Piotr: Na pewno komunikacja bo jest bardzo istotna w codziennej pracy. Tak jak wcześniej powiedziałem, traktuje siebie jak taką  piłeczkę ping pongową pomiędzy developerami, klientami, użytkownikami i jeszcze nie wiadomo kim 🙂

Myślę, że warto dodać też umiejętność zadawania pytań w taki sposób, aby uzyskać wartościowe odpowiedzi.

Nie zapominajmy też o sztuce priorytetyzacji i zarządzania czasem. W ogóle zarządzanie swoim czasem i zarządzanie produktem są według mnie bardzo sobie bliskie.

Grzesiek: A co powiedziałbyś osobom, które chciałyby zostać product managerem?

Piotr: Powiedziałbym, że bardzo dużo jest produktowych guru, którzy mówią o tym jak ciężka jest to praca, a ja uważam, że jest to praca, która dostarcza bardzo dużo radości. Pracowałem na wielu różnych stanowiskach (operacje, support, sprzedaż, finanse) i mało jest takich ról, które są w stanie spowodować tak wiele uśmiechu na twarzy jak w produkcie.

Ważne jest, aby zrobić pierwsze kroki i przebić się do tego stanowiska. Bardzo dużo wiedzy jeśli chodzi o Product Managera jest dostępnej w internecie.

Warto też szukać takich początkujących pozycji w młodych organizacjach, bo można rosnąć razem z tą firmą.

Na pewno nie wydawałbym ogromnych pieniędzy na kursy bo praktyka jest dużo bardziej wartościowa i kształtuje nas w przekonaniu jakim Product Managerem chcesz być, a jakim nie.

Grzesiek: Dziękuje bardzo za wartościowy wywiad!

Piotr: Również dziękuje. Jeśli ktoś ma jakieś pytania to zapraszam do siebie na LinkedIn 🙂