– Ustalenie celu w sposób autorytarny pozbawia lub co najmniej silnie ogranicza możliwość zbudowania relacji emocjonalnej z celem. Przez to realne zaangażowanie i motywacja do realizacji takiego “odgórnego” celu będą słabsze – mówi Michał Gaździk, CEO w Onely, autor ebooka “Product Owner – czyli co warto wiedzieć o tej roli ale mało się o tym mówi”.
Kto powinien stawiać cele, które realizuje Product Owner wraz z zespołem?
Powinna to być osoba która bierze ostateczną odpowiedzialność za ich realizację bądź brak realizacji.
Natomiast chyba postawiłbym to pytanie trochę inaczej. Forma “kto powinien stawiać” sugeruje, iż dzieje się to w sposób autorytarny i jednoosobowy. Jakkolwiek jest to prawdopodobnie praktyka, która istnieje w niektórych firmach, to uważam, iż takie podejście nie jest adekwatne z kilku powodów.
Po pierwsze, ustalenie celu, który realnie może być zrealizowany, wymaga wiedzy i danych z różnych obszarów. Cel musi nieść realną wartość dla użytkowników produktu, biznesu, organizacji. Również powinien być wykonalny (pod kątem posiadanych kompetencji, technologii, itd.). Wykonywalność należy rozważyć zarówno na poziomie ogólnym, jak i na poziomie zadanego horyzontu czasowego (bo cele mają sens głównie w jakimś czasie). A co idzie za możliwością realizacji to koszt finansowy i lista zasobów niezbędnych. Elementy, które należałoby rozważyć przy stawianiu celu można dalej mnożyć, ale mam nadzieję, iż widać już na tym etapie, iż jedna osoba może zwyczajnie nie mieć dostatecznej wiedzy żeby samodzielnie stawiać cele zespołowi produktowemu.
Po drugie, ustalenie celu w sposób autorytarny pozbawia lub co najmniej silnie ogranicza możliwość zbudowania relacji emocjonalnej. Przez to realne zaangażowanie i motywacja do realizacji takiego “odgórnego” celu będą słabsze niż w podejściu, gdzie zespół też jest zaangażowany w definiowane i rafinowanie celu na możliwie wczesnym etapie. Moim zdaniem otwarcie się na takie partnerskie podejście bardzo pomaga w zdobyciu ”buy-in’u” ze strony zespołu. Dzięki temu w trakcie realizacji zespół będzie bardziej proaktywny i zdeterminowany do pokonywania przeszkód, które nieuchronnie pojawiają się na drodze do realizacji każdego celu.
Jedno z moich ulubionych powiedzeń to “Można kazać komuś coś zrobić, ale nie można kazać komuś czegoś chcieć”. A w momencie, kiedy pracujemy z zespołem specjalistów, którzy budują innowacje i rozwiązują pewne problemy po raz pierwszy – myślę, iż dużo lepiej jest pracować z ludźmi, którzy sami chcą działać i dowozić cele.
Po trzecie, uważam iż w pracy z dowolnym zespołem istotny jest czynnik empowermentu. Na koniec dnia to zespoły produktowe mają za zadanie dostarczenie wartości użytkownikom, a przez to organizacji i biznesowi. Dlatego też ważne jest dla mnie, żeby tam, gdzie to możliwe dawać przestrzeń do działania i wpływania na kierunek rozwoju produktu. Empowerment to nie tylko prawo głosu i dodawanie swoich “trzech groszy” do każdej dyskusji, ale jest to też branie odpowiedzialności za plany, ich realizację i co najważniejsze – za dostarczony efekt.
Czego PO potrzebuje do swojej pracy? Nie pytam o narzędzia, a raczej o przestrzeń, budżet, możliwości itp.
W moim odczuciu PO przede wszystkim potrzebuje zaufania. Jakkolwiek byśmy nie “pokroili” roli PO, struktury firmy, procesów – bez zaufania (obustronnego) w relacji z zespołem, interesariuszami, przełożonymi, współpracownikami a także użytkownikami – bardzo ciężko będzie skutecznie wykonywać jakąkolwiek pracę, komunikować się. To jest moim zdaniem absolutna podstawa.
W następnej kolejności PO potrzebuje pewnego otoczenia, które umożliwi przekładanie decyzji na realnie działające rozwiązania, które klienci mogą kupić i wykorzystać. Celowo nie podaję tutaj konkretów na zasadzie “co najmniej 5-cio osobowy zespół developerski, grafik, tester i analityk”, bo chyba w dzisiejszych czasach jesteśmy już na trochę dalszym etapie rozwoju. Zauważam, iż z różnych względów odchodzi się od koncepcji “kompletnego” zespołu, a np. stosuje się strukturę macierzową, gdzie np. testerzy, designerzy, researcherzy dzielą swój czas pomiędzy kilka produktów i zespołów produktowych a sercem zespołu jest np. PO i troje-czworo developerów.
Do tego też nie należy zapominać o tym, iż w ostatnich latach dużo wiedzy i zadań kiedyś realizowanych przez osoby i wyspecjalizowanych rolach teraz jest dużo łatwiej dostępne dzięki gotowych narzędzi, automatyzacji czy bardzo popularnego od ponad roku AI.
Konkrety dotyczące tego “otoczenia” zależą też trochę od specyfiki produktu, organizacji, możliwości finansowych. W mniejszej organizacji obstawiam, iż raczej to PO będzie spędzać czas przeglądając analitykę. W większych strukturach już możliwe, iż będzie zasadne stworzenie osobnej roli, która będzie dostarczać wnioski wszystkim zainteresowanym.
Warto tutaj też myślę wspomnieć o poziomie dojrzałości organizacji i produktu. Produkt, który dopiero szuka swojego dopasowania rynkowego prawdopodobnie nie potrzebuje np. rozbudowanej hurtowni danych i wielopoziomowych raportów. Z kolei organizacja dojrzała i ustabilizowana, potrzebuje bardziej rozbudowanych struktur wspierających realizowanie dużej ilości zmian w produkcie przez wiele zespołów na raz.
“Warto budować relację z ludźmi, a nie ze stanowiskami” – napisałeś w swoim ebooku. Czym różnią się te podejścia?
Stanowisko jest dla mnie jakimś niewielkim wycinkiem tego, kim jest dany człowiek. Stanowiska są definiowane poniekąd odgórnie przez organizacje, nadawane są obszary odpowiedzialności, decyzyjność, “przypisywany” jest zespół. I z perspektywy współpracy na pewno trzeba zdawać sobie sprawę z tego, jakie metryki stoją za daną osobą, jakie są jej kompetencje, zakres decyzyjności.
Natomiast stanowisko jest dla mnie czymś odrobinę… teoretycznym? Jak się nad tym zastanowić to finalną decyzję o tym, jak dana osoba zareaguje w interakcji z nami podejmuje sam człowiek. Co za tym idzie – rozmawiamy nie tylko z “rolą”, ale z żywą osobą, która ma swoje motywacje, lęki, doświadczenia, trudności, przekonania i te elementy mają moim zdaniem dużo większy wpływ na to jaką postawę ktoś przyjmie w stosunku do nas niż sama definicja roli.
Może łatwiej będzie to przekazać na przykładzie. PO potrzebuje wsparcia zespołu sprzedażowego w nowym projekcie, więc zaczyna rozmowę z managerem tego zespołu. Okazuje się, iż podobny pomysł już kiedyś był realizowany (np. zanim aktualny PO dołączył do organizacji) i finał był bardzo niekorzystny dla zespołu sprzedawców i manager mocno to odczuł na swojej skórze.
Nie jest więc dziwnym, iż osoba, z którą rozmawia PO nie jest bardzo skora do powtórzenia tego samego pomysłu, bo spodziewa się ponownie negatywnych konsekwencji.
Reakcja PO na tę sytuację jest kluczowa moim. Z jednej strony można próbować się powoływać właśnie na stanowiska, struktury w organizacji, wymuszać wsparcie dla zespołu produktowego (bo tego wymaga produkt). Możliwe nawet, iż w tej sytuacji uda się wyegzekwować (wymusić) realizację tego pomysłu. Może choćby tym razem całość zakończy się sukcesem. Ale przez cały czas w tym przypadku zdeptaliśmy relację miedzyludzką z managerem sprzedaży, nie zbudowaliśmy większego zaufania, co w przyszłości na pewno nie poprawi relacji ani nie ułatwi kontaktów.
Natomiast alternatywnym scenariuszem jest wejście w rozmowę z zespołem sprzedażowym i zrozumienie, co dokładnie poszło nie tak, co można zrobić lepiej, co można zapewnić żeby zabezpieczyć ich przed ewentualnymi konsekwencjami (zarządzanie ryzykiem). A docelowo warto byłoby zdobyć buy-in managera sprzedaży. Pozwoli to nie tylko zrealizować pomysł bez wychodzenia z pozycji siły, ale bardziej zaangażowany zespół udzieli mocniejszego wsparcia, zadziała bardziej proaktywnie w trakcie realizacji, co powinno przynieść lepsze efekty.
Traktując kogoś po partnersku, otwierając się na jego trudności i pomagając je przełamać zdobywamy zaufanie, budujemy relację, co z kolei przy kolejnych interakcjach będzie skutkowało większą otwartością i odwagą do realizowania trudniejszych, bardziej ambitnych projektów.
Jakbyś określił, czym różni się lider od managera?
Nie każdy lider musi być managerem i nie każdy manager musi być liderem (choć uważam, iż powinien). Dla mnie management czy zarządzanie jest czynnością, która odnosi się z natury do obiektów nieożywionych. Na przykład – zarządzać możemy backlogiem produktu, priorytetami zadań, czasem, contentem, oczekiwaniami, komunikacją. Natomiast w odniesieniu do ludzi – nie przepadam za formą ”zarządzania”, która (przynajmniej w moim odczuciu) jest nacechowana jednostronnie i autorytarnie.
Kiedy pracujemy z zespołem specjalistów, którzy mają w swoich obszarach specjalizacji wiedzę i doświadczenie często przekraczające nasze własne – dużo bardziej adekwatne wydaje mi się prowadzenie w kierunku wspólnego celu. Ponownie – możemy kazać komuś coś zrobić, ale nie możemy kazać komuś czegoś chcieć. Tak więc specjalista, który niekoniecznie chce być pomocny – na pewno zrobi to, co mu każemy, ale nie liczyłbym na duże zaangażowanie i proaktywną postawę w takiej sytuacji.
Drugie rozróżnienie to prawdopodobnie znany większości czytelników obrazek porównujący szefa i przywódcę:
Chociaż też nie jest to idealne porównanie, bo z jednej strony napewno lider będący lokomotywą całego zespołu jest skuteczniejszy w prowadzeniu zaangażowanego zespołu niż autorytarny przełożony wskazujący tylko kolejne cele do realizacji. Ale jednocześnie istnieją różne style przywództwa i nie każdy z nich wymaga żeby lider był na pierwszej linii pracy nadając tempo zespołowi.
Dla Product Ownera etap tworzenia roadmapy produktu to najlepszy czas?
Myślę, iż wszelkie etapy planowania są dobrym czasem, bez względu na rolę czy sytuację. Jak mówi przysłowie – “Papier przyjmie wszystko” więc teoretycznie w bardzo łatwy sposób możemy poczuć smak zwycięstwa, praktycznie nie wykonując jeszcze żadnej pracy. A ponieważ nasze mózgi bardzo lubią wszelkie formy poczucia sukcesu to planowanie jest przyjemnym i (stosunkowo) łatwą aktywnością.
Natomiast po planowaniu i podejmowaniu zobowiązań przychodzi moment zderzenia z rzeczywistością i wtedy brutalnie szczerze wychodzą na światło dzienne wszystkie hurra-optymistyczne założenia, niedoszacowane nakłady pracy, przeszacowane możliwości, co z kolei niesie za sobą już nieco trudniejsze emocje, czasami zwątpienie, spadek nastroju.
Jest to moim zdaniem nieunikniona sytuacja i na pewno nie zalecałbym też popadania w ultra-konserwatyzm przy planowaniu celów, bo to z kolei będzie prowadziło do stagnacji produktu, co też jest niepożądanym stanem.
Ścieżką, która w moim odczuciu jest adekwatna w takiej sytuacji, jest zrozumienie i zaakceptowanie wszystkich etapów pracy z produktem, a także zbudowanie umiejętności znajdowania radości, szczęścia, wdzięczności w każdym z tych poszczególnych etapów.
Pomyśl o tym, iż nieco inny zestaw emocji towarzyszy nam przy planowaniu, inne przy dowożeniu poszczególnych sprintów, inne przy wdrożeniu na produkcję nowej funkcji, inne przy naprawieniu błędu i jeszcze inne kiedy np. po miesiącu od wdrożenia funkcji dowiadujemy się o wpływie biznesowym na organizację i biznes, albo dostajemy pozytywny feedback od klientów.
Jednocześnie każdy z tych etapów ma swoje trudności i wyzwania które trzeba pokonywać na co dzień. Czasami bilans tych emocji jest dodatni, a czasami ujemny. Niezmiennie jednak należy mieć świadomość, iż praca z produktem cyfrowym jest maratonem a nie sprintem i wytrwałość połączona z systematycznością są w stanie zaprowadzić organizację dużo dalej, niż krótkie zrywy mocnego “grindu”, po których następują tygodniowe lub miesięczne okresy bezczynności lub chaosu.
Czy dla rozwoju PO ma znaczenie to w jakiego rodzaju firmie pracuje?
Jeśli chodzi o branżę, rozmiar organizacji, zespołu, etap rozwoju, używaną technologię – to myślę, iż jest to coś co może mieć znaczenie w zależności od personalnych preferencji danego PO.
Z mojego punktu widzenia uniwersalnie ważne są takie czynniki, jak kultura i wartości firmy, forma leadershipu stosowana w organizacji, komunikacja, czy też wizja firmy i to, na ile ona rezonuje z moją wewnętrzną motywacją.
Ważne jest też dla mnie aby w ramach roli, w której się znajduję mieć możliwość rozwoju, kontaktu z ludźmi, współpracy nad projektami, jasność celów wysoko poziomowych oraz możliwość wnoszenia realnych kontrybucji do rozwoju organizacji i zespołu.
Czynniki, które wymieniłem w pierwszej części tej odpowiedzi również są dla mnie istotne, ale nie decydujące, bo wiem, iż choćby w najbardziej innowacyjnej i rozwojowej firmie można trafić do działu/zespołu, który jest pełny toksycznych postaw i zachowań, co w dłuższej perspektywie wysysa z człowieka chęć do życia i pasję do pracy, powoduje iż dominują trudne emocje.
Na liście rekomendowanych przez Ciebie lektur nie znalazłem polskiej pozycji. Z czego to wynika?
Po prostu nie trafiałem na polskie pozycje literaturowe z zakresu budowy produktów cyfrowych. Mam w swojej kolekcji kilka książek na temat prowadzenia projektów, procesów, ale nie były dla mnie przełomowe czy kształtujące. Nie twierdzę, iż nie mają wartości, ale z jakiegoś powodu nigdy chyba nie miałem WOW po przeczytaniu polskiej lektury.
Jedyny wyjątek tutaj stanowi książka “Zaufanie w organizacji innowacyjnej”, na którą trafiłem już nieco po napisaniu swojego ebooka. Choć tak naprawdę jest to opracowanie naukowe bardziej niż klasyczna książka instruktażowa.
To też nie jest tak, iż w polskiej branży produktowej nie powstają interesujące i wartościowe treści. Od kiedy sięgam pamięcią były one dostępne w nieco innej formie, tzn. platformy społecznościowe, newslettery, blogi, szkolenia. Ale pozycji stricte literaturowej nie przypominam sobie.
Powodem może być to, iż thought leadership w zakresie zwinnego wytwarzania oprogramowania, transformacji cyfrowej był mocno skupiony m.in w Dolinie krzemowej i stamtąd publikacje dopiero przynosiły do Polski te koncepcje.
Przykładem może być to, iż Manifesto for Agile Software Development został spisany w 2001 roku, a SCRUM wg. Google został ”wynaleziony” w 1993 roku. Myślę więc iż tempo “osmozy” innowacji powoduje, iż trudno byłoby teraz wysunąć się na czoło w skali światowej. Niemniej coś, co mogą robić produktowcy, managerowie i liderzy to być otwartym i dynamicznym w adoptowaniu innowacji w swoich zespołach i organizacjach.
Michał Gaździk. CEO, Tech Leader, Project Manager i Product Owner w Onely. Swoją ścieżkę zawodową zaczynał 15 lat temu- od programisty PHP, tworzenia prostych stron, potem nieco bardziej zaawansowanych aplikacji aż do budowy platform i narzędzi SaaS. Fascynacja organizowaniem pracy zespołu i procesem wytwarzania oprogramowania, doprowadziła go do rozstania stricte z programowaniem i wkroczenie na ścieżkę managersko-liderską przez role Tech Leadera, Project Managera i Product Ownera.
Aktualnie realizuje swoje cele i wspiera zespół jako CEO w Onely (onely.com) oraz po godzinach promuje zdrowe i świadome podejście do leadershipu w ramach darmowego newslettera nextgenleadership.pl i konta instagramowego pod taką samą nazwą.
