Cykl życia produktu: podróż funkcji produktu

To czwarty wpis z pięcioczęściowej serii, którą piszę, aby pomóc aspirantowi produktu wejść do świata zarządzania produktem.

W moim ostatnim poście podzieliłem dyscyplinę zarządzania produktem na cztery części, aby pomóc kandydatom w zarządzaniu produktem zrozumieć ich trajektorię kariery w firmie lub ogólnie. W tym poście opowiem o życiowej podróży funkcji produktu, od pomysłu do porzucenia, aby pomóc aspirantowi Product Management uzyskać 360-stopniową perspektywę na to, na czym polega rola Product Managera.

T – 30 dni

Mówi się, że potrzeba jest matką wynalazków. Tak jest dosłownie w przypadku narodzin funkcji produktu. Wszystko zaczyna się od pewnego poziomu dyskomfortu.
Jakiś pracownik w firmie odczuwa dyskomfort w realizacji jednego ze swoich codziennych zadań – być może zwiększyła się baza użytkowników i nie jest w stanie nią zarządzać starymi procesami. Jakiś dyrektor w firmie patrzy na arkusz Excela i myśli, że firma traci zbyt dużo pieniędzy z powodu, powiedzmy, dużej liczby anulowanych produktów. A może konkurent wprowadził funkcję produktu, która powoduje, że klienci opuszczają produkt tej firmy. Ktoś przyglądający się ścieżce konwersji marketingowej zauważył duże spadki na pewnym etapie i uznał, że optymalizacja może mu pomóc w osiągnięciu celu kwartalnego. Lub może to być 100 różnych powodów, od dużej liczby skarg klientów dotyczących wspólnego problemu do nowej funkcji wymaganej przez większość ankietowanych użytkowników w poprzednim tygodniu. Chodzi o to, że wszystko zaczyna się od pewnego poziomu dyskomfortu.

Teraz ten dyskomfort zostaje zauważony przez Menedżera Produktu; a może Product Manager jest tym, który zauważa to jako pierwszy. Jest to punkt, od którego zaczyna się łańcuch wydarzeń, które mogą prowadzić do narodzin nowej funkcji.

T – 25 dni

Czas, aby Menedżer Produktu przemyślał opis problemu. Idzie i rozmawia z klientami lub interesariuszami wewnętrznymi, którzy zgłosili dyskomfort, a następnie z tymi, którzy faktycznie go doświadczają; wszystko w jednym celu – upewnieniu się, że zidentyfikował „główny” problem. Jeśli ten etap zostanie potraktowany lekko lub Product Manager nie poświęci na to wystarczająco dużo czasu, wtedy zrodzone cechy produktu są kruche, zniekształcone i dość szybko kończą się.
Gdy Menedżer Produktu zidentyfikuje główne sformułowanie problemu, decyduje, czy warto go rozwiązać. Czy dyskomfort jest naprawdę duży, czy może jest przesadny lub gorzej, po prostu wymyślony? Czy rozwiązanie tego problemu faktycznie przyniosłoby znaczną wartość klientowi i/lub firmie? Czy rozwiązanie go nie nałożyłoby znacznej kary na klienta i/lub firmę? Czy istnieje sposób na rozwiązanie tego problemu przez drobne poprawki w procesach lub przez jakąkolwiek czynność, która nie wymaga zmian w produkcie – na przykład zmiana dostawcy, wynegocjowanie lepszej ceny od istniejącego dostawcy, pozyskanie oprogramowania innej firmy w celu rozwiązania problemu, zatrudnienie dodatkowy pracownik, zmiany w treści, grafice, przycisku wezwania do działania itp.?

Zasadniczo, jeśli istnieje sposób, abyśmy mogli uzyskać podobną wartość dodaną z metody, która nie wymaga zmian w produkcie, wówczas zdecydowalibyśmy się na to, zamiast zmieniać cokolwiek w produkcie – niezależnie od tego, czy oznacza to dodanie, czy usunięcie. Kiedy Menedżer Produktu jest przekonany, że rozwiązanie problemu przyniesie znaczną wartość, a zmiana poziomu produktu przyniesie znacznie większy zwrot z inwestycji (biorąc pod uwagę wartość czasu, pieniędzy i wysiłku w stosunku do wartości) niż zmiana na poziomie nieproduktowym, zalążek nowego cechy produktu są sadzone.

T – 15 dni

Jeśli Product Manager ma już jakieś doświadczenie, może zaproponować rozwiązanie oparte na tym doświadczeniu. Jednak może to nie być najlepsze rozwiązanie we wszystkich przypadkach.
Jeśli opis problemu wymaga wysoce technicznego rozwiązania, menedżer produktu omawia to samo z programistami i kierownikami inżynierii i korzysta z ich porad, jak najlepiej rozwiązać ten problem. Jeśli rozwiązanie wymaga zmian na poziomie projektu, można skonsultować się z liderem UX. Może się zdarzyć, że Product Manager i osoba UX zorganizują sprint projektowy i wybierzą rozwiązanie, które jest dobrze odbierane przez rzeczywistych użytkowników tej funkcji. Czasami problem jest całkowicie związany z biznesem i dlatego wymaga poparcia wyższego kierownictwa.
Tak więc istnieje wiele sposobów, w jakie można sfinalizować rozwiązanie. Ale kiedy już to nastąpi, Product Manager jest odpowiedzialny za przekształcenie tego teoretycznego rozwiązania w aktywną funkcję produktu.

T = 0 (czyli narodziny cechy produktu)

Po zidentyfikowaniu konkretnego rozwiązania, Product Manager, we współpracy z odpowiednim zespołem, opracowuje podstawowy zarys rozwiązania. Może zawierać prototyp rozwiązania lub nie. Czasami jest to po prostu podstawowy arkusz Excela z warunkami „jeśli-to” napisanymi, kiedy pokazać konkretne wezwanie do działania użytkownikowi itp.
Menedżer Produktu ujmuje rozwiązanie w słowa w odpowiednim PRD (Dokumencie Wymagań Produktu). Jeśli funkcja jest mała, może to być po prostu akapit w istniejącym PRD dla większej funkcji. Czasami funkcja jest tak duża, że ​​wymaga pełnego PRD, aby odpowiednio ją szczegółowo opisać. PRD jest prowadzony przez odpowiednie zespoły, a Menedżer Produktu upewnia się, że istnieje szeroki konsensus dotyczący tej funkcji.

T + 15 dni

Zamrożenie małych elementów może zająć mniej niż jeden dzień. Duże funkcje czasami potrzebują więcej niż 30 dni, aby wszyscy byli gotowi.
Poświęćmy średnio 15 dni, aby powiedzieć, że jest to czas, w którym nowatorska funkcja zostanie wprowadzona do programistów. Właściwy projekt i przekazanie PRD ma miejsce, w którym programiści pracujący nad projektem są informowani o 5W (Co, Dlaczego, Kiedy, Gdzie, Kto) i przypadkach testowych (jak funkcja powinna zachowywać się lub nie zachowywać się po jej wydaniu) .
Wraz z kierownikiem ds. inżynierii ustalany jest odpowiedni harmonogram wydań funkcji wraz z terminami, w których zakończy się rozwój, kiedy rozpocznie się testowanie, kiedy zgłoszone błędy zostaną naprawione oraz ostateczna data wydania. Następnie cała oś czasu podzielona jest na mierzalne sprinty (zwykle 15 dni). Gdy programiści są usatysfakcjonowani, rozpoczyna się rozwój.

T + 30 dni

Sprint 1 się kończy. Jedna część funkcji produktu została wdrożona. Może nie jest to jeszcze skierowane do klienta, ale większość zespołów stosuje dziś metodologie Agile do tworzenia oprogramowania – co oznacza, że ​​budujemy przyrostowo i iteracyjnie. Tak więc, zamiast tworzyć dużą funkcję w 6 miesięcy i wypuszczać za jednym razem, dzielimy całość na niezależne części, które mogą działać samodzielnie (kilka historii użytkowników) i są szybko gotowe do przeglądu i iteracji.
Menedżer produktu upewnia się, że harmonogram wydania jest zgodny z harmonogramem, poprzez codzienne spotkania Scrum i dyskusje z odpowiednim kierownikiem technicznym pracującym nad projektem. W przypadku opóźnienia terminy są odpowiednio dostosowywane lub małe części funkcji są usuwane, aby upewnić się, że wydanie nastąpiło na czas. Po każdym sprincie poczyniony postęp jest prezentowany Menedżerowi Produktu i odpowiednim interesariuszom na spotkaniu, a po zatwierdzeniu jest publikowany.
Rok programu zarządzania produktami UpGrad

T + x dni

Po 'n' liczbie sprintów rozwój jest zakończony i cała funkcja jest dostępna. Nie jest konieczne, aby klienci mogli korzystać z funkcji dopiero po całkowitym wydaniu. Mogli z niego korzystać od czasu wydania na koniec samego sprintu 1. Każde kolejne wydanie cyklu sprintu sprawia, że ​​funkcja jest bardziej niezawodna i zbliża ją do tego, do czego ma być.
Uruchomienie funkcji samo w sobie jest sztuką i obejmuje wiele kroków, które pominiemy i po prostu założymy, że po wielu bębnieniach i uderzaniu w klatkę piersiową ogłoszono światu, że funkcja została wydana. Może to być tak złożone, jak pełnoprawna informacja prasowa, w której sam prezes mówi o nowej premierze, lub może to być po prostu wiadomość, na którą wysyłana jest wiadomość do konkretnego działu, który będzie korzystał z tej funkcji i prawdopodobnie zażądał jej w pierwsze miejsce. Teraz, gdy ta funkcja jest dostępna, nadajmy jej nazwę – Mr. Feature.

T + y dni

Nawet po ostatecznym wydaniu czasami coś idzie nie tak. Pan Feature, który kiedyś był błyszczący i cenny, może już nie być taki sam i może być wiele powodów. Ta faza cyklu produktu polega na wspieraniu produktu. Pewnego pięknego dnia wydano kolejną wersję, która spowodowała niezamierzone działanie Mr. Feature (czyli stała się błędna) lub być może usunięta została inna funkcja, która miała pewne zależności od Mr. Feature i to spowodowało błędne zachowanie. Może się również zdarzyć, że kiedy funkcja została stworzona, nie oszacowaliśmy liczby użytkowników, którzy będą z niej korzystać lub nie zaplanowaliśmy wszystkich przypadków użycia, a teraz funkcja nie jest w stanie skalować się do tak wielu użytkowników lub przypadków użycia.

Jest to albo zgłaszane przez zespół testowy podczas okresowego przeglądu, albo zgłaszane przez członka zespołu, który właśnie odkrył to podczas korzystania z funkcji. W przypadku funkcji skierowanych do klienta, reklamacje te mogą pochodzić od rzeczywistych klientów produktu i być komunikowane Menedżerowi Produktu za pośrednictwem zespołu Customer Experience.

Product Manager stara się zrozumieć podstawową przyczynę błędu i, zgodnie z priorytetem, planuje poprawkę na następny cykl wydania – może zostać dodana w bieżącym sprincie, jeśli jest to priorytet o wysokim priorytecie lub nawet w kolejnych sprintach. Po naprawieniu i wydaniu błędu Mr. Feature doczeka kolejnego dnia, choć w zreformowanej formie – Mr. Feature 2.0 – dzięki kierownikowi produktu i zespołowi inżynierów. Sława!

T + z dni

Mówi się, że wszystko, co dobre, musi się skończyć. Niestety, tak samo jest w przypadku Mr. Feature, bez względu na jego wersję – może Mr. Feature 9.263.75! Oznacza to, że pan Feature miał długie i szczęśliwe życie, ale teraz koniec drogi jest tutaj.
Może to wynikać z różnych powodów. Pojawiła się nowa funkcja, która sprawiła, że ​​potrzeba Mr. Feature jest całkowicie zbędna. To też może być coś ekstremalnego – na przykład firma uznała, że ​​chociaż ta funkcja dodaje wartości użytkownikom, to nie ma już dla nich sensu ekonomicznego.

Bez względu na powód, menedżer produktu (lub to on rozpoczyna dyskusję) jest komunikowany, że usługi pana Feature nie będą już potrzebne. Teraz, jakkolwiek bolesny, kierownik produktu ma obowiązek odłożyć Mr. Feature na spoczynek. Chociaż wcześniej musi upewnić się o kilku rzeczach, takich jak poinformowanie użytkowników, którzy korzystali z funkcji Mr., że nie będzie ona dostępna od określonej daty, nowa funkcja działa dobrze przed usunięciem funkcji Mr. przepływ zostaje zakłócony, gdy nie ma Mr. Feature i tak dalej.

Czas więc powiedzieć RIP panu Feature. W swojej karierze zarządzania produktem będziesz musiał to robić wiele razy. Pamiętaj jednak, że koniec jednej cechy jest początkiem drugiej i cykl trwa. Takie jest życie zarządzania produktem!

Ucz się kursów zarządzania produktami online na najlepszych światowych uniwersytetach. Zdobywaj programy Masters, Executive PGP lub Advanced Certificate Programy, aby przyspieszyć swoją karierę.

Polecany program dla Ciebie: Program certyfikacji Design Thinking od Duke CE