Zgodność dzięki planom rozwoju produktu (z Brandonem Blackmanem z Crema)
Michael Luchen
Plany rozwoju produktu to kluczowy dokument, który może wzmacniać współpracę w wielu zespołach produktowych albo ograniczać ich potencjał przez brak zgodności. Wszyscy znamy plany rozwoju produktu, ale co by było, gdyby można je było wykorzystywać do budowania prawdziwej, autentycznej współpracy? Co by było, gdyby zamiast postrzegać je jako statyczny dokument, traktować je jako coś organicznego, przejrzystego i iteracyjnego? Dziś rozmawiamy z doskonałym menedżerem produktu, którego doświadczenie obejmuje zarówno opiekę zdrowotną, jak i rozwój produktów dla przedsiębiorstw. Porozmawiamy o planach rozwoju produktu i o tym, jak najlepiej wykorzystywać je do tworzenia świetnych produktów. Zostańcie z nami.
To jest podcast dla menedżerów produktu — głosy społeczności, która tworzy podręcznik zarządzania produktem, rozwoju produktów i strategii. Sponsorem programu jest Crema, agencja produktów cyfrowych, która pomaga osobom i firmom rozwijać się dzięki kreatywności, technologii i kulturze. Dowiedz się więcej na crema.us.
Słuchaj dalej, aby poznać praktyczne i autentyczne wskazówki, które pomogą Ci odnieść sukces w świecie zarządzania produktem.
Z ogromną radością witam dziś
Brandon Blackman w naszym podcaście. Doświadczenie Brandona w zarządzaniu produktem rozpoczęło się w startupie z branży technologii medycznych, a następnie objęło nadzorowanie rozwoju sklepów internetowych, aplikacji mobilnych i aplikacji internetowych dla przedsiębiorstw. Brandon z pasją pomaga wcielać pomysły w życie.
Jego pasją jest motywowanie wysokowydajnych, zwinnych i interdyscyplinarnych zespołów produktowych. Oprócz tego, że miałem okazję współpracować z Brandonem w firmie Crema, jest on także członkiem rady dyrektorów HealthSplash — platformy opieki zdrowotnej skoncentrowanej na rozwiązywaniu problemu odrzucanych roszczeń medycznych wynikających z nieprawidłowych danych.
Brandon, witamy w programie.
Brandon Blackman
Cześć. Bardzo się cieszę, że tu jestem.
Michael Luchen
Dziękuję, że do nas dołączyłeś. Zaczynamy rozmowę o planowaniu rozwoju produktu?
Powiązana lektura: Jak wykorzystać mapowanie historyjek użytkownika do usprawnienia ustalania priorytetów rejestru zadań w podejściu zwinnym
Brandon Blackman
Tak. Bardzo się cieszę, że będziemy o tym rozmawiać.
Michael Luchen
Ja również. To jeden z tych tematów, na temat których istnieje wiele opinii i wiele właściwych sposobów działania.
Zacznijmy od podstaw. Jakie masz osobiste doświadczenia z planami rozwoju produktu?
Brandon Blackman
Jako menedżer produktu siłą rzeczy mam z nimi duże doświadczenie. Są kluczową częścią naszego procesu i przepływu pracy związanego z rozwojem produktu. Powiedziałbym jednak, że moje doświadczenie opiera się głównie na metodzie prób i błędów. Pamiętam pierwsze plany, które przygotowywałem. Były bardzo mocno skoncentrowane na datach i niemal przypominały podejście kaskadowe. Nic nigdy nie było realizowane zgodnie z terminem zapisanym w planie. Zamiast pomagać, plany stawały się źródłem stresu i niepokoju, gdy interesariusz albo ktoś z kierownictwa pytał: „Kiedy możemy spodziewać się tego elementu? Czy mogę zobaczyć plan?”. Myślałem wtedy: „Wpakowałem się w kłopoty, ale muszę im go pokazać”. Tak zaczynałem pracę z planami i właśnie to skłoniło mnie do szukania lepszego sposobu.
Dużo o tym czytałem, prowadziłem badania i eksperymentowałem w zespołach produktowych, w których pracowałem. Bardzo podoba mi się obecne podejście. Naprawdę lubię plan rozwoju produktu. Stał się nieocenionym narzędziem dla mnie, mojego zespołu oraz naszych użytkowników i interesariuszy — zarówno wewnętrznych, jak i zewnętrznych.
Michael Luchen
To świetne. Opowiedziałeś o początkach i o tym, jak zaczynałeś od bardzo sztywnych planów kaskadowych, a następnie napotykałeś ich ograniczenia. Jaka jest Twoja osobista filozofia dotycząca planów rozwoju produktu?
Brandon Blackman
Najważniejsze zasady są proste: utrzymuj plan na wysokim poziomie, ponieważ im bardziej szczegółowy się staje, tym większe ryzyko niespełnionych oczekiwań; stale go aktualizuj; i nieustannie wydawaj kolejne wersje produktu. W przypadku produktów cyfrowych należę do zwolenników wczesnego i częstego publikowania.
Michael Luchen
Jaki powinien być ostateczny cel planu rozwoju produktu?
Brandon Blackman
Plan powinien komunikować kierunek rozwoju produktu. Powinien odzwierciedlać także kierunek obrany przez całą firmę lub organizację. Jego podstawowym zadaniem jest zapewnienie zgodności wszystkim osobom zaangażowanym w produkt — użytkownikom, zespołowi produktowemu i kadrze kierowniczej. Musimy zgrać ludzi o różnych perspektywach wokół tego, czego mogą spodziewać się w przyszłości. Plan powinien więc jasno i zwięźle informować wszystkich interesariuszy, dokąd zmierzamy z produktem.
Michael Luchen
Czyli jest trochę jak opowieść, która ciągle się zmienia, ponieważ służy wielu interesariuszom.
Brandon Blackman
Dokładnie. W dobrej historii nie chcemy zanudzać odbiorcy zbyt wieloma szczegółami. Plan powinien być angażujący i dostarczać tylko tyle informacji, ile potrzeba do osiągnięcia celu, czyli zapewnienia zgodności. Nie powinien być jednak tak szczegółowy, abyśmy przez nadmierną precyzję zaczęli pomijać wymagania lub nie dotrzymywać terminów.
Michael Luchen
Czy plan powinien być statycznym dokumentem, czy raczej czymś organicznym i iteracyjnym?
Brandon Blackman
Zdecydowanie powinien być organiczny i iteracyjny. Jeśli jest statyczny, prawdopodobnie przyjęliśmy błędne założenia dotyczące użytkowników albo sposobu działania produktu po uruchomieniu. Plan jest prognozą — pokazuje przyszłość, której nie da się w pełni przewidzieć, niezależnie od ilości planowania. Najdokładniejsza prognoza powstaje wtedy, gdy obserwujemy teraźniejszość i na jej podstawie korygujemy przyszłe przewidywania. Dlatego plan powinien być stale aktualizowany i nigdy nie należy zakładać, że istnieje jego ostateczna wersja.
Michael Luchen
Kiedy tworzysz plan dla produktu, na czym powinien się on koncentrować?
Brandon Blackman
Na „dlaczego” i „co”, a nie na „jak”. Pokusa skupienia się na sposobie realizacji jest szczególnie silna u osób, które nie mają dużego doświadczenia w planowaniu. Pytanie „jak” należy pozostawić rejestrowi zadań. Plan powinien odpowiadać na pytania: dlaczego zmierzamy w tym kierunku, dlaczego skupiamy się na określonych elementach i co dokładnie chcemy zbudować. Sposób realizacji powinien zostać opisany w rejestrze zadań.
Michael Luchen
W planach często umieszczamy statusy, tematy i rezultaty. Jak należy je rozumieć?
Brandon Blackman
Statusy mogą oznaczać: „nad tym pracujemy teraz”, „tym zajmiemy się w następnej kolejności” oraz „tym zajmiemy się później”. Zauważ, że nie ma przy nich konkretnych dat. Data może czasem być potrzebna, ale jej dodanie tworzy zobowiązanie, które mogło być niepotrzebne.
Temat może dotyczyć na przykład relacji z klientami. Następnie można określić elementy, epiki i historyjki użytkownika, które przyczyniają się do realizacji tego tematu. Plan skoncentrowany na rezultacie może natomiast określać cel, taki jak zwiększenie liczby interakcji z klientami o 30 procent. To dobre „dlaczego” i „co”. Sposób realizacji pozostaje w rejestrze zadań i należy do ekspertów wchodzących w skład zespołu produktowego.
Michael Luchen
Wiele osób chciałoby unikać dat, ale interesariusze często wymagają informacji o terminach. Jak sobie z tym radzisz?
Brandon Blackman
Gdybym mógł decydować, daty nigdy nie pojawiałyby się w planie. W rzeczywistości dyrektor generalny, zespół marketingowy i obsługa klienta potrzebują informacji o terminach. Dlatego trzeba stosować daty w pewnym zakresie, ale najlepiej podawać je na możliwie wysokim poziomie. Najczęściej dobrze sprawdzają się plany kwartalne. Można powiedzieć, że do drugiego kwartału zwiększymy liczbę interakcji z klientami o 30 procent. To daje marketingowi wystarczająco dużo informacji do przygotowania kampanii, a obsłudze klienta — do przygotowania odpowiednich procesów.
Plan kwartalny zapewnia także margines trzech miesięcy. Cel może zostać osiągnięty na początku, w środku albo pod koniec kwartału, a jednocześnie pozostaje wystarczająco konkretny dla interesariuszy.
Michael Luchen
Bardzo podoba mi się pojęcie marginesu. Innym przydatnym modelem jest stożek niepewności. Na początku mamy dużo miejsca i niepewności dotyczącej dostarczenia funkcji lub osiągnięcia rezultatów. W miarę upływu czasu i zdobywania wiedzy zbliżamy się do celu i zyskujemy większą pewność. W środowisku zwinnym można wykorzystywać punkty historyjek, aby śledzić tempo pracy i lepiej określać terminy, gdy zespół zdobędzie więcej informacji.
Brandon Blackman
Stożek niepewności świetnie pasuje do planów. Można zapytać interesariusza: „Czy chcesz odpowiedzi z 90-procentową pewnością, czy odpowiedzi z 30-procentową pewnością?”. W ten sposób pokazujemy, że wiemy, dokąd zmierzamy, ale jednocześnie uczciwie komunikujemy poziom niepewności.
Michael Luchen
Jak zarządzać zależnościami w planie rozwoju produktu?
Brandon Blackman
Po pierwsze, należy je odnotować i komunikować. Powinny pojawić się w planie. Jeśli określasz rezultat, który ma zostać osiągnięty w konkretnym kwartale, zaznacz, że zależy on od określonych elementów. To pomaga zachować zgodność między wszystkimi stronami.
Często tworzymy również kontrakty między zespołami interfejsu użytkownika i zaplecza. Może to być kontrakt API — dokument opisujący, czego można oczekiwać od tworzonego interfejsu. Zespół interfejsu może pracować na podstawie tego kontraktu, nawet jeśli samo API nie jest jeszcze gotowe. Dzięki temu obie strony wiedzą, jakie są ich zobowiązania, a późniejsze połączenie elementów jest prostsze.
Tego rodzaju kontrakty można tworzyć także między zespołem programistycznym i marketingowym, zespołem produktowym i obsługą klienta albo dowolnymi innymi grupami. Trzeba jasno określić, czego każda strona może oczekiwać, gdy praca zostanie ukończona.
Michael Luchen
To ważne, bo zależności nie dotyczą wyłącznie biznesu i treści. Mogą być również techniczne i wpływać na sposób organizacji zespołów.
Brandon Blackman
Tak. Rzeczy mogą pójść niezgodnie z planem — właśnie dlatego istnieją zależności. Należy się z tym liczyć i zapisywać je w planie. Gdy coś się zmieni, można wyjaśnić, że przyczyną była konkretna zależność albo większy zakres pracy, niż początkowo zakładano. Jeśli niepewność i zależności są komunikowane z wyprzedzeniem, można wyeliminować większość problemów związanych z prognozowaniem przyszłości.
Michael Luchen
Jakie inne wyzwania pojawiają się przy planowaniu rozwoju produktu, zwłaszcza w połączeniu z zarządzaniem wydaniami i dostarczaniem w podejściu zwinnym?
Brandon Blackman
Często dotyczą one osób i zespołów, które nie pracują bezpośrednio nad produktem. W przedsiębiorstwach interesariusze mogą nie znać procesu zwinnego, dlatego trzeba stale wyjaśniać, czym jest zwinność i dlaczego budujemy produkty w ten sposób.
Nie tworzymy zwykle kolejnego domu, którego konstrukcję znamy od lat. Często budujemy coś, czego wcześniej nie zbudowano, albo tworzymy znane rozwiązanie w zupełnie wyjątkowy sposób. Nie da się więc przewidzieć wszystkiego. Podejście zwinne nie usuwa niepewności, ale pozwala z nią pracować i porządkować chaos tak, aby nadal tworzyć wartościowe produkty dla użytkowników.
Michael Luchen
Rozwój oprogramowania polega w dużej mierze na tworzeniu i zdobywaniu wiedzy. To znacznie więcej niż budowanie domu: musimy wiedzieć, jak układać cegły, jak je wytwarzać, jak nauczyć się ich tworzenia i co zrobić, gdy potrzebny jest zupełnie inny materiał. Ta zmienność dodatkowo wpływa na plan.
Brandon Blackman
Zgadza się.
Michael Luchen
Jak sprinty pomagają rozbić plan rozwoju produktu na mniejsze części?
Brandon Blackman
Każdy sprint powinien mieć cel. Po jego zakończeniu cel powinien zostać osiągnięty, a praca powinna przesunąć produkt, zespół i użytkowników dalej w kierunku wyznaczonym przez plan. Jeśli cel sprintu jest od niego oderwany, praca nie wspiera kierunku rozwoju produktu.
Podczas planowania sprintu zaczynam od omówienia planu, a dopiero później wybieram historyjki użytkownika i formułuję cel. Cel powinien jasno wskazywać, z którym elementem planu jest związany. Czasami będzie to bezpośrednia realizacja, a czasami krok przygotowawczy, na przykład eksperyment techniczny potrzebny do późniejszego dostarczenia funkcji.
Michael Luchen
Jak nie dopuścić do tego, aby sprinty stały się małymi projektami kaskadowymi?
Brandon Blackman
Sprinty powinny składać się z niezależnych i użytecznych historyjek użytkownika. Powinny być testowalne, możliwe do wykorzystania i niezależne od pracy zaplanowanej na kolejne sprinty. Nie chcemy sytuacji, w której funkcja staje się użyteczna dopiero po zakończeniu trzech kolejnych sprintów.
Każdy sprint powinien być niezależny i możliwy do wydania. Użytkownik powinien hipotetycznie móc z niego skorzystać nawet w środowisku przedprodukcyjnym. Częste wydawanie nie musi oznaczać udostępniania każdej wersji wszystkim użytkownikom, ale powinniśmy regularnie dostarczać działające elementy do środowiska, w którym można je sprawdzać i uzyskiwać z nich wartość.
Michael Luchen
Historyjki użytkownika nie powinny być zbyt szczegółowe, bo wtedy same mogą stać się małym projektem kaskadowym. Potrzebujemy jednak wystarczającej jasności, aby zespół mógł działać, oraz odpowiedniej niejednoznaczności, która pozostawia przestrzeń na zmianę kierunku i kreatywność.
Brandon Blackman
To bardzo ważne. Nadmierne szczegóły przenoszą nas z powrotem do pytania „jak”. Menedżer produktu nie ma pełnej wiedzy programistycznej ani projektowej. Jeśli pozostawimy pewien poziom niejednoznaczności, eksperci mogą zdecydować, jak osiągnąć cel. W ten sposób wzmacniamy najbardziej kompetentne osoby w zespole, zamiast narzucać im rozwiązanie wynikające z ograniczonej perspektywy menedżera produktu.
Michael Luchen
Jak często należy przeglądać plan rozwoju produktu?
Brandon Blackman
Jako menedżer produktu zaglądam do niego codziennie albo co drugi dzień. Zespół produktowy powinien przeglądać go podczas każdego rozpoczęcia sprintu i każdego okresu planowania, ponieważ plan powinien pomagać określać sprinty, cele sprintów, wybierane historyjki i epiki. Z szerszej perspektywy należy pokazywać plan za każdym razem, gdy komunikujemy interesariuszom informacje o produkcie. Dzięki temu nie pokazujemy tylko pojedynczego fragmentu, ale zapewniamy pełny kontekst.
Michael Luchen
Jaki jest Twój ulubiony typ planu i podejście do planowania?
Brandon Blackman
To zależy od produktu, ale najczęściej wybieram plan skoncentrowany na tematach. Podoba mi się możliwość powiązania tematu z najważniejszymi celami firmy. Zespół produktowy może wtedy zdecydować, nad czym pracować, a programiści i projektanci — jako eksperci w swoich dziedzinach — wybierają sposób osiągnięcia celu. W przypadku mniejszych produktów plan musi być bardzo zwięzły i ogólny. Statusy pozwalają szybko przekazać: nad czym pracujemy teraz, czym zajmiemy się później i czego można oczekiwać w dalszej przyszłości.
Michael Luchen
Na koniec chciałbym zadać kilka krótkich, osobistych pytań.
Brandon Blackman
Jasne.
Michael Luchen
Który z Twoich osobistych nawyków najbardziej przyczynił się do Twojego sukcesu?
Brandon Blackman
Jestem trochę staroświecki i lubię robić notatki analogowo. Nie zawsze mam na to czas, więc często zapisuję informacje cyfrowo, ale zapisywanie ich w notesie pomaga utrwalić je w pamięci i przenieść z pamięci krótkotrwałej do długotrwałej. Na papierze mogę również szkicować listy zadań i cele, porządkować przeszłość, organizować teraźniejszość i planować przyszłość. To podejście zaczerpnąłem z metody dziennika punktowego.
Michael Luchen
Jakiego innego narzędzia używasz regularnie?
Brandon Blackman
Prawdopodobnie nie będzie to dla Ciebie zaskoczeniem: Miro, czyli wirtualna tablica. Korzystamy z niego bardzo często w firmie Crema. Od kiedy odkryłem Miro, nie przygotowałem planu w innym narzędziu. Mogę umieścić plan w osobnej ramce, dodać obrazy i integracje z Figmą, a także zapisywać historyjki użytkownika na tablicy i integrować je z Jirą. Miro całkowicie zmieniło mój sposób pracy i korzystam z niego przy każdym planie.
Michael Luchen
Jaki jeden element porady dałbyś osobie rozpoczynającej karierę w zarządzaniu produktem?
Brandon Blackman
Powiedziałbym młodszemu sobie, żeby podjął pracę w startupie i został menedżerem produktu bez wcześniejszego doświadczenia. Na początku nie wiedziałem, czym jest zarządzanie produktem ani podejście zwinne, ale po prostu się zaangażowałem. Osobom, które chcą rozpocząć tę drogę, radzę znaleźć startup albo stworzyć własny projekt. Nie oznacza to koniecznie rezygnacji z pracy — można poświęcić na to wieczory. Warto nauczyć się procesu zwinnego i zastosować go do stworzenia czegoś, co nie istnieje.
Może powstanie z tego firma warta miliard dolarów, a może nic z tego nie wyjdzie. W obu przypadkach zdobędziesz doświadczenie, które pomoże Ci później znaleźć pracę i rozwijać się w obszarze, który naprawdę Cię interesuje.
Michael Luchen
To bardzo mądre słowa. Dziękuję, Brandon, za udział w podcaście i za podzielenie się wiedzą na temat planowania rozwoju produktu, a także doświadczeniem z zakresu rozwoju produktów.
Więcej informacji o pracy Brandona znajdziesz na stronie crema.us albo na jego profilu w serwisie LinkedIn. Brandon, jeszcze raz dziękuję za dzisiejszą rozmowę.
Brandon Blackman
Dziękuję za zaproszenie.
Michael Luchen
Dziękuję wszystkim za słuchanie.
Pamiętajcie, aby zostawić recenzję podcastu i napisać, co Wam się podobało, czego chcielibyście usłyszeć więcej oraz czy jest coś, co pominęliśmy i do czego powinniśmy wrócić. Koniecznie obserwujcie nas i dołączcie do naszej społeczności@theproductmanager.com. Jeszcze raz dziękuję wszystkim za słuchanie. Do usłyszenia w kolejnym odcinku.

