Jak wykorzystać sposób myślenia założyciela w rozwiniętej firmie (z Brendanem Fortune’em)
Przeczytaj transkrypcję:
Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie zawsze działa w 100% poprawnie.
Hannah Clark: Szczere pytanie: jak myślisz, co jest trudniejsze — bycie założycielem startupu czy bycie pierwszym menedżerem produktu w startupie tego założyciela? Myślę, że można przedstawić argumenty przemawiające za każdą z tych odpowiedzi, zależnie od wcześniejszych doświadczeń. Choć to pytanie może być nieco subiektywne, sądzę, że możemy się zgodzić, iż obie role są głęboko zaangażowane w sukces produktu. I tu pojawia się problem: sukces menedżera produktu zależy również od jego zdolności do zdobycia i utrzymania zaufania kadry kierowniczej. A jeśli chcesz, żeby założyciel ci zaufał, być może musisz zacząć myśleć jak założyciel.
Moim dzisiejszym gościem jest Brendan Fortune, szef sztabu w Customer.io. W trakcie swojej kariery Brendan przekonał się na własne oczy, że przyjęcie sposobu myślenia założyciela jest ogromnym wsparciem dla menedżerów produktu, zwłaszcza w kontekście tworzenia produktu od zera. Za chwilę usłyszycie, jak dzieli się świetnymi spostrzeżeniami na temat zarządzania napięciami zamiast rozwiązywania problemów, szybkiego ponoszenia porażek, a także swoich ulubionych porażek oraz najbardziej emocjonalnego momentu na drodze od zera do jednego. Zaczynajmy.
Witamy ponownie w podcaście Klubu CPO.
Brendan, dziękuję, że jesteś dziś z nami. Jak się masz?
Brendan Fortune: Mam się świetnie. Dzięki, Hannah, za zaproszenie.
Hannah Clark: Czy możesz opowiedzieć nam trochę o swoim doświadczeniu i o tym, jak trafiłeś do obecnej roli w Customer.io?
Brendan Fortune: Zawsze fascynują mnie historie innych ludzi, ponieważ zwykle kończą się one w momencie, gdy dokonują przejścia do zarządzania produktem. Spróbuję więc opowiedzieć swoją.
Zacząłem pracę w dziale wsparcia IT, kiedy studiowałem w Los Angeles. Po ukończeniu studiów miałem dużo szczęścia. Zostałem zwerbowany przez rekrutera, którego nigdy wcześniej nie spotkałem, do pracy w startupie zatrudniającym 150 osób, działającym w obszarze telefonii internetowej. To była bardzo techniczna firma, więc pracowałem tam jako specjalista wsparcia technicznego. Wieczorami pisałem muzykę filmową, ponieważ wciąż miałem swoje wielkie hollywoodzkie marzenie.
Z czasem zrozumiałem, że muzyka filmowa jest dla mnie znacznie zdrowszym hobby niż zawodem. Zrezygnowałem z niej i rozpocząłem studia MBA w trybie łączącym naukę z pracą. Jeśli ktoś o nich nie słyszał — ja również wcześniej o nich nie słyszałem — to jest to coś w rodzaju studiów zaocznych. Pracujesz na pełny etat, a jednocześnie chodzisz do szkoły; całość trwa trzy lata.
Właśnie tam dowiedziałem się, czym jest zarządzanie produktem. To połączenie umiejętności technicznych, kreatywności i przywództwa było naprawdę ekscytujące. Wykorzystałem więc studia MBA jako dźwignię, aby zdobyć stanowisko młodszego menedżera produktu w firmie, w której wcześniej przez cztery lata pracowałem w dziale wsparcia technicznego, a następnie przeszedłem do IT.
To było trudne. Naprawdę trudne. Początkowo nie chcieli mi dać tej szansy. Prawdopodobnie mieli ku temu powody, ale ostatecznie, na szczęście, i tak zacząłem wykonywać tę pracę. Kilka miesięcy później udało mi się formalnie zdobyć to stanowisko. Następnie odszedłem z firmy jako dyrektor ds. produktu. Przez pewien czas pracowałem w GoDaddy w dziale hostingu.
Później pracowałem w Drip, platformie automatyzacji marketingu działającej w modelu SaaS. Obecnie jestem w Customer.io. Zaczynałem w dziale produktu, a teraz jako szef sztabu zajmuję się tworzeniem systemów organizacyjnych, które pomagają liderom inżynierii, produktu i projektowania wykonywać najlepszą pracę. Cokolwiek miałoby to oznaczać. Jest tam tak wiele różnych rzeczy.
Hannah Clark: Dziś skupimy się na sposobie myślenia założyciela i na tym, jak wygląda on w ramach ograniczeń rozwiniętej firmy. To zupełnie inna sytuacja niż w startupie.
Najpierw nakreślmy nieco temat. Jak zdefiniowałbyś sposób myślenia założyciela, gdybyś miał go podsumować, i jak wygląda on w praktyce?
Brendan Fortune: Uważam, że to bardzo ciekawe pytanie, ponieważ czasami określenie „sposób myślenia założyciela” może być dla mnie niemal onieśmielające. Myślę wtedy: nigdy nie założyłem własnej firmy. Czy to oznacza, że nie mogę myśleć jak założyciel? Czy coś jest ze mną nie tak?
Skoro próbuję budować produkty, dlaczego tego nie zrobiłem? Jednak po latach pracy z czterema założycielami zacząłem postrzegać to zupełnie inaczej. Dla mnie sposób myślenia założyciela oznacza skłonność do tworzenia własnych rzeczy zamiast podążania za tym, co stworzył ktoś inny. Może chodzić o nowy produkt, nową filozofię albo nowe podejście do zarządzania.
Tak naprawdę może chodzić o wszystko. Zachowaniem definiującym jest to, co robisz w obliczu wyzwania: czy odruchowo próbujesz stworzyć własne wyjście z sytuacji, czy szukasz odpowiedzi poza sobą? Sposób myślenia założyciela polega na tworzeniu własnego wyjścia. Nie oznacza to ignorowania wszystkiego, co powiedzieli inni, i robienia wszystkiego samodzielnie. Oznacza natomiast, że z natury sceptycznie podchodzisz do istniejących materiałów i pomysłów, dopóki naprawdę dobrze ich nie zrozumiesz.
Tak właśnie rozumiem sposób myślenia założyciela. Mogę wskazać kilka przykładów jego zastosowania. Spróbujmy. Pomyślmy o przykładzie związanym z produktem, skoro jest to podcast dla menedżerów produktu. Kiedy zostałem zatrudniony w GoDaddy, zespół kierowniczy powiedział mi: „Potrzebujemy, żebyś zbudował dla nas produkt hostingu w chmurze”.
Były to stosunkowo wczesne dni Amazon Web Services. Wydaje mi się, że Google dopiero wchodził do tej branży. GoDaddy uznało, że ma szansę odnieść sukces. Powiedziano mi więc, że właśnie tym mam się zająć. Trzy miesiące później wróciłem i powiedziałem: „Nie, to nie jest właściwy pomysł dla tej firmy”.
Zamiast tego powinniśmy stworzyć działalność z zakresu usług zarządzanych, opartą na Amazon Web Services. W tamtym czasie był to dość kontrowersyjny plan. Pamiętam rozmowy z niektórymi współpracownikami i przełożonymi. Pojawiało się poczucie: „Chwileczkę, nie powinieneś tego robić. Jakie będą polityczne konsekwencje?”.
Myślę, że sposób myślenia założyciela polega w tym przypadku na tym, aby w jak największym stopniu mówić o tym, w co naprawdę wierzysz, zamiast przedstawiać to, co twoim zdaniem może być właściwe albo co ktoś inny uważa za właściwe, jeśli sam nie rozumiesz tego w pełni.
Hannah Clark: Tak, to chyba nacisk na zaradność i pytanie: jak osiągnąć więcej przy mniejszych zasobach albo kreatywnie podejść do rozwiązań. Naprawdę wierzę w to, że kreatywność jest napędzana przez ograniczenia.
Przyjrzyjmy się bliżej sposobowi myślenia założyciela w kontekście projektów produktowych od zera do jednego. Jakie jest, twoim zdaniem, główne wyzwanie, przed którym staje menedżer produktu próbujący zbudować zupełnie nowy produkt?
Brendan Fortune: Uwielbiam to pytanie. Odwrócę jednak nieco perspektywę. Sądzę, że jednym z głównych wyzwań dla menedżera produktu w takiej sytuacji jest przezwyciężenie sposobu myślenia założyciela. Może to brzmieć nieintuicyjnie, bo jeśli tworzysz coś nowego, oczywiście musisz myśleć kreatywnie.
Istnieje jednak zagrożenie wynikające ze sposobu myślenia założyciela: poczucie, że skoro to stworzyłem, to naprawdę do mnie należy. Czy słyszałeś kiedyś, jak ktoś mówi o projekcie „moje dziecko”? Jeśli tak, to rozumiesz, że ludzie używają tego określenia, ponieważ poczucie własności może być aż tak silne. Projekt staje się niczym dziecko. Czasami ludzie mówią to żartobliwie, ale z mojego doświadczenia wynika, że w takich przypadkach nie ma w tym nic zabawnego.
Jeśli przychodzisz do firmy, aby stworzyć coś od zera do jednego, i próbujesz wykorzystać sposób myślenia założyciela, jednocześnie budując produkt z zespołem — a to jedyny znany mi sposób działania — powinieneś zrobić wszystko, aby dzielić tę drogę z innymi. Nie wiem, jak daleko można rozciągnąć tę analogię, ale chodzi o wspólne wychowywanie. Naprawdę nie chcesz robić wszystkiego samodzielnie. Wychowanie dziecka wymaga całej wioski.
To jedno z głównych wyzwań. Bardzo łatwo wpaść w pułapkę myślenia: „To ja muszę mieć pomysły. To ja muszę być właścicielem projektu. To ja muszę podejmować wszystkie decyzje”. Ostatecznie prowadzi to, moim zdaniem, do większej liczby porażek niż praca z zespołem. Główne wyzwanie to samotne działanie. Kiedy jednak wyruszasz w niebezpieczną podróż od zera do jednego, musisz od początku zaprosić do niej odpowiednich ludzi.
To sformułowanie zaczerpnięte z książki „Od dobrego do wielkiego” Jamesa Collinsa. Nadal bardzo ją cenię. Z czasem nieco się zestarzała, ale zawiera wiele świetnych wskazówek. Chodzi o to, że nie musisz dokładnie wiedzieć, dokąd zmierzasz i co dokładnie budujesz, zanim dowiesz się, kogo potrzebujesz na tej drodze.
Nie musisz najpierw powiedzieć: „Dołącz do mnie w tym przedsięwzięciu. Potrzebuję, żebyś wykonał tę pracę”. W książce chodzi o to, że musisz znać swoje mocne i słabe strony oraz znaleźć ludzi, których mocne strony w miarę możliwości równoważą twoje słabości.
To kwestia właściwego dopasowania elementów układanki. W ten sposób można przezwyciężyć część problemów związanych ze sposobem myślenia założyciela i poczuciem własności: „To moje dziecko”.
Hannah Clark: Rozwijając tę analogię do rodzicielstwa: chcesz znaleźć partnera, który podziela niektóre z twoich wartości, ale jednocześnie równoważy twoje słabości i dobrze uzupełnia twoje mocne strony. To naprawdę dobra analogia.
Chciałabym nieco bardziej zagłębić się w ideę zapraszania odpowiednich ludzi do autobusu. W teorii łatwo powiedzieć, jak zastosować to w praktyce. Jak, na podstawie swojego doświadczenia, oceniasz, kto powinien znaleźć się w autobusie? Jak rozpoznajesz mocne i słabe strony?
Brendan Fortune: Zacznijmy od prostych przykładów. Załóżmy, że jesteś geniuszem technicznym albo technicznym menedżerem produktu, ale brakuje ci umiejętności opowiadania historii i charyzmy, które pomagają przewodzić zespołowi. To dość częsty schemat.
Prawdopodobnie powinieneś znaleźć kogoś, kto posiada te umiejętności. Dotyczy to zwłaszcza budowania nowego produktu w istniejącej firmie. Wysiłek ewangelizacyjny nie ogranicza się do klientów, których próbujesz przekonać do zakupu produktu. Musisz również przekonać ludzi w samej firmie, szczególnie kadrę kierowniczą, ponieważ angażujesz w to przedsięwzięcie ludzi, energię i pieniądze.
Jeśli wiesz, że nie jest to twoja mocna strona, to przykład umiejętności, której powinieneś poszukać u innej osoby i zaprosić ją do zespołu. Inny przykład: jeśli budujesz produkt, o którym niewiele wiesz, nie rozumiesz jeszcze domeny, rynku ani klientów, musisz znaleźć kogoś, kto to rozumie. W przeciwnym razie powinieneś zadać sobie pytanie, czy jest to właściwy produkt do zarządzania i tworzenia od zera do jednego.
Jednym z największych zagrożeń jest osoba na stanowisku kierowniczym, która nie rozumie obszaru, w którym działa produkt. Zrozumienie i poczucie obszaru wymaga czasu. W przeszłości popełniłem błąd, sądząc, że szybko nadrobię te braki, i poniosłem porażkę.
Hannah Clark: Mogę sobie wyobrazić, jak mocno trzeba polegać na opiniach użytkowników i informacjach zwrotnych oraz ile trzeba się nauczyć, aby osiągnąć podstawowy poziom zrozumienia potrzebny do rozpoczęcia pracy nad produktem. To może być ogromne wyzwanie.
Chcę porozmawiać o szybkim ponoszeniu porażek. To niemal hasło — idea szybkiego ponoszenia porażek. Wiele kultur zespołowych przyjmuje ją na poziomie deklaracji, ale rzadko precyzyjnie określa, jak ma wyglądać w praktyce. Ile czasu i wysiłku powinniśmy poświęcić pomysłowi, zanim uznamy, że zakończył się niepowodzeniem? Jak w ogóle definiujemy porażkę? Czy współpracownicy mają psychologiczne bezpieczeństwo, aby powiedzieć: „Nie sądzę, żeby to działało”?
Brendan Fortune: Uwielbiam to pytanie, ponieważ dotyczy różnicy między tym, co ludzie mówią, a tym, co naprawdę praktykują i w co wierzą. W idei szybkiego ponoszenia porażek jest pewna wartość, ale sposób jej formułowania bywa mylący.
Łatwo pomyśleć, że oznacza ona: „Mogę ponosić tyle porażek, ile chcę”. Albo odwrotnie: „Ponieś porażkę szybko”, ale bez rzeczywistego przekonania, że to w porządku. Przywodzi mi to na myśl jedną z zasad przywództwa Amazonu: liderzy często mają rację. Mój brat przez pewien czas pracował w Amazonie i pamiętam, jak rozmawiałem z nim o tej zasadzie. Powiedział: „Ta zasada jest bez sensu. Przecież powinieneś wzmacniać swój zespół. Liderzy nie powinni podejmować wszystkich decyzji”.
To nieco inna rozmowa, ale myślę, że szybkie ponoszenie porażek często oznacza po prostu: „często masz rację”. Owszem, czasami ponosisz porażkę, ale tak naprawdę szybko osiągasz sukces dzięki porażkom.
To prowadzi do pytania, jak definiujemy sukces i porażkę. Klasyczne pytanie zadawane przez inteligentną osobę brzmi: „Jakie są wasze mierniki sukcesu?”. To dobre i pobudzające do myślenia pytanie. Powinniśmy mieć na uwadze pewne mierniki sukcesu, ale nie zawsze musimy je dokładnie zdefiniować przed podjęciem jakichkolwiek działań.
W przypadku wszystkich produktów, które budowałem od zera do jednego, nigdy nie zdarzyło się, aby początkowe mierniki sukcesu zadziałały dokładnie tak, jak planowaliśmy. Mam świeży przykład z Customer.io. Najnowszy produkt, nad którym pracowaliśmy, nazywa się Customer.io Data Pipelines.
To platforma danych klientów, czyli centralny punkt integracji wszystkich danych firmy. Przekazujesz tam dane klientów, takie jak ich imiona i zachowania w produkcie, a następnie możesz łatwo wysłać je do różnych miejsc, na przykład do systemu CRM albo narzędzia automatyzacji marketingu.
Kiedy około półtora roku temu zaczynaliśmy pracę nad tym projektem, zaplanowane mierniki sukcesu zakładały zdobywanie klientów konkurencji dzięki niższej cenie oraz generowanie dwucyfrowych miesięcznych przychodów cyklicznych od nowych klientów korzystających wyłącznie z tego produktu.
Chcieliśmy również zarabiać wystarczająco dużo, aby opłacić zespół potrzebny do budowy produktu. Sześć miesięcy po uruchomieniu produktu zgadnij, ile z tych mierników sukcesu osiągnęliśmy.
Hannah Clark: Zgaduję, że zero albo jeden.
Brendan Fortune: Zero. Dokładnie zero. Ale nie zamknęliśmy projektu. Dlaczego? Nie dlatego, że wpadliśmy w pułapkę kosztów utopionych. Po prostu znaleźliśmy sukces w innych, nieoczekiwanych miejscach.
Odkryliśmy, że najlepiej radzili sobie klienci, którzy wcześniej nigdy nie korzystali z platformy danych klientów. Zobaczyliśmy też początki nowego koła zamachowego ekonomiki produktu. Początkowo wyceniliśmy produkt tak jak większość podobnych platform — według liczby wywołań interfejsu programistycznego.
Im więcej danych wysyłasz, tym większą wartość możesz uzyskać z produktu, a my pobieramy za to więcej. Klienci, którzy wdrażają produkt, zwiększają wykorzystanie z miesiąca na miesiąc. To kluczowe dla ekonomicznego koła zamachowego Customer.io.
Nie zdobyliśmy klientów konkurencji niższą ceną. Osoby korzystające już z konkurencyjnych rozwiązań mówiły: „To w porządku, ale mogę dostać rabat”. Nie było tam praktycznie żadnego zainteresowania. Rozwijaliśmy się znacznie wolniej. Próbowaliśmy zdobywać przychody, podczas gdy powinniśmy byli budować koło zamachowe wzrostu, które z czasem przełoży się na przychody.
Dlatego produkt nadal się rozwija. Jeśli tworzysz coś od zera do jednego, uważnie określ mierniki sukcesu, ale spodziewaj się, że będą ewoluować. Możesz znaleźć sukces w innych obszarach. Jeśli odnosisz sukces gdziekolwiek, projekt powinien być kontynuowany. Porażka następuje wtedy, gdy naprawdę nie znajdujesz sukcesu w żadnym miejscu.
Hannah Clark: To bardzo trafne spostrzeżenie. Wielu z nas zna sytuacje, w których oczekiwany rezultat nie pojawia się dokładnie w przewidywanej formie. Nie oznacza to jednak, że nie można uzyskać innej wartości ani osiągnąć kolejnych kamieni milowych prowadzących do przyszłych korzyści.
Skoro rozmawiamy o porażkach, chcę postawić cię nieco w ogniu pytań. Jaka jest twoja ulubiona porażka w karierze — taka, która przyniosła ci najwięcej wartości?
Brendan Fortune: Mam wiele ulubionych błędów i porażek. Pierwsza, która przychodzi mi do głowy, wydarzyła się w GoDaddy. Budowaliśmy nowy produkt o nazwie Enterprise WordPress. Był to produkt hostingowy dla dużych agencji tworzących strony internetowe, na przykład dla ABC.com.
Chcieliśmy stworzyć produkt skalujący się wraz z ruchem, którego potrzebowały te agencje, a jednocześnie zachowujący elastyczność WordPressa, bardziej dostępnego dla osób o mniejszej wiedzy technicznej.
Mieliśmy dobre relacje z klientami i uruchomiliśmy pilotaż w kilku agencjach. Pracowaliśmy nad produktem przez dziewięć miesięcy do roku, z zespołem pięciu lub sześciu osób, głównie inżynierów. Zamknęliśmy projekt miesiąc lub dwa po premierze.
Zbudowaliśmy coś, co od początku było skazane na niepowodzenie. Nie można było w czysty sposób przenieść strony ze środowiska testowego do produkcyjnego. Wydawało nam się, że jesteśmy bardzo sprytni technicznie: chcieliśmy zapewnić bezpieczeństwo, uniemożliwiając bezpośrednie zmiany w środowisku produkcyjnym.
Okazało się jednak, że klienci zupełnie tego nie chcieli, a my tego nie zweryfikowaliśmy. Powiedzieliśmy im tylko: „Oto, co planujemy”, i usłyszeliśmy kilka przytaknięć. Wpadliśmy prosto w pułapkę testu mamy.
Nauczyłem się, że jeśli uważasz, że jesteś sprytny, upewnij się, że naprawdę masz rację. Jeśli w zespole nie ma osoby z dużą wiedzą domenową, trzeba zachować ostrożność. Nawet jeśli współpracują z tobą klienci, musisz uważać. W naszym zespole, łącznie ze mną, nie było nikogo, kto dobrze znałby Enterprise WordPress.
Hannah Clark: Dla osób, które nie znają testu mamy, możesz krótko wyjaśnić, na czym polega?
Brendan Fortune: Jeśli pytasz kogoś, komu zależy na tobie i kto chce, żebyś odniósł sukces — na przykład typową mamę lub rodzica — czy uważa, że twój pomysł jest świetny, prawdopodobnie otrzymasz odpowiedź, której oczekujesz. Nie dostaniesz szczerej ani krytycznej informacji zwrotnej, której potrzebujesz, aby sprawdzić, czy ktoś rzeczywiście kupiłby twój produkt.
To duża różnica między „Popieram to” a „Wpłacę pieniądze i zapłacę za ten produkt”. Na tym polega test mamy.
Hannah Clark: To bardzo zabawne, bo szczególnie w Ameryce Północnej wiele osób jest kulturowo przyzwyczajonych do mówienia: „Tak, tak, świetny pomysł”, a potem budujesz coś, czym w rzeczywistości wcale nie są zainteresowane.
Brendan Fortune: Dokładnie. To prowadzi mnie do rozmowy o radykalnej szczerości — modelu Kima Scotta, który przeciwstawia szkodliwą empatię nieprzyjemnej agresji. To osobny, bardzo ciekawy temat. Kiedy mówisz o kulturze Ameryki Północnej i o tym, że ludzie chcą wspierać innych, unikając bezpośredniej krytyki, właśnie o tym myślę. Potrzebna jest radykalna szczerość, choć jest ona całkowicie niezgodna z dominującą kulturą.
Hannah Clark: Radykalna szczerość jest szczególnie ważna w zespole produktowym. Mogę sobie tylko wyobrazić, ile pieniędzy — tysięcy, a zapewne milionów dolarów — zmarnowano, ponieważ ludzie nie praktykowali radykalnej szczerości.
Brendan Fortune: Miliardów. Nie sądzę, żebym kiedykolwiek pracował w firmie, która naprawdę dobrze sobie z tym poradziła. Jednym z powodów jest to, że kultura jest kwestią wymagającą stałego zarządzania, a nie problemem, który można raz na zawsze rozwiązać.
Nie można powiedzieć: „Udało się, mamy już kulturę radykalnej szczerości i od tej pory wszystko będzie działać”. To bardzo nieuporządkowany proces. Istnieje napięcie między tym nieuporządkowaniem a profesjonalizmem.
Kiedy próbuję zbudować z kimś zaufanie i dochodzę do pierwszej rozmowy o informacji zwrotnej, często mówię o własnych aspiracjach zawodowych. To wrażliwy temat. Otwarcie się na coś jest ryzykowne i może wyglądać jak polityczna kalkulacja, czyli dokładnie odwrotnie niż powinno wyglądać budowanie zaufania.
Potrzebujesz zaufania, aby praktykować radykalną szczerość. Samo powiedzenie komuś, co myślisz, z założeniem, że masz rację i druga osoba musi cię wysłuchać, również jest toksyczne — po prostu w inny sposób.
Ludzie często próbują deeskalować takie sytuacje. Widzą konflikt i mówią: „Przestańcie się spierać”. W ten sposób go zabijają. Radykalna szczerość znika. Myślisz, że pomagasz, ale radykalna szczerość wiąże się z konfliktem. Konflikt jest ryzykiem, ale może być też nagrodą.
Hannah Clark: Konflikt jest właściwie szansą. Mamy na ten temat cały artykuł, więc możecie go sprawdzić.
Wspomniałeś o napięciach, którymi trzeba zarządzać. Chodzi o ramę „napięcia do zarządzania kontra problemy do rozwiązania”. To bardzo interesująca koncepcja, ponieważ odnosi się do wielu obszarów zarządzania ludźmi. Czy możesz ją wyjaśnić?
Brendan Fortune: Przyjmę perspektywę menedżera produktu. Kiedy zaczynałem pracę w zarządzaniu produktem, byłem motywowany do dostarczania rzeczy. Rozwiązywaliśmy problemy klientów, dostarczając funkcje. Po dostarczeniu pojawiało się poczucie ukończenia.
Pracujemy z zadaniami, historiami użytkowników i innymi elementami, które można zamknąć. Widzimy sekwencję postępu. Kiedy przechodzisz do szerszej roli, na przykład menedżera ludzi, łatwo przyjąć ten sam sposób myślenia: „Zidentyfikuję problemy, dostarczę rozwiązania i problemy znikną”.
Rzeczywistość jest inna, ponieważ ludzie nieustannie się zmieniają. Nawet jeśli skład zespołu się nie zmienia, napięcia i problemy ciągle ewoluują. Ponadto masz rozwijać swoich ludzi. Chcesz, aby się zmieniali, a gdy się zmieniają, musisz zarządzać nimi inaczej.
Dlatego pomocne jest dla mnie traktowanie tych kwestii jako napięć, którymi trzeba zarządzać, i zakładanie, że w chwili rozwiązania problem znów stanie się nierozwiązany. Trzeba pozostawać w kreatywnym, twórczym sposobie myślenia. To może być wyczerpujące, ale doskonale łączy się ze sposobem myślenia założyciela.
Jeśli lubisz tworzyć, jest to idealne podejście. Zarządzanie napięciami pasuje do sposobu myślenia założyciela. Tak myślę o budowaniu zgodności i zarządzaniu ludźmi. Trzeba być gotowym do adaptacji i tworzenia. Nie ma podręcznika, który zdejmie z ciebie konieczność zarządzania napięciami.
Hannah Clark: Bardzo podoba mi się ta idea, ponieważ jako menedżer ludzi nie oczekujesz wtedy ostatecznego rozwiązania. Taki sposób myślenia pozwala lepiej zarządzać własną energią.
Skoro mówimy o tym samym temacie, chciałabym porozmawiać o zgodności. Każdy ma chyba inne wyobrażenie o tym, co zgodność oznacza w zespole, ale jest ona niezwykle ważna. Jakie masz wskazówki dotyczące uzgadniania zespołu wokół ważnego rezultatu, takiego jak zupełnie nowy produkt?
Brendan Fortune: Ostatnio dużo o tym myślałem w związku z Data Pipelines. Są dwie rzeczy, które działają bardzo dobrze, choć zacząłem je stosować zbyt późno. Pierwsza to indywidualna informacja zwrotna.
Załóżmy, że przygotowałem plan działania na ten rok, wizję, tablicę wizji i kilka makiet. Kuszące jest zebranie wszystkich w jednym pomieszczeniu, zaprezentowanie wizji i przeprowadzenie sesji pytań i odpowiedzi. Można wtedy pomyśleć: „Świetnie, ludzie zadali pytania i wydają się zaangażowani. Mamy zgodność”.
W praktyce grupowe uzgadnianie nie działa. Po miesiącu lub dwóch okazuje się, że jedna osoba nie rozumiała, o czym mówiliśmy, nie miała okazji się zaangażować i nie czuła się wysłuchana. Jeśli nie czujesz się wysłuchany, nie możesz nawet zgodzić się na odmienne zdanie i mimo to zobowiązać się do działania, ponieważ nie zostałeś wysłuchany.
Jeśli masz prezentację, którą chcesz przedstawić grupie, najpierw zrób to indywidualnie. Zbierz informacje zwrotne od właściwych interesariuszy w rozmowach jeden na jeden i upewnij się, że możesz powtórzyć własnymi słowami to, co usłyszałeś. Wskaż miejsca niejasności. Zdalnie można wykorzystać tablicę, umieszczając na niej notatki z wypowiedziami ludzi, aby widzieli, że ich słuchasz.
Nie oszczędzaj na tym czasie, szczególnie w przypadku głównego zespołu. Jedno trzydziestominutowe spotkanie nie wystarczy. Potrzeba kilku rozmów.
Druga rzecz dotyczy zgodności na poziomie kierownictwa. Istnieje pojęcie mapy drogowej uczenia się. Nie pamiętam, gdzie o nim przeczytałem, ale nie jest to mój pomysł. W moim doświadczeniu kadra kierownicza chce widzieć postęp: co dostarczacie, gdzie jest wartość, na co przeznaczane są pieniądze i jaki jest zwrot z inwestycji.
Podczas tworzenia produktu od zera przez długi czas nie ma jeszcze pieniędzy, które można pokazać. Kierownictwo rozumie to w teorii, ale jeśli nigdy samodzielnie nie budowało produktu, może naciskać na szybsze działanie. Mapa drogowa uczenia się pozwala pokazywać postęp, zanim pojawią się pieniądze.
Zamiast powiedzieć: „Dostarczymy tę funkcję do określonej daty”, możesz powiedzieć: „W tym tygodniu odpowiemy na następujące pytania”. Na przykład: czy produkt powinien być samodzielnym rozwiązaniem, czy powinien zostać zintegrowany z istniejącym produktem?
Zbierasz rozmowy z klientami, analizę rynku i inne sygnały, a następnie zapisujesz odpowiedź wraz z dowodami. Dostarczasz tę wiedzę i możesz przejść do kolejnego pytania, na przykład dotyczącego modelu cenowego.
Możesz również zapytać: ilu klientów podpisałoby umowę i zapłaciło za to, co budujemy? To przeciwieństwo testu mamy — zamiast pytać, czy ktoś uważa pomysł za dobry, pytasz, czy podpisze dokument zobowiązujący go do zapłaty.
Jeśli zapiszesz założenia, które testujesz, i pytania, na które musisz odpowiedzieć, a następnie umieścisz je na mapie drogowej uczenia się, możesz pokazywać postęp związany z wiedzą obok postępu związanego z funkcjami. To dobry sposób na uzyskanie zgodności na poziomie kierownictwa. Pozwalasz kadrze śledzić postęp, wyrażać opinie i współtworzyć rozwiązanie.
Hannah Clark: To świetna wskazówka dotycząca zarządzania napięciem.
Na zakończenie chcę porozmawiać o tym, że produkt stworzony od zera do jednego jest niczym dziecko, ale każde dziecko musi dorosnąć. Jak wygląda przejście od produktu, który udało się doprowadzić od zera do jednego, do kolejnego etapu? Dlaczego jest ono tak trudne i jak można zarządzać tą zmianą, gdy czujemy silne poczucie własności lub rodzicielstwa wobec projektu?
Brendan Fortune: Najlepszym rozwiązaniem jest nie pozwolić, aby produkt od początku stał się twoim dzieckiem. To trudne, ponieważ przy produktach tworzonych od zera do jednego musisz wierzyć w nie bardziej niż ktokolwiek inny. Jesteś ich ewangelizatorem i przelewasz w nie część swojej duszy. W ten sposób produkt staje się częścią twojej tożsamości.
Sugerowałbym określenie punktu końcowego i przejęcie kontroli nad przekazaniem produktu dalej, aby nie czuć, że dzieje się to bez twojego udziału. To ty sprawiasz, że przekazanie następuje.
W przypadku Data Pipelines odpowiedni moment pojawił się kilka miesięcy po osiągnięciu ogólnej dostępności, gdy firma potrzebowała szefa sztabu. Wtedy uznaliśmy, że jest to dobry moment, aby znaleźć kogoś innego. Wiedziałem, kogo potrzebujemy, więc mogłem zatrudnić tę osobę i wdrożyć ją do pracy.
Jeśli możesz wybrać moment przekazania, jest to emocjonalnie łatwiejsze. Jest też cytat z Yody, który dobrze do tego pasuje: przekaż dalej to, czego się nauczyłeś — siłę, mistrzostwo, ale również słabości i porażki. Mówi on, że jesteśmy tym, co nasi następcy przekraczają. To prawdziwy ciężar wszystkich mistrzów.
Może dziwnie jest myśleć o sobie jako o mistrzu produktu, ale chodzi o podobną ideę: „To ja to rozwinąłem i do mnie należy”. Prawdziwy sukces następuje wtedy, gdy ktoś inny potrafi wykonywać tę pracę lepiej od ciebie. To samo dotyczy zarządzania ludźmi. Jeśli w to uwierzysz, łatwiej będzie cieszyć się z przekazania produktu.
Hannah Clark: To było piękne. Wybaczam ci, że nie użyłeś głosu Yody.
To była niezwykle ciekawa rozmowa, Brendan. Bardzo doceniam, że do nas dołączyłeś i podzieliłeś się tymi spostrzeżeniami.
Gdzie można cię obserwować lub znaleźć w internecie?
Brendan Fortune: Chętnie połączę się z ludźmi na LinkedInie. Jeśli ktoś ma pytania albo próbował zastosować te rzeczy i nie zadziałały, chętnie o tym usłyszę. Jestem też na Twitterze jako @mnproductmgr, czyli product MGR. To może być nieco mylące. Mieszkam w Minnesocie, stąd „MN”.
Hannah Clark: Niedoceniany stan. Rozmawialiśmy już o tym.
Dobrze, Brendan. Bardzo dziękuję. Mam nadzieję, że wkrótce znów porozmawiamy.
Brendan Fortune: Dziękuję, Hannah.
Hannah Clark: Dziękujemy za wysłuchanie. Aby poznać więcej wartościowych spostrzeżeń, poradników i recenzji narzędzi, zasubskrybuj nasz biuletyn pod adresem theproductmanager.com/subscribe. Więcej takich rozmów znajdziesz, subskrybując Klub CPO w dowolnym miejscu, w którym słuchasz podcastów.

