Michał Mazur

Z tej strony Michał Mazur. Witam Was w kolejnym odcinku ITteracji. Dzisiaj ze mną jest Kamil Cupiał z Product Pro. Cześć, Kamilu.

Kamil Cupiał

Cześć, Michał. Dzień dobry wszystkim słuchaczom. Miło mi Was tutaj powitać. Piękne studio. 

Michał Mazur

Jakbyś mógł kilka słów o sobie powiedzieć, czym się zajmujesz?

Kamil Cupiał

Jasne. Ja jestem Kamil i razem z Michałem Redą rozwijamy markę Product Pro. Pomagamy polskim zespołom produktowym, polskim firmom technologicznym pracować nad rozwojem produktów mądrze. I opieramy naszą działalność o takie trzy filary. Pierwszym jest strategia produktowa, drugim jest analityka produktowa. No i trzecim już tutaj pozwolę sobie napomknąć, a jeśli chodzi o temat dzisiejszego odcinka, czyli product discovery, które uważamy za takie paliwo do wszystkich możliwych działań okołoproduktowych, jeśli chodzi o rozwój produktów cyfrowych.

Michał Mazur

A jeśli mógłbyś w kilku słowach właśnie powiedzieć, co, powiedzmy, wpada do tego koszyczka w tym, jak też Wy do tego podchodzicie, jak to rozumiecie, jeśli chodzi o product discovery, bo wiem, że w różnych organizacjach może to też oznaczać trochę co innego. Więc jak Wy do tego podchodzicie, jeszcze jak Ty do tego podchodzisz?

Kamil Cupiał

Jasne, panie. No, my jesteśmy w branży, gdzie słowo produkt w ogóle może oznaczać dziesięć tysięcy różnych rzeczy, więc tutaj faktycznie ujednolicenie takiego zbudowania wspólnego słownika jest super ważne. Ja discovery, product discovery traktuję dwutorowo. Pierwszy taki ogólny sposób rozumienia tego pojęcia to dla mnie jest filozofia, zmiana perspektywy, że my nie tworzymy produktu, tylko my odkrywamy, jakich produktów rynek potrzebuje. Czyli nie jest to na zasadzie, że zamykamy się w piwnicy i tutaj mamy wizję po paru głębszych, co będzie najlepszym produktem, co będzie się najlepiej sprzedawało, tylko wychodzimy na rynek, pytamy naszych potencjalnych klientów, w ogóle zastanawiamy się, kto jest tym naszym potencjalnym klientem. No i to się wiąże wtedy już tym drugim sposobem rozumienia product discovery jako czegoś węższego, czyli jako zestawu narzędzi, frameworków, sposobów pracy nad tym rozwojem produktu.

Michał Mazur

Powiedz mi, dlaczego to też jest ważne? Bo rozumiem, że jeśli działacie w ramach Product Pro, oferujecie swoje usługi edukacyjne, warsztaty, konsulting. Jest na to potrzeba na rynku i podejrzewam, że wiąże się to też z tym, że w organizacjach są pewne przyzwyczajenia, które Wy też próbujecie zmienić, razem z nimi.

Kamil Cupiał

Jasne. W ogóle wiesz, product discovery jest stosunkowo nowym podejściem. O nim zrobiło się głośno tak naprawdę po premierze książki Teresy Torres "Continuous Discovery Habits". W Polsce początki discovery, jak my to pamiętamy, to 2018  rok i od tego czasu sobie powoli to pojęcie rośnie. Są różne podejścia, jeśli chodzi o to discovery. Natomiast z jakimi najczęściej problemami czy wyzwaniami zgłaszają się do nas organizacje? Tutaj jest to nazywane w bardzo różny sposób, ale można to podsumować prostym stwierdzeniem: "Mamy super produkt, z którego nikt nie korzysta, za który nikt nie chce zapłacić. No i dlaczego?” No i jakby wiesz, są organizacje, które pracują genialnie wdrożonym Scrumie. Mierzą sobie to swoje velocity, wypuszczają fajne ficzerki, dług technologiczny zerowy, downtime zerowy, itd. Natomiast z jakiegoś powodu nikt nie chce płacić. Więc tutaj te organizacje dbają o to, żeby zadbać o ten obszar "build the thing right", natomiast nie dbają o to "build the right thing". I tutaj właśnie discovery jest odpowiedzią na to pytanie, bo największą zaletą discovery jest minimalizacja ryzyka biznesowego, czyli pozwolenie sobie pracować nad tym, co jest naprawdę istotne, co jest naprawdę ważne. Czyli często zrobienie kroku do tyłu po to, żeby się zastanowić, na czym powinniśmy skupić nasze zasoby, na czym powinniśmy się skupić teraz. Discovery dla mnie to też jest zmiana sposobu myślenia, bo my nie myślimy w kategoriach metryk outputowych, czyli np. to słynne, scrumowe velocity, tylko myślimy w kategoriach metryk outcome’owych. I tutaj output rozumiemy jako zmianę sposobu zachowania użytkownika, poprzez nasz produkt. I to z mojej perspektywy jest takim mostem pomiędzy outputem a impaktem. Impakt rozumiany właśnie już jako ten “hajs, który do nas płynie szerokimi strumieniami”. Żeby do tego dojść, no to musimy coś zbudować, co zmieni zachowanie użytkowników. W dużym skrócie.

Michał Mazur

Zmieni ich zachowanie, czyli na przykład usunie bariery, usunie problemy lub stworzy dodatkową wartość.

Kamil Cupiał

Dokładnie. Ta wartość powinna iść zawsze w jakiejkolwiek postaci. Mówiąc o wartości, ja się najczęściej odwołuję tutaj do słynnej piramidy Jobs-to-be-Done, prawda? Mamy te joby funkcjonalne, czyli oszczędność czasu, zwiększenie produktywności. Mamy te joby społeczne, joby emocjonalne i często idą one ze sobą w parze, bardzo blisko. Ale żeby intencjonalnie tworzyć ficzerki, produkty, moduły, nawet kampanie marketingowe, które te joby realizują, no to musimy mieć bardzo głęboką znajomość naszej grupy docelowej. I ona wykracza poza taką przeciętną znajomość, jaką obserwuję wśród firm, z którymi współpracuję.

Michał Mazur

A powiedz mi, jak to się odnosi, czy jak się łączy metodologia dookoła właśnie Discovery? Dla mnie to brzmi bardzo podobnie do tego, co ja jako osoba z backgroundem UX-owym znam od wielu lat, po prostu pod nazwą UX Research albo UX Strategy. Czy to są jakieś tożsame pojęcia, bo wydaje mi się, że wiele też metod, czy takich aktywności, które się robi, są dosyć podobne.

Kamil Cupiał

Tak, zdecydowanie. Wiesz, my jako UX jesteście takim ambasadorem użytkownika końcowego po stronie produktu. Teraz natomiast zachęcam, żeby wdrażane Discovery było prowadzone przez tzw. Trio produktowe, czyli Product Manager, UX Research/UX Designer, i Tech Lead, dlatego że w Discovery próbujemy łączyć te trzy perspektywy, tak jak chyba zresztą macie w czołówce do ITeracji, że przypomnieliśmy, jak to dokładnie leci, ale z różnych perspektyw o tym samym - łączenie technologii i biznesu, Discovery właśnie na tym polega. My myślimy w Discovery holistycznie, myślimy często modelami biznesowymi. I znowu, jeśli sobie weźmiemy najbardziej popularne modele, które proponuje na przykład Alex Osterwalder, np. Business Model Canvas albo Lean Canvas, no to w zasadzie wszystkie te dziewięć segmentów, które mamy na tej kartce, możemy połączyć, żeby odpowiedzieć na pytanie: czy ktoś będzie tego używał, czy my powinniśmy to budować i czy możemy to zbudować. Czyli takie trzy obszary. No i UX w zasadzie wchodzi we wszystkie te trzy obszary, bo po pierwsze wy tłumaczycie potrzeby klienta, które poznajemy, na język produktowy, techniczny. Po drugie, powinniście mieć, w dojrzałych organizacjach, wpływ na to, jak ten produkt wygląda też od strony technologicznej. No i zdecydowanie, jeśli chodzi o generowanie wartości czy sposób przedstawienia wartości produktu, to też się tam pojawia. Natomiast Discovery jest po prostu pojęciem szerszym, bo Discovery również wchodzi w grę wtedy, kiedy jeszcze do końca nie wiemy, kto jest naszym użytkownikiem, kiedy dopiero szukamy. Takim dość częstym case'm z mojego doświadczenia agencyjnego jest sytuacja, w której przychodzi do nas ktoś, software house, jacyś founderzy, którzy mają świetną technologię, świetnie działający algorytm, na przykład sfinansowany ze środków Unii Europejskiej. I przychodzą z pytaniem: "Dobra, mamy super produkt, w naszym mniemaniu super. Komu to teraz sprzedać, nie?" No i to jest taki reverse engineering w tym kontekście. I UX-i, poprawcie mnie, jeśli się mylę, ale zakładam, że w takiej sytuacji, w sytuacji UX, mogą się czuć troszeczkę zgubieni, bo to jest w ogóle taka abstrakcja.Nie wiecie z kim rozmawiać, nie wiecie, co robić żeby jakoś to działało. Dobry UX to jest coś zupełnie innego dla grupy A i coś zupełnie innego dla grupy B. Więc tutaj Discovery troszeczkę odpowiada również na tego typu wyzwania.

Michał Mazur

To mi przywodzi też na myśl to, o czym też rozmawiałem w pierwszym odcinku tego sezonu z Michałem Wardą, o nowych technologiach, które właśnie często wchodzą i mamy technologie blockchain czy AI. Chociażby nawet ten Chat GPT, który powstał kilka lat temu, ostatnio się spopularyzował i to jest takie hard innovation, że dosłownie potem zastanawiamy się, czy nawet obserwujemy dopiero, kto tę technologię jakoś adaptuje, prawda?

Kamil Cupiał

Tak, zdecydowanie. Jak pracowałem nad projektem tzw. metaverse, czyli kochane web3, projekt miał świetnie rozpędzony marketing, czyli nie narzekał, na przykład na brak osób, które chciały inwestować w niego. Ale zespół odpowiedzialny za ten projekt zupełnie nie miał pojęcia, kto jest ich personą i dla kogo w zasadzie budują ten produkt, który cały projekt metaverse'owy jakby firmował, nie? Więc wtedy w grę weszło Discovery bardzo szeroko zakrojone, żebyśmy się tak naprawdę dowiedzieli, bo czym innym było nagonienie ludzi, a czym innym było zrozumienie, dlaczego oni przyszli. I wiadomo, że idealnie Discovery powinno się wydarzyć wcześniej, natomiast jedną z najważniejszych cech dobrego Discovery jest adaptowalność. Więc dobre Discovery i potem też można poznać tzw. różnicę między tzw. dogmatycznym discovery, gdzie bierzemy sobie książkę, podręcznik i lecimy punkt po punkcie, a adaptowalnym discovery, gdzie już rozumiemy, co służy czemu i co kiedy powinniśmy wykorzystać, żeby co osiągnąć. 

Michał Mazur

Czyli mamy jakiś taki zestaw metod, aktywności, które możemy sobie dopasowywać do tego, co w danym momencie potrzebujemy, tak?

Kamil Cupiał

Dokładnie. No tak, w największym skrócie Discovery można podzielić na eksploracyjne albo eksploratywne i walidacyjne. Czyli ten pierwszy etap, bo to są często etapy, choć później, jak to w świecie iteracyjnym się zdarza, one się zaczynają przenikać, ale ten pierwszy etap służy do zrozumienia i pogłębienia tak zwanego problem space. Czyli my szeroko sobie eksplorujemy naszą grupę docelową, ich problemy, ich motywacje itd. A później w researchu czy w Discovery walidacyjnym wchodzimy w tak zwany solutions space, czyli musi nastąpić moment, w którym, oczywiście, Wy jako UX jesteście nieocenieni, bez Was się tego dobrze zrobić nie da. Kiedy zastanowimy się, które bolączki klientów, które motywacje, które te joby chcemy zagospodarować, mamy szereg pomysłów, czyli te tak zwane nasze solutions, no ale jeszcze przed oddaniem tego do delivery, do developmentu, dobrą praktyką, często pomijaną niestety, natomiast dobrą praktyką, która drastycznie może ściąć późniejsze koszty developmentu, jest walidacja tych rozwiązań. Czyli można to robić nawet w trakcie wywiadów. Oczywiście trzeba uważać, żeby nie wpaść w pułapkę deklaracji, ale można to teoretycznie robić w ramach wywiadów. Natomiast tutaj potęgą są metody, które dostarczają nam danych behawioralnych, czyli począwszy od jakiś prostych eksperyment page'ów po smoke test, po bardziej skomplikowane, tak zwane Human Operated Tests albo po polsku testy interfejsu białkowego, nie? Bo to człowiek, przez jakiegoś stażystę często, który klika i udaje działanie algorytmu, i wtedy niskim nakładem kosztów tak naprawdę możemy sprawdzić, czy to rozwiązanie, za development którego mielibyśmy zapłacić X złotych/dolarów, tak naprawdę jest sens wdrażać. 

Michał Mazur

Czy właśnie testy użyteczności, gdzie dajemy też właśnie jakieś scenariusze osobom do przejścia, nawet w takim prototypie figmowym? Figma nie oferuje jeszcze, powiedzmy, tego, co potrzebujemy rzeczywiście, żeby zbudować takie doświadczenia produktowe. Jakiegoś zarządzania danymi tam nie ma czy formularzy. Natomiast wszystko przed nimi, tak? Może te miliardy od Adobe zostaną na coś tam wydane. Natomiast właśnie to też przychodzi mi do głowy, jak mówiłeś o tych dwóch bazach, to ten model podwójnego diamentu, gdzie właśnie najpierw myślimy szeroko, szukamy problemów, eksplorujemy, ale potem decydujemy się też na to, które problemy chcemy rozwiązać. I wydaje mi się, że tutaj też na tych etapach właśnie takich przejściowych, że najpierw zarzucamy szeroko sieć, ale potem wspólnie jako organizacja czy zespół podejmujemy decyzję, którą stronę rzeczywiście chcemy, jeśli zanim pomyślimy o rozwiązaniach, to zastanawiamy się, które właśnie problemy należy rozwiązać. I tutaj przychodzi mi na myśl wiele takich metod czy rodzajów spotkań warsztatowych, gdzie mamy właśnie metody typu Impact Effort Matrix, to może już troszkę później, co prawda, w etapie, ale wszelkie takie spotkania warsztatowe, gdzie jednak razem, w jednym momencie, podczas jednego, dwóch, trzech, pięciu dni siadamy jako zespół i zastanawiamy się, jak to powinno iść. Plus takie warsztaty skopingowe już w zasadzie wtedy występują.

Kamil Cupiał

Ja bym jednak cofnął się jeszcze krok do tyłu, bo kiedy możemy robić wszystko, często wpadamy w taki paraliż. Więc moim zdaniem, na etapie podejmowania decyzji, co robimy, w którą stronę idziemy, powinniśmy jeszcze pomyśleć o strategii produktowej albo na wczesnym etapie przynajmniej o takim drafie strategii produktowej. Bo strategia, jak ja ją rozumiem, strategia produktowa wynikająca ze strategii biznesowej, to nie są te same rzeczy i to też często bywa mylone w organizacjach. To jest nie tylko sposób myślenia o tym, co robimy, ale też myślenie o tym, czego nie robimy. I to drugie jest często bardziej trudniejsze, bo jako folderze inaczej obserwuję pewne tendencje, które są oczywiście w pełni zrozumiałe, że jeśli na przykład leżą pieniądze na stole, bo przyszedł jakiś klient z konkretnym requestem i mówi: "Ja podpiszę umowę na rok, tylko dajcie mi tę feature", no to są wtedy tendencje do tego, żeby taką metodą tzw. HIPPO troszeczkę narzucać tę swoją wolę. Jeśli nie ma strategii produktowej albo jeśli ona jest tylko w głowach paru osób i nie jest powszechnie znana, nie jest nawet wstępnie opomiarowana, zwymetrykowana, nie jest przemyślana, no to wtedy takie wasze skopingowe mogą się zamienić w koncert życzeń, z mojej perspektywy. I strategia produktowa, moim zdaniem, powinna powstawać równolegle do Initial Product Discovery, jeśli powstają nowe produkty, jeśli dopiero zaczynamy pracę, no to to są takie dwie strony tej samej monety. Z jednej strony, bo strategii nie stworzymy bez Discovery, ale Discovery też jest ukierunkowane w jakąś stronę. Więc my powinniśmy świadomie podejmować decyzje, co chcemy eksplorować, bo nie da się, wiesz, eksplorować wszystkiego.

‍

Ja kiedyś miałem klienta, który prowadził startup aspirujący do startupu biotechnologicznego, po czym nagle skręcił. I o ile pivotowanie nie jest złe, tak ten skręt na podstawie jednego requestu od potencjalnego klienta sprawił, że oni zaczęli rozwijać software do monitoringu zdrowia koni w boksach. Uwaga. To zupełnie inna grupa docelowa, zupełnie inne problemy. Jedyny mianownik, moim zdaniem, to było to, że tu i tu mamy software. I takie rzeczy się dzieją, jeśli nie mamy strategii, nie mamy sami narzuconych na siebie takich filtrów strategicznych, przez które przepuszczamy wszystkie potencjalne problemy, dyskusje, potrzeby. Nawet myślę, szkic propozycji wartości na samym początku może być taką mega wstępną strategią produktową, byleby coś nas odpowiednio kierunkowało. Muszę zapytać, czy mieliście personę konia w tym projekcie?

‍

Na szczęście udało się skalować ten projekt, zanim byliśmy zmuszeni tworzyć persony konia. Chociaż myślę, że taka proto-persona była, bo ten pomysł z monitoringiem zdrowia koni w boksach to nie jest pozbawione sensu. Wiesz, to są często bardzo drogie wierzchowce. Wyobrażam sobie, że jak ktoś ma konia za pół miliona złotych, to to jest też inwestycja. Poza tym, że to jest oczywiście żywe stworzenie, to jest to też dla niego inwestycja, więc nie było to pozbawione sensu, tylko nie w tym produkcie.

‍

Jeśli myślimy właśnie o takim procesie, który się trochę przenika pomiędzy biznesem a produktem, widzę tutaj, że też często, szczególnie w tym świecie, powiedzmy IT szeroko pojętym, często właśnie mamy produkty typu SaaS, gdzie właściwie firma i produkt to jedno, gdzie ta firma nie oferuje żadnych innych produktów. Więc jeśli weźmiemy sobie na przykład takie Notion na przykład

‍

Czy w takim wypadku jako strategię biznesową i strategię produktową traktowałbyś jako to samo, czy na przykład bardziej to rozbijać? Wiem, że wiele firm tak robi, że po prostu tworzy oddzielne zespoły czy działy produktowe na aplikację mobilną, integrację, aplikację webową lub z kolei już dzieli to na przykład na poziomie ficzerów, czyli wyszukiwanie, billing, czy jakieś tam konto, i tak dalej. Jakie masz doświadczenia właśnie w takiej utożsamianiu strategii biznesowej z tą strategią produktową? Z kolei dzieleniu tego na jakieś mniejsze kawałeczki.

‍

Poruszyłeś jedną z najtrudniejszych tematów, z mojej perspektywy. Bo doświadczenia mam bardzo różne i nie jestem w stanie wskazać, które są dobre, a które nie sądowe. I zaczniemy w ogóle od pojęcia produktu. Produkt, w definicji life'owej, to jest zamknięta całość, która dostarcza, czy realizuje propozycję wartości. Ja mam z tą definicją bardzo duży problem, bo ona jest przy większych produktach niezarządzalna. Jeśli weźmiemy przykłady z polskiego podwórka, na przykład takie Allegro. Allegro w tym momencie ma ponad sześćdziesiąt product managerów. I tutaj, patrząc na strukturę, no to product manager jest osobą odpowiedzialną za produkt. Więc oni siłą rzeczy, przy takiej strukturze, dzielą sobie jedno duże Allegro na mniejsze produkty. I dla nich, np. wyszukiwarka jest produktem. Dla Allegro, nawet produktem będzie Smart, prawda? Czyli system lojalnościowy, w zasadzie.

‍

No i teraz pytanie: czy wyszukiwarka, poza kontekstem Allegro, realizuje jakąś propozycję wartości, czy Smart, poza kontekstem Allegro, realizuje jakąś propozycję wartości? No nie. Ja muszę korzystać z Allegro, muszę tam robić zakupy, żeby mieć jakiekolwiek benefity ze Smarta. I takie podejście jest moim zdaniem w pełni uzasadnione, bo w tak skomplikowanych ekosystemach, jakim jest Allegro, czy przywołanym przez Ciebie nowszym, trudno będzie znaleźć osobę, która w szczególe będzie wszystko o danych ficzerach, modułach, zwał jak zwał, wiedziała.

‍

Więc idąc od góry, ja wychodzę z założenia, że wszystkie strategie powinny mieć wszechstronny aspekt funkcjonalny. Tym herbem mówię, że dobra strategia to użyteczna strategia. Więc ja tutaj znowu stawiam na adaptowalność. Dla mnie, strategia biznesowa jest takim szerokim paskiem na samej górze, z której wynikają później poszczególne, pomniejsze strategie. Ze strategii biznesowej wynika w końcu nie tylko strategia produktowa. Oczywiście, dla nas jest najważniejsza, ale nie możemy zapominać o strategii brandingowej, marketingowej, operacyjnej, i tak dalej. To wszystko są zupełnie osobne worki. Natomiast w tej strategii produktowej możemy mieć ogólną strategię, która mówi nam, jak poprzez cele produktowe realizujemy te cele biznesowe, importowe.

‍

No i następnie obserwuję, jak te konkretne, tutaj znowu proszę się nie czepiać słówek, niech to będą te podprodukty, subprodukty, moduły, ficzery, bardzo często mają swoje takie podstrategie, które mają określone własne KPI, własne bety, czyli zakłady, jak długoterminowo myślimy o rozwoju tego produktu. No i tutaj już się zaczyna zabawa, bo pojawiają się korelacje między szczególnymi ficzerkami, pojawiają się właśnie kwestie, nie wiem, mergowania albo rozdzielania, rozbudowywania, killowania.

‍

Więc, jakby dla mnie, struktura strategii jest ściśle oparta o struktury organizacyjne, z którymi pracujemy. Natomiast najważniejsze jest to, żeby ta strategia była w jakiejkolwiek formule. Nawet sama strategia biznesowa to jest już, i tak naprawdę, bardzo dużo.

‍

Które to mi też przychodzi na myśl metodologię OKR, które na to trochę pozwalają budować takie właśnie drzewka, że tak powiem, gdzie z jednych z głównych, nadrzędnych celów organizacji wynikają jakieś drobniejsze rzeczy już per departament czy zespół. I to rzeczywiście wtedy da się jakoś prześledzić. Są oczywiście też aplikacje do tego, my też na taką jedną aplikację do klientów pracujemy, czy gdzieś tam, może niekoniecznie nad tym modułem, ale oni też dowożą takie rzeczy, gdzie, no, też dla dużych organizacji może być to niesamowicie trudne, szczególnie dla organizacji międzynarodowych, gdzie zespoły często się mijają w ogóle czasowo. No, to jednak takie wspólne zrozumienie tej strategii wydaje mi się, rzeczywiście, jest kluczowe.

‍

Tutaj właśnie przykład Allegro też jest bardzo fajny. I pamiętam, jak pracowałem w organizacji, gdzie była to marka obuwnicza, gdzie były sklepy stacjonarne, ale ja pracowałem w zespole, czy w dziale, odnośnie związane z e-commerce. No i też to było tak, że z jednej strony ja mogłem sobie powymyślać jakiś feature. Pamiętam, myśleliśmy nad taką funkcją, która jest bardzo standardowa w sklepach internetowych, ale jeszcze tam tego nie było. Gdzie wchodząc na podstrony jednego produktu, jednego modelu butów, masz podgląd na to, jakie są inne dostępne kolory, czy warianty w ogóle kolorów, materiałów. No i teraz pojawiały się pytania: dobra, czy pokazujemy, czy rozdzielamy te warianty materiałowo i kolorystycznie? No to musimy się spytać kogoś od produktu fizycznego, że tak powiem, jakie przewidujemy w ogóle rodzaje wariantów danych butów. Musieliśmy zobaczyć od strony technicznej, czy nasz build Magento, nad którym wtedy pracowaliśmy, czy on też pozwala na odpowiednie zarządzanie tymi wariantami tak, jak my sobie to wyobrażamy. I jeszcze z innej strony, czy na przykład my powinniśmy pokazywać, jeśli but jest czerwony, a drugi jest bordowy, czy pokazujemy miniaturkę koloru czerwonego w obu przypadkach, czy robimy każdy kolor dla każdego modelu oddzielnie? I tu mówimy o sklepie, który sprzedaje tysiące modeli butów. Pokazujemy wycinek zdjęcia, tylko wtedy musimy się skontaktować z fotografem, który to zdjęcie musi przygotować.

‍

A teraz, ja bym to zrobił. Teraz ja bym to zrobił tak: wycinek zdjęcia, ale to pokazało mi, że nawet tak naprawdę takie pierdoły, takie drobne ficzery, których ludzie nie zauważają, bo już są oczywiste, pomagały często w takiej dużej pracy pomiędzy tymi departamentami. A im większa organizacja, tym takich współzależności jest więcej. I, jeśli w ogóle, bardzo niestety często spotykaną z moich obserwacji patologią jest konkurencja wewnętrzna. I to jest coś strasznego. I to nie ma uzasadnienia ani logicznego, ani emocjonalnego. Ona się bierze zazwyczaj z jakiejś historii, ale moim zdaniem, tutaj takim bezpośrednim powodem jest to, że nie ma ogólnodostępnej strategii. I to na jakimkolwiek poziomie, że ludzie w organizacji tak naprawdę wszyscy podejmujemy decyzje strategiczne od zarządu, gdzie to jest oczywiste, po dewelopera, który musi podjąć decyzję, czy ma dowieźć taska do końca dnia, bo tak mu manager powiedział, czy weźmie na siebie i powie, sorry, nie dałem rady, potrzebuję więcej czasu, bo inaczej to będzie kiepsko działało. I to wynika ze strategii, czy my stawiamy na prędkość, bo w niektórych sytuacjach to jest uzasadnione, żeby wypuścić coś nieidealnego, ale szybko, czy przestawiamy na rzetelność. I to są takie elementy, gdzie każdy w organizacji powinien powiedzieć w jakiej sytuacji podjąć jaką decyzję. I to jest po prostu konsekwencja strategii.

‍

Czy przychodzą Ci na myśl jakieś produkty czy organizacje, które Twoim zdaniem, przynajmniej z tego, co da się wyczytać, też z zewnątrz, chyba że też znasz z wewnątrz, które właśnie bardzo dobrze podchodzą do tematu właśnie chociażby discovery czy strategii produktowej i tych metodyk, o których też rozmawialiśmy, czy na temat których edukujecie? A to jest bardzo dobre pytanie. Wiesz, jeśli chodzi o polskie podwórko, to ja myślę, że przywołałbym tutaj Allegro. Z tym samym współpracujemy dość regularnie. Ja jestem pod dużym wrażeniem, jak tak duża organizacja z tak skomplikowanym produktem ogarnia sobie to discovery, bo oni faktycznie, jak przywołałeś ten przykład, czy buty takie, czy świadczą o tym, jak bym zrobił krok do tyłu i zapytał ludzi, czy w ogóle zwrócą na to uwagę, czy jest to często nieistotne. I Allegro bardzo często nawet takie super niskopoziomowe decyzje opiera właśnie na ciągłym discovery. To jest element ich procesu rozwijania produktu. Jeśli chodzi o inne organizacje, to mogę tutaj rzucać takimi przykładami naszych klientów, na przykład z ostatnich, gdzie obserwujemy, jak to, czego się uczą, na przykład jest później fajnie wdrażane.

‍

Tutaj na przykład pozdrawiam Dominika Smart Lunch. To jest taki ciekawy startup B2B, który zapewnia wyżywienie różnym organizacjom, na przykład nie mam na myśli fabryk, gdzie są hale fabryczne, ale dużą organizację, która potrzebuje dowozu jedzenia. I tam to Discovery jest na bardzo szeroką skalę zakrojone i wszystkie decyzje, albo większość decyzji istotnych, jest podejmowanych po prostu tak, on the flow.

‍

Z dużych organizacji, z kolei, no to myślę, że tutaj takich, które wszyscy znają, no to pomijając takie ikony, chciałbym zwrócić uwagę na przykład na Hubspot. Hubspot, czyli taki marketing automation/s CRM i tak dalej. W sumie to teraz wszystko. Oni również mają bardzo prężnie działający zespół Discovery i moje codzienne narzędzie, Miro albo Miro, jak kto woli. Oni z kolei stawiają na Discovery ilościowe oparte na mikromomentach, czyli wiesz, użyjesz jakiegoś template'a, to od razu pytają o skalę i tak dalej. Podobnie, mają bardzo dużo programów badawczych opartych o grupę heavy userów, na przykład Airbnb. Wiem, bo dużo korzystam, więc jestem w każdej i ja jestem pod bardzo dużym wrażeniem tego, że oni mają odwagę, po pierwsze, to robić, nie oszczędzają na tym zasobów, ale też trzecia rzecz, nie boją się powiedzieć, że coś im nie siada albo coś nie realizuje celów.

‍

Czyli ja teraz, na przykład, mam w głowie takie cztery grupy w kontekście Mirror, w których uczestniczyłem, gdzie testowałem jakiś produkt, dawałem feedback i dwa spośród tych modułów nie weszło na rynek, po prostu je skasowali. I tutaj znowu nawiązuje do mądrości Aleksandra Starwardera. Im większy kill rate w organizacji, tym większe szanse na sukces. Bo wtedy odrzucamy pomysły dobre, zostają tylko bardzo dobre.

‍

To nie jest tak, że organizacje boją się rzeczywiście zabijać ficzery? Większość się boi. Tutaj działa efekt kosztów utopionych, to już na pewno znacie to z badań UXowych. Mamy tendencję inwestowania w coś, co już inwestowaliśmy, czyli organizacje widzą, że jak poszło w blisko awarii tam x godzin, no to halo, coś tam musi z tego być, nie odpuszczamy. Sam pracowałem przez Discovery na zasadzie "Zrób jak musisz, ale ma być tak i tak". Decyzja już została podjęta.

‍

BHU: To mi się kojarzy trochę z systemem szkolnictwa, takim tradycyjnym, gdzie mamy klucz odpowiedzi. Mamy zrobić jakieś zadanie, ma być jakiś wynik. Jeszcze krok po kroku, tak jak jest w kluczu. Dokładnie. A nie można powiedzieć na końcu: "Hej, to nie ma sensu, nie zgadzam się z tym". Powinniśmy to robić jak najczęściej, bo tutaj statystyka działa. To nie jest możliwe, żebyśmy mieli tylko dobre pomysły, a nie wiemy, które pomysły są dobre, złe albo bardzo dobre, dopóki ich nie przetestujemy. Bo zupełnie inaczej rozmawia się z użytkownikiem na IDI na początku, gdzie on może deklarować coś, a zupełnie inaczej wtedy, kiedy już mamy dane behawioralne, już zrobiliśmy kroczek do przodu, mamy makietę, mamy jakiegoś landing page itd. Wiadomo, że to wymaga więcej pracy, ale wciąż mniej pracy niż właściwe development.

‍

Z jednej strony właśnie mamy tutaj te metody Discovery związane właśnie z użytkownikami, właśnie te wywiady pogłębione, wszelkie ankiety, grupy fokusowe i tak dalej. Z drugiej strony też mamy taką właśnie analizę biznesu i ja sobie też zawsze myślę o tym, że biznesy i organizacje to z jednej strony oczywiście te wszystkie systemy, dokumentacje, jakiś kontekst prawny tego wszystkiego, ale to też są ludzie i ci ludzie mają swoje doświadczenia, swoje ambicje, tak jak mówisz, co czasami prowadzi do konkurencji, jakiś wewnątrz, ale domyślam się, że rozmowa z ludźmi i trochę wyciąganie też z nich tego, czego oni potrzebują jako osoby, żeby też ta praca i organizacja była dla nich satysfakcjonująca, podejrzewam, że to też ma duży wpływ na straty. Duży, na przykład, multikagen, on wyróżnia nawet Discovery wewnętrzne. Jeśli mówimy o rozwoju produktu, to czym innym jest badanie potrzeb, co często świetnie się zajmują po prostu biznes analitycy, zwłaszcza w kontekście takiej pracy agencyjnej, ale właśnie takie Discovery wewnętrzne, czyli poświęcenie trochę więcej czasu na zrozumienie takich motywacji ukrytych, to też potrafi nam zmienić perspektywę.

‍

I o ile jestem bardzo daleki od stwierdzenia, że powinniśmy opierać priorytety naszego produktu na tym, co uważają nasi z tej folderze, jestem bardzo daleki. Tak, Discovery wewnętrzne pozwala nam zaplanować odpowiednią komunikację w stosunku do nich, bo różnice w tej folderze będą oznaczać również różne potrzeby charakterologiczne. Jesteśmy inni, różne argumenty będą do nas trafiać. Są osoby bardziej wizyjne, są osoby bardziej nastawione na dane i tak dalej, więc istnieje taki model bardzo prosty, DISC, opracowany przez Eriksona, znany z książek w stylu "Otoczeni przez idiotów", "Łódź w szewie z idiotą" itd. Bardzo prosty w założeniach, ale o bardzo potężnie szerokiej gamie zastosowań.

‍

W poprzedniej agencji, Project People, robiliśmy ćwiczenie, które pozwalało nam ocenić na warsztatach, które pozwalało nam ocenić właśnie kolor charakteru z tych holderów, po to, że później, jak montowaliśmy sobie prezentację podsumowującą albo robiliśmy synchro, dostosowywaliśmy kolejność argumentów albo sposób ich przedstawienia do tego, kto nas słuchał i kto podejmował decyzje. I to działało super. No brzmi super. Brzmi to jak bardzo świadome podejście, bo de facto to są też ludzie, którzy podejmują potem decyzję, tak jak mówisz, trzeba się z nimi odpowiednio komunikować. Chwilę czasu potrafimy zaoszczędzić w ten sposób. Ćwiczenie trwa piętnaście minut. To było bardzo proste ćwiczenie, mogę zdradzić słuchaczom. Skorzystaliśmy z narzędzia Value Poker, czyli takie karty wirtualne, pięćdziesiąt czy pięćdziesiąt pięć kart, i tam od dyscypliny po empatię, każda wartość miała przypisany swój kolor, bo polecenie było takie: wybierz trzy najważniejsze wartości, jakimi kierujesz się w trakcie współpracy.

‍

Na przykład osoby czerwone, nastawione na działanie, akcje, są to osoby, które na przykład dzwonią do Ciebie, bez "cześć" i zadają pytania i czym się rozłączają. To jest bardzo charakterystyczne. I unikają konfrontacji? Nie, no właśnie, oni unikają, oni są bardzo konfrontacyjni, czerwoni są bardzo konfrontacyjni. Tak, że nie unikają niczego, jak to wyglądało. No i właśnie takie osoby czerwone często wybierają wyniki, rezultaty i tak dalej. Od razu po takim ćwiczeniu, jeszcze najlepiej z omówieniem, masz czarno na białym, że ta osoba jest czerwona, ta osoba jest żółta, czyli trzeba troszeczkę bardziej długoterminowo, wizyjnie, a storytellingowo przedstawić. Ta osoba jest niebieska, więc jakiegoś Excela pewnie trzeba przygotować, bo na PowerPointa to nie spojrzy i tak dalej. Genialne, dziesięć minut inwestycji na kickoffie, a później masz załatwione.

‍

Ok. Jakim ty jesteś kolorem? Ja jestem bardzo ciekawym zjawiskiem, podobno, bo ja mam bardzo wymieszane. Mam najwięcej, pięćdziesiąt pięć procent żółtego, podobno, a reszta jest praktycznie porównywalna. U mnie też duża przewaga żółtego wyszła, bo też robiliśmy to wewnętrznie, też właśnie bardzo fajne warsztaty. Takie wewnętrzne też mieliśmy właśnie przez nasz zespół kilku prowadzony. Pozdrawiamy sobie, obie Zuzie. Tutaj rzeczywiście to pokazało nam, że mamy tak różne osoby, i to jest też fajne, że to spojrzenie takie ludzkie pozwala dobrać zespoły, tak żeby były dobrze zbilansowane, a po drugie, właśnie tak jak mówisz, komunikację celów.

‍

Podejrzewam, że to też się troszkę różni, przepraszam, kulturowo. Wydaje mi się, że wy pracujecie, z tego co kojarzę, głównie z polskimi klientami i nie wiem, czy miałeś okazję pracować, na przykład, z klientami ze Stanów czy z krajów skandynawskich. To są też zupełnie różne podejścia do biznesu, prawda? Tak, tutaj jest też takie bardzo fajne narzędzie, które pozwala nam ocenić kulturę biznesową w całym kraju. To są wymiary Hofstede'a, jeśli dobrze pamiętam, Hofstede, Instytut. Tam bodajże jest sześć czy siedem takich wymiarów, czyli na przykład dystans do władzy, dyscyplina itd. Itp. To widać. Na przykład ze Stanami. Moje ostatnie doświadczenie, byłem w takim programie akceleracyjnym, amerykańskim, i to, jak często my się rozbijaliśmy o jakieś rzeczy, które dla nas były oczywiste i dla nich były oczywiste, ale oczywiste w inny sposób. To było niesamowite. Na przykład dla mnie nie do pojęcia było odpisywanie czy odbieranie calli biznesowych w sobotę. Dla nich to standard i totalne niezrozumienie, że podchodzisz niepoważnie do sprawy i tak dalej. Dzwonię do ciebie, czego nie odbierasz i mówię: "W sobotę nie pracujesz, jak ty nie pracujesz?" Taki najprostszy, najprostszy przykład. I tego było całe mnóstwo. Tak, co ogarniam.

‍

Super, bardzo ciekawe. Rzeczywiście, w te tematy można się zagłębiać i dalej, więc wróćmy trochę też do tego Discovery. Dwóch żółtych usiadło na mikrofonie. Tak, to już dalej lecimy na freestyle. Wracając do tego Discovery, powiedz mi, jak wy, jako osoby prowadzące te programy edukacyjne i konsultacje, możecie zaobserwować to, jak książkowe podejście przekłada się na praktykę organizacyjną, gdzie pewnie też czasami osoby, które są bardzo podekscytowane tymi tematami, niekoniecznie mają w swoich organizacjach władzę i siłę przebicia. Jak więc ta wiedza, teoretyczna i książkowa, przekłada się na praktykę właśnie tak, w organizacjach, oddolnie?

‍

My mamy to szczęście, że większość organizacji, która się do nas zgłasza, widzi już potrzebę zmian, czyli albo dostrzegła problem, albo zaczyna go dostrzegać. My przychodzimy z gotowym rozwiązaniem albo rozwiązaniem, które oni mogą sobie dopasować do siebie. Dlatego jestem pod bardzo dużym wrażeniem, jak w większości przypadków to wygląda. Ważne jest, aby zrozumieć, że świadomość poprzedza zmianę. To nie jest tak, że wyślesz jedną, dwie osoby na szkolenie i wszystko ulegnie zmianie. Bo dobrze wdrożone Discovery to jest zmiana kulturowa, zmiana praktycznie na każdym etapie pracy rozwoju oprogramowania. Najbardziej cieszę się z takich warsztatów dedykowanych, gdzie mamy dwa lub trzy dni z całym zespołem i możemy bardzo głęboko wejść w kontekst organizacji, łącznie z rozpytaniem matrycy interesariuszy, zastanowieniem się nad ich charakterem i tym, jaki action plan możemy opracować, aby ich edukować, na jakie spotkania ich zaprosić, kto ma z kim porozmawiać. Wtedy efekty są zdecydowanie największe i najfajniejsze. Bo, jak wspomniałam, bliskość weryfikacji to jest coś w rodzaju filozofii.

‍

Bardzo się cieszę z warsztatów, na których mamy szeroki przekrój uczestników, czyli od UX-ów, którzy są chyba największą grupą na naszych warsztatach, ale też po analityków biznesowych, po deweloperów, którzy również powinni wiedzieć, co z czego wynika. I o ile nie zmuszam ich do rozmów z użytkownikami, choć uważam, że to jest dobra praktyka, aby każdy z userem porozmawiał przynajmniej raz w miesiącu. Na przykład HubSpot robi to tak, że nieważne, czy jesteś CEO, czy junior developerem, masz pogadać z jednym użytkownikiem w miesiącu, choćby nie wiem co, więc to jest super. To właśnie osoby z zarządu, które też przychodzą, często obserwuję, jak rozmawiam z pojedynczymi osobami, konflikt na zasadzie "nie pozwalają mi robić Discovery". I faktycznie może być takie poczucie, jakbym był osobą raczej na dole struktury niż na górze. Mam związane ręce, mam ograniczone możliwości. Natomiast to też nie jest tak, że zabraniają nam robić Discovery, bo mają złą wolę. Wszyscy chcą dobrze, zwłaszcza im ktoś jest wyżej, tym bardziej zależy mu na lepszych rezultatach. Więc jeśli Discovery jest blokowane, to prawdopodobnie wynika to z braku zrozumienia wartości stojących za Discovery albo z jakichś innych zmartwień czy dowodów anegdotycznych na zasadzie "konkurencja nie robi Discovery, a patrz, gdzie są", bo takie rzeczy też się zdarzają. Moim zdaniem tutaj edukacja na poziomie całej organizacji to nie jest overnight success. To jest po prostu proces.

Które trzeba wspierać, które trzeba dolewać gdzieś tam paliwko, i tak dalej. I jak ktoś czasem zadaje pytanie, no ale ja nie zrobię całego discovery, co mogę zrobić? No to odpowiedzią jest tutaj mikro discovery, bo też nie trzeba rozpisać projektu badawczego na dwanaście tygodni, tylko można po prostu umówić się z jednym użytkownikiem, pogadać z nim. Wspominałeś w materiale, chyba z Gosią, że kiedyś przygotowałeś taką kompilację z wywiadu ze swoimi użytkownikami. To zupełnie otworzyło oczy innym interesariuszom, chyba było przy okazji rejestracji czy czegoś takiego. Tak, to było związane z rejestracją i formularzem, gdzie było też to zabezpieczenie reCAPTCHA, które było bardzo denerwujące dla użytkowników. No właśnie, nie? I pewnie trudno by ci było przepchać wniosek formalny na zasadzie "ogarnijmy tą reCAPTCHA", gdyby nie ten materiał. Więc takie mikro discovery, porozmawiaj z jednym czy dwoma użytkownikami, nagle ich wytnij, co ciekawsze fragmenty, podziel się tym, już potrafi zdziałać cuda. Puść wersję A/B i pokaż, ile zaoszczędziłeś na konwersji, bo wersja lema, na przykład, trzydzieści procent więcej. To jest coś, co można zasygnalizować w godzinę, więc nie zapłacą ci za tę godzinę? Trudno, bądź przedsiębiorcą w swojej organizacji. Bo to akurat był ciekawy przykład, tak jak mówisz, bo rozwiązanie polegało na tym, że osoba, która u nas administrowała tą reCAPTCHA, miała za zadanie po prostu przesunąć suwak poziomu zabezpieczeń z wysokiego na niski. Więc dosłownie rozwiązanie zajęło dwie minuty. Natomiast wartość dla organizacji była duża i rzeczywiście to był taki moment, gdzie ludzie trochę zaczęli się interesować, co tam UX wyczyniają. Że rzeczywiście może jest tutaj trochę też takich low-hanging fruits, które możemy zerwać. I to też mi przewodzi właśnie na myśl to, że akurat na to natknąłem się przy okazji jakichś tam badań ogólnie, chyba procesu zakupowego, i ta rejestracja była po drodze. I wtedy zobaczyłem te problemy. Poszedłem za tym wątkiem i wykonałem kilka testów, żeby w ogóle ten proces rejestracji przetestować.

‍

No i to gdzieś też powinno trafić w organizacji. I teraz chciałem się zapytać, czy znasz jakieś metody, sposoby, narzędzia na to, żeby też zarządzać tą wiedzą, nabywaną w procesie Discovery, żeby tą wiedzą zarządzać w organizacji, bo ja mam wrażenie, że czasami ta wiedza może trochę uciekać, szczególnie, tak jak mówiliśmy, o dużych organizacjach, gdzie zespoły się, na przykład, nie komunikują regularnie, a jednak ta wiedza jest przydatna. Tak jak mówiłeś, dla marketingu, czy dla brandingu, czy dla jakiejś logistyki. Jeden punkt może być równoważny. Nie mam tutaj jednej prostej odpowiedzi, bo mam swoje narzędzia, których ja korzystam. Natomiast, z drugiej strony, uważam, jak wchodzimy do innej organizacji, że trzeba wykorzystywać to, z czego organizacja już korzysta, czym czuje się dobrze, bo często narzucanie im narzędzia, nawet najlepszego od strony zarządzania wiedzą, chociażby są toole dedykowane tylko do tego, no to poskutkuje tym, że i tak nikt nie będzie z tego korzystał. Więc odpowiadając toolboxowo, to myślę, że nawet Google Sheets powinien dać radę, jeśli sobie to odpowiednio zorganizujemy, pokategoryzujemy i faktycznie będziemy tym zarządzać.

‍

Więc tyle, jeśli chodzi o toolbox, jeśli chodzi o sposób agregacji tej wiedzy, to moim zdaniem tutaj game changerem mogą być dwa elementy. Pierwszy element, ja roboczo nazywam bazą hipotez, i to jest coś, na co wpadłem trochę przez przypadek. To nie jest coś, o czym przeczytałem w książkach, itd., tylko zrodziło się to z potrzeby. Wtedy, jak pracowaliśmy nad tym projektem metaverse'owym, to było dwa lata temu, więc to pojęcie dopiero rosło. I to była sytuacja, w której, jeśli zapytasz dziesięć osób, co to jest metaverse, to dostaniesz dwadzieścia odpowiedzi, więc poziom pewności czegokolwiek był minimalny. I tam były tylko hipotezy, więc zaczęliśmy sobie takie hipotezy tworzyć, od najbardziej oczywistych, które później okazywało się, że wcale takie oczywiste nie są, bo już super zaawansowane technologicznie, łącznie z tym, nie wiem, na jakim silniku będziemy co tworzyć.

No i ta baza hipotez w bardzo krótkim czasie nam się rozrosła do prawie pięciu tysięcy rekordów, więc praca nad tym pierwsze była pewnym wyzwaniem. No bo odpowiednia kategoria, właśnie przeznaczenie, metodziliśmy PR dział, czyli tam na przykład był dział designerów zajmujących się game designem, był dział marketingu itd. Itp. Później każda z tych subbaz miała odpowiednią kategorię, w stylu to dotyczy użytkowników, to dotyczy problemów, to dotyczy rozwiązań, itd. I tam podobne. Wiesz, to jest ogrom masy, ale jeśli pracujemy nad trudnymi projektami, to musimy radzić sobie z trudnymi rzeczami. To nie jest tak, że w jeden dzień zrobimy, uprościmy to maksymalnie, bo wierzę, że owszem, po pewnym czasie pewne hipotezy można odrzucać, one wchodzą do DNA i tak dalej, więc nie ma sensu nimi sobie zaburzać obrazu, ale na samym początku po prostu musimy przełknąć, że hipotez będzie pięć tysięcy.

‍

A drugą rzeczą jest Decision Log, czyli w momencie podejmowania decyzji projektowych powinniśmy przynajmniej jednym zdaniem, w jednym miejscu odnotować, z czego ta decyzja wynika. I to może być na zasadzie "bo tak". Bo nie każdą decyzję będziemy w stanie oprzeć o research, ale właśnie bardzo dobrze, jeśli mamy odwołanie, "tak wyszło z ankiet", "tak wyszło z rozmów", "tak wyszło na warsztacie", "tak wyszło z rozmów z ekspertami" i tak dalej, żebyśmy mieli po prostu odwołanie. I podobnie w Decision Log powinny być przede wszystkim elementy, czego nie robimy, bo z mojego doświadczenia jest tak, że ludzie też rotują i wiele rzeczy mamy w głowach tak naprawdę. Ty możesz wiedzieć, że z czymś już eksperymentowaliście i to nie siadło, ale później sobie pójdziesz, przyjdzie ktoś inny i on tego nie będzie wiedział. Więc taki decyzyjny log pozwala nam też odpowiednio zarządzać historią dokonanych właśnie decyzji, łącznie z uzasadnieniem, bo pewne rzeczy też mogą się zdezaktualizować. Pewne research po jakimś czasie można ponowić, może się zmieniła grupa, może ich kontekst się zmienił, może konkurencja wprowadziła nowy standard, więc wtedy można się o to odbić. Natomiast na pewno jest już to wiedza, którą będziemy agregować.

‍

Ja osobiście korzystam z Notion i jest jeszcze jeden fajny tool, który w tym momencie testujemy, Orbit, jak te gumy do żucia. I oni sobie mają właśnie dedykowanego toola do Discovery. Ich tool opiera się jeszcze o całą metodykę Teresy Torres z Opportunity Solution Tree, więc pod kątem wizualizacji to też jest mega fajne. Natomiast nie testowałem tego na dużych, skomplikowanych projektach jeszcze. To też muszę sprawdzić, tego Orbita jeszcze nie słyszałem, więc chętnie przetestuję.

‍

Czy oprócz wspomnianej tutaj Opportunity Solution Tree, mamy wiele takich różnych modeli, które mogą być przydatne. Czy jakieś kilka modeli dla naszych słuchaczy też mógłbyś wyróżnić, które na pewno byłyby warte uwagi, żeby je jakoś zgłębić w codziennej pracy produktowej? Moim zdaniem Opportunity Solution Tree jest świetnym punktem wyjścia, bo jest proste, przynajmniej na prostych produktach i kiedy nie mamy pięciu tysięcy hipotez do zagospodarowania. Jest wizualnym modelem i stanowi też fajny punkt wyjścia, później po do rozbudowania zarówno o strategie, epiki, poziomowe stories, ficzery i tak dalej. Więc dla mnie takie Opportunity Solution Tree jest punktem wyjścia w zasadzie do pracy nad każdym projektem. Później, mówiąc o już organizacji pracy, to polecam naszą Product Discovery Canvas. Mogę się zareklamować, na stronie Product Field do znalezienia. To jest też inspirowana modelem biznesowym Alexa Osterwaldera. Jednostronicowa Canvas, która pozwala zdefiniować cele produktowe, sposób pracy, wartości itd.

‍

Więc też fajne narzędzie, które można przy okazji kickoffu na przykład zastosować, a później tak naprawdę wszystko zależy od kontekstu, bo tych frameworków to też śmiejemy się z "frameworkozy", ale prawda jest taka, że ich jest ogrom i ja wychodzę z założenia, że czasem lepiej jest wybrać obojętnie jaki framework, jeśli tylko zespół go rozumie w podobny sposób i myśli systemowo, niż szukać idealnego frameworku, bo taki nie istnieje. W kontekście wyboru sposobu pracy, no to tutaj przede wszystkim myślenie systemowe, i raczej tutaj też obserwuję taką korelację, im większa firma, im więcej ludzi zaangażowanych w proces, tym framework powinien być... Owszem, mogę podać super skomplikowane przykłady, łącznie ze wzorami na scoring hipotez, wzory, wiesz, liczysz na przykład dwadzieścia procent pewności od tej osoby i od tego z tej... cholera, takie rzeczy istnieją, tylko nikt tego nie rozumie. No tak, tak. Spotkałem się często na warsztatach z klientami, gdzie czasami właśnie próbujemy jakiś innowacyjnych metod, gdzie mamy właśnie szablony z wieloma polami i różnymi kształtami i mają ludzie czasami z tym problem, bo nie wszyscy też myślą tak bardzo wizualnie, czasami zamiast tego zrobić prosto tabelkę i to już ludzie zobaczyli, na przykład, drugą prostą matrycę, nie? Tak, tak.

‍

Powiem ci o największym moim osobistym faux pas z tego roku, jeśli chodzi o warsztaty, postanowiłem oprzeć warsztaty strategiczne na frameworku, na którym osobiście pracowałem wcześniej. Dla mnie był genialny, super, wiesz, logiczny, przejrzysty, nie był prosty, ale uznałem, że grupa zaawansowana to damy radę. Nie daliśmy. Nie daliśmy, więc upraszczamy. Myślę, że powoli możemy zmierzać do końca odcinka. Już mam tutaj prawie godzinkę chyba wybija. Więc pytałem o frameworki, może jeszcze po prostu zapytam na koniec też o ewentualnie jakąś literaturę czy źródła wiedzy dla naszych słuchaczy. Jakieś polecenia od ciebie osobiście? Oczywiście ściągawkę tutaj przygotowałem, żeby nic ważnego nie pominąć, więc absolutna podstawa moim zdaniem to "Continuous Discovery Habits" od Teresy Torres - ja bym każdemu polecał od tego zacząć. Drugim nazwiskiem, z którym moim zdaniem każdy powinien się zapoznać w kontekście Discovery, jest literatura Itamara Gilada. On niedawno wydał książkę "Lean B2B" i cała książka jest oparta o jego "Confidence Level Model", który też fajnie nam pokazuje, na jakim etapie z daną hipotezą jesteśmy, w zależności od źródła i pozyskania zasobów, weryfikacji i tak dalej. Więc to jest druga, mniej oczywista. Dwie pozostałe książki, które chciałem polecić, no to jest też, myślę, kanon w tej chwili, czyli Marty Cagan, jego książki "Empowered" i "Inspired". To jest szersze ujęcie product managementu również w kontekście właśnie tego Discovery, bo podkreślę na sam koniec, podobno ludzie pamiętają początek i koniec, więc podkreślę: Moim zdaniem product managementu bez Discovery robić się nie da. Bez Discovery to nie jest product management, tylko product... nie wiem, magic. Dziękuję ci bardzo i za polecenia, i za całą rozmowę. Więcej od ciebie, od was dostaniemy na Product Field. Także na dzisiaj możemy kończyć. Dziękuję ci bardzo za rozmowę, za przybycie tutaj do Warszawy do nas. I mam nadzieję, że jeszcze gdzieś w branży się spotkamy. I was, słuchaczy, zachęcamy do lajkowania, subskrybowania, oceniania tego podcastu, gdziekolwiek go słuchacie. I do zobaczenia w następnym odcinku. Dzięki, Kamil. Dziękuję ci za zaproszenie. Jeśli mogę coś jeszcze dodać, to zapraszam do obserwacji na LinkedInie. Tam jesteśmy przede wszystkim aktywni. I myślę, że dzielimy się tam też różnymi fajnymi przemyśleniami, często takimi backstage'owymi przygodami, które mamy w pracy z klientami w kontekście zarządzania produktami czy warsztatów, więc zapraszamy. I dziękuję raz jeszcze za zaproszenie. Kraków pozdrawia Warszawę tutaj. Nie ma nienawiści między miastami. Nie ma nienawiści. Super. Dzięki wielkie. Do zobaczenia.

‍