Definiowanie podstaw, czyli MVP
Przy tworzeniu nowych rozwiązań lub rozwoju nowych funkcjonalności zwykle kierujemy się chęcią uzyskania kompletności. Ta naturalna potrzeba ujawnia się z resztą w różnych dziedzinach życia. Kupując nowy samochód, przeglądamy katalog wyposażenia lub korzystamy z interaktywnego konfiguratora i wybieramy opcje, które w większości nie są pierwszorzędne i konieczne, ale każda z nich dopełnia naszą wizję samochodu marzeń. Po podliczeniu zamówienia zwykle wracamy do konfiguratora, żeby ponownie przemyśleć i zrewidować, jak bardzo tego wszystkiego potrzebujemy. Gdy rezygnujemy z kolejnych kawałków, czujemy, że tracimy kompletność i poziom naszej satysfakcji, automatycznie się obniża. Definiowanie podstaw i przypisywanie potencjalnej wartości do każdego z elementów to jednak niezbędny element efektywnego zarządzania produktem. MVP (z ang. Minimum Value Product) to owoc negocjacji pomiędzy Product Managerem a interesariuszami, który z jednej strony powinien być w pełni funkcjonalny, żeby zaspokoić podstawowe potrzeby użytkownika, z drugiej jednak może być odbierany jako zgniły kompromis i nie satysfakcjonować do końca odbiorców. MVP tego samego produktu w różnych organizacjach może znacząco się od siebie różnić. Dla jednych zaawansowane opcje mogą poczekać, a dla innych będą podstawą danego rozwiązania i muszą być jego integralną częścią od pierwszego dnia użycia. Nie ma zapewne jednej odpowiedzi na pytanie, jaki zestaw funkcjonalności jest optymalny, ale z pewnością jest wiele technik, które pozwalają podjąć ostateczne decyzje.
Evidence based management
Zarządzanie oparte na dowodach lub inaczej danych, jest bardzo przydatnym narzędziem do szacowania wartości, kosztów i ryzyka. Dane są dziś niezbędne do podejmowania decyzji w procesie biznesowym. Nie rozwija się funkcjonalności, których użytkownicy nie używają, nie wycofuje się tych, które przynoszą nam największy profit. Brzmi prosto, ale rzeczywistość jak wiemy, jest bardziej złożona. Nie zawsze bowiem mamy dostęp do niezbędnych danych, nie zawsze mamy czas lub umiejętności, żeby je poprawienie zinterpretować. Największym wyzwaniem jest jednak sytuacja, w której danych mamy wydawałoby się wystarczająco, lecz nie dają one jednoznacznej odpowiedzi. Otóż w zarządzaniu opartym na dowodach wszystko wydaje się spójne, dopóki owe dowody są dostępne i jasne. A pozyskanie takich jest nie tylko czasochłonne, ale i drogie. Czy fakt, że użytkownicy nie korzystają z jednego z naszych modułów, oznacza, że go nie potrzebują? Być może. Spektrum odpowiedzi na to pytanie może być dość szerokie: od- nie wiedzą, że taka funkcjonalność w ogóle istnieje, po – gdyby tylko dodać jedno małe usprawnienie w postaci np. zapisu danych do pliku, moduł byłby z powodzeniem używany. Dziś jednak nie pokrywa on w pełni ścieżki, którą użytkownik chce przejść. Zbieranie danych ilościowych, jak i jakościowych może całkowicie odmienić naszą percepcję potrzeb użytkowników i pomóc podejmować odpowiednie decyzje. Pamiętajmy też, że w wachlarzu danych i zmiennych podjęcie decyzji to także użycie intuicji opartej na wiedzy czerpanej z naszego doświadczenia. Product Manager znając swój produkt, rynek i interesariuszy intuicyjnie wie co robić i dokąd zmierzać w codzienności swoich wyborów.
Co poza czystą wartością wynikającą z funkcjonalności?
Zakładając, że realizacja wizji produktu poprzez podążanie za roadmapą i zwinnym reagowaniem na nagłe zmiany okoliczności, to wyścig z czasem, konkurencją i przeciwnościami, możemy zidentyfikować mnóstwo czynników, które nas potencjalnie spowalniają. W skrócie są to wszystkie niefunkcjonalne, nieprzynoszące wprost wartości wymagania i odpowiedzi na regulacje zewnętrzne, a także dług techniczny. Celowo zaznaczam, że spowolnienie jest potencjalne, bo zwykle wartość, którą dostarczamy, wypełniając wspomniane wyżej wymagania, mierzymy długoterminowo lub traktujemy jako aktywatory. Bez dostarczenia odpowiedzi na regulacje nasz produkt może przestać być legalnie dostępny lub nie uzyska akredytacji klienta.
Inaczej wygląda kwestia długu technicznego, gdzie rzadko wyhamowuje on zespół do zera, ale jego nawarstwienie spowalnia przyrost nowych, wartościowych funkcjonalności. Wszelkie usprawnienia
w kodzie traktowane są więc bardzo poważnie przez doświadczonych Product Managerów i uzyskują odpowiedni priorytet przy planowaniu pracy zespołu. Chociaż określenie dług techniczny związany jest ściśle z produktami cyfrowymi, sama idea wydaje się immanentną częścią rozwoju produktów niezależnie od branży. Wszelkie niedopracowane procesy, stare technologie wytwarzania, czy złe środowisko pracy- obniżają efektywność i spowalniają tempo dostarczania na rynek wartości. Dodatkowo, jeśli uznamy, że zespół i jego umiejętności to część produktu to dług techniczny demotywuje ludzi do pracy i spowalnia zespoły.
Idealna mikstura
Wyznaczając kierunek rozwoju produktu, zawsze powinniśmy pamiętać o końcu jego drogi, czyli osiągnięciu dojrzałości lub wycofaniu z rynku, w zależności od okoliczności i obecnej pozycji w cyklu jego rozwoju. Ilość wymagań, a także wielość ich źródeł i interesariuszy skutkuje koniecznością podejmowania szeregu decyzji, negocjacji, ustępstw, kontraktów, a także konfliktów, którym Product Manager musi sprostać każdego dnia. Te ostatnie zniechęcają wielu znakomitych managerów do pracy w ściśle regulowanych branżach – na przykład bankowej, a także w wielkich korporacjach, które same stanowiąc rozbudowane regulacje, spowalniają i ograniczają możliwość rozwoju produktów. Natomiast w mniejszych biznesach balansują pomiędzy inwestorami, klientami i zespołami aby sprostać przede wszystkim ogromnemu tempu pracy i oczekiwaniom dotyczącym zysków. Wszystko to znów sprowadza się do wyznaczenia sobie i swoim zespołom pryncypiów, wizji i kierunku, w którym dany produkt i organizacja chcą zmierzać oraz odpowiedniej komunikacji tych ustaleń do interesariuszy. Pomaga to ograniczyć, choć nie całkowicie wyeliminować, natłok komunikacji i nieodpowiednie adresowanie oczekiwań w projekcie. A co najważniejsze, pomaga zrozumieć szeroko rozumianemu zespołowi produktowemu, jaki jest sens ich pracy i jakimi wartościami powinni się kierować w podejmowaniu decyzji o produkcie.
