#014 Czy Product Managerowie zabiorą pracę UX Researcherom? (W. Smajda, J. Tutaj, M. Jędrzejczak)

Cześć, z tej strony Tomaszewski, a to jest podcast Product Vision, w którym razem z Olgą Springer gościmy najlepszych praktyków product managementu, a także sami dzielimy się swoją wiedzą, swoimi doświadczeniami związanymi z tworzeniem i rozwojem produktów cyfrowych. Dzisiaj porozmawiamy o Product Discovery, Opportunity Solution Tree i dramie dyma, które wybuchły między autorką tego narzędzia, Teresą Torres, a społecznością UX Researcherów. A sponsorem dzisiejszego odcinka jest... Akademia Analityki Produktowej. Nasz czterotygodniowy intensywny program nauki analityki produktowej i podejmowania decyzji w oparciu o danej. Następna edycja już maj, czerwiec 2024. Niedługo rusza sprzedaż biletów. Zapraszamy Was na to bardzo serdecznie. Akademia Analityki Produktowej to czterotygodniowy intensywny program. Co tydzień warsztaty z Twoją małą grupą. spotkania live z mentorami, dodatkowe lekcje i szablony online oraz społeczność, którą będziesz miał okazję współpracować podczas trwania Akademii. Zapraszamy Cię bardzo serdecznie. Na stronie Akademii Analityki Produktowej możesz też już odebrać cztery darmowe lekcje z tej Akademii, żeby zobaczyć jak ona wygląda od środka. Zapraszamy. Dzisiejszy podcast wyjątkowo poprowadzi z razem ze mną gościnnie Wojtek Smajda, senior product manager z Endesco. Cześć Wojtko. Cześć, cześć, wszystko się zgadza. Tak jest, a naszymi gości będą również świetni product managerowie. Jakub tutaj, senior product manager w softr.io. Cześć Kuba, dobrze powiedziałem? Cześć Kuba, świetnie powiedziałeś, dziękuję za zaproszenie. Oraz Marcin Jędrzejczak, associate principal product manager w Celonisie. Cześć. Cześć, witam Was. Bardziej associate czy bardziej principal, Marcin? Bardziej associate. Nie zgodziłbym się. Wojtek, mamy tu samych seniorów, principali, headów, liderów. Ja nie wiem, czy to wszystko wytrzyma tutaj zderzenie tego wszystkiego, tego silnego ego i silnych osobistości product managementu. Spróbujemy. Spróbujemy. Panowie, czy wy śledzicie w ogóle świat freakfightów i dram internetowych? No, ostatnio wczoraj chyba ktoś pomylił boks z MMA, więc... Tak. No właśnie, bo ja mam wrażenie, że ostatnio trochę tego świata zajrzało do naszego świata product managementu i właśnie do tej dramy pomiędzy UX Researcherami i Teresą Torres, ale zanim zaczniemy, to myślę, że słowo wstępne, najpierw ja trochę opowiem o Teresie Torres i właśnie o Opportunity Solution Tree, a Wojtek o samej dramie, o tym, co tam wypłynęło, no i potem podzielimy się swoimi jakimiś doświadczeniami, spojrzeniami na to, bo jeśli chodzi o Opportunity Solution Tree, to jest to jednak popularna technika, popularny framework, używany ogólnie do nawigacji po product discovery. Autorką tego narzędzia jest właśnie Teresa Torres, ona kilka lat temu wydała taką książkę Continuous Discovery Habits, w którym przedstawiała właśnie to narzędzie. No i to narzędzie stara się właśnie w takiej strukturze drzewa pokazać, jak nawigować po product discovery. U góry są cele, za którymi chcemy podążać, potem są opportunities, czyli problemy użytkowników, których rozwiązanie ma doprowadzić do tych celów biznesowych. Poniżej mamy jeszcze rozwiązania, czyli jakimi rozwiązaniami. tych problemów użytkowników będziemy w tamtą stronę kroczyć, no i na samym końcu są eksperymenty, czyli w jaki sposób te rozwiązania będziemy gdzieś testować. Całością tego procesu powinno zajmować się product trio, czyli product manager, product researcher, designer i dev lead, no i powinniśmy wspólnie w sumie pracować nad tymi czterema poziomami, no i dzięki temu mieć takie big picture, gdzie jesteśmy w tym procesie product discovery, no i jakie są powiązania między tymi różnymi obszarami, więc jakby w teorii to wszystko wygląda świetnie. Natomiast mamy ostatnio niezłą dramę w internecie i na LinkedIn. Wojtek, opowiesz może trochę jako wstęp do naszej dyskusji. No dobra, no więc tak jak powiedziałeś, mamy dymy, mamy dramę. Miesiąc temu Teresa Torres na swoim LinkedIn opublikowała taki post, w którym pyta właściwie, czy ta książka wyrządziła więcej szkód niż pożytku, no bo okazuje się, że niektórzy stwierdzili, stwierdzają, że no dobra, no jeśli mamy... jeśli mamy ten framework, jeśli mamy pomysł, jak organizować te idee, no to może nie potrzebujemy tych UX-owców, jeśli możemy sobie zrobić wszystko sami. No ale to, co najciekawsze, to wylało się w tych komentarzach pod tym postem, tam mieliśmy taką dyskusję, że po pierwsze, tak jak powiedziałem, często PM-owie twierdzą, że właściwie to mogą ogarnąć cały proces, a czasami ta rola UX-a to jest marginalizowana i to jest ten głos UX-owców podnoszony w tej dyskusji. Nie no, róbcie naszą robotę, ale może najpierw to fajnie byłoby, jakbyście robili ją w jakiś sensowny... przemyślany sposób, a zabieracie się za naszą robotę, bierzecie nasze kredki, ale nie do końca umiecie rysować. Tam było kilkaset, kilka tysięcy komentarzy, jak dobrze pamiętam, właśnie UX researcherów, którzy wręcz zarzucali, że ta książka i to podejście doprowadziło do tego, że wielu z nich zostało zwolnionych. No i Teresa tam się starała dosyć mocno się bronić, że ona nigdy tak wcale nie mówiła, że UX researcher jest niepotrzebny, ale jednak skoro ludzie tak mówią, to z jakiegoś powodu... o tym wspominają, czyli jakieś takie podejście gdzieś w jakichś firmach musiało być. No dobra, no to takie właśnie pierwsze pytanie w ogóle, czy może prowokacyjne, może pod tą tezę, czy w ogóle ten UX-or jest uważać, że jest potrzebny w organizacji? No ja jakbym miał UX-researchera, to bym dał za niego każde pieniądze i nic od niego nie brał, żadnego zadania, które mógłby nam wykorzystać do tego, żeby odkryć, co potrzebują użytkownicy. Więc trochę zastanawia mnie to larum i wydaje mi się, że... Trochę ono może wynikać z takiego szybciego przeskakiwania do wniosków, nie rozumiejąc jeszcze fundamentów, czyli na czym się opiera, w ogóle ten framework takiego zobaczenia na główka i wskoczenia właśnie w ten kocioł dyskusji. Plus może też jest całe, może to ma jakieś powiązanie z tym, że jeśli wypowiadają się UX-owcy, to UX-owcy też już mają swoje wszystkie różne gałęzie typu UX Designer, UX Researcher. Może część ludzi, która jest zdenerwowana zwolnieniami np. była z tej grupy designerów, co wiemy, że nie tylko designerzy, ale również produktowcy w ostatnim czasie byli ofiarami lay-offów, więc może to wszystko podsyca te napięcia, ale chciałbym usłyszeć opinię Marcina. Jestem książką jakiś czas temu, ja zdecydowanie pamiętam, że mi jako produktowcowi książka dała zdecydowane jakieś narzędzia do formułowania sposobu komunikacji też z researcherami. Czyli jakby jeszcze bardziej miałem wrażenie, że ona pozwala zrozumieć, jak produktowiec i z researcherem powinni ze sobą rozmawiać, żeby zbudować pewien cykl sieci komunikacyjnej. Oczywiście nie zawsze jest tak, że żyjemy w tych czasach luksusowych, że tego researchera mamy i wtedy przejmujemy pewne rzeczy na siebie na klatę jako produktowca, ale tak... Krótko mówiąc, myślę, że zdecydowanie broniłbym tej tezy, że jednak książka nie zabiera pracy researcherom. No dobra, ale tam jest jakby dosyć mocne argumenty padają takie, no kurczę, przecież wy produktowcy się tak naprawdę na tych badaniach nie znacie dobrze, nie? I możecie wyciągnąć błędne wnioski. I zabieracie się za coś, na czym się nie znacie do końca. Może trochę się nauczyliście jakichś takich podstaw. a my tu jesteśmy ludźmi, którzy się na tym znają i jesteśmy w stanie dobrze taki proces product researchu przeprowadzić i może też właśnie pojawia się trochę jednak pomysł, że skoro jakby produktowiec sam w stanie jest robić jakiś proces, pytanie czy dobrze, czy źle właśnie, no to w sumie może rzeczywiście ci UX researcherzy są niepotrzebni i wtedy właśnie firma się z nimi żegna, bo trochę taki product manager zabiera tą pracę. Ja będę bronił tej tese, że są niepotrzebni, może nie aż tak hardkorowo, że w ogóle, ale nie sądzę, że zawsze są potrzebni. To znaczy, ja myślę, że Marcin i Kuba reprezentują takie kierunki, które są bardziej klienckie, bardziej front-endowe, bardziej widzialne przez użytkowników, natomiast ja jestem takim może bardziej technicznym GM-em, który zajmuje się na przykład integracją danych. I koniec tej pracy rzeczywiście jest bardzo widzialny, bardzo dotykalny przez klienta, ale powiedziałbym, że 80-70% tej pracy. To są pytania techniczne, na które prawdopodobnie nasi użytkownicy, nasi klienci nie będą nam w stanie odpowiedzieć, bo nie mają takiej wiedzy, więc myślę, że ten UX-owiec, on jest ważny, on jest luksusem, tak jak Marcin czy Kuba powiedział. Warto go mieć w organizacji, ale potrafię sobie wyobrazić, gdzie rzeczywiście jest niepotrzebny, gdzie rzeczywiście jest zaprzęganiem armaty do muchy. zbyt dużego kalibru do zupełnie innej domeny. Ja sobie myślę, że żeby dodać do tego, do tych argumentów za i przeciw, to myślę, że ja zarówno się zgadzam, jak i nie zgadzam, bo jak zwykle to zależy. I nie tylko to kryterium tego, czy coś jest back-endowe, czy front-endowe jest ważne, ale też od etapu, na którym jest dana organizacja. Czyli przykładowo, jeśli jesteś organizacją dużą, jak Zendesk, to właśnie na ten luksus możesz sobie pozwolić i już masz na tyle wypracowane wszystkie procesy. osoby i zorganizowane grupy zespołowe, gdzie ta osoba może poświęcić 100% swojego czasu, żeby rozdystrybuować wszystkie insajty na odpowiedni zespół, zespoły w odpowiednim obszarze i tak dalej. Da się to świetnie zagospodarować. Natomiast w małych startupach, seria A albo bootstrap, no to zawsze zatrudniasz kolejną, piątą, szóstą, siódmą osobę do zespołu, tylko wtedy, jeśli już... kompletnie nie ma absolutnie żadnego innego wyjścia. Więc dopóki jest możliwość CEO, pracuje jako CEO, CMO, CFO, CPO, potem zaczyna zatrudniać poszczególne osoby, potem ma pierwszego PM-a, który się staje potem lead PM-em na przykład paru product managerów i ten lead PM biedny. w cudzysłowie, razem z tymi product managerami, pełnią też rolę researcherów. I potem, kiedy następuje ten luksus, trochę jest więcej organizacji, już dopracowuje się ten łańcuch dostarczania wartości dla użytkowników, da się znaleźć miejsce i nawet w końcu zaczyna PM-om brakować czasu na przetwarzanie wszystkich sygnałów, rozumienia ich i dobrej interpretacji. I tu wydaje się, że ta rola jest na tyle specyficzna, że nadchodzi trochę później w cyklu życia dojrzałości organizacji, podobnie jak copywriterzy itp. itd. Może to być bardzo wczesna rola na wczesnym etapie życia organizacji, specyficzna, jeśli absolutnym wymaganiem, że na przykład najważniejszy jest messaging i brand voice i tego typu kwestie, na przykład... w kontekście copywritera albo turbo zrozumienie klienta już na wczesnym etapie tej organizacji, to często na przykład nie będzie jeszcze PM-a, a już będą te role w organizacji zapełnione. Fajnie to powiedziałeś, jak ja się zastanawiam w ogóle nad, jakby rozłożyć na czynniki pierwsze tytuł książki, Continuous Discovery Habits, tak jak ja sobie patrzę na te trzy słowa i bym miał je sklasyfikować... które z tych słów miała największą i najistotniejszą wartość tej książki, powiedziałbym w kolejności habits, continues i dopiero na końcu discovery. Wydaje mi się, że najważniejszą rzeczą, którą Teresa stara się gdzieś tam podkreślić, jest właśnie, co robimy jako organizacja, żeby... zbudować pewne habits, które pozwolą nam właśnie w cyklu kontynuacji robić te discovery. No i największe teraz jest pytanie, czym jest to discovery i czy ono nie urosło do takiego aż może za dużego słowa w ostatnich latach, które powoduje, że jest trochę więcej niezrozumienia niż zrozumienia w tym całej istocie robienia discovery. Bo gdybyśmy powiedzieli, że discovery jest po prostu zmniejszeniem prawdopodobieństwa albo ryzyka porażki budowania danej funkcji, funkcjonalności. Zupełnie inaczej podchodzimy tak naprawdę do narracji tego, w jaki sposób my przedstawiamy coś. I tak jak mówisz, to może być troszeczkę inny, może być w małych startupach, gdzie ryzyko biorą na siebie fonderzy zwalidowania tego, czy to działa, czy to nie działa. W trakcie rundy no to zespoły produktowe biorą na siebie bardziej ryzyko, a potem już bierzemy to ryzyko tak naprawdę na siebie i bardziej pracujemy z innymi funkcjami. czyli i z designerem i z działem technicznym, bo może pojawia się być ryzyko, gdzieś tam jak organizacja jest związana bardziej z infrastrukturą, więc w sumie zależy to trochę bardziej od domeny, zależy to też od etapu i rola researchera w tym wszystkim wydaje mi się, że wkracza w momencie, w którym tak naprawdę ja zauważyłem w zasadzie, że od researchera uczyłem się w historii swojej jako produktowiec najbardziej właśnie jak tworzyć ten habit. Tak żeby to powiedzieć szczegółowo, dosłownie w Selonisie prowadzimy teraz fajny research odnośnie jednego z takich projektów. Celem jest też, jak możemy zmniejszyć ryzyko niepowodzenia wdrożenia pewnej funkcjonalności. Akurat nie mam tego przywileju, że nie udało mi się mieć researchera dokładnie w tym konkretnym projekcie, bo też mamy pewien proces przypisywania researcherów do tych projektów, ale to nie znaczy, że nie mogą zaczerpnąć wiedzy odnośnie tych researcherów. Słuchajcie, powiedzcie mi, jak powinienem najlepiej zrekrutować userów do tego. jak powinniśmy jak najlepiej sprawić, aby ci userzy konwertowali do tego badania i potem jak przeprowadzić skrypt. I powiem wam, że najpierw przeprowadziłem sobie to jakiś taki prosty skrypt samemu. Zacząłem rekrutować wśród pewnej bazy klientów, które oni mi udostępnili i miałem zaskakująco niską konwersję. Zastanawiałem się, czemu kurczę tak mało osób z tej bazy się nie kwalifikuje do tego badania. Wtedy jeszcze raz poszedłem do mojego działu researcheru, powiedzcie mi, czy jestem w stanie coś tutaj poprawić. I wiecie, było prostych kilka takich wskazówek, chociażby dotyczących tego, słuchaj, brakuje linku do kalendli, w którym ktoś powinien się zapisać. Brakuje tam jakiegoś takiego bardziej lepiej sformułowanego call to action, kogo chcemy konkretnie. i dlaczego chcemy to badanie przeprowadzić z kim? I to są takie detale, które powodują, że na każdej fazie weryfikowania, myślę, że i researcherzy mają już dużo lepiej wypracowane praktyki. Tutaj jest to value zdecydowane dodanie, które odchodzi. Poza tym, co Martin powiedział, to bardzo często... Niestety, jakkolwiek bym się starał tego nie robić, to często przez moje techniczne skrzywienie myślę rozwiązaniami, myślę potencjalnymi implementacjami i to, w czym mi UX Research pomaga, to w próbie sfalsyfikowania tego rozwiązania. To raz. Dwa, prawdopodobnie siłą rzeczy, gdybym sam próbował robić taki IP Research, To próbowałbym potwierdzić moją rację, próbowałbym zadać tak pytania, które jakoś weryfikują, czy starają się zweryfikować pozytywnie tą moją hipotezę, a tutaj ta pomoc UX-owca, który nie jest przywiązany emocjonalnie do implementacji jest bardzo pomocna. To są moje doświadczenia. Jaka jest ta wasza fizyka? Ja ogólnie nie lubię w ogóle, nie jestem fanem tytułów, stanowisk. Dobrze one są, mają swoją rolę, tak i tak dalej, ale generalnie mam wrażenie, że one bardzo mocno spłaszczają człowieka, jednak tworzenie produktu zwykle jest jakimś portem zespołowym i ktoś jest po prostu w czymś lepszy, ktoś jest w czymś gorszy. I żeby robić dobry product management, musimy robić jakieś elementy discovery. I teraz pytanie, jak my to będziemy robić? Czy będziemy to robić właśnie z UX Researcherem, czymś, kto jest ekspertem odrobienia badań? czy na przykład nie mamy takiej osoby i musimy w takiej sytuacji zrobić to samodzielnie. Tak samo jak z wieloma innymi obszarami w product managementcie, który product manager musi zrobić, jeśli w organizacji. czy w zespole po prostu nie ma do tego kompetencji. Nagle się pojawia jakaś rzecz, nie wiem, marketingowa czy coś innego, a nie mamy wcale dostępu do marketingu i trzeba chociaż troszeczkę tutaj coś zadziałać i rozumieć jakby ten obszar, tak samo jak każdy inny, więc ja nie lubię bardzo mocno tych tytułów, bardzo lubię w ogóle tę koncepcję taką product trio czy budowania jakichś takich korowych zespołów produktowych, które uzupełniają się kompetencyjnie i które starają się razem ciągnąć w jedną stronę. I jeśli mam tam product researchera, to dla mnie byłoby to... idealnie, bo ja w badaniach jestem średni, o chyba tak bym powiedział, więc jakby potrafię je zrobić, pewnie nie jestem ekspertem tak dobrym jak product research, więc na pewno idealnie jakbym kogoś takiego mógł mieć, ale po prostu realia są takie, że często kogoś takiego nie mam i dlatego muszę podstawę tej kompetencji gdzieś tam też posiadać. Bardzo bym chciał mieć takiego product research'era, tak samo jak chcę mieć tech lead'a, z którym mogę współpracować, tak samo jak chcę mieć marketing lead'a, jeśli to jest produkt typowo rynkowy, tak samo jak chcę mieć innego specjalistę od innego obszaru. który obniża najbardziej te ryzyka produktowe, nad którymi aktualnie pracujemy. Na przykład... jak startowaliśmy gdzieś z nowym produktem, to tam się okazało, że na przykład w korowym zespole produktowym musimy mieć naszego CEO, który otwierał ścieżki do wielkich korporacji, żeby do nich wchodzić, robić w ogóle jakieś wywiady, cokolwiek się o nich dowiadywać, bo fajnie, że mielibyśmy UX Researchera, fajnie, że mielibyśmy nie wiem, Product Manager Tomka, fajnie, że mielibyśmy specjalisty OTIA, natomiast największym ryzykiem było to, czy my w ogóle jesteśmy w stanie się dostać do korporacji i zacząć z nimi w ogóle rozmawiać i te ryzyko najlepiej obniżał nie Tomek Tomaszewski, nie UX Researcher. tylko nasz na przykład i on był w naszym korowym zespole produktowym razem mogliśmy coś takiego robić super przykład to chciałbym teraz w związku z tym że jest tu czterech piemów i zero research a pewnie popełniliśmy błąd selekcji gości z balansowaną dyskusję Natomiast to może teraz wcielmy się trochę w rolę pomocników UX Researcherom, skoro tak bardzo ich chcemy, jak moglibyśmy pomóc osobom, które decydują o tym, czy mieć w zespole UX Researchera, czy nie, przekonać te osoby do posiadania tej roli? Jeśli czujemy, że ona jest tak przydatna, jest takim luksusem, czemu to się nie dzieje? Nie ma pomysłów. Szachmat. Nie, ja mam kilka jakichś takich przemyśleń ogólnie. To jakby pierwsza sprawa, no to uzmysłowić sobie, że właśnie wcale ja nie jestem taki dobry w tym researchu, discovery i tak dalej. To jest jakby jedna sprawa. Możesz się w tym rozwijać, ale wiedzieć, że na pewno nie będę ekspertem, jeśli tym również zajmuję się tak zwanym business viability risk, z zespołem obniżam ryzyka techniczne, jeszcze jakby nie wiem, pracuję z psycholaterami, no to ja nie będę nigdy ekspertem od tego. Więc to jest pierwsze takie uświadomienie sobie, zmienienie swojej perspektywy. Pytanie, czy się zabawimy w takiego agenta zmiany, który będzie tą rzecz bardzo mocno promował. Ogólnie moim zdaniem w takim razie research i discovery, bo jeśli będę to promował, to wtedy zacznie się pojawiać coraz więcej tego typu potrzeb. A wówczas można trochę zaatakować tak, że hej, fajnie, ale ja nie jestem w stanie się tym zajmować wszystkim, bo jakby mam 40 godzin w tygodniu, więc tą częścią też ktoś się musi zająć jakby. Kto nie dość, że będzie miał na to czas, to jeszcze będzie robił to dwa razy lepiej. I też pokazując na przykładzie, że hej, tu mimo discovery robionego przeze mnie, i tak podjęliśmy złą decyzję, bo na przykład mogliśmy zrobić jeszcze, nie wiem, badanie X, badanie Y, badanie Z, albo przeprowadzić więcej wywiadów z użytkownikami, a nie zrobiliśmy tego, bo nie mieliśmy ludzi, więc tak naprawdę poniesimy bardzo duże koszty zrobienia złego rozwiązania. Trochę wydaje mi się, że to się sprowadza do tego, żeby pokazać w ogóle wartość discovery i researchu. Jak pokazujemy wartość discovery i researchu, to wtedy już trochę od nas, że hej, ciśniemy w tą stronę, żeby pokazać, że potrzebujemy do tego ludzi. Tak samo jak mamy niejednego dewelopera. tylko zespół deweloperów, tak, czy tak samo w marketingu, nie mamy jednej osoby albo product manager nie zajmuje się marketingiem, tylko współpracuje z chipem marketingu i tak dalej. Spisując się pod to, co Tomek powiedziałeś, to generalna obserwacja. Widzę, że PM-owie rekrutują się z dwóch ścieżek. Z takiej być może bardziej technicznej, którą ja reprezentuję i być może z takiej bardziej designerskiej, którą wydaje mi się, że Marcin reprezentuje. Słowo UX to jest user experience. I teraz tym zadaniem tego UX-a to są te badania, o których rozmawiamy, skupiliśmy się na tym wątku, ale ta rola UX-a nie skupia się przecież tylko i wyłącznie na gadaniu do ludzi. To jest ważna część. ale często to jest zrobienie jakiegoś prototypu, pokazanie tym użytkownikom, czy podoba wam się bardziej A czy B. I to jest fajnie, że o tym mówisz, bo to jest świetne, jakby pokazuje, że teraz z Noidu znajdą się tacy, którzy powiedzą wcale nie, bo UX i Searcher nie powinien zajmować się robieniem prototypów, tylko powinien zajmować się robieniem właśnie badań, a prototypami powinien się zajmować designer na przykład, a interfejsem to UI, jeśli mamy pieniądze. i widzimy z tego zysk, że mamy tak duży zespół i jesteśmy w stanie dowodzić wartości, to to jest super, nie? Tylko bardzo często właśnie nie mamy, a to jest ta często dyskusja, która się pojawia, że chcemy mieć jedną osobę, która wszystkiego się zajmuje i że te oferty pracy są bezsensowne, bo przecież jak można zaleźć takiego unikorna, nie? Pytanie, czy te 3, 4, 5 osób bardzo specjalistycznych, którzy zarabiają x tysięcy złotych, policzmy sobie nawet, nie wiem, 15 tysięcy złotych netto, 20 tysięcy złotych netto. 4-5 osób, to jest 100 tysięcy złotych miesięcznie. Pytanie, czy te osoby się zwrócą, czy rzeczywiście wartość tego wszystkiego taka będzie. I trochę moim zdaniem do tego to się też sprowadza często ta dyskusja, że w sensie my trochę nie zdajemy sobie sprawę, ile to kosztuje. I to na pewno lepiej ograniczy ryzyka, bo tak jak mówicie, product discovery, fajnie mi się to, co Marcin powiedział, że product discovery, ja bardzo rezonuję ze mną, ta definicja. Naszym celem jest obniżanie ryzyk. I teraz czy czterokrotnie większy zespół spowoduje, że my o tyle obniżymy więcej ryzyk? że koszty błędu czy zyski z tego będą lepsze niż jakby to zrobiła np. jedna osoba albo prezes, jeśli ostatecznie zwolni też product managera. Nikt się często tego nie jest w stanie dowiedzieć, bo już jesteś postawiony przed decyzją, której nigdy nie zweryfikujesz w wersji drugiej historycznie oprócz testów. W sumie zahaczyłeś o ciekawy wątek, bo czasem w historii życia organizacji pojawia się precedens, który jest takim turning pointem, który generuje zmianę, czyli niekoniecznie musisz zobaczyć stratę lub zysk na poziomie 100 tysięcy dolarów, ale jeśli raz się przejedziesz grubo i wiesz, że rozwiązaniem dokładnie postmortem było posiadanie researchera, a potem widzisz kilka razy, że w sumie to by się przydało i być może ryzykujemy to zbyt bardzo, no to otwiera to drzwi. Ostatnio rozmawiałem z firmą, która przekonała się tak trochę do mindsetu produktowego i mam nadzieję, że potem docelowo też researchowego, bo nie wiem ile wydała w złotówkach, ale wydała kilka, kilkanaście osób, które pracowały przez, nie wiem, chyba 6 czy 7 miesięcy nad projektem, jakby częścią produktu, który potem się okazało, że kompletnie jakby nikt tego nie używa i nie byli nawet w stanie do końca zmierzyć, bo jeszcze tego nie było pomiarowane, więc tak naprawdę trochę taka intuicja po pół roku pokazała, że chyba, kurczę, ktoś tego nie używa, potem ktoś troszeczkę sprawdził i firma, która ma... 200 osób. Nagle się zdarzało, że kilkadziesiąt osób było zaangażowane w przedsięwzięcie, którego potem nikt nie korzysta. I ta właśnie był ten taki punkt zwrotny dla nich, że hej, może trzeba pomyśleć nad mindsetem produktowym. Przechodzi mi do głowy jest taki framework, który nazywa Bezos Mandate. Jeff Bezos kiedyś powiedział, że są dwa typy decyzji. Decyzji typu pierwszego, które są bardzo łatwo odwracalne i powinniśmy je podjąć w najszybszy możliwy sposób. i są decyzje typu drugiego, które są bardzo trudne, odwracalne. Wydaje mi się, że to też się wiąże z tą kaską, o której cały czas mówimy, że w pewnym momencie dochodzisz w organizacji do takiego momentu, że pula decyzji typu drugiego, decyzji, które mogą mieć znaczące konsekwencje dla kasy, dla produktu, zaczyna być nietrywialna, więc być może to jest sposób przekonania. Jako trigger. A teraz chciałem trochę pociągnąć kołderkę w drugą stronę i opowiedzieć Wam, jak obywamy się jeszcze bez researcherów obecnie w naszym zespole produktowym. I wygląda na to, że na razie właśnie ten poziom redukcji ryzyka jest wystarczająco dobry, aby jeszcze nie podejmować tej decyzji przez jakiś czas. Mianowicie mamy obecnie pięciu product managerów i to jak działamy, to właśnie nie dojdziemy raczej nigdy do punktu, kiedy nasze capacity nie pozwoli nam się skupić na discovery. tylko poświęcamy jakiś kwant czasu w sposób continuous i mamy habit, że mamy po pierwsze rozdystrybuowane po sobie rozmowy z klientami, które się odbywają każdego tygodnia, więc każdy product manager ma rękę na pulsie, więc w taki sposób round robinowy powiedzmy trochę jesteśmy w stanie bardzo dużo kolektywnie zebrać wiedzy i zbudować taki wspólny mózg, który rozumie klienta. Oprócz tego mamy wiadomo różne źródła, z których przychodzą do nas insajty od klientów i one również, jeśli jeden PM miałby za zadanie każdego dnia albo co tydzień tam wchodzić i przez to wszystko przechodzić, no to ta potrzeba zatrudnienia UX Researchera pojawiłaby się od razu. Natomiast... Znowu przypisujemy ownership do każdej z gałęzi tych inputów, które zwykle się pokrywają między sobą, po prostu są różnymi źródłami danych, które do nas przychodzą i wspólnie procesujemy te informacje i gromadzimy insajty i się nimi dzielimy. I znowu tu wchodzi to, jak sobie zorganizowaliśmy fajnie proces wokół zbierania tych informacji. Znowu na pewno nie robimy tego w najlepszy sposób, czyli dostajemy jakiś sygnał, czasem udaje nam się go zinterpretować poprawnie, czasem pewnie go nadinterpretowujemy, ale przez to, że mamy różne kanały dostępu do tych klientów i różne rodzaje klientów, z którymi rozmawiamy, gdzieś pewnie... się przestrzelibujemy, ale jesteśmy na tych pewnie 60-80% bycia w dobrym miejscu odnośnie ryzyka. Więc jest to też ciekawy model i jestem ciekaw, jak to się będzie rozwijało. Czy to jest też szansa dla UX researcherów trochę zbliżyć się do tego, czym się zajmie product management, a nam tego, do czego zmierza research? Czy to jest tylko po prostu charakterystyczne dla małych organizacji, jaką jeszcze jesteśmy? Ja myślę, że fajnie to opisałeś w zasadzie i tak jak mówisz, na koniec końców opisałeś pewien habit. który gdzieś tam sobie w swojej organizacji wypracowaliście. Ja myślę, tak jak sobie teraz słucham, to myślę, że rola UX Researchera być może jest właśnie rolą, która powoduje zbudowanie pozytywnych nawyków właśnie w organizacji, idących w kierunku właśnie, jak możemy jeszcze częściej rozmawiać z klientami, jak możemy jeszcze lepiej ich słuchać, albo jak możemy jeszcze lepiej ich obserwować. Bo tak jak w sumie opisałeś, tak jak macie super fajnie zorganizowany proces, gdzie możecie bardzo szybko zidentyfikować użytkownika, możecie szybko go sprostować, jego potrzeby. Przypomniało mi to też trochę nasz proces, który jakiś czas temu wdrażaliśmy i do tego używaliśmy takiego toola, nie wiem, czy znacie, może zrobimy teraz małą reklamę, nazywa się condens.io. Podlinkujemy w opisie odcinka. Bardzo fajnie usprawniam rolę komunikacji zespołów produktowych z rolem researchera. I to jest bardzo proste. Wrzucasz nagranie z interview z klientem. I jest ono w taki sposób fajnie analizowane przez ten tool, że praktycznie nie dość, że masz automatyczny transkrypt z tej rozmowy, to jeszcze researcher bądź każda inna osoba, która gdzieś tam wciela się w rolę badacza i obserwatora tego wideo, może zaznaczać sobie elementy tej rozmowy, które wywarły na niej powiedzmy jakiś wpływ. Zaobserwowałem coś, być może z mimiką twarzy, być może z mimiką ciała albo reakcją tego użytkownika, co pozwoliło mi mieć fajny insight. I my sobie to już tak zwane ustrukturyzowaliśmy, że właśnie udawało nam się to przypisywać do pewnych jakichś takich, czy to hipotez produktowych, czy to metryk itd., itd. Cała ta idea była wdrożona przez researchera. Muszę powiedzieć, że jako produktowiec korzystam z tego skondensowanego zbioru danych nieustająco, w taki continuous sposób. czy to jak muszę stworzyć jakąś prezentację odnośnie produktu, czy to jak robimy jakieś demo, testimonials odnośnie feedbacku, czy jak rzeczywiście musimy podejmować dane, mamy to wszystko fajnie ustrukturyzowane. Jest to myślę, że fajny habit. No i zadawać pytanie, w jakiej skali organizacja w zasadzie można to gdzieś tam z sukcesem wdrażać. Ja pracuję w Sylonisie, gdzieś do organizacji, która łącznie ma około 130 PM-ów. A jedną fajną rzecz chciałem fajną, ale ciekawy temat też wrzucić. Jak powinien PM zachowywać się, waszym zdaniem, w organizacjach, w których właśnie nie ma takiej kultury produktowej jeszcze. I powiedzmy, ja przeczytałem sobie przed chwilą, załóżmy, że jestem PM-em, przeczytałem sobie książkę Teresy Torres i mówię, kurczę, stwórzmy u nas taką fajną kulturę robienia eksperymentów. Ja przepraszam, Maciej. 130 product managerów? Tak. Przecież w Zendesku też tylu chyba jest lub było. To firma jest jak duża? U nas? 131 osób. 131 osób, tak? U nas jest 1000. Ok, mega ciekawy temat. Dobra, wracamy w takim razie do tematu. Mogę powiedzieć trochę o swoim doświadczeniu, bo wiele razy się spotykałem właśnie z tym tematem. Coś sobie fajnego przeczytałem, jakby w to wdrożyć. Też... Rozmawiałem z kilkoma product managerami, którzy właśnie na świeżo coś pochłonęli jakąś wiedzę, która prawdopodobnie jest słuszna, gdzieś została faktycznie wdrożona. Najgorszą chyba metodą, jaką można zrobić, to przyjść do zespołu i powiedzieć, ej, zróbmy to, bo to jest super, teraz będziemy robić to tak. Jeszcze zwykle spotyka się to co najmniej z oporem, a w najgorszych przypadkach z utratą zaufania do tej osoby, która przynosi ten wspaniały pomysł. Co jest trochę smutne, bo wiadomo, intencje są dobre i zwykle zmierzają do tego, żeby ten zespół działał lepiej. Lepszą metodą, jaką znalazłem, to jest praca u podstaw i rozpoczęcie. Czyli co mam na myśli? Zrób to sam i zrób najmniejszy możliwy fragment i pokaż rezultat. A jeśli spaliłeś, to nie pokaż złych rezultatów, dopóki nie dostaniesz rezultatu. I teraz co mam na myśli? Na przykład pierwszy raz chcesz porozmawiać z jakimś swoim użytkownikiem? No to wyślij maila. i zapytaj go, co o tym myślisz, albo umówisz się ze mną na 30 minut, nie pytaj, czy dostaniesz approval na kalendli, na gift card do Amazona, czy coś, tylko robądź informację, czy można się skomunikować w ogóle z klientem, który na przykład ma problem z tym bugiem. Cokolwiek, zrób jakiś pierwszy krok, żeby wyciągnąć insight. Jak to się sprawdzi, zaczniesz dostawać jakieś kwanty informacji. Powiedz zespołowi o tym, że możemy tym kanałem dostać jakiś kwant informacji. I popatrzcie, zrobię to jeszcze 10 razy i po miesiącu, patrzcie, tu mam podsumowanie z naszych ostatnich 10 konwersacji z klientami. No i w ten sposób, takimi małymi kroczkami, to już zmierza do tego etapu, o którym mówi Tomek, że przez przykład pokazania już jakichś efektów można zacząć mieć argumenty w ręce do tego, że warto podjąć w jakąś stronę danego rozwiązania, jakiejś praktyki, habitu. My tak wrażyliśmy trochę o Opportunity Solution Tree do planowania takiego strategicznego. W ogóle nie nazywałem tego Opportunity Solution Tree, tylko zrobiliśmy prosty warsztat, gdzie powiedziałem, dobra, to skoro w drogiej zarządzie taki mamy jakby cel, to hej, zastanówmy się jakby zmianą czyich zachowań, outcome'ami jesteśmy w stanie do tego doprowadzić. A jakich mamy tam, jakich głównych aktorów, czy zwykle użytkowników. zmianą czyich zachowań, jesteśmy w stanie tego doprowadzić, mieliśmy nagle jeden poziom tego Opportunity Solution Tree jako potencjalne takie hipotezy, ja nawet już to przygotowałem po prostu na bazie jakichś takich naszych wcześniejszych badań, razem z dopiskami, że na podstawie czego to wiemy, a tutaj potencjalnie tylko jakieś zarysy rozwiązań i tak pierwszy raz trochę użyliśmy, powiedziałem ok, zróbmy taki warsztat metodą taką drzewkową i tyle, nie nazywałem w ogóle tego Opportunity Solution Tree i że mamy to co... cały czas teraz wykorzystywać, że roadmapy mamy na to zmienić, że w taki sposób będziemy sobie podchodzić do planowania, tylko zróbmy sobie takie ćwiczenie, które nam ułatwi trochę planowanie. Wyszło super i następnego kwartału wszyscy chcieli po prostu wrócić do tego i w taki sposób podejść w ogóle do takiego planowania gdzieś tam strategicznego. Pamiętam deflit spodobała mu się bardzo bo tam też określił się po prostu poziom inwestycji w dane oportunity więc wiedział jakie capacity potencjalnie chcemy na to przeznaczyć nie i trochę właśnie to o czym mówisz nie czyli jakby nie że teraz planujemy wielkie wdrożenie danej metody tylko ja to przygotowałem zdrażamy zmianę tak uwaga zarządzanie zmianą 6 miesięcy i okazało się super, ale żeby nie było tak kolorowo, no to też jest cała masa zmian, które robimy tak, czasem efektów tak jak mówisz, że nie ma, albo są takie niejednoznaczne i wcale jakby zespoły inni nie chcą się do tego jakby do końca przekonać, wtedy może jakaś taka metoda albo zdartej płyty, albo w drugą stronę budowania takich warunków, że ludzie widzą, że coś im przeszkadza na przykład i zaczną sami poszukiwać rozwiązań i wpadną na ten potencjalny pomysł, to są takie moje podejście. No właśnie, ale mówimy o przekonywaniu do Opportunity Solution Tree, do UX-owca, ale czy macie jakieś takie realne, ciekawe case'y, którymi powinniście się podzielić, że w Waszym projekcie, w Waszej inicjatywie, którą prowadziliście, realnie Wam ten UX zmniejszył ryzyko? Ja mam jeden przykład, który się mogę podzielić jako nerd, człowiek technologii. Lubię sobie wyobrażać, że... Wszyscy najchętniej to by sobie zrobili jakiś model machine learningowy w TensorFlow. To są zabaw, którymi ludzie się bawią. Natomiast pracując nad takim jednym z projektów eksportu danych, integracji do innych narzędzi analitycznych z Zendeska, masz takie przekonanie, że ludzie używają Tableau, że ludzie używają Lookeru, że ludzie używają bardzo różnych skomplikowanych, zaawansowanych rozwiązań. No i później, nie będę tutaj może podawał jakiejś marki, ale globalna marka, spotyka się z takim klientem i widzisz reporting wielkiego globalnego brandu zapięty na Excelu. Nagle okazuje się, że być może ten research, być może te rozmowy z użytkownikiem miały sens, bo w pokoju z inżynierami myślisz sobie, no to co, integracja z tablo must have, looker must have, co tam jeszcze mamy, może byśmy jakieś chmury od razu, jakieś konektory zrobili. Robisz badania i lądujesz, że takim generalnym use case'em w 70% przypadków jest Excel, więc jestem też ciekaw, czy macie jakieś takie success stories, z którymi się możecie podzielić. Może żeby za bardzo nie wchodzić w szczegóły, ale klasycznym chyba przykładem jest to, że słyszysz od klientów takie szczątkowe informacje, że powinieneś coś zbudować i słyszysz bardzo dużo tego feedbacku. Już prawie zaczynasz to budować, ale w ostatniej chwili z nimi rozmawiasz i okazuje się, że to, co oni potrzebują, to tylko dlatego, żeby zrobić workaround na to, co ci nie działa w twoim produkcie. I tak naprawdę powinieneś w ogóle jeszcze bardziej uciąć to, co jest obecnie możliwe i stworzyć właściwe rozwiązanie, którego ci ludzie potrzebują. Więc kilka razy tak mi się udało w całej karierze trafić na takie złoto. Fajny temat poruszyłeś, bo akurat może nie z własnego podwórka, ale czytałem o fajnych dwóch use case'ach, którymi się mogę podzielić. Właśnie tak jak mówisz, jak czasami jest problemem dużym zła identyfikacja problemu. i jakby chęć rozwiązałem go w sposób zupełnie inny i to był just case właśnie, akurat domino pizza. Przy pewnym momencie domino pizza zorientowała się, że jakby czas oczekiwania na pizzę znacząco się wydłuża, ponieważ bardzo dużo ludzi dzwoni na domino pizzę i stara się dowiedzieć, gdzie jest moja pizza, dlaczego moja pizza jeszcze nie przyjechała. Oni zwrócili uwagę, że ludzie, którzy też odbierają telefony, mniej czasu mogą w stanie poświęcić na fizyczne jakby zorganizowanie procesu logistycznego tej pizzy. I im więcej osób dzwoniło, tym więcej ten proces się wydłużył, czyli problem był jeszcze gorszy. No i jakby pierwsza reakcja na ten problem jest, kurde, no to co, może zatrudnimy dedykowaną osobę, która będzie musiała odbierać te telefony i mówić ludziom, że jaki jest czas oczekiwania na pizzę jeszcze. Wydaje mi się, że często organizacje, szczególnie większe z mojego doświadczenia, w ten sam sposób myślą, jakby może zatrudnienie osoby na kolejne stanowisko będzie rozwiązaniem tego problemu i będziemy mieli troszeczkę spokoju. A co się okazało? Okazało się, że spróbowali podejść do tego troszeczkę inaczej, przeanalizowali sytuację i po pewnym researchu z ludźmi okazało się, że ludzie tak naprawdę nie są zdenerwowani, że względu na to, że czas oczekiwania na jej pizzy jest długi, tylko oni są zdenerwowani, bo nie wiedzą. kiedy ta pizza będzie. Jak mam informację, że ta pizza będzie za 50 minut, to będę robił coś, co przez te 50 minut. Jak referando mi powie, że mam przez godzinę 30, no trudno, ale będę coś robił przez godzinę 30, ale ważne, że wiem. Więc jakby co Domino Pizza zrobiła? Zrobili jakiś prosty tool do monitoringu czasu tej pizzy, co spowodowało, że ludzie nie musieli zatrudniać żadnej nowej osoby. Wydaje mi się, że ta właśnie właściwa obserwacja... tego dlaczego często użytkownicy mają właśnie pewne anxiety albo właśnie takie uczucie niezadowolenia nie do końca wynika z tego, że zmieńmy ten feature, dodajmy coś innego, tylko jakby zastanówmy się dlaczego właściwie użytkownicy na tym etapie produktu. mają pewne uczucie dyskomfortu. I tu znowu wchodzimy w tę rolę, gdzie czy my jako produktowcy, gdzie często płacą nam na hej, wymyślcie nowy feature albo jak usprawnić ten feature, bylibyśmy w stanie to wyhaczyć tak samo fajnie, jak zrobili to researcherzy, którzy jednak analizują to obserwowanie tego klienta troszeczkę inaczej. Dobra, a ja chciałem właśnie tak, nie wiem czy na koniec, już pod koniec pewnie, jednak włożyć klimarowisko w drugą stronę, bo tak bardzo mocno chyba się opowiedzieliśmy po tej jednej stronie, Teresy Torres, ale ja chciałem jednak z drugą strony na to spojrzeć, że kurczę, no jak myślimy na przykład o zespole deweloperskim, no to tu jakoś nie zastępujemy tych ludzi, nie mówimy, że to jest praca zespołowa i product manager może być deweloperem na przykład. Albo w drugą stronę, jakby czy my nie czulibyśmy takiego... depowermentu właśnie w momencie, kiedy na przykład CEO zacząłby wykonywać naszą pracę, to często też się zaczyna dziać, czy jakiś tam dyrektor na przykład taką naszą produktową, a my jesteśmy produktowcami i możemy z nim gdzieś tam współpracować. I trochę też takie się argumenty pojawiały. Nie wiem, czy się nie trudno z nimi w jakiejś części też nie zgodzić. To jest ciekawy temat i to wynika chyba z dostępności do domeny. Być może zaczniemy też obserwować to samo w świecie deweloperów. że my, niedobrzy product managerowie, zanim zapytamy dewelopera, czy da się coś wrzucić w local storage, to zapytamy czata GPT i powiemy mu, że tu mamy takie trzy zmienne i potem pójdziemy do dewelopera z kodem, ej, możesz to wsadzić do swojego skryptu. I też myślę, że mogą być podobne odczucia deweloperów, że dlaczego wchodzimy z butami, bo do tej pory nie mieliśmy wystarczająco domenowego skilla, na przykład, żeby w ogóle coś zasugerować oprócz... ogólnego zrozumienia architektury i obszaru, w którym się poruszamy, ale raczej kodu za deweloperów nie piszemy. Ale to się może zmienić wkrótce i w sumie wszyscy mogą paść trochę ofiarą tego podpowiadania sobie, jak kto powinien wykonywać swoją pracę. No już wiemy, że chyba w następnym razem musimy się rozprawić Kuba, Marcin z tematem low-code. To już może trochę zaspoilerowałeś, bo to ciekawy temat. Ciekawe i dobrze rzeczywiście do tego pasujący, bo ja rzeczywiście też na przykład ostatnio widziałem w jednej z firm właśnie trochę zastąpienie zespołu developerskiego dzięki temu, że są narzędzie no-code przez product managera. Może tego product managera w przyszłości zastąpi prezes. Ale właśnie Product Manager dołączył do firmy, zespół był uwikłany w różne tam techniczne rozgrywki przy jakimś tam core'owym produkcie, chcieli wystartować nowy produkt. Zbudował na platformie NoCode, sam z delikatną pomocą jakiejś agencji chyba na zewnątrz, działający cały produkt jakby technicznie używany przez kilkadziesiąt czy kilkaset tysięcy użytkowników. Więc tak naprawdę w sumie teraz trochę zaczyna się to też dziać, że jakby praca dewelopera też trochę tak jak... Praca designera, researchera, a tak naprawdę też i product managera może być zawłaszczana przez kogoś innego, bo to co chyba Kuba powiedziałeś, jakby ten dostęp do wiedzy domenowej, wejście w wiedzę domenową jest łatwiejszy. Wcale niekoniecznie to musi oznaczać, że jakby to jest dobre jakościowo, jakby długoterminowo, ale ten punkt wejścia jest dużo prostszy. I to jest z jednej strony jakby fajne, z drugiej strony właśnie jest to chyba niebezpieczeństwo. To myślę, że fajnie, jakbyśmy sobie krótko poruszyli. Jakie jest niebezpieczeństwo jakby zastąpienia UX Research'a przez product managera czy kogokolwiek innego, bo to tego samo się sprowadza, że rząd wejścia jest łatwy, ale jakby osiągnięcie jakiejś jakości albo wyciągnięcie złych wniosków albo dojście do złego punktu przez to, że nie mamy tej wiedzy takiej już naprawdę fajnej, może być bardzo ryzykowne. No właśnie, bo jak to mówiłeś, to się zastanawiałem, jaka jest ta unfair advantage, ta nieuczciwa przewaga UX researchera nad product managerem. Jak miałbym sobie odpowiedzieć na takie pytanie, to bym powiedział prawdopodobnie czas, to po pierwsze. Po drugie, wydaje mi się, że w idealnym świecie jakaś psychologia, to znaczy, tak jak Kuba powiedział, Część produktowców rekrutuje się z mniej klienckich środowisk, mniej ubytych z rozmawianiem z drugim człowiekiem, a to też jest duży skill, jak komuś nie sugerować odpowiedzi, jak kogoś aktywnie słuchać, etc. To nie jest given u każdego product managera i nie jest też wymagane często. Można całkiem długo przebrnąć bez pokładu w empatii i być doskonałym egzekjutorem jakiejś wizji. i może doprowadzić do takich różnych rzeczy ostatnio właśnie z jednym zespołem gdzieś tam robiłem szkolenie z podstaw więc to jakby było naturalne że tak rzeczywiście w takim punkcie gdzieś byli nie ale jakby rzeczywiście chcieli się trochę tego Discovery nauczyć i Pierwsze ich wywiady, które robili właściwie na warsztatach, były w stu procentach skupione na rozwiązaniach i dopytywaniu o rozwiązaniach. I jakby na tej podstawie wysnuwali wnioski, że użytkownik tego potrzebuje. I zaprowadzała ich to w bardzo złą jakby stronę. I tu może być tak samo, że jakby to jest fajne, że jest ten punkt wejścia łatwy. Na pewno jest to pewnie lepsze niż nic nie robienie, ale z drugiej strony, jeśli nie mamy tego dobrego warsztatu... to trochę to ryzyko obniżymy, ale nie jakoś dużo, więc jakby i tak musimy tą kompetencję zdobywać, a docelowo pewnie fajnie mieć jednak kogoś, kto się na tym zna w sposób lepszy niż my. A wracając na chwilę do tego tematu, że CEO może zastąpić nas, to teraz miałem styczność z case study MIT Uniwersytetu, który korzysta z naszego narzędzia naukodowego i to jak oni się wypowiedzieli o tym, co oni robią, to oni eksperymentują w czasie prowadzenia konwersacji, w takim czasie, w jakim możesz prowadzić konwersację. Tak o tym myślą, co robimy dla nich jako naukodowe narzędzie. Właśnie już nie ma nawet dewelopera w tym myśleniu trochę, znaczy wiadomo, jest tam osoba, która jest architektem rozwiązania, ale to rozwiązanie nie jest zależne od dewelopera, od posiadania produktowca, od posiadania designera, od posiadania researchera, tylko po prostu masz pomysł. i za godzinkę masz pierwszą wersję, którą możesz już testować z użytkownikami. Możesz się pomylić o 100%, potem pomylić drugi raz o 100%, w północy na wschód. W końcu dojdziesz z zachodu na południe i gdzieś zaczniesz zahaczać o użytkownika. Wydarza się to w dzień, a nie w rok, jak do tej pory na przykład często w produktach, tego typu myślenie. Więc wracamy do tej redukcji ryzyka. To myślę, że ciekawe będzie. na przestrzeni najbliższych lat kryterium też tego, jak myślimy o redukcji ryzyka. Być może researcherzy staną się takimi architektami trochę, że będą mieli w końcu narzędzia do prototypowania i rozmawiania z użytkownikami na sześciu różnych rozwiązaniach, które skraftowali w godzinkę albo w dzień. W ciekawą stronę to może zmierzać, po prostu kto będzie czymś się zajmował. To prawda, no i szczególnie jak już tak sprzedajesz nauką, ten temat nauką, to też dążąc do płynku. Akurat Sylonis też w części gdzieś tam bazuje na low-code, no-code. Tak jak mówisz, zaobserwowaliśmy, że mimo tego, że technologia i jej sposób zaawansowania umożliwia coraz więcej w coraz szybszym czasie i coraz to innym ludziom, to nadal jednak dla nas jakby rola researchera jest na tyle istotna, bo pojawiają się nowe pytania, na których nigdy wcześniej nie mieliśmy już odpowiedzi. Także jak miałbym dążyć do puenty, to wydaje mi się, że to byłoby fajne prostowanie, że jakby ten rozwój tych technologii w ostatnich czasach, szczególnie jak go obserwujemy, powodują, że potrzeba na researchera wydaje mi się, że gdzieś się będzie ewaluowała, tak samo jak ewaluują niewiadome tak naprawdę w tych rozwiązaniach, które widzimy, bo oni jako product managerowie, wydaje mi się, że i tak, czy tak będziemy się borykać z tymi pytaniami. No i pytanie, gdzie będziemy szukać odpowiedzi i jak? Kuba, puenta od Ciebie? Nadchodzą zmiany, jeszcze nawet nie wiemy, w którą stronę zmierza ta zmiana i wydaje się, że ten shift się zaczyna właśnie od tych być może luksusowych, jak to określiłeś Marcin, ról, ale dotknie wszystkich w najbliższych 3, 4, 5 latach, czyli... Każdy z nas będzie musiał się nauczyć trochę pracować w innym stylu, więc wydaje się, że trochę palenie się na socialach to jest takie obracanie się w miejscu, kiedy właśnie mówimy, hej, nie możemy korzystać z maszyn, bo one zawią nam pracę, podczas gdy to po prostu charakter pracy nam się zmienia i musimy się zacząć dostosowywać do kolejnej fali. Wojtku, od ciebie? Moje wnioski, to co zapamiętałem z tej naszej dyskusji, to jest researcher w kontekście optymalizacji ryzyka. Bardzo często sobie je spisujemy, które mitygujemy, które nie mitygujemy, a to jest jedna z implementacji ograniczenia tego ryzyka, takiej aktywnej, nie tylko wrzucenia sobie tego w Jire czy w Confluence'a. Super. A ja od siebie dorzucę, że researcherom życzę, żeby spotykali na swojej drodze kumatych product managerów, którzy rozumieją jakby ich pracę i product managerom życzę, żeby spotykali fajnych i mieli ten luksusowe dobro researcherskie w swoich zespołach, żebyśmy rozumieli, że to tak naprawdę niezależnie pewnie od naszych stanowisk, czy jakby jaką mamy rolę, jaką antykietę, to trochę to jest jednak ten sport zespołowy. Przynajmniej ja bardzo mocno w to wierzę i niezależnie od tego, jak się nazywamy, to ja bardzo chcę, żebyśmy razem jako zespół te produkty budowali. Panowie, bardzo wam dzisiaj dziękuję za ten podcast, trochę w innej formie niż dotychczas. Wojtek, wielkie dziękuję za co-hostowanie naszego podcastu. Tak jak powiedziałeś, to był teamwork. Mój, twój, Kuby. Marcina Kuba Marcin dzięki wielkie też za spotkanie super się rozmawiał fajne dyskusje dziękujemy wam bardzo ten odcinek podcastu jeśli podobało wam się to co tutaj powiedzieliśmy albo nie podobało albo jakieś pytania albo chcecie nasz hejtować piszcie w komentarzach pod podcastem wszystkie rzeczy o których wspominaliśmy wrzucimy w linkach pod pod tym podcastem w jakimś opisie podcastu żebyście mogli je znaleźć dziękujemy i zapraszamy do słuchania dalej szukajcie też Kuby Marcina i ojtka w social mediach. Trzymajcie się ciepło. Hej!

W dzisiejszym odcinku podcastu Product Vision porozmawiamy o product discovery, opportunity solution tree i... dramie, która wybuchła między autorką tego narzędzia, Teresą Torres, a społecznością UX Researchów.

👉 co myślimy o dramie między Teresą Torres a UX Researcherami?
👉 czy potrzebujemy UX Researchu przy rozwoju produktu?
👉 jak przekonywać do UX Researchu w firmie?
👉 nasze najciekawsze case'y, gdy research był potrzebny
👉 dlaczego PMowie realizują product discovery?

W podcaście wystąpili: Wojtek Smajda (Senior Product Manger w Zendesk), Jakub Tutaj (Senior Product Manager w Softr), Marcin Jędrzejczak (Principal Product Manager w Celonis).

Oczywiście to tylko nasza PMowa perspektywa. Na punkt widzenia środowiska UX zapraszamy tutaj 👉 https://www.youtube.com/watch?v=tbczL24Agb0

✨ Sponsor odcinka: https://kursy.productvision.pl/product/akademia-analityki-produktowej/

🎧 Słuchaj na Spotify, Apple Podcast, itp.: https://productvision.pl/podcast/

Linki:
- Co to jest Product Discovery? https://youtu.be/2pHA908ST5c?si=3viI2ksegXMNv8al
- Drama między Teresą Torres i UX researcherami: https://www.linkedin.com/posts/teresatorres_over-the-past-few-weeks-there-have-been-activity-7156053272812777472-1U_g/
- Wątek o dramie na Reddit: https://www.reddit.com/r/UXDesign/comments/1abyrrx/teresa_torres_continuous_discovery_causes_ux/
- Poradnik Opportunity-Solution-Tree - https://www.productcraft.pro/p/opportunity-solution-tree-101-uporzadkuj-swoje-product-discovery