Czy w zarządzaniu produktem powinni być bohaterowie?
Przeczytaj transkrypcję:
Próbujemy transkrybować nasze podcasty za pomocą programu komputerowego. Wybacz wszelkie literówki, ponieważ bot nie jest poprawny w 100% przypadków.
Hannah Clark: Zanim przejdziemy do rozmowy, chcę dokładnie wyjaśnić, co mam na myśli, mówiąc o bohaterach w zarządzaniu produktem. Nie mówię o liderach opinii, takich jak Marty Cagan czy Lenny Rachitsky. Mówię o TOBIE. Mówię o osobie, na której polega Twój zespół produktowy, gdy trzeba ratować sytuację, w której coś zaczyna płonąć. Mówię o bohaterze, który nosi wiele kapeluszy, ale nigdy peleryny. Mówię o powodzie, dla którego nie możesz pracować mniej niż 50 godzin tygodniowo, a mimo to nadal masz wrażenie, że nie jesteś dalej niż tydzień wcześniej.
Jeśli brzmi to jak opis Ciebie, mam dobrą wiadomość — dzisiejszym gościem jest Clement Kao, założyciel Product Teacher. Jako osoba, która szkoliła menedżerów produktu w najróżniejszych środowiskach, od startupów na wczesnym etapie po firmy z listy Fortune 500, widział wiele dynamik zespołów produktowych, w tym wiele takich, które wymagały poważnego ratunku.
Porozmawiamy o tym, dlaczego bycie bohaterem zespołu produktowego samo w sobie jest niebezpieczne. Jeśli ten temat jest Ci bliski, zostań z nami do końca, aby dowiedzieć się, jak zdobyć nadludzką siłę i wreszcie odwrócić sytuację. Zaczynajmy.
Witamy ponownie w podcaście Menedżer Produktu. Dziś rozmawiam z Clementem Kao. Jest założycielem Product Teacher.
Clement, bardzo dziękuję, że do nas dołączyłeś.
Clement Kao: Tak, bardzo dziękuję za zaproszenie.
Hannah Clark: Zacznijmy tak, jak zawsze zaczynamy. Czy możesz opowiedzieć nam trochę o swoim doświadczeniu i o tym, co skłoniło Cię do założenia Product Teacher?
Clement Kao: To świetne pytanie. Początkowo, zaraz po ukończeniu studiów, nie zajmowałem się zarządzaniem produktem.
Zacząłem jako konsola zarządzania. Następnie, jako konsola zarządzania, przypadkowo zostałem badaczem UX. Później przypadkowo zostałem analitykiem danych. A następnie przypadkowo zostałem menedżerem produktu. Mam więc bardzo nietypową ścieżkę kariery. W miarę rozwoju jako menedżer produktu zaczynałem jako młodszy menedżer produktu na dole drabiny, a następnie awansowałem na menedżera produktu, starszego menedżera produktu, menedżera grupy produktowej i głównego menedżera produktu.
Zauważyłem, że wiele innych osób zmagało się z tymi samymi problemami co ja. Nie zawsze miały pod ręką odpowiednie zasoby. Jak rozwiązać konkretny problem? Jak przepracować konkretny błąd? Co oznaczają te wszystkie terminy i dlaczego mają znaczenie?
Z czasem, gdy stawałem się coraz bardziej doświadczony jako menedżer produktu, zacząłem zadawać sobie pytanie: jak mogę wywrzeć największy możliwy wpływ? Zrozumiałem, że wywieranie największego wpływu niekoniecznie oznacza dalsze zajmowanie się zarządzaniem produktem w jednej firmie. Może oznaczać pomaganie setkom, a nawet tysiącom innych menedżerów produktu w osiąganiu sukcesu, gdy po raz pierwszy obejmują tę rolę.
To może być bardzo dezorientująca zmiana, a później można pomagać im wspinać się po szczeblach kariery. Dlatego założyłem Product Teacher. Product Teacher pomogło ponad 7000 menedżerów produktu odnieść sukces w pracy — czy chodziło o wejście do branży produktowej, awans, czy o ustalanie strategii produktu jako szef produktu i tworzenie przejrzystych procesów dla całego zespołu.
To była niezwykle satysfakcjonująca podróż.
Hannah Clark: Brzmi to jak najbardziej świadoma część Twojej kariery, a nie…
Clement Kao: Tak. To jedyna rzecz, której nie zrobiłem przypadkiem.
Hannah Clark: Dziś będziemy analizować ideę bohaterstwa w zarządzaniu produktem, wobec której przyjmujesz dość krytyczne stanowisko. Co dokładnie oznacza to w tym kontekście i jak przejawia się w organizacjach, z którymi pracowałeś?
Clement Kao: Świetne pytanie. Chcę doprecyzować, że nie twierdzę, iż bohaterstwo jest całkowicie złe. Jedną z kluczowych cech pracy menedżera produktu jest to, że ostateczna odpowiedzialność spoczywa na nim.
To Ty odpowiadasz za sukces produktu i musisz być gotowy zakasać rękawy, gdy jest to konieczne. Może nie mamy osoby odpowiedzialnej za zapewnienie jakości i nagle musimy dopilnować, aby wszystko zostało dobrze przetestowane przed wdrożeniem. Może projektant zachorował i trzeba ruszyć sprawy z miejsca, aby odblokować pracę inżynierów.
Może klienci mają trudności ze zrozumieniem części produktu i musisz przejąć rolę operacyjną, aby przeprowadzić wdrożenie i pomóc im osiągnąć sukces. Menedżer produktu powinien umieć wkroczyć do działania. Problem pojawia się wtedy, gdy bohaterstwo staje się czymś, co trzeba robić cały czas, zamiast czymś, po co sięgamy wyłącznie w wyjątkowych sytuacjach.
Menedżer produktu powinien móc wkroczyć i doprowadzić sprawy do końca, gdy jest to konieczne, ale nie powinien być osobą, która robi wszystko przez cały czas. Często, gdy mówi się: „Ten menedżer produktu jest prawdziwym bohaterem”, okazuje się, że odbiera on dużą część obowiązków innym współpracownikom, aby produkt działał.
W rezultacie reszta organizacji zaczyna słabnąć. Ludzie nie wykonują tego, co jest potrzebne z perspektywy marketingu produktu, analityki produktu, sukcesu klienta czy sprzedaży. Wszystkie te obszary stają się mniej solidne i mniej powtarzalne, gdy polegamy na jednej osobie, która robi wszystko.
Widziałem to wokół siebie. Gdy taki menedżer produktu zachoruje, pójdzie na urlop albo odejdzie z organizacji, wszyscy zostają w bardzo trudnej sytuacji.
Menedżerowie produktu powinni być gotowi przejąć inicjatywę, gdy pojawia się taka potrzeba. Jeśli jednak taka potrzeba występuje codziennie lub co tydzień, prawdopodobnie istnieje głębszy problem, którym trzeba się zająć.
Hannah Clark: Możemy sobie wyobrazić logiczne konsekwencje sytuacji, w której menedżer produktu cały czas znajduje się w takiej pozycji. Dlaczego jednak Twoim zdaniem tak wielu menedżerów produktu nadal w niej pozostaje?
Clement Kao: Myślę, że często dzieje się tak dlatego, że sposób organizacji pracy zmienił się z czasem. Wszyscy mają przekrojowe obowiązki i muszą zajmować się wieloma różnymi rzeczami.
W przeszłości jeden projektant UX mógł skupiać się na jednej inicjatywie. Dziś ta sama osoba może wspierać pięć produktów. Analityk biznesowy, który kiedyś zajmował się jednym zestawem inicjatyw, może teraz wspierać siedem różnych zespołów.
Przez takie nakładanie się obowiązków coraz mniej jasne jest, kto powinien przejąć odpowiedzialność. Kiedy coś idzie nie tak, nie wiadomo, kto powinien wkroczyć. A ponieważ nie jest to jasne, domyślnie robi to menedżer produktu.
Jeśli jasno określimy, kto powinien zajmować się danym problemem, menedżer produktu nie będzie musiał go przejmować. Jednak wraz z rozwojem startupów technologicznych i mniejszych, bardziej autonomicznych zespołów często brakuje przejrzystych wytycznych dotyczących podziału obowiązków.
Gdy tylko pojawia się sytuacja „Nie wiemy, kto powinien to zrobić”, odpowiedzialność trafia do menedżera produktu. Jeśli zrobi to raz i wykona zadanie bardzo dobrze, powstaje samonapędzająca się pętla: skoro zrobił to wcześniej i poradził sobie lepiej niż my, dlaczego nie miałby zrobić tego ponownie?
Widziałem menedżerów produktu, którzy przejmowali całą analitykę, wszystkie badania rynku, rozmowy z klientami, rozmowy sprzedażowe i zamykanie transakcji. Ponieważ radzili sobie lepiej od innych, organizacja zaczynała stale na nich polegać.
Hannah Clark: Czy są jakieś sygnały, wczesne oznaki, że organizacja nie wykonała pracy potrzebnej do ochrony menedżerów produktu przed koniecznością bycia bohaterem albo nie przygotowała odpowiednich procesów?
Clement Kao: Jednym ze sposobów rozpoznania tego problemu jest obserwowanie częstotliwości, z jaką musisz wkroczyć do działania. Jeśli zdarzyło się to raz, wszystko jest w porządku. Jeśli jednak interweniujesz co miesiąc, przy każdym uruchomieniu produktu albo za każdym razem, gdy pojawia się błąd, zaczyna się tworzyć wzorzec.
Jeśli ten sam problem pojawi się dwa razy z rzędu, trzeba przeprowadzić głębszą rozmowę. W organizacji, która ceni retrospektywy, należy przeanalizować, dlaczego problem wystąpił. Jeśli retrospektyw nie ma, warto je wprowadzić.
Pierwsza retrospektywa powinna pomóc zapobiec powtórzeniu problemu. Jeśli jednak problem się powtórzy, retrospektywa powinna obejmować pytanie, dlaczego powstał wzorzec. Dzięki temu można zauważyć, że osoby zajmujące się produktem regularnie wykonują zadania wykraczające poza ich zakres odpowiedzialności.
Hannah Clark: Retrospektywy brzmią jak mało atrakcyjne rozwiązanie takiego problemu.
Clement Kao: Są bardzo mało atrakcyjne.
Hannah Clark: Jaki proces powinien stosować menedżer produktu, aby przeprowadzić odpowiednią retrospektywę i zaangażować wszystkich w konieczne zmiany?
Clement Kao: Podczas retrospektywy bardzo ważne jest, aby nie szukać winnych i rozmawiać o systemie, a nie o ludziach. Nie chcemy, aby retrospektywa zaczynała się od wskazywania palcem na inżyniera, który był zbyt zajęty, aby wykonać dane zadanie.
Powinniśmy raczej zapytać: dlaczego klient zgłosił problem sześć miesięcy temu, a my nie zwróciliśmy na niego większej uwagi? Dlaczego czekaliśmy, aż klient bardzo się sfrustruje i będzie bliski anulowania umowy, zanim menedżer produktu wkroczył do działania?
Trzeba spojrzeć na sytuację z perspektywy systemu. Nie chodzi o to, że konkretna osoba nie zgłosiła czegoś w odpowiednim czasie. Należy zapytać, co jako system i proces moglibyśmy zrobić lepiej, gdyby sytuacja się powtórzyła.
Można porównać to do kontroli ruchu lotniczego. Kontroler ruchu lotniczego ma dopilnować, aby samoloty bezpiecznie startowały i lądowały. Gdy dochodzi do wypadku, kontroler jest obecny, ale nie oznacza to, że wina w 100% leży po jego stronie. Na sytuację wpływa wiele innych, nakładających się czynników, które mogą stworzyć pojedynczy punkt awarii.
Nie chcemy wzmacniać jednego punktu awarii. Chcemy stworzyć wiele miejsc, w których można wcześniej zapobiec problemowi. Odpowiedzialność nie powinna spoczywać wyłącznie na osobie noszącej tytuł menedżera produktu.
Najważniejszym nastawieniem podczas retrospektywy powinno być: „Przechodzimy przez to razem. Nie wskazujemy winnych. Nie twierdzimy, że konkretna osoba jest odpowiedzialna i że jej kariera jest zagrożona. Audytujemy system. Co w nim nie zadziałało i jak możemy go ulepszyć dla nas wszystkich, gdy sytuacja wydarzy się ponownie?”
Takie podejście pomaga zbudować właściwe role wspierające i procesy wspierające. Menedżer produktu nie powinien za każdym razem scalać kodu ani zapobiegać odejściu klienta. Jeśli jednak przy każdej rozmowie z klientem zagrożonym odejściem potrzebny jest menedżer produktu, należy zmienić sposób działania.
Hannah Clark: To ma sens — trzeba odtworzyć problem, a następnie znaleźć rozwiązanie, zaczynając od jego źródła. Czy w swojej pracy z zespołami produktowymi widziałeś organizacje, którym udało się skutecznie rozwiązać taki problem?
Clement Kao: Tak. Zacznę od własnej historii. W pewnym momencie wykonywałem wszystkie zadania związane z operacjami produktu, choć nie powinienem tego robić. W przypadku jednego z produktów B2B SaaS, za który odpowiadałem, uruchamialiśmy zupełnie nowy produkt sąsiadujący z naszym dotychczasowym rozwiązaniem.
Ponieważ przeprowadziłem badania klientów i rozumiałem ich problemy, przygotowywałem informacje o wydaniach, nagrania, szkolenia i demonstracje. Chciałem upewnić się, że klienci odniosą sukces podczas konfiguracji i korzystania z produktu.
Było to w porządku, gdy mieliśmy tylko trzech klientów. Gdy dotarliśmy do siedemdziesiątego, zrozumiałem, że popełniłem błąd. Powinienem był wcześniej podnieść rękę — przy dziesiątym lub piętnastym kliencie — i powiedzieć, że moim zadaniem nie jest prowadzenie każdej demonstracji i każdego szkolenia.
Myślałem: „To moja praca. Jestem menedżerem produktu i muszę dopilnować, aby produkt odniósł sukces, bez względu na wszystko”. Nie zauważałem, że odbieram zespołom sukcesu klienta i marketingu produktu możliwość przejęcia pełnej odpowiedzialności i zbudowania całościowego obrazu doświadczeń klientów.
Zacząłem podważać możliwości moich współpracowników. Nie dawałem im szansy przejąć odpowiedzialności za dany obszar od początku do końca. Zawsze wkraczałem, gdy było to konieczne. W rezultacie ludzie pytali: „Clement, pozyskuję nowego klienta do produktu, za który odpowiadasz. Nie wiem, jak to skonfigurować. Jakie są dostępne opcje?”
Powinien istnieć właściciel szerszej dokumentacji, opisującej konfiguracje, odpowiednie zastosowania, filmy, zrzuty ekranu i pytania kwalifikujące do procesu wdrażania klienta.
Miałem szczęście pracować z wyjątkowym dyrektorem produktu. Powiedział: „Clement, widzę, że jesteś ostatnio przytłoczony i wykonujesz wiele zadań, które technicznie nie należą do Ciebie”. Odpowiedziałem: „Tak, ale ostateczna odpowiedzialność spoczywa na mnie”.
Wyjaśnił mi, że przez takie podejście nie budujemy solidnego systemu wspierania klientów w długiej perspektywie. Mogłem wspierać od jednego do dziesięciu klientów, ale przy siedemdziesięciu osiągnąłem granicę. Chcieliśmy podwoić tę liczbę w kolejnym roku. Jak miałbym to zrobić?
Wtedy zrozumiałem, że ma rację. Zebraliśmy wszystkie zainteresowane osoby i ustaliliśmy, kto powinien za co odpowiadać. Właścicielstwo nie jest obciążeniem — może odblokować możliwości. Dajemy ludziom nowe role i nowe supermoce, ponieważ pozwalamy im przejąć obszary, które wcześniej im odbierałem.
W tym przypadku kluczowe były trzy rzeczy. Po pierwsze, potrzebne było wsparcie liderów zarządzania produktem. Jeśli liderzy mówią menedżerowi produktu: „Po prostu to zrób”, trudno przekazać obowiązki innym osobom.
Po drugie, trzeba odpowiednio opisać zmianę. Nie chodzi o to, że dajemy komuś więcej pracy albo nieprzyjemne zadania. Chodzi o większą odpowiedzialność i możliwość kontrolowania obszaru od początku do końca. Wcześniej niesprawiedliwie odbieraliśmy tę możliwość.
Po trzecie, trzeba regularnie sprawdzać, jak przebiega przekazanie odpowiedzialności. Na początku warto spotykać się co tydzień lub co dwa tygodnie, omawiać kontekst i informacje, które należy przekazać, a następnie stopniowo ograniczać częstotliwość spotkań.
Nie można po prostu przerzucić zadania przez mur i powiedzieć: „Od teraz to Twoja sprawa”. Należy wspólnie zrozumieć, co działało wcześniej i jak chcemy działać w przyszłości. Nowi właściciele powinni mieć możliwość znalezienia lepszego sposobu realizacji zadania.
Hannah Clark: Podoba mi się sposób, w jaki przedstawiasz to jako przywracanie zespołowi sprawczości i dzielenie się obciążeniem. Widziałam podobne sytuacje w organizacjach, w których pracowałam. Ktoś niesprawiedliwie przejmuje odpowiedzialność za coś, co do niego nie należy, co ogranicza jego rozwój i możliwość wniesienia wkładu przez innych. Czy masz jeszcze inne przykłady?
Clement Kao: Tak, mam bardzo świeży przykład. Obecnie pracuję z dużą organizacją, w której zespół produktowy jest stosunkowo nowy. Wcześniej jego członkowie pełnili głównie funkcję architektów rozwiązań.
Organizacja miała dział IT, który tworzył niestandardowe rozwiązania dla poszczególnych klientów. Nie był to skalowalny produkt. Liderzy zdecydowali, że potrzebny jest zespół produktowy, ponieważ rozwiązania dla różnych klientów miały wiele wspólnych elementów.
Chcieli budować solidne, skalowalne produkty zamiast pojedynczych rozwiązań. Część architektów rozwiązań przeszła więc do zespołu produktowego, aby przeprojektować sposób pracy i tworzyć skalowalną technologię.
Problem polegał na tym, że z powodu wcześniejszego doświadczenia osoby te nadal wykonywały pracę architektów rozwiązań. Gdy opracowywały rozwiązanie produktowe, zaczynały także decydować, jak klienci powinni wdrażać procesy i korzystać z systemów.
Rzeczywiści architekci rozwiązań zaczęli pytać: „Co ja właściwie robię?”. Powstało wrażenie wchodzenia sobie w drogę. Zespół produktowy chciał zapewnić dobre przyjęcie produktu, ale to architekt rozwiązań powinien analizować środowisko klienta i określać, jak połączyć produkt z istniejącymi systemami.
Zespół produktowy powinien pracować w skali: budować solidną platformę, a nie wykonywać jednocześnie pracę menedżera produktu i architekta rozwiązań przy każdym wdrożeniu. Chodziło o odejście od relacji jeden menedżer produktu — jeden klient na rzecz modelu jeden do wielu.
Wymagało to wielu rozmów z całym zespołem. Trzeba było uznać dobre intencje menedżerów produktu, ale wyjaśnić, że jeśli odbierają architektom rozwiązań możliwość pracy z klientami, nie będą mieli czasu na budowę technologicznego fundamentu.
Należało jasno powiedzieć „nie” i wyjaśnić dlaczego, a następnie oddać odpowiedzialność architektom rozwiązań. Zespół zareagował bardzo dobrze, ponieważ był otwarty na informacje zwrotne. Udało się wcześnie zdefiniować relację, zanim utrwaliła się na lata.
Ostatecznie menedżer produktu odpowiada za produkt, a architekt rozwiązania za rozwiązanie. To ważne rozróżnienie, szczególnie dlatego, że cały zespół produktowy wcześniej pracował jako architekci rozwiązań.
Hannah Clark: Chciałabym porozmawiać jeszcze o nastawieniu oraz dojrzałości organizacji i ich wpływie na sposób pracy. W miarę rozwoju organizacji zasady i procesy stają się bardziej skomplikowane, a przytłoczenie narasta. Można utknąć w sytuacji, która nie jest zrównoważona, ale wydaje się jedynym możliwym rozwiązaniem.
Trudno wydostać się z sytuacji, w której jest się przeciążonym i bierze się na siebie odpowiedzialność za pracę, która formalnie nie należy do nas. Jeśli ktoś nieumyślnie doprowadził do osłabienia organizacji i czuje się przytłoczony zakresem odpowiedzialności, jaka czeka go ścieżka wyjścia? Jak można zadbać o swoje interesy w organizacji znajdującej się na takim etapie?
Clement Kao: Zacząłbym od dołu. Pierwszym krokiem jest rozpoznanie, że jesteś przeciążony w sposób, na który się nie umawiałeś. Często ta świadomość w ogóle się nie pojawia, ponieważ pracujesz 70 lub 80 godzin tygodniowo i nie masz czasu pomyśleć: „Chwileczkę, to nie wygląda jak zarządzanie produktem”.
Warto poświęcić dziesięć minut na początku lub końcu tygodnia na refleksję: jak czuję się z pracą, którą obecnie wykonuję? Czy rzeczywiście zajmuję się produktem? Czy przesuwam właściwe wskaźniki? Czy wykonuję zadania o niskiej wartości tylko dlatego, że ktoś uznał, iż to ja muszę je zrobić?
Trzeba samodzielnie rozpoznać tę sytuację, bo bez tego nie można skutecznie działać we własnym imieniu. Następnie należy uzyskać wsparcie przełożonego. Menedżerowie często nie wiedzą, że wykonujesz dodatkową pracę. Mają własne wskaźniki, zarządzają wieloma osobami i mogą nie widzieć, ile czasu poświęcasz na zadania, które do Ciebie nie należą.
Gdy powiesz: „Spędzam dziesięć godzin tygodniowo na tych zadaniach”, przełożony prawdopodobnie zapyta: „Dlaczego? Szkoda, że nie powiedziałeś wcześniej, bo to nie powinno należeć do Ciebie”. Pomagasz mu realizować jego wskaźniki, ponieważ Twoje wskaźniki są częściowo również jego wskaźnikami.
Przedstaw, co robisz, ile czasu to zajmuje i dlaczego Twoim zdaniem wykonujesz te zadania. Następnie wspólnie zastanówcie się, co powinno należeć do innych zespołów. Może wykonujesz projekty UX i makiety, mimo że w firmie jest projektant. Może tworzysz doraźne zapytania SQL, choć istnieje zespół analityczny, który może zbudować pulpit automatyzujący tę pracę.
Gdy przestajesz być bohaterem i przekazujesz zadania właściwym zespołom, organizacja może się skalować. Warto rozmawiać z tymi zespołami, wyjaśniać, co robiłeś, dlaczego uważasz, że powinno należeć to do nich, i wspólnie przeprowadzić zmianę odpowiedzialności.
Po przekazaniu obowiązków trzeba regularnie sprawdzać, czy nowi właściciele czują się komfortowo i mają kontekst potrzebny do osiągnięcia sukcesu. Z czasem można ograniczyć częstotliwość spotkań.
Na końcu tej drogi odzyskujesz czas, który od początku powinien być przeznaczony na podstawową pracę produktową: poznawanie klientów, kreatywną współpracę z projektantami i inżynierami, budowanie atrakcyjnych i skalowalnych rozwiązań oraz współpracę z biznesem nad strategią wejścia na rynek.
Będziesz mieć więcej przestrzeni, aby skupić się na produkcie. Wiem, że to trudne, ponieważ sam przez to przechodziłem, ale efekt był bardzo wartościowy. Mogłem tworzyć produkty o większym wpływie i znacznie głębiej rozumieć klientów.
Warto również pamiętać, że menedżerowie produktu często bardzo chcą, aby inni odnieśli sukces, i dlatego spychają własne potrzeby na dalszy plan. Zamiast poświęcić dziesięć minut na zastanowienie się, co można przekazać, wybierają przygotowanie planu wdrożenia, uporządkowanie dokumentacji lub oczyszczenie zadań w backlogu.
Pomocne jest rozdzielenie siebie na dwie role. Jedna to osoba wykonująca zadania — Clement jako menedżer produktu. Druga to lider produktu, który wymaga, aby w kolejnym tygodniu powstał plan bardziej zrównoważonej pracy.
Możesz nadać tej drugiej osobie inne imię. Ja używałem swojego drugiego imienia, Richard. Mówiłem sobie: „Richard, dyrektor produktu, oczekuje, że w przyszłym tygodniu przygotujesz plan zwiększenia skalowalności pracy”. Dzięki temu traktowałem spotkanie z samym sobą jak rzeczywiste zobowiązanie.
To pomaga wyjść z roli osoby, która tylko wykonuje zadania. Jesteś również właścicielem strategii. Jako menedżer produktu sam jesteś ważnym interesariuszem i nie możesz zaniedbywać własnych potrzeb podczas realizacji produktu.
Hannah Clark: Uwielbiam nietypowe rozwiązania, szczególnie takie, które pozwalają spojrzeć z zewnątrz na własną wartość i wkład w pracę zespołu. To niesamowite, że najbardziej bohaterską rzeczą, jaką można zrobić w organizacji, jest wzmacnianie innych ludzi, a pośrednio także siebie.
Clement, bardzo dziękuję za udział w rozmowie. To było naprawdę świetne. Zawsze doceniam Twoje spostrzeżenia. Masz tak wiele do zaoferowania w tej dziedzinie. Gdzie można znaleźć Cię w internecie?
Clement Kao: Można znaleźć mnie na LinkedIn. Prawdopodobnie jestem jedynym Clementem Kao. Można też odwiedzić productteacher.com — bez spacji i bez myślników. To właśnie tam najczęściej pomagam osobom zajmującym się produktem osiągać sukces.
Hannah Clark: Świetnie. Do usłyszenia.
Clement Kao: Dziękuję za zaproszenie.
Hannah Clark: Dziękujemy za wysłuchanie. Po więcej ciekawych spostrzeżeń, poradników i recenzji narzędzi zapisz się do naszego newslettera pod adresem theproductmanager.com/subscribe. Więcej rozmów tego typu znajdziesz, subskrybując Klub CPO na dowolnej platformie, na której słuchasz podcastów.

