📣 PRODUKTOWE ROZMOWY: WYWIAD Z PIOTREM WIŚNIOCHEM!

Piotr Wiśnioch ma kilkuletnie doświadczenie w pracy jako Product Manager. Obecnie pracuje w łódzkim Software House – BinarApps.
Grzesiek: Cześć Piotr, na wstępie dziękuję, że chciałeś ze mną porozmawiać i podzielić się swoimi doświadczeniami. Opowiedz jak to wszystko się zaczęło.
Piotr: Cześć, również dziękuje za zaproszenie! Wszystko zaczęło się ponad 5 lat temu w Łodzi. Siedziałem sobie spokojnie z boku, przy wynajmowanym od BinarApps biurku i tworzyłem interaktywne wystawy i gry miejskie. Już wtedy zacząłem ich obserwować. W BinarApps pracowalo 8 osób. Ja dołączyłem do Software House, gdy miał 50 osób. Obecnie w firmie pracuje 200 osób.
Zacząłem jako Project Manager (bo takiego potrzebowali). To były (jeszcze) piękne czasy gdy nie trzeba było mieć 6 lat doświadczenia w pracy z projektami i doświadczenia w IT. Na początku tworzyliśmy produkty pod dyktando klienta, a nie pod potrzeby użytkownika. To wszystko powodowało, że później było bardzo dużo problemów z takim klientem. Skłoniło mnie to do wdrożenia “komórki w firmie”, która dodatkowo zajmowała się analizą potrzeb klienta – taka dodatkowa usługa konsultingowa. Nasz dział jest odpowiedzialny za to żeby zrozumieć o co chodzi klientowi, czasami podważyć to co chce – być takim mądrym krytykiem – partnerem. Nie tylko technologicznym, ale też biznesowym.
Obecnie w naszym dziale jest siedmiu konsultantów oraz siedmiu designerów. Z każdym z naszych klientów odbywamy tzw. “warsztat zero”, w trakcie którego staramy się dowiedzieć o jego potrzebach i motywacjach. Pokazujemy jak pracujemy,a dopiero później tworzymy ofertę, którą przedstawiamy naszym klientom. Nie jesteśmy jak 90% Software Housów, które od razu przechodzą do delivery. Większość naszych klientów jest z nami od samego początku bo dbamy o wartość.
Oczywiście czasami zdarza się, że klient się uprze i nie chce współpracować. Myśli, że jest najmądrzejszy i nie potrzebuje rozmawiać o problemach z klientami. Takie podejście najczęściej kończy się bardzo źle.
Grzesiek: Co się zmienia w Software House gdy firma skaluje się z 50 do 200 osób?
Piotr: W momencie w którym wzrasta skala firmy, wprost proporcjonalnie wzrasta też skala oczekiwań klientów wobec danej firmy. Klient oczekuje, że będzie profesjonalna, a nie chałupnicza – chodzi o to, że nie tylko zależy mu na tym, że coś będzie działało w kontekście technicznym, ale też że, klienci dla których buduje nasz klient, będą chcieli używać tego rozwiązania.
Nie wystarczy już tylko posiadać deweloperów. Trzeba mieć też designerów, marketingowców (którzy podpowiedzą jak stworzyć strategię GTM i np. poprowadzą kampanię dla klienta). Łączymy te wszystkie kompetencje i w zależności od etapu projektu, którym się zajmujemy – możemy je odpowiednio zaadresować. To powoduje, że jesteśmy bardziej profesjonalni.
Grzesiek: A za co jesteś odpowiedzialny jako Product Manager?
Piotr: W software House, każdy z tych siedmiu konsultantów, nie jest dedykowany w 100% do jednego projektu. Mam takie projekty, w których jestem bardziej w roli analityka, ale mam też takie gdzie jestem wsparciem zespołu deweloperskiego lub prowadzę tylko discovery. To jest dość duże wyzwanie, aby nie tracić czasu na przełączania się pomiędzy projektami.
Jako Product Manager jestem obecnie odpowiedzialny za produkt, który pozwala dystrybuować klipy na planie filmowym – dość skomplikowany. W zespole mam iOS developerów, BE developerów, Testerów QA, designera i analityka więc można powiedzieć, że taki zespół cross funkcjonalny.
Moim głównym zadaniem jest zwalidowanie hipotez z użytkownikami i dostarczenie odpowiednich featerów na czas zgodnie z wcześniej ustalonymi timeline’ami. Trzeba najpierw wymyślić, zwalidować, zaplanować i rozpracować problem. Prowadzę warsztaty z użytkownikami, aby dowiedzieć się, jakie mają problemy i jak możemy je rozwiązać, za pomocą zaimplementowanych później funkcjonalności.
Grzesiek: W jakiej metodologii pracujecie w firmie?
Piotr: Nie ma odgórnego wymogu w firmie, że musisz pracować w Scrumie, Kanbanie czy w jakimś innym podejściu zwinnym. Najważniejsze jest to, abyśmy dostarczali rzeczy skutecznie. Klienci potrzebują mieć konkretny efekt w konkretnym czasie, w konkretnym budżecie – brzmi jak typowy fix, ale staramy się zachować elastyczność w tym wszystkim.
W kilku projektach pracujemy w miesięcznych cyklach bo ustaliliśmy, że to dla nas optymalny czas, aby dostarczyć coś co może być feater’em i przynosić wartość dla klientów. Próbowaliśmy z krótszym czasem (2 tygodnie), ale niestety nie udawało się. W trakcie tego miesiąca określamy sobie base scope i extended scope. Base scope to coś co przyniesie użytkownikowi pożądaną wartość, a wszystkie dodatkowe elementy są nice to have i zawierają się w extended scope. Po dwóch tygodniach sprawdzamy gdzie jesteśmy i co robimy: zmieniamy zakres (ale żeby nadal przynosił wartość) czy jesteśmy “on track”. Następnie po miesiącu robimy wydanie, a potem mamy tydzień na “sprzątanie”. W tym czasie robimy jakieś spike analityczne lub techniczne i dogrywamy zakres na kolejny cykl.
Grzesiek: Czy w tym cyklu wpadają jakieś inne rzeczy? Jakieś wrzutki?
Piotr: Pracujemy blisko z danym klientem, więc jeśli umawiamy się z nim na daną funkcjonalność to nowe/ inne rzeczy nie wchodzą bo mamy inny cel. Oczywiście w praktyce to wygląda trochę inaczej bo produkt cały czas żyje i jeśli wchodzi jakiś bug w trakcie sprintu to zawsze sprawdzamy priorytet i krytyczność danego zgłoszenia, aby zadecydować czy wrzucamy go do sprintu czy do backlogu. Jeśli wrzucamy go do sprintu to musimy zastanowić się co zostanie usunięte z zakresu do którego się zacomittowaliśmy. Zwykle nie ruszamy tego głównego zakresu, tylko ten dodatkowy. (extended scope).
Grzesiek: Jakie było Twoje największe wyzwanie w roli produktowej pracując w Software House?
Piotr: Opowiem o dwóch. Jedno dotyczy stricte Software House, a drugie roli produktowej. Zacznę od SH. Generalnie SH żyje z klientów – musimy mieć dużo klientów i dużo ludzi, którzy są w stanie dostarczyć wartość dla tych klientów. W przypadku naszej roli (produktowej) jesteśmy bardzo często przypisywani do wielu projektów na raz, co powoduje czasami, że brakuje czasu na skupienie ze względu na częste zmiany kontekstu. Z kolei brak skupienia powoduje, że czasami popełniamy błędy. Aby zmniejszyć ilość błędów, działamy w dwójkach – mamy kapitana i tzw. skrzydłowego. Jedna osoba prowadzi projekt, a druga jest trochę jak taki sparing partner.
Drugim wyzwaniem jest to, że często klienci chcą widzieć efekty tu i teraz i bardzo ciężko jest wytłumaczyć im, że wartością jest uporządkowana praca. Nie rozumieją potrzeby posiadania Product Managera. Obecnie to się mocno zmienia bo klienci są coraz bardziej świadomi tego, że warto poświęcić więcej czasu, aby pomyśleć, zanim przejdziemy do etapu robienia.
Grzesiek: Jakie są top 3 umiejętności powinna posiadać osoba, która chce zostać Product Managerem w Software House?
Piotr: Myślę, że umiejętność zdobywania szacunku developerów i budowanie wewnętrznego zespołu w sposób oparty na relacji i prawdziwości. Druga to umiejętność traktowaniu klienta jako człowieka w potrzebie, a nie jako kolejnej osoby, która przychodzi ze swoimi problemami. Trzecia to umiejętność zarządzania czasem i pracy w sposób ustrukturyzowany czyli łączenia różnych wątków w sposób, który nie pozwoli Ci zwariować – bo jednak masz kilka projektów na raz, a doba ma tylko 24h.
Grzesiek: Zatem jak być produktywnym i odpowiednio zarządzać czasem, aby nie zwariować?
Piotr: Najgorsze co może się wydarzyć to ciągłe zmiany kontekstu – czytałem kiedyś, że człowiek potrzebuje minimum 20 min czasu, aby przełączyć się do innego zadania. Staram się zatem blokować sobie sloty w kalendarzu, które pozwolą mi wejść w tryb FLOW i pracować efektywnie. Te sloty mają nazwy tematów, które próbuje rozgryźć.
Kolejną rzeczą jest sposób notowania moich myśli. U mnie najlepiej sprawdza się długopis i kartka papieru. Stosuje też Remarkable bo w prosty sposób mogę od razu zdigitalizować to co mam na kartce “papieru”.
Bardzo lubię układać sobie rzeczy od tyłu czyli tzw. reverse engineering, np. jeżeli wiem, że funkcjonalność ma wyglądać w taki,a nie inny sposób – to sobie idę od tyłu – jeżeli user na samym końcu klika w dany przycisk, to zastanawiam się co musi być wcześniej, co musi być jeszcze wcześniej…i tak dochodzą do samego początku. ‘
Warto też znaleźć w trakcie doby przedział czasowy w którym pracujemy najlepiej – ja mam taki okres od 18 do północy. Każdy z nas ma taki slot czasowy.
Jeśli chodzi o narzędzia, to korzystam z produktów takich jak Asana do zarządzania różnymi projektami, Airtable do wywiadów, Miro do warsztatów online, Notion do notatek oraz tablet Remarkable do notowania myśli. To wszystko służy do tzw roboczych notatek. Efektem końcowym jest strona w confluence, która zbiera to wszystko w całość i można w łatwy sposób do niej wracać – jest jedynym źródłem prawdy dla nas i klienta.
Grzesiek: Możesz podzielić się jakimś ciekawym miejsce w internecie, które regularnie odwiedzasz i czerpiesz wiedzę?
Piotr: Czytam namiętnie bloga Teresy Torres bo pozwala mi to rozwijać swoje umiejętności związane z discovery. Ostatnio również trafiłem na stronę growth design, która przedstawia w sposób graficzny różne kejsy – super sprawa.
Grzesiek: Ostatnie pytanie. Co byś polecił osobom, które chciałyby rozpocząć swoją karierę w Product Management?
Piotr: Na pewno poleciłbym, aby spojrzeć na aplikacje, które używamy na co dzień i zastanowić się “Jak oni to zrobili?, Dlaczego tak, a nie inaczej” czyli taka czysta ciekawość. Można nawet olać ten cały digital i podumać nad sprzętami, które posiadamy w domu – np. robot sprzątający – i zastanowić się jak działa.
Innym sposobem jest próba ćwiczenia naszego produktowego myślenia, która pozwoli nam przedstawić naszą wizje danego procesu np. zakup biletu do pociągu. Chodzi o to, żeby znowu zmusić się do myślenia i zadawania odpowiednich pytań: “Jak bym zmienił ten proces? Co bym w nim ulepszył?”.
To bardzo pomaga później w przypadku pracy z różnymi klientami – uczy produktowego myślenia, które jest bardzo ważne w codziennej pracy.
Grzesiek: Dzięki za wartościową rozmowę!
Piotr: Dzięki!