Jak budować zaufanie w zespole produktowym i zdobywać poparcie interesariuszy

Przeczytaj transkrypcję:

Próbujemy transkrybować nasze podcasty za pomocą programu komputerowego. Wybaczcie wszelkie literówki, ponieważ bot nie jest poprawny w 100% przypadków.

Hannah Clark: Nakreślmy sytuację: jesteś w sali konferencyjnej ze wszystkimi kluczowymi interesariuszami. Spoglądasz w lewo i widzisz dyrektora ds. obsługi klienta kończącego wiadomość e-mail. Po prawej stronie szef działu inżynierii ma skrzyżowane ramiona i podejrzliwie przygląda się Twojej prezentacji. Masz też niemal pewność, że główny projektant produktu ocenia układ Twoich slajdów. W jakiś sposób musisz przekonać wszystkie te osoby, aby podążały w tym samym kierunku. Zanim jednak będzie to możliwe, musisz zdobyć ich zaufanie. Jak więc możesz je zdobyć i uzyskać poparcie?

Dziś rozmawiam z Noą Goldman, główną menedżerką produktu w DagsHub. Kariera Noi rozpoczęła się w tworzeniu oprogramowania, więc poznała obie strony — co oznacza, że wie, jak trudno zdobyć poparcie w zespołach międzyfunkcyjnych i ostatecznie stworzyć dobre rozwiązanie problemów klientów. Noa podzieliła się swoim sposobem na zdobywanie poparcia interesariuszy, budowanie relacji i wzmacnianie efektów pracy zespołu. Zaczynajmy.

Bardzo dziękuję, Noa, że do nas dołączyłaś.

Noa Goldman: Dziękuję. Cieszę się, że tu jestem. Dziękuję za zaproszenie.

Hannah Clark: Tak, cieszymy się, że jesteś z nami. Noa, masz doświadczenie w tworzeniu oprogramowania, które z pewnością przydało Ci się na wiele sposobów. Chciałabym jednak, abyś opowiedziała nam, jak wpłynęło ono na Twoje podejście do zarządzania produktem.

Noa Goldman: Oczywiście. Przez osiem lat byłam programistką full-stack. Część tego okresu obejmowała służbę wojskową, część pracę w małych startupach i dużych korporacjach. Następnie przeszłam do zarządzania produktem, a dziś specjalizuję się w świecie narzędzi dla programistów — w czym bardzo pomogło mi doświadczenie programistyczne w tym obszarze.

Wpłynęło to na mnie w dużym stopniu. Po pierwsze, wykształciło we mnie silny nawyk myślenia zarówno o użytkowniku, jak i o profilu nabywcy. Wiem, że większość menedżerów produktu mówi, iż jest to dla nich bardzo ważne i że stale myślą o użytkowniku oraz profilu nabywcy. Z mojego doświadczenia wynika jednak, że często tak nie jest.

Dzięki temu, że jestem programistką, a teraz menedżerką produktu zajmującą się narzędziami dla programistów, zawsze myślę o obu tych grupach. Na przykład jeśli mamy funkcję, którą chcemy wydać, albo nowy produkt, który chcemy uruchomić, zawsze wyobrażam sobie siebie podczas korzystania z tej funkcji. Jak bym się z nią czuła?

Jak mój współpracownik czułby się z tą funkcją? Jak byśmy jej używali? Według czego jesteśmy oceniani? To naprawdę ważne, a mam wrażenie, że często się o tym zapomina. Kiedy wydajesz konkretną funkcję, zawsze chcesz pomyśleć o tym, według czego użytkownik jest oceniany — na jakiej podstawie — oraz czy ta funkcja lub konkretny produkt pomoże mu się poprawić albo wesprze go w osiąganiu wyników i w tym, jak jego kierownictwo ocenia go w danym przypadku użycia.

To oczywiście wpłynęło na mój sposób myślenia o profilu użytkownika, ale bardzo pomogło mi również w odniesieniu do profilu nabywcy. Ponownie mam wrażenie, że profil nabywcy jest stale pomijany podczas wydawania nowych funkcji i produktów.

Kiedy próbujemy uruchomić nowy produkt, zawsze zastanawiam się: dobrze, kto uczestniczy w procesie zakupu? Kto jest zaangażowany? Kto powinien podjąć tę decyzję? Na przykład myślę o sobie. Jako programistka poszłabym do lidera mojego zespołu z nową funkcją lub nowym produktem i powiedziałabym: „Hej, to jest świetne”.

A liderzy zespołów powiedzieliby: „W jaki sposób nam to pomoże?” albo „Dlaczego mielibyśmy płacić tej konkretnej firmie?”. Zawsze staram się więc myśleć również o tych profilach. To bardzo ważna część mojego bycia menedżerką produktu, w czym bardzo pomogło mi także doświadczenie programistyczne. Myślę również, że wpłynęło ono na mnie w kwestii ustalania priorytetów.

W przypadku każdej nowej funkcji nie zawsze muszę iść i pytać lidera zespołu. Mam wrażenie, że dla liderów zespołów lub liderów działów badań i rozwoju może to być nieco trudne, gdy menedżer produktu stale pyta ich, ile coś potrwa albo jaki będzie nakład pracy. Uważam więc, że do pewnego stopnia mogę robić to samodzielnie.

To bardzo mi pomogło i miało na mnie duży wpływ. Myślę jednak, że najważniejszą rzeczą, którą wyniosłam z pracy programistki, są relacje z innymi programistami. Wiem, jak jako programistka postrzegałam menedżera produktu, i wiem, jak postrzegali go moi współpracownicy. Nie zawsze jest miło i przyjemnie, a oni nie zawsze się z nim zgadzają.

Wydaje mi się, że wyniosłam z tego chęć, aby programiści, z którymi pracuję, dobrze się ze mną czuli i chcieli mi pomagać. Wiem, jak ważna jest relacja i wiem — a przynajmniej tak mi się wydaje — jak zdobyć ich zaufanie. Wiem więc, o co warto walczyć, a co jest mniej lub bardziej ważne. Myślę, że świadomość, iż to zaufanie jest ważne, bardzo mi pomogła, ponieważ wcześniej byłam programistką.

Hannah Clark: Chciałabym usłyszeć nieco więcej na ten temat. Jeśli menedżer produktu, który nas słucha, chce jak najlepiej współpracować z zespołem programistycznym, nie chce wywoływać niechęci ani napięć, to jakie dobre praktyki mogą pomóc menedżerom produktu skutecznie pracować z zespołem programistycznym?

Noa Goldman: Tak, oczywiście. Czasami pojawia się wiele konfliktów i może to być frustrujące dla obu stron. Ponieważ pracowałam po obu stronach, bardzo dobrze to rozumiem. Myślę, że jedną z najważniejszych rzeczy jest zawsze wyjaśnianie „dlaczego” oraz łączenie tego z aspektem biznesowym.

My, jako menedżerowie produktu, jesteśmy w centrum wszystkiego i stale rozmawiamy. Nieustannie współpracujemy z zespołem marketingowym, sprzedażowym albo z wyższym kierownictwem. Programiści nie robią tego często. Kiedy przedstawiasz programistom i zespołom badań i rozwoju coś, co chcesz opracować, dla Ciebie jako menedżera produktu jest bardzo jasne, czego chcesz, dlaczego tego chcesz i w jaki sposób ma to pomóc firmie.

Programiści, którzy słyszą o tym po raz pierwszy, niekoniecznie połączą jednak wszystkie elementy. Dlatego bardzo ważne jest wyjaśnienie „dlaczego” i powiązanie go z aspektem biznesowym. W moim przypadku wiem, że jeśli ktoś przychodzi i prosi mnie o zrobienie czegoś, nie zawsze się zgodzę, ponieważ nie jestem pewna, dlaczego mam to zrobić. Jeśli jednak wyjaśni mi, dlaczego i z jakiego powodu, a także jak pomoże to firmie, najprawdopodobniej poprę ten pomysł albo przynajmniej będę otwarta na rozmowę. Myślę, że to bardzo ważne. Jako menedżerowie produktu większość naszej pracy zależy od innych.

Rzadko robimy coś samodzielnie — na przykład opracowujemy funkcję albo prowadzimy marketing. Zawsze musimy wyjaśniać innym, co chcemy zrobić. Dlatego bardzo ważne jest wyjaśnienie „dlaczego” i połączenie wszystkich elementów z punktu widzenia biznesu. Myślę też, że bardzo ważne jest pokazywanie danych. Jeśli wyjaśniasz, dlaczego coś robisz, przedstawiasz aspekt biznesowy i pokazujesz, jak pomoże to firmie się rozwijać, potrzebujesz dowodów i musisz poprzeć to odpowiednimi danymi.

Jestem pewna, że każdy menedżer produktu albo większość z nich powie, że podejmuje decyzje na podstawie danych. W tych konkretnych sytuacjach, gdy pokazujesz coś zespołowi programistycznemu, szczególnie ważne jest jednak podejście oparte na danych. Ponownie: chcesz, aby Ci zaufali, chcesz zdobyć ich zaufanie i chcesz, aby poparli Twój pomysł. To kolejna bardzo ważna rzecz.

Kolejna rzecz, której nauczyłam się z czasem, może zabrzmieć dziwnie, ale po prostu wyrażaj uznanie. Jak powiedziałam wcześniej, duża część naszej pracy zależy od innych. Kiedy ktoś, na przykład programista, popiera nasz pomysł, wykonuje ciężką pracę i opracowuje funkcję, bardzo ważne jest, aby to zauważyć, docenić i wyrazić uznanie, mówiąc osobiście „Dobra robota” albo „Świetnie wykonane”, ale także na szerszym forum, aby wszyscy o tym wiedzieli.

Dla mnie osobiście, gdy ktoś docenia moją pracę, chcę wykonać ją dobrze — chcę kontynuować działania i pomagać. Powiedziałabym więc, że to właśnie najbardziej pomaga mi we współpracy z zespołem programistycznym.

Hannah Clark: Tak, myślę, że wyrażanie uznania jest bardzo ważne niemal w każdej roli. To jedna z tych prostych rzeczy, które ludzie zdają się pomijać, choć mogą one naprawdę wiele zmienić we wszelkiego rodzaju współpracy międzyfunkcyjnej.

Pozostając przy tym temacie: kiedy myślisz o współpracy z zespołami międzyfunkcyjnymi wykraczającej poza sam zespół programistyczny, jakie dobre praktyki okazały się przydatne, aby zapewnić sprawny rozwój funkcji i wspólne rozumienie sytuacji przez wszystkich, niezależnie od ich obszaru kompetencji?

Noa Goldman: Pamiętam jedną konkretną funkcję, która pomogła mi stworzyć własny sposób postępowania z długoterminowymi funkcjami wymagającymi dużego nakładu pracy i czasu. Była to konkretna funkcja. Udoskonaliliśmy proces wdrażania w firmie, w której pracowałam jako menedżerka produktu, i udało nam się zwiększyć współczynnik konwersji z 15% do 90%.

To było niesamowite, ale stanowiło bardzo długą podróż. Byłam młodszą menedżerką produktu, więc współpraca z zespołami międzyfunkcyjnymi, marketingiem, sprzedażą i wyższym kierownictwem była dla mnie bardzo trudna. Wtedy stworzyłam własny przepis na to, jak sobie z tym radzić. Pierwszym krokiem, jeszcze zanim przedstawisz zespołowi nową funkcję, jest upewnienie się, że motywacja jest właściwa i że wewnętrznie jest to odpowiednia rzecz do zrobienia w danym momencie.

Zanim przedstawię coś innym, sama chcę mieć pewność, że robię właściwą rzecz. Niezależnie od tego, jak wymagająca jest funkcja, zawsze staram się upewnić, że prawidłowo odczytuję sytuację. Oznacza to ciągłe słuchanie strony biznesowej i jej próśb, prowadzenie listy próśb użytkowników dotyczących funkcji oraz obserwowanie, jak użytkownicy korzystają z produktu.

Zawsze staram się więc upewnić, że mam obraz tego, jak obecnie wygląda sytuacja, co jest ważne dla firmy, a co nie. Kiedy pojawia się duża funkcja, najpierw sprawdzam sama ze sobą, czy jest to właściwa rzecz. Porównuję ją z posiadanym obrazem sytuacji i upewniam się: dobrze, to właśnie ma teraz największy sens i jestem gotowa to zrobić.

Upewniam się, że akceptuję tę decyzję. Następnie weryfikuję ją ponownie za pomocą danych. Sprawdzam, czy liczby mają sens. Porządkuję je bardzo dokładnie, analizuję i upewniam się, że są logiczne oraz że realizacja tej konkretnej długoterminowej funkcji zwiększy — albo zmniejszy — określoną wartość, którą chcemy osiągnąć.

Upewniam się, że dane są poprawne i mają sens. Dzięki temu sprawdzam również, czy nie zakochałam się po prostu w konkretnej funkcji. To dane przekonują mnie, że jest to właściwa rzecz do zrobienia. Kiedy już jestem w pełni przekonana, że należy to zrobić, szukam bardzo jasnego sposobu przedstawienia pomysłu. Staram się stworzyć jedno lub dwa zdania opisujące problem i wyjaśniające, dlaczego ważne jest jego natychmiastowe rozwiązanie.

Te zdania powinny wyjaśniać problem zarówno najbardziej technicznej, jak i najmniej technicznej osobie w pomieszczeniu. Ponieważ jest to praca zespołu międzyfunkcyjnego, chcę, aby sprzedaż, marketing, wyższe kierownictwo oraz liderzy zespołu badań i rozwoju bardzo jasno rozumieli: to jest problem, a jego rozwiązanie pomoże usprawnić działalność firmy.

Dbam więc o to, aby przedstawić problem tak jasno, jak czterolatkowi, a następnie biorę uporządkowane już dane i prezentuję je w bardzo przejrzysty sposób. Brzmi to dziwnie, ale zawsze trzeba zadbać o to, aby dane były dobrze zdefiniowane i przedstawione. Na przykład zielony oznacza coś dobrego, czerwony — coś złego. Używaj odpowiedniego wykresu.

To rzeczy, które brzmią banalnie, ale często nie są właściwie przedstawiane. Dbam więc o to, aby problem i dane, które go potwierdzają, były zaprezentowane bardzo dobrze i jasno, tak aby każdy w pomieszczeniu je zrozumiał. To drugi krok. Trzeci krok może zabrzmieć dziwnie, ale w mojej książce nazywa się „Dziel i zwyciężaj”. Może mieć nieco negatywne znaczenie, ale wcale taki nie jest.

Zasadniczo oznacza to, że zanim przedstawię funkcję wszystkim osobom w pomieszczeniu i wszystkim liderom zespołów międzyfunkcyjnych, staram się odbyć indywidualne rozmowy z każdym liderem każdego zespołu międzyfunkcyjnego. Zabierze mi to znacznie więcej czasu, ale będzie tego warte. Spotykam się osobno z szefem marketingu, szefem sprzedaży, szefem działu badań i rozwoju oraz wszystkimi innymi osobami zaangażowanymi w ten proces, które muszę przekonać do poparcia pomysłu.

Robiąc to, przede wszystkim sprawiam, że czują się wysłuchani i zauważeni. Jak powiedziałam wcześniej, jeśli chcesz, aby ktoś poparł Twój pomysł, ta osoba nie musi Cię słuchać ani się z Tobą zgadzać. Ma na głowie inne sprawy. Jeśli chcesz zdobyć jej poparcie, musisz sprawić, aby poczuła, że ma znaczenie i jest ważna.

Indywidualne spotkanie, krótka lub długa rozmowa — cokolwiek jest potrzebne — nawet jeśli zajmie Ci to nieco więcej czasu, będzie tego warte. Dzięki temu czują się wysłuchani, a kiedy już tak się czują, chcą Ci pomóc. Drugą korzyścią jest przygotowanie mnie do kolejnego kroku, czyli spotkania ze wszystkimi w jednym pomieszczeniu.

Wiem już, co wszyscy czują. Jestem przygotowana na ich pytania i wiem, jak odpowiedzieć na ich uwagi dotyczące tej funkcji. Wreszcie indywidualne rozmowy pomogą Ci także dlatego, że inni często mają naprawdę dobre pomysły, a Ty chcesz uwzględnić je w tej funkcji.

Oczywiście sprawisz, że poczują się bardziej zaangażowani, ponieważ ich pomysły zostaną uwzględnione, ale mogą też mieć dobre pomysły, których chcesz wysłuchać. Przeprowadzenie tych indywidualnych rozmów pomoże Ci stworzyć lepszą funkcję, nad której opracowaniem większość zespołu będzie chciała pracować. To właśnie ten krok — indywidualne spotkanie z każdą z tych osób.

Z mojego doświadczenia wynika, że po tym etapie większość zaangażowanych osób będzie już popierać pomysł, ponieważ czuje się częścią procesu i ma poczucie, że została wysłuchana. Kolejnym krokiem jest spotkanie zespołu, czyli zebranie wszystkich w jednym pomieszczeniu. To trochę trudne.

Możesz czuć zdenerwowanie, ale na tym etapie powinnaś być już przygotowana, ponieważ odbyłaś wszystkie indywidualne rozmowy. Zbierasz wszystkich w jednym pomieszczeniu i przedstawiasz im dokładnie to samo, co zaprezentowałaś podczas spotkań indywidualnych. Jeśli pamiętasz poprzednie kroki, masz jedno lub dwa zdania bardzo prosto opisujące problem, masz dane i rozmawiałaś już z każdą osobą znajdującą się w pomieszczeniu.

Po prostu robisz to ponownie i jeszcze raz przedstawiasz te informacje. Na tym etapie większość osób będzie popierać pomysł albo przynajmniej będzie otwarta na rozmowę. Podczas tego spotkania chcesz przede wszystkim upewnić się, że wszyscy zostali wysłuchani na tym samym, szerszym forum, a także uzyskać zgodę większości.

Nigdy, a przynajmniej prawie nigdy, nie uzyskasz zgody wszystkich osób w pomieszczeniu, ale kiedy wszyscy czują się wysłuchani, przynajmniej pozostają otwarci na pomysł. Na tym etapie większość powinna już popierać propozycję. To końcowy krok prowadzący do zdobycia poparcia wszystkich. Kolejne kroki nazywam po prostu „wyjściem na scenę”.

Kiedy wszyscy zgadzają się na opracowanie funkcji, a proces już postępuje, musisz zadbać o to, aby stale wszystkich informować. Wyjdź na scenę — co tydzień, co miesiąc albo podczas już istniejącego spotkania synchronizacyjnego — i poświęć kilka minut na aktualizację dla wszystkich. Zawsze lubię pokazywać zmiany wizualne.

Lubię dzielić dużą funkcję na mniejsze, szybkie zwycięstwa. Dzięki temu możemy wizualnie obserwować zmiany i postępy. Informując wszystkich na bieżąco, podtrzymujesz ich zaangażowanie. Chcą o tym słuchać, widzą, że robimy postępy, i to naprawdę pomaga. To także dobra okazja, aby pokazać dane, jeśli funkcja została już wydana, oraz zaprezentować sukcesy i porażki.

Dbaj tylko o to, aby przedstawiać proces bardzo jasno i uczciwie, a wszyscy będą popierać pomysł. To również świetna okazja, aby ponownie wysłuchać ich opinii i pomysłów oraz dowiedzieć się, co sądzą o poczynionych już postępach. Robienie tego podczas opracowywania funkcji zasadniczo pomaga wszystkim zespołom międzyfunkcyjnym stale ją popierać i chcieć pomagać.

Hannah Clark: To świetny proces. Myślę, że jest też bardzo łatwy do prześledzenia. Jestem jednak ciekawa, co dzieje się w sytuacji, gdy grupa jest bardziej podzielona, gdy nie ma pełnej zgody albo gdy nie ma wystarczającego konsensusu, aby funkcja mogła powstać. Jak sobie z tym radzisz?

Noa Goldman: Jeśli jestem pewna, że to właściwa rzecz do zrobienia i że ma sens dla firmy, zawsze staram się pamiętać, że ostatecznie wszyscy jesteśmy jednym zespołem i wszyscy chcemy, aby firma odniosła sukces. Ponownie próbuję więc dzielić i zwyciężać, wyjaśniać aspekt biznesowy oraz „dlaczego”, a także przekonywać ich, że wszyscy jesteśmy jednym zespołem.

Ostatecznie to działa. Jeśli nadal nie działa, staram się wybierać swoje bitwy. Jeśli ktoś nie popiera pomysłu, zastanawiam się, jak go przekonać — może pozwolić mu zająć się innymi funkcjami albo pomóc mu przeforsować jego priorytety w określony sposób.

Ponownie: dla mnie wszystko sprowadza się do relacji. Kiedy pomagasz komuś, ta osoba często chce odwdzięczyć się pomocą. Trzeba więc poruszać się w tych negocjacjach i zadbać o to, aby ostatecznie każdy otrzymał to, czego chce.

Hannah Clark: Tak, to ma sens. Przejdźmy więc trochę do ustalania priorytetów. Jak zawsze powtarzam, kiedy rozmawiamy o zarządzaniu i opracowywaniu funkcji, ustalanie ich priorytetów jest bardzo ważną częścią tego procesu. Jakie są Twoje sekrety sukcesu albo metody stosowane przy ustalaniu priorytetów funkcji?

Noa Goldman: Mam własną metrykę przewodnią, którą jest biznes. Cokolwiek firma potrzebuje, aby się rozwijać, jest moją metryką przewodnią. To właśnie z tym ostatecznie porównuję wszystkie działania, ponieważ moim zadaniem jest pomagać rozwijać się firmie i biznesowi.

Nie chodzi o funkcje, które lubię, ani o to, co moje zespoły chcą opracować w danym momencie. Chodzi o pomoc firmie. Opisałam już obraz sytuacji, który zawsze mam przed oczami. Stale śledzę prośby użytkowników, prośby biznesowe, potrzeby marketingu i cały rynek.

Staram się myśleć o biznesie. Przy każdej funkcji pytam: dobrze, czy to właśnie najbardziej pomoże teraz firmie się rozwijać? Jeśli ma to sens, a odpowiedź brzmi „tak”, zadaję kolejne pytanie: czy to najłatwiejszy sposób opracowania tej funkcji?

Jeśli chodzi o ustalanie priorytetów, zawsze wybiorę to, co najbardziej pomaga firmie, co jest najłatwiejsze do opracowania i wymaga najmniejszego nakładu pracy. To dwa pytania, które sobie zadaję. Jeśli potrafisz odpowiedzieć na te dwa pytania, potrafisz ustalić priorytety wszystkiego.

Hannah Clark: Prawie kończy nam się czas, ale chciałam zakończyć czymś nieco przyjemniejszym. Jedno z pytań, które ostatnio zadaję kilku naszym gościom, dotyczy muzyki i jest trochę nieoczywiste. Czy słuchasz muzyki w pracy albo poza nią? Jest jakiś artysta, album lub gatunek muzyczny, który szczególnie Cię teraz interesuje?

Noa Goldman: To bardzo ciekawe pytanie. Cieszę się, że je zadałaś. Nie wiem nawet, dlaczego tak bardzo się cieszę. Tak, zdecydowanie stale słucham muzyki. Staram się robić to podczas pracy nad rzeczami, które nie wymagają dużego skupienia, bo inaczej się rozpraszam. Moim głównym artystą, którego teraz słucham, jest Paulo Nutini.

Nie wiem, czy o nim słyszałaś, ale jest świetny. Właśnie wydał nowy album, który uwielbiam, a moim marzeniem jest zobaczyć go na koncercie. Prawdopodobnie do tego nie dojdzie, ale będę nad tym pracować, więc zobaczymy.

Hannah Clark: Świetnie. Nie słyszałam o nim, ale mam nadzieję, że uda nam się stworzyć playlistę podcastu dla menedżerów produktu na podstawie propozycji wszystkich naszych gości.

Noa Goldman: Bardzo bym chciała.

Hannah Clark: Chętnie go sprawdzę. Noa, bardzo dziękuję, że do nas dziś dołączyłaś. Naprawdę doceniam poświęcony czas i podoba mi się, że przedstawiłaś nam przepis w tak świetnym i łatwym do zastosowania formacie, który pozwala zdobyć konkretną wiedzę. Naprawdę doceniam, że z nami jesteś.

Noa Goldman: Dziękuję. Naprawdę bardzo mi się podobało. Bardzo dziękuję.

Hannah Clark: Dziękuję za wysłuchanie. Więcej świetnych spostrzeżeń, poradników i recenzji narzędzi znajdziesz, zapisując się do naszego newslettera pod adresem theproductmanager.com/subscribe. Więcej rozmów tego rodzaju usłyszysz, subskrybując podcast Product Manager w miejscu, w którym słuchasz podcastów.