Praca w IT

Product Discovery nie dzieje się raz. To proces. Wywiad z Justyną Izydorczyk

justyna izydorczyk goodylabs

Produkty powinny powstawać na podstawie danych. To wiedzą wszyscy, ale czy stosują się do tej zasady? Z drugiej strony, czy wszystkie decyzje o produkcie powinniśmy podejmować w oparciu o dane? O znaczeniu procesu Product Discovery rozmawialiśmy z Justyną Izydorczyk, Head of Strategy Department w goodylabs.

Jeśli chodzi o budowę produktów – a “pochodzę” z branży startupowej, więc widziałem sporo produktów – mam wrażenie, że najczęściej powstają one na podstawie intuicji i doświadczenia. Dziś też tak jest? Większość produktów powstaje bez oparcia w danych o potrzebach odbiorców?

Trudno mi wyrokować, jak wygląda to statystycznie. Czy większość twórców kieruje się wyłącznie intuicją? Tego nie wiem. Wiem natomiast, że wciąż ten model funkcjonuje i ma się dobrze. Na swojej drodze spotkałam wielu wizjonerów, którzy mieli pomysł na produkt, w który mocno wierzyli i… w zasadzie na tym koniec. Ruszali z jego realizacją bez weryfikacji i bez poparcia w danych. Daleka jestem od mówienia, że to jest zła droga. O ile masz zapał, zasoby (zwłaszcza finansowe) i ogromną otwartość – zwłaszcza na naukę z porażek, na dynamiczne zmiany i pivotowanie – to jest ok. 

O wiele bliższe jest mi jednak podejście Product Discovery, które osadza produkt w realnych potrzebach. To one stają się punktem wyjścia, a następnie na nich budowana jest propozycja wartości, mechanika produktu, model biznesowy, a całość jest następnie testowana, iterowana i udoskonalana, aby docelowa implementacja miała realną (a nie wyłącznie domniemaną) szansę na sukces. Na szczęście na rynku coraz częściej pojawiają się świadomi twórcy. Mam przyjemność z nimi pracować i za każdym razem jest to fascynująca współpraca!

Co mogłoby zmienić ten stan? Dlaczego warto tworzyć produkty w oparciu o wiedzę o użytkownikach i ich potrzebach? Wydaje się, że proces pozyskania wiedzy jest długi, czasochłonny.

Niestety taka jest obiegowa opinia: że to wymaga wiele czasu, wielu pieniędzy. Tymczasem sposobów na zdobycie tej wiedzy jest wiele i są one różnorodne. To, które z nich wybierzemy, zależy od naszych decyzji: ile pieniędzy jesteśmy w stanie przeznaczyć na walidację hipotez biznesowych, jakim czasem dysponujemy, ile osób możemy zaangażować w sam proces, jaką siłę dowodów chcemy uzyskać itd. 

Nie zawsze musimy wskakiwać na głęboką wodę i dążyć do wyeliminowania całego ryzyka (zresztą to dość abstrakcyjna idea). Sama uczestniczyłam w procesach Discovery, gdzie twórcy nowych produktów już po pierwszej turze badań eksploracyjnych wiedzieli, że ich pomysł wymaga fundamentalnego pivotu, na który nie są w stanie się zdobyć. 

Czasem taka wiedza może nas uchronić przed roztrwonieniem sporych kwot. Bo budowanie dla samego budowania (i satysfakcji twórcy-założyciela) to podróż w ślepy zaułek. Ktoś musi tego później używać, ktoś musi chcieć za to zapłacić, a produkt powinien na siebie zarabiać i – nie oszukujmy się – przynosić również profity (finansowe lub inne). Musimy patrzeć dalekosiężnie – nie tylko na moment wdrożenia. Dlatego najlepszą drogą jest odwrócenie percepcji i zamiast na finał realizacji, spojrzenia na źródło, czyli użytkownika. 

Co w kontekście użytkownika powinno nas zainteresować?

Kluczowe jest tu odpowiedzenie sobie właśnie na te pytania: Czego potrzebuje nasz użytkownik? Jakie są jego problemy i frustracje? Na co nie znajduje do tej pory rozwiązania lub rozwiązanie to nie przynosi mu dostatecznej wartości? Dopiero na tych filarach budujemy. Czyli najpierw rozpoznajemy problem, a dopiero po tym dopasowujemy rozwiązanie. Nie odwrotnie.

To ostatnie zdanie wskazuje, że raczej większość produktów powstaje… odwrotnie. Czyli najpierw powstaje rozwiązanie, a później poszukuje się użytkowników/klientów. Może taki model wcale nie jest zły?

Bardzo daleka jestem od mówienia komukolwiek, że jakiś schemat działania jest zły. U każdego co innego się sprawdza. Można polegać na starych, przetestowanych ścieżkach działania, a można je udoskonalać, zmieniać, eksperymentować. Można też dodawać elementy Discovery, dostosowując swoje realia pracy do tego, co chcemy osiągnąć. Nie w każdej organizacji da się bowiem przeforsować pełen proces Product Discovery. Ale w mało której organizacji nie da się przemycić części procesu, która już da nam jakąś wartość. 

A wracając jeszcze do perspektywy następstwa po sobie poszczególnych działań. Sama najczęściej spotykam się z tym, że gdy rozmawiam z wizjonerami, którzy mają pomysł na biznes, to przychodzą oni z gotową ideą. I wtedy zaczynamy dyskusję – na co ten produkt odpowiada? Jaką wartość daje? Czy jest to potrzebne i komu? Czasem potrzeba będzie zauważona jako pierwsza i z niej wysnuta zostanie wysokopoziomowa wizja produktu. Czasem rozwiązanie wpadnie do głowy pierwsze i wtedy tak, jak mówisz – szuka się odpowiedzi czy ktokolwiek zechce to kupić… Ważne jest jednak, żeby w całym procesie te fundamentalne pytania wybrzmiały i znalazły swoją odpowiedź.

Jak w Twoim przekonaniu wygląda idealny proces wprowadzenia zmiany w produkcie, dodania feature’a?

Jeśli mówimy o istniejącym produkcie, to sprawa już na starcie jest dużo prostsza. Bo to znaczy, że mamy dane. Znamy naszych użytkowników, wiemy, jak się zachowują, na co narzekają, czego im brakuje, jak używają naszego produktu. I to z tego punktu – wiedzy o użytkowniku – warto zacząć. Niech nas jednak nie zwiedzie deklaracja ze strony użytkownika czy klienta. Tu już pojawia się pierwsza pułapka, z którą należy się zmierzyć: walidacja problemu/potrzeby. 

Pierwszy krok to zatem eksploracja problemu/potrzeby – dowiedzmy się więcej na ich temat: co za nimi stoi? Dlaczego sądzimy, że jest to istotny problem/potrzeba? Jak wygląda realny problem/potrzeba (a nie tylko deklarowana)? Z czym się wiąże i na co ma wpływ? Jaki jest szerszy kontekst? Jaka praktyka towarzyszy użytkownikom? Przykładowo: nasi użytkownicy zgłaszają potrzebę, aby w aplikacji pojawił się widok na którym zobaczą wszystkie przyjmowane przez siebie suplementy diety. Wbrew pozorom nie jest to jeszcze potrzeba, ale rozwiązanie, które uznali za stosowne dla realizacji swojego celu. A jest nim np. kontrola dziennych dawek i pamiętanie o przyjmowaniu wszystkich zaplanowanych suplementów. Sprawdzajmy co jest realną potrzebą, faktycznym celem do osiągnięcia.

Gdy już znamy realny problem/potrzebę, kolejny krok to oszacowanie jego skali (perspektywa odbiorców) i wpływu na biznes (perspektywa wewnątrz organizacji). Musimy wiedzieć na ile jest to temat istotny, aby się nim zająć. Dla jak wielu użytkowników ma to praktyczny sens i będzie przez nich używane? Na ile problem ten jest uwierający? Na ile potrzeba popycha do skorzystania z rozwiązania? Kogo dotyczy problem? Co tracimy, jeśli się nim nie zajmiemy? Odpowiedź na powyższe pytania powinna w naturalny sposób wpisać się w odpowiedź na kluczowe zagadnienie: jaką wartość biznesową może przynieść nam rozwiązanie zdiagnozowanego problemu/potrzeby?

Równolegle do tych dwóch obszarów musimy zwalidować, na ile kierunek, w jakim podążamy, myśląc o rozwiązaniu poznanego problemu, jest zbieżny z naszą strategią produktową czy biznesową. I to kryterium akceptacji – zbieżności z wizją produktu – będzie nam towarzyszyło aż do końca tej drogi, czyli przez cały proces discovery – od walidacji problemu, prototypowania rozwiązania, przez jego wdrożenie, aż po analizę i optymalizację. W przeciwnym razie łatwo się zagalopować i zacząć tworzyć produkt, który zaczyna być hybrydą, jego wizja się rozmydla, całość pracuje na rzecz różnych interesów i koniec końców trudno jest określić jego wiodący cel i target grupę.

Poznaliśmy potrzebę, zdiagnozowaliśmy, że jest ona istotna i potencjalnie jej zaspokojenie wygeneruje wartość dla użytkownika i dla naszego biznesu. 

Co jest kolejnym krokiem?

Kolejny krok to wygenerowanie pomysłu na rozwiązanie. Tu również metod i dróg dojścia do docelowego efektu jest wiele. Koniec końców wypracowujemy wersję rozwiązania, którą następnie testujemy z rynkiem. To kluczowe, aby już na wczesnym etapie pomysłu, zderzyć go z odbiorcami. Możemy to zrobić na wiele różnych sposobów. Wybór tego, który sprawdzi się u nas, zależy od kontekstu, dlatego warto być elastycznym. Już na tym etapie ścieżka się rozwidla i de facto możemy testować nasze koncepcje, wdrażając je do realnego organizmu (MVP, beta testy), a możemy robić to poza produktem, np. testując prototyp w testach użyteczności, podczas walidacji w wywiadach itd.

Myślę, że przy tym wszystkim ważne jest też to, aby na wdrożeniu nie poprzestawać. Warto wiedzieć w jaki sposób nasza funkcjonalność kontrybuuje w sukcesie biznesowym, warto znać jej wpływ na zachowania użytkowników, warto śledzić jej adaptację i odbiór. Dlatego zawsze zachęcam, żeby ustalać metryki, monitorować je i wyciągać wnioski. Bo Product Discovery nie dzieje się raz. To proces. Proces, który najwięcej osiąga, gdy mamy jego continuum z góry założone w organizacji. To wymaga silnej kultury produktowej, ale to też zwraca się i odpłaca nam bogactwem wiedzy, która w dowolnym momencie może zostać wykorzystana, by stać się punktem wyjścia do nowego odkrycia i kroku w rozwoju.

Jakie najczęstsze błędy popełniamy na etapie wprowadzania feature’ów?

Pewnie jest ich sporo, ale ja podzielę się tymi, które przychodzą mi w pierwszej myśli:

  • myślenie wyłącznie o rozwiązaniu zamiast o problemie i wartości, jaką musimy dostarczyć,
  • brak poparcia w strategii produktu i biznesowego uzasadnienia dla rozwiązania,
  • brak zderzenia pomysłu z odbiorcą, pomijanie fazy testowania i iteracji,
  • zakochanie się we własnym pomyśle/rozwiązaniu,
  • “wszystko albo nic”, czyli perfekcjonizm ponad MVP,
  • brak otwartości na lekcje, zwane również błędami.

Swoją drogą – to zabawne: organizacje unikają błędów, nie dopuszczają ich do świadomości, a nie robią zbyt wiele, by wyeliminować je na wczesnym etapie, np. w formie walidacji pomysłu.

Ile czasu trwa wdrożenie produktu w oparciu o metodologię PD? Porównajmy to z modelem, w którym po prostu wdrażamy produkt, bez badań i potwierdzenia tezy stojącej za danym rozwiązaniem?

Takie porównanie moim zdaniem zupełnie nie ma sensu. Product Discovery jest procesem bardzo zwinnym i tu wszystko się może zdarzyć. Możemy wypivotować, możemy odrzucić pomysł na wdrożenie, bo rynek pokaże nam, że nie jest na to gotowy, albo proces odkrywania pokaże, że technologicznie może udźwigniemy wdrożenie, ale procesowo nie damy rady utrzymać takiego produktu, bo nie mamy na niego zasobów, których potrzebuje. 

Jednocześnie Product Discovery dla problemu, który pierwotnie chcieliśmy rozwiązać jakimś skomplikowanym mechanizmem, może nas doprowadzić do rozwiązania w postaci….komunikatu. Sam zatem przyznaj, czy jest sens porównywać te scenariusze? Zamiast tego, proponowałabym porównać ze sobą ryzyka i szanse, które na nas czekają przy opcji z Product Discovery i bez niej. Tu robi się znacznie ciekawiej.

Na koniec, jak zostać Digital Strategistem? Co przemawia za tym, że jest to zawód warty uwagi?

Uśmiecham się w duchu, bo zakres moich obowiązków oraz działania, które podejmuję, w zależności od chwili i otoczenia, można zdefiniować i zakwalifikować do różnych zawodów. Tak więc nazewnictwo uważam za kwestię wtórną. Wspólny mianownik w tym, co robię, to zawsze łączenie dwóch perspektyw: konsumenckiej i biznesowej. Pytasz jak dojść do tego miejsca? Myślę, że dróg jest bardzo wiele. Pracowałam zarówno po stronie marki, jak i po stronie agencji, która markę obsługiwała. To pozwoliło mi lepiej zrozumieć biznes, ale i lepiej poznać specyfikę docierania do i interpretowania konsumentów. To, czym zajmuję się na co dzień z pewnością wymaga otwartej głowy i spodoba się każdemu, kogo fascynuje świat, ludzie. A łączenie kropek jest wyjątkowo atrakcyjnym zajęciem, zwłaszcza, jeśli w finale widzisz, że dostarcza to realnej wartości drugiemu człowiekowi czy biznesowi.


Justyna Izydorczyk. Head of Strategy Department w goodylabs, service designerka, pasjonatka badań oraz projektowania doświadczeń. Pracuje z interdyscyplinarnymi zespołami nad badaniami z użytkownikami, walidacją konceptów biznesowych, tworzeniem usług i produktów end-to-end i rozwijając te istniejące. Na koncie ma realizacje dla takich marek, jak: 4F, mBank, PKO Ubezpieczenia, Sephora, Adamed, Outhorn, Lilou, PWN, Orange.

Redaktor naczelny w Just Geek IT

Od pięciu lat rozwija jeden z największych polskich portali contentowych dot. branży IT. Jest autorem formatu devdebat, w którym zderza opinie kilku ekspertów na temat wybranego zagadnienia. Od 10 lat pracuje zdalnie.

Podobne artykuły