Odkrywanie Produktu

Czy znasz tę sytuację? W Twojej firmie jest wielki entuzjazm wobec pewnego pomysłu na produkt i Ty jako menedżer produktu masz ten produkt zdefiniować. Mówi się Ci, że deweloperzy za cztery tygodnie skończą swój obecny projekt. Oznacza to, że możesz poświęcić tyle czasu, ile chcesz, o ile skończysz za cztery tygodnie…

Mówisz, że to żaden problem (w końcu czasem masz tylko kilka dni, więc cztery tygodnie brzmią jak marzenie). Skorzystasz nawet ze wszystkich tych świetnych metod, o których zawsze tyle mówię. Zaczniesz od oceny możliwości, aby zrozumieć problem do rozwiązania. Następnie przeprowadzisz wywiady z prawdziwymi użytkownikami i stworzysz wstępną listę wymagań. Na początku drugiego tygodnia powinieneś więc już móc pracować z projektantem interakcji nad prototypem. W trzecim tygodniu będziesz mógł testować ten prototyp, a w czwartym tygodniu dopracujesz szczegóły przypadków użycia i zweryfikujesz prototyp i specyfikacje z deweloperami.

Rzeczywistość w Product Discovery

Brzmi świetnie – jednak to, co dzieje się w rzeczywistości, zazwyczaj nie jest tak fajne: Podczas rozmów z klientami na samym początku okazuje się, że klienci nie są tak zachwyceni produktem jak zarząd, i/lub masz trudności z zaprojektowaniem prototypu, z którym klienci mogą sobie poradzić, i/lub klientom nie podobają się pomysły wdrożone w prototypie. Czas już się jednak skończył, a deweloperzy są gotowi. Przez następne trzy do sześciu miesięcy rozwijany jest więc ten sam bezużyteczny i nudny produkt, który był już widoczny w prototypie. Kiedy produkt jest w końcu dostarczony, zarząd jest słusznie rozczarowany wynikiem.

Na czym polega problem?

Problem nie leży w niezawodności oprogramowania. Deweloperzy nie są więc niczemu winni – w końcu zbudowali tylko to, o co ich poprosiłeś. Wszyscy wiedzą więc, że to Twój błąd jako menedżera produktu.

Nie ma bowiem żadnego sensu rozmawiać z użytkownikami, tworzyć prototypy i testować je razem z użytkownikami, jeśli nie wdraża się tego, czego się przy tym uczy.

Myśl o traktowaniu wymagań i projektowania jako sekwencyjnej, przewidywalnej i zaplanowanej fazy w procesie tworzenia produktu jest tak głęboko zakorzeniona w naszej branży, że organizacjom produktowym bardzo często trudno jest porzucić ten nawyk.

Ale muszą to zrobić. W organizacjach produktowych trzeba rozumieć, że tworzenie nowych produktów jest w swej istocie procesem twórczym. To bardziej sztuka niż nauka. Dlatego wolę nazywać tę fazę „Product Discovery" niż „wymagania i projektowanie".

Pojęcie "Product Discovery" podkreśla dwa szczególnie ważne punkty:

• Po pierwsze, trzeba sprawdzić, czy na rynku są klienci, którzy naprawdę chcą mieć ten produkt. Oznacza to, że należy zdefiniować rynek i poprosić klientów o potwierdzenie możliwości produktowej.

• Po drugie, trzeba znaleźć rozwiązanie tego problemu, które jest użyteczne, przydatne i wykonalne. A to oznacza, że należy zaprojektować produkt, a następnie zwalidować go razem z klientami i zespołem deweloperskim.

Product Discovery w przemyśle farmaceutycznym

Przemysł farmaceutyczny jest skrajnym przykładem. Znalezienie rynku nie jest szczególnie trudne – zawsze jest wystarczająco dużo problemów wartych rozwiązania (np. ratowanie życia, przedłużanie życia lub poprawa jego jakości). Znalezienie na to rozwiązania to trudna część. Kiedy firmy farmaceutyczne rozpoczynają „fazę discovery", są w pełni świadome, że nie ma żadnej gwarancji, że znajdą rozwiązanie ani jak długo potrwa ten proces. W tej branży trzeba więc radzić sobie z tą niepewnością (a ryzyko odzwierciedla się w cenach produktów).

Powody trudności z Product Discovery

I choć wszyscy wiemy, że to trudne i że większość wydań oprogramowania kończy się niepowodzeniem, bo nie spełniają pożądanych celów, to przy tworzeniu oprogramowania nadal nalegamy na planowanie fazy discovery tak jak budowy budynku.

Szczególnie zarząd ma trudności z koncepcją Product Discovery. I uważam, że są ku temu dwa powody:

• Po pierwsze, proces discovery jest nieprzewidywalny. Zarząd obawia się, że przez miesiące pracuje się nad czymś i nic z tego nie wychodzi. Jeśli po prostu się ruszy i coś zbuduje, można przynajmniej twierdzić, że coś dostarczono. Prawdopodobnie to ten sam powód, dla którego tak wielu menedżerów nie radzi sobie dobrze ze Scrumem – chcą dokładnie wiedzieć, ile 30-dniowych Sprintów będzie potrzebnych, żeby skończyć.

• Po drugie, w organizacji produktowej zajmującej się oprogramowaniem deweloperzy są zawsze postrzegani jako ograniczony zasób. Myśl o tym, że zespół deweloperów siedzi i nic nie robi poza graniem w piłkarzyki, doprowadza zarząd do szaleństwa.

Ironicznie, to właśnie ta argumentacja prowadzi do tego, że deweloperzy są marnowani jako zasób.

Niemal każda firma stosuje właśnie opisany proces discovery. Zamiast spędzać kilka tygodni z prototypem, angażują cały zespół deweloperów do realizowania całych cykli wydań, aby tworzyć oprogramowanie, które przechodzi przez kontrolę jakości i jest wdrażane do systemów produkcyjnych. Dlatego tak wiele firm potrzebuje trzech lub nawet więcej wydań i roku lub dwóch, zanim uzyska coś przydatnego i użytecznego. Używają organizacji deweloperskiej do budowania bardzo bardzo drogiego prototypu i czynią swoich klientów mimowolnymi uczestnikami testów.

To jest też powód, dla którego tak wiele startupów nie odnosi sukcesu. Po prostu nie mają niezbędnego kapitału, żeby czekać dwa lata, zanim wystartują. Więc bierz swoich deweloperów, daj im z siebie dać wszystko i poczekaj, co się stanie.

Podsumowanie

Dlatego doradzam zarówno start-upom, jak i dużym firmom, aby skupiły swoje siły na tym znacznie szybszym procesie odkrywania. Gdy tylko znajdą rozwiązanie, które działa (które jest użyteczne, przydatne i wykonalne), wszystko kręci się wokół pracy deweloperskiej. Do tego momentu nie muszą jeszcze mieć tak wielu deweloperów. Deweloperzy, których mają, mogą i powinni aktywnie uczestniczyć w procesie odkrywania. Do pewnego stopnia deweloperzy mogą już w trakcie procesu odkrywania przygotowywać infrastrukturę.

Możesz pomóc swojemu kierownictwu zrozumieć proces Product Discovery. Jeśli konsekwentnie podkreślasz, że Twoim obowiązkiem jest dbanie o to, aby deweloperzy tworzyli coś użytecznego i przydatnego, i angażujesz się w poszukiwanie obiecującego rozwiązania, uda Ci się skierować uwagę kierownictwa na tę niezwykle ważną fazę procesu tworzenia produktu.

Tekst pochodzi z bloga Marty'ego Cagana i został przez nas przetłumaczony. 

Tworzenie świetnych produktów

=> Discovery vs Delivery w produktach.

Projektowanie strategii produktu

Dowiedz się, czym różni się strategia firmy od strategii produktu.