Link do wydania
Część 2 wywiadu z Piotrem Goliankiem
Grzesiek: Cześć Piotrek, w poprzedniej części rozmawialiśmy o Twojej drodze do zarządzania produktem. Zaczęliśmy też temat discovery, który dzisiaj będziemy kontynuować. Co się dzieje po etapie analizy rynku (etapie makroekonomicznym)?
Piotr: Po etapie makroekonomicznym wschodzimy niżej do etapu mikroekonomicznego, czyli tam mamy cały research związany z personami, z użytkownikami, czyli już schodzimy głębiej.
Chodzi nam tam przede wszystkim o to, żeby zrozumieć bolączki użytkowników, jakie są ich „jobs to be done”, jakie korzyści może przynieść produkt. To jest też dobry moment na to, żeby posegmentować potencjalnych użytkowników.
Bardzo istotne jest to, żeby upewnić się, czy ten problem, który chcemy rozwiązać, jest dla użytkowników wystarczająco ważny.
Rozwiązywanie danego problemu powinno być wartościowe. Research person to jest fajny czas, żeby zweryfikować po raz pierwszy nasze asumpcje, które założyliśmy wcześniej, zderzyć to po prostu z żywymi ludźmi.
Oczywiście później są kolejne etapy walidacji — rozmowy z użytkownikami – to jest pierwszy moment, gdzie można się nad tym wszystkim zastanowić i zderzyć z rynkiem, bo produkt niezderzony z rynkiem to za dużo nam nie powie — może być wciąż super dla nas, ale bezwartościowy dla klientów.
W kontekście użytkowników chodzi nam o projektowanie ich doświadczeń – lejka, w jakim oni funkcjonują.
Personalnie bardzo lubię tak zwany lejek piracki, czyli acquisition, activation, retention, refferal i revenue. Na tym etapie można się zastanowić nad pozyskiwaniem użytkowników, nad ich akwizycją, nad early adopterami – nad tym, jak chcemy, żeby w przyszłości wyglądał ten lejek sprzedażowy dla danego produktu — w zależności jaki tam model biznesowy zostanie przyjęty.
To jest też etap, żeby zrobić „check” – taki moment, w którym możemy coś sprawdzić po raz pierwszy. Później bazując na informacjach, które uzyskujemy z zewnątrz, możemy sobie dalej ten model iterować oraz updatować. Zwłaszcza na wczesnych etapach powstawania jakiegoś pomysłu pivoty są jak najbardziej wskazane, bo lepiej, żebyśmy doszli do takiego wniosku, że coś trzeba zmienić, niż brnęli w takim modelu, że nie zmieniamy tego, bo nasze podejście jest słuszne i to użytkownicy się dostosują do naszego podejścia.
Po tym pierwszym etapie takiego mocnego discovery, który może składać się z różnych etapów, bo może zawierać różnego rodzaju eksperymenty, przychodzi czas na tę walidację produktu.
Walidacja może być niskonakładowa, ale też wysokonakładowa.
Zawsze staram się rozdzielać te dwa typy, bo na początku warto zwalidować istnienie problemu oraz danego rozwiązania — sprawdzamy tzw. problem solution fit, a dalej szukamy naszego product channel market fit i dopóki do niego nie dojdziemy, to w sumie my jesteśmy na etapie walidowania — takiego przedłużonego walidowania.
Z racji tego, że rynek jest zmienny, warto cały czas dostosowywać produkt, aby zachować element równowagi pomiędzy tymi trzema obszarami (product, channel, market).
Grzesiek: Czy uważasz, że jest sens w tworzeniu biznes model canvasów, product vision board i korzystanie z innych tego typu szablonów?
Piotr: Z mojej perspektywy, te wszystkie frameworki to są tylko narzędzia. To, czy z nich skorzystasz, czy nie, zależy całkowicie od ciebie. Wartość, która dają te frameworki jest taka, że pozwalają nam stworzyć plan.
Główną wartością, którą dodają, jest to, że pomagają utrzymać odpowiednią strukturę i zmusić nas do myślenia — umożliwić komunikowanie efektów myślenia z innymi osobami (stakeholderami). Pozwalają przelać efekty wspólnego brainstormingu w jeden model, który będzie zrozumiały dla wszystkich i wystarczająco prosty.
Jeśli napiszesz 30-stronicowy dokument, który pokryje ten obszar, który mamy w canvasach, to jest wszystko okej. Chodzi też o to, aby forma prezentacji i zrozumienia była jak najbardziej efektywna.
Wydaje mi się, że jest duża przewaga tych cavasów. Zauważyłem, że tworzenie takich szablonów trochę nas zmusza do myślenia. Niby większość twierdzi, że ma to w głowie, ale to tak nie działa. Jak przelejemy to na kartkę, to okazuje się, że są białe dziury, których wcześniej nie byliśmy w stanie zilustrować. To jest taki „bezpiecznik”, który warto robić, ale z drugiej strony warto pamiętać, że do wszystkiego trzeba podchodzić z dozą rozsądku.
Grzesiek: Fajnie to ująłeś, że ludzie wiele rzeczy mają w głowie, ale dopiero gdy zaczynasz o czymś głęboko myśleć, robić research – zaczynają pojawiać się w głowie myśli czy to wszystko ma sens, czy rozwiązujemy realny problem.
Piotr: Dalej następuje etap zderzenia tych efektów z rzeczywistością, czyli z rynkiem. Chodzi o etap walidacji, który cały czas powinien być iterowany.
Taką walidację rozpatruje w kilku częściach: mamy eksperymenty niskonakładowe i wysokonakładowe. Z drugiej strony mamy walidację problemu, pomysłu i rozwiązania.
W dzisiejszych czasach jest bardzo dużo możliwości na zrobienie walidacji – internet daje nam ogromne możliwości.
Podstawową walidacją, którą robi większość firm (i na tym ta ich walidacja się ogranicza), to są po prostu rozmowy z użytkownikami lub z osobami, które z użytkownikami współpracują.
Taki typ walidacji dostarcza nam dużo danych jakościowych, ale skala tego jest ograniczona, bo nie jesteśmy w stanie przebadać, nie wiadomo jakiej liczby użytkowników. Na pewno nie jest to coś, z czego należałoby zrezygnować — jak najbardziej trzeba to robić.
Inną specyfiką charakteryzują się wywiady z użytkownikami w przypadku produktów B2B, a w przypadku produktów B2C. W przypadku produktów B2C mamy jeszcze trochę więcej innych możliwości walidacji, gdzie w przypadku B2B to często z rozmów dowiadujemy się najwięcej.
Oprócz tego jest wiele fajnych sposobów jak np. prototypowanie, gdzie dzisiaj z tymi narzędziami np. no/low-code, które mamy — jesteśmy w stanie zrobić bardzo dużo.
Za pomocą takiej „działającej aplikacji” – jesteśmy w stanie zwalidować problem, rozwiązanie, architekturę – po prostu zderzyć takie rozwiązanie z użytkownikami bez konieczności dużej inwestycji w development.
Tych innych opcji do walidacji jest też bardzo dużo, bo można wykorzystać różne nośniki marketingowe jak np. video lub blog posty, posty w mediach społecznościowych, landing page. Tylko po to, żeby wygenerować odpowiedni ruch — organicznych czy to płatny — zachęcić, żeby użytkownicy weszli na te strony, zbadać jak oni się na tej stronie zachowują (badania behawioralne) i czy spełniają określony cel, jaki my sobie założyliśmy.
Sprawdzić, czy są zainteresowani i wpisują się na wishlistę, dodają swój e-mail, klikają „zakup” – to nam też pozwala (jeśli zrobimy to na większą skalę) na taką estymację popytową, która odpowie nam na pytanie jakie jest zainteresowanie użytkowników.
Możliwości, które daje nam obecny marketing, są dzisiaj superokazją, do tego, żeby zrobić jakąś walidację – szybko i prosto. Bardzo wiele rzeczy jesteśmy w stanie zrobić sami, bo narzędzi wspomagających product management jest dzisiaj mnóstwo i można to zrobić w dość przystępnej, fajnej cenie.
Mając już odpowiedni ruch, który ściągniemy na jakiś dany cel, możemy bawić się w takie rzeczy, jak testy A/B, które pozwalają nam stwierdzić, czy lepiej robić wersję A, czy B.
Prototyp czy jakaś prosta wersja MVP, to bardzo fajne sposoby na to, żeby zwalidować dane rozwiązanie wyższym kosztem niż eksperyment niskonakładowy, ale jednocześnie taniej niż mielibyśmy robić rozwiązanie docelowe.
Grzesiek: Przeszliśmy sobie różnego rodzaju walidacje. Co dalej?
Piotr: Mając w różnej formie zrobioną walidację, powinniśmy zebrać wszystkie insajty, zrobić review i zweryfikować na podstawie naszych poprzednich działań czy nasze założenia i pomysły było słuszne.
To jest moment, w którym chcemy się zastanowić i podjąć decyzję, czy idziemy dalej z tym do przodu, czy potrzebny jest jakiś pivot, czy walidacja pokazała, że w ogóle nie ma sensu robić czegoś takiego.
Często powstaje jakieś POC, czyli takie minimum, żeby dalej zbierać informacje jakościowe, ilościowe, które nam posłużą, żeby dowieźć MVP.
MVP to minimalny produkt, który wygeneruje jakąś wartość — będziemy mogli go wypuścić, zderzyć z rynkiem, z użytkownikami i zbadać ich zachowanie.
W moim odczuciu takim prawdziwym produktem, który chcemy, żeby użytkownicy za niego zapłacili jest taki minimum markable product, czyli produkt, który generuje odpowiednią wartość. Składa się z dużo mniejszych MVP-ków, na których my się jeszcze trochę uczymy i tę wartość podnosimy.
Musimy dojść do takiego punktu, w którym rynek nam powie: “Hej, to jest wystarczające, żeby ktoś za to zapłacił”.
Następny etap, który już ciągnie się cały czas i powinniśmy go łączyć z podejściem iteracyjnym, jest taki, że my cały czas dowozimy kolejne rzeczy, czyli budujemy, mierzymy, uczymy się. Najlepiej, jeśli pracujemy w Duat Track’u i cały czas spływa do nas „świeże mięsko”.
Kolejny etap dotyczy tematu stricte go to market. Tutaj skupiamy się na product market fit. Ja rozszerzam go do product channel market fit. W moim odczuciu kluczowe jest, żeby dojść do tego momentu, gdzie mamy ten stan równowagi pomiędzy tymi trzema przestrzeniami.
Grzesiek: Możesz to rozwinąć?
Piotr: Często jak prowadzę jakieś warsztaty czy szkolę ludzi, używam porównania, które usłyszałem pierwszy raz od Radka Zalewskiego z Netguru. On o product channel market ficie mówił w bardzo fajny, alegoryczny sposób. Poprosił nas, żebyśmy wyobrazili sobie kebaba, jako produkt, budę z kebabem, czyli miejsce, gdzie tego kebaba sprzedają i Dworzec Kraków Główny, czyli miejsce, gdzie taka buda z kebabem może stać. Co to ze sobą miało wspólnego? Te trzy obszary są ze sobą w odpowiedniej równowadze, czyli pomiędzy tymi trzema przestrzeniami był odpowiedni fit.
Mówimy też o różnych preferencjach naszych użytkowników. Nasza strategia powinna zawsze zakładać, jacy są nasi odbiorcy- czy to są zapracowani ludzie na Dworcu Kraków Główny – pędzący gdzieś, którzy chcą szybko zjeść jakiś posiłek.
Musimy też pamiętać o naszej konkurencji, jaki jest popyt, czy on jest wystarczający. Czy wystarczający jest popyt użytkowników, którzy będą za to płacić oraz jaką cenę będą w stanie za to zapłacić?
Jest jeszcze super istotny obszar, czyli dystrybucja i kanały, bo można mieć fajny produkt, który rozwiązuje dany problem, ale jeśli w odpowiedni sposób nie dotrzemy do użytkowników, to nikt z tego i tak nie skorzysta. Najlepiej gdy produkt rozprzestrzenia się w sposób viralowy. Takim przykładem viralowego wzrostu (specyficznego, bo wywołanego specyficznymi czynnikami) był rozwój Zoom-a lub Slack-a. Osiągnięcie viralowosci jest super ważne — trzeba jednak pamiętać, żeby ją utrzymywać. Utrzymać retencję też była na fajnym poziomie — żeby później nie było zjazdów, że po pewnym czasie okazuje się, że przyrost użytkowników był zbyt duży, bo np. nasza wartość jest krótkotrwała itd.
Grzesiek: Wspomniałeś wcześniej o ciekawym podejściu do tworzenia dokumentacji. Czy mógłbyś coś o tym powiedzieć?
Piotr: Osobiście doświadczyłem kultury dokumentacji poprzez stosowanie one pagerów, czyli takiej skróconej formy 6-pagera Amazona. W organizacjach, z którymi miałem do czynienia wszystko było utrzymywane w formie tych one pagerów, czyli każda inicjatywa oraz każdy eksperyment miał swój one pager – to faktycznie było przestrzegane.
Te one pagery miały określoną strukturę, wiadomo, że można tam dokonywać pewnych elastyczności — nie jest wszystko zapisane w kamieniu, ale odpowiednia struktura i jakość dokumentacji poprawia mocno komunikacje.
Innym przykładem, który bardzo lubię jest PRD – product requirements document, czyli taki obszerny dokument, który używany gdy podchodzimy do tworzenia nowego produktu.
Gdy robimy coś nowego, to w tym dokumencie streszczamy cały zamysł. Tworzenie dokumentacji redukuje silosowość i zwiększa świadomość pomiędzy zainteresowanymi osobami czy działami — zwłaszcza że w tych dokumentach mamy coś takiego jak sign off danej osoby z danego departamentu. Oznacza to, że ta osoba musi przejść przez ten dokument i być z nim zaznajomiona.
Największym problemem, który pojawia się w organizacjach (nie tylko produktowych), jest komunikacja, a za pomocą odpowiedniego dokumentowania, wierzę, że jesteśmy w stanie zlikwidować silosowość. Oczywiście to jest też proces, który przybliża nas do tego idealnego świata.
Grzesiek: A mógłbyś opowiedzieć, w jaki sposób wygląda tworzenie tego one pagera?
Piotr: One pagery różnią się na pewno w zależności od organizacji. Takim najważniejszym elementem one pagerów są rozpisane cele oraz oczekiwania — informacja co chcemy osiągnąć za pomocą danej funkcjonalności, danej inicjatywy, danego eksperymentu.
Oprócz tego na pewno metryki – na jakiej podstawie zdecydujemy, że coś jest sukcesem czy nie. Warto też dodać wprowadzenie do samej idei, co chcemy osiągnąć, jak taka idea ma wyglądać. Często w takim dokumencie znajduje się także input jakościowy czy ilościowy np. w formie appendixów.
Następnie dodajemy plan egzekucji. Oczywiście w zależności od tego, czego dotyczy ten one pager, to będzie trochę się różnić, bo one pagery inaczej wyglądają w przypadku eksperymentu testu A/B a inaczej w przypadku jakiejś dużej, grubej funkcjonalności.
Bardzo często w tych one pagerach później pojawiało się takie drzewko decyzyjne: osiągnęliśmy to, to i to, jakie podejmowane są następne decyzje, jakie są kolejne kroki i lessons learnt, czyli to, czego się nauczyliśmy.
Przy one pagerach bardzo często dodawaliśmy rzeczy związane z designem (np. mockupy, user flowy). One pager to miało być takie miejsce jedno, do którego ludzie będą mogli wracać ludzie i wszystko będzie w fajny, przystępny i zwięzły sposób opisane.
Na koniec trzeba dodać jeszcze sign offy — czyli różne osoby, z różnych działów musiały zatwierdzić ten dokument, przed wejściem w życie.
Grzesiek: Czy jest coś co chciałbyś jeszcze dodać?
Piotr: Na pewno to, na co chciałbym zwrócić uwagę w takim kontekście ewangelizacyjnym dla całego rynku produktowego, abyśmy mimo różnych nacisków, które często się pojawiają, brali pod uwagę to, żeby robić solidne discovery, żeby robić solidną walidację i żeby zwiększyć nacisk na budowanie produktów, funkcjonalności, które będą miały sens, bo ta smutna statystyka, że 60 czy 80 proc. funkcjonalności, które produkujemy są nieużywane — jest niestety prawdziwa — sam się z tym spotkałem.
To jest i czas i pieniądze wywalone w błoto, więc zachęcałbym do tego, żeby z tym procederem walczyć. Kolejny kierunek, w którym powinniśmy dążyć, jest to, żebyśmy my jako product managerowie brali, walczyli i dostawali empowerment do robienia naszej roboty produktowej i żebyśmy walczyli, dążyli do tego, żeby nasze stanowisko było odpowiednio rozumiane, odpowiednio definiowane i doceniane w organizacjach, bo wciąż często mając stanowisko product managera, ogranicza się do tego, że dana osoba zajmuje się tym, czym zajmuje się project manager czy product owner.
To oczywiście wynika z tego, że u nas w Polsce rozwój produktu i zarządzanie produktem jest jeszcze znacznie młodsze, mniej dojrzałe niż na zachodzie, ale dążmy do tego, żeby korzystać z tych najlepszych praktyk i wcielać je w życie.
Grzesiek: Zapomniałem jeszcze zadać jedno pytanie. Jak zarządzasz stakeholderami?
Piotr: Zarządzanie stakeholderami to chyba najbardziej wymagający obszar pracy product managera (poza komunikacją). Bardzo lubię współpracę ze stakeholderami bo rozmowy z nimi często są dla nas dużym źródłem informacji.
Stakeholderzy powinni być w odpowiednim stopniu angażowani w produkt (w zależności od tego kim są i co robią) – taka relacja bazuje na dwustronnym feedbacku, na takim dwustronnym challengowaniu się. Challengowanie się polega na tym, że jak my, czy oni proponują nam jakieś pomysły, to jesteśmy w stanie wzajemnie się argumentować. Ta argumentacja wynika z kontekstu, z danych, z eksperymentów, z całego tego bagażu, który wcześniej zgromadziliśmy.
Oczywiście prawda jest taka, że nie w każdej organizacji możemy trafić na tak fajnych stakeholderow i jeśli jest szansa, żeby ich ewangelizować, to trzeba w tym kierunku iść. Zdarza się niestety, że na tak wyglądającą współpracę nie ma i produkt bardzo na tym cierpi (wraz z Product Managerem).
Pod tym kątem szablonów, personalnie bardzo polecam ćwiczenia z obszaru stakeholder mapping oraz team canvas, bo na takie ćwiczenia pomagają zjednoczyć wszystkich, z którymi współpracujemy i zrozumieć misję, wizję oraz strategię w sposób ustrukturyzowany.
Grzesiek: W jaki sposób mówisz „nie” do swoich stakeholderów, jak odrzucasz ich pomysły?
Piotr: Podając uzasadnienie, dlaczego nie uważam, że coś takiego w tym momencie powinniśmy robić. Jak mam taką możliwość, to zawsze staram się podchodzić danymi, które mamy zgromadzone.
Odkryłem jakiś czas temu, że super działa używanie różnych anegdotek, więc staram się wplatać to w swoją komunikację ze stakeholderami, zwłaszcza jeśli są to osoby nietechniczne. Trzeba być otwartym na dyskusje. Bardzo lubię brainstormy ze stakeholderami. To musi być konstruktywna wymiana zdań i opinii.
Grzesiek: Jeśli startowałbyś jeszcze raz jako product manager, to co być zrobił inaczej?
Piotr: Zaczynałem jako „one in army”, jako samouk, samodzielnie uczyłem się tego wszystkiego na swoich błędach, z książek, z kursów, z rozmów z różnymi ludźmi. Jest to fajna metoda, na pewno przedsiębiorcza, natomiast młodym ludziom (osobom, które zaczynają ścieżkę w product managmencie) poradziłbym, żeby weszli do fajnego środowiska ludzi produktowych i tam w tym środowisku byli. Poszukali sobie jakiegoś mentora, który mógłby im pomóc na tym pierwszym etapie rozwoju, i żeby znaleźli fajne miejsce, w którym mogliby złapać wiele dobrych praktyk produktowych.
Polecam pójść do firmy produktowej, tylko takiej, która już jest na odpowiednim etapie rozwoju produktowego, żeby były szanse na mentoring i naukę dobrych praktyk.
Jeśli zaczynałbym od nowa, to na samym początku poszedłbym gdzieś, gdzie już ten product management już jest, bo ja tworzyłem wszystko od zera — to była bardzo fajna przygoda, bardzo rozwijająca, natomiast to też nie jest ścieżka dla każdego. Jest to na pewno ścieżka wymagająca, cięższa, nie zawsze dłuższa.
Grzesiek: Dzięki za dzisiaj!
Piotr: Również dziękuje i pozdrawiam!