Jak zacząć z Opportunity Solution Tree? Moja praktyka i case studies- Tomek Tomaszewski |T3c #109 UX

Dobrze, mam nadzieję, że mnie dobrze słychać. Jeśli tak to łapka w górę, za chwilę i tak to będziemy ćwiczyć jeszcze raz. Słychać mnie, nie słychać? Słychać. Super. Słychać, widać. Tomek, zapraszam. Dobra, nie dość, że macie tylko dwie prezentacje, to jeszcze przyszedł do Was typ, który nie zajmuje się UX-em, bo jestem Product Managerem, więc gościnnie, ale pracowałem przez rok, półtorej jako UX. No chcę Wam trochę dzisiaj pokazać moje perspektywy produktowej na jedno narzędzie Opportunity Solution Tree, jak je poznać. kiedy zacząłem je wykorzystywać. Zrobimy małe case study, a właściwie zobaczycie małe case study tego jak to wyglądało kiedy zaczynałem z tym narzędziem. No i spróbujemy sobie nawet takie drzewko ułożyć w praktyce, a jak to z live codingiem czy endzone różnie może być. Mam nadzieję, że wszystko pójdzie dobrze. Także będzie Opportunity Solution Tree, żeby wam trochę pomóc w temat discovery, odkrywania tego czego użytkownik może potrzebować. Ja nazywam się Tomek Tomaszewski, przez ostatnie 5 lat pracowałem jako Product Manager Head of Product w CentiOne, wcześniej tak jak mówiłem, między innymi też jako UX Designer czy Product Manager w innych organizacjach. Jestem autorem newslettera Product Craft Pro, może niektórym jest Product Vision, kojarzę takiego podcastu. Tworzymy też akademię taką produktową. Ogólnie specjalizuję się w ogóle w tematach takich Product Discovery, odkrywania tego, co jest użytkownikom potrzebne, szczególnie na początkowych etapach. życia produktu, czyli przy wprowadzaniu nowego produktu na rynek, tam gdzie musimy znaleźć ten product market fit, a przez to, że byłem headem, to też dużo ostatnio czasu poświęcam w ogóle budowaniu zespołów produktowych. Z takich fanfaktów, dużo certyfikatów, ale jeden zdobyłem niedawno i jutro go będę odbierał. Mam 35 lat i zdałem egzamin na prawo jazdy państwowe. Na szczęście, mimo że mam mobilne w kieszeni, to nie przyjechałem dzisiaj samochodem, więc nie musicie się obawiać dzisiaj, jeżeli ktoś jest autem. Natomiast jutro będę odbierał, więc uważajcie na drogach. Kto jest designerem? Poznajmy się trochę. Łapka w górę. Kto się tak identyfikuje? Sporo. Kto się identyfikuje w temacie UX Research? O, dobrze. To mało osób, które będzie mnie chciało zjechać za to, co tutaj mówię. Kto woli sernik z rodzynkami niż bez? No nie no są takie tacy ludzie. Jest ich więcej niż UX Researcherów okazuje się. Dobra kto wie co to jest Opportunity Solution Tree? Słyszał o czymś takim? O mało osób to w sumie fajnie rzeczywiście. Będziecie mogli okazję poznać. No to czy ktoś z tych kto słyszał stosuje w praktyce? To jestem jedyną osobą na tej sali. A jest mamy. Super. Dobra, fajnie, to zrobimy, będzie wstęp teoretyczny, żeby trochę poznać to narzędzie i o co w nim chodzi, ale też w praktyce spróbujemy na case study je zobaczyć i przetestować. Ale zanim do jakby tej praktyki, to trochę właśnie wstępu odnośnie case'a, w ogóle mojej historii, kiedy ja to gdzieś pierwszy raz użyłem. W Sent1 odpowiadałem za taką platformę, która nazywała się Sent1 Automate, służącą do automatyzacji obsługi klienta. Jeśli dzwonicie do banku lub na przykład do jakiegoś telekomu i odbiera bot, Ten, który was denerwuje to jest duże prawdopodobieństwo, że jest to robione przez tą platformę, którą ja zaczynałem i potem gdzieś tam rozwijałem jako product manager w Sent1. To jest używane przez duże organizacje do automatyzacji właśnie obsługi klienta z wywołacą botów i voice botów. W tamtej platformie można autoprojektować tego bota i to jest jakaś jedna część, tym takim tutaj właśnie drabinkami, to co widzicie tutaj trochę się tak projektuje, że hej, jeśli coś się wydarzy to bot ma zrobić coś. A druga duża część to jest właśnie ta część taka typowo AI, gdzie bota uczymy, że jeżeli użytkownik coś powie, zrozumieć, to bot ma coś zrozumieć. No i tutaj, żeby ten bot coś zrozumiał, to musimy podać mu kilka przykładów takich uczących, tak zwany zbiór treningowy, po to, żeby on się mógł tego nauczyć i na tej podstawie wnioskować. Dużą rzeczą, którą zapamiętajcie, bo to będzie ważne w kontekście case'a jest to, że tak jak z modelami AI, może niektórzy z was z tym gdzieś pracowali, no to jest tak, że jeżeli uczamy, dorzucamy do zbioru uczącego coś, to ten model za każdym razem trzeba trochę tak przetrenować, żeby on się na nowo trochę nauczył. No i w tej platformie też jest taka opcja, jeśli dorzucamy jakieś kolejne frazy, na przykład mówimy botowi, że powitanie to nie jest tylko cześć i hej, ale też na przykład jak użytkownik mówi hello, no to to jest dodatkowa fraza, po której bot musi się przeuczyć, że hej, on teraz już będzie rozumiał tą frazę i jakieś... zbliżone do tego, że to jest powitanie. Więc to jest jakby ta część taka uczenia i to pamiętać, że trzeba to niestety każdy model przetrenować po takim dorzuceniu tych danych. Ta platforma jest wytraczana on-premisowo, czyli na serwerach klienta, no i ci klienci często mają jakieś środowisko testowe i produkcyjne, żeby sobie najpierw to przetestować u siebie na środowisku testowego, a potem dopiero na produkcji tego bota gdzieś. wystartować. No i tak mniej więcej wygląda produkt. Ja ten produkt wprowadzałem na rynek jakieś sześć lat temu, on się dosyć fajnie rozwinął i teraz jest gdzieś wdrażany w dużych organizacjach. No i jestem tym product managerem i gdzieś tam chyba po roku, po dwóch już pierwsi klinici zacznieją z tego korzystać. No przychodzi do mnie CTO, przychodzi project manager, przychodzi manager, bo to tak jak dziwnie w tym samym mniej więcej momencie mówią Tomek musimy zrobić funkcję konkretną, funkcję przenoszenia modeli tych AI między środowiskami, bo klienci nie mogą pracować. Nie wiem czy kojarzycie tego typu teksty, które czasem padają, czyli zróbcie mi funkcję albo klienci nie mogą pracować, albo użytkownicy nie mogą pracować. Trochę to jest podkoloryzowane, ale tak rzeczywistości gdzieś było. No mi się oczywiście gdzieś zapala jakaś taka... czerwona lampka w momencie kiedy ktoś mówi hej zróbmy jakiś feature zamiast zastanówmy się jaki problem chcemy rozwiązać to jest raz, a dwa jak słyszę, że klienci nie mogą pracować to też jest ciekawe, no bo w sumie jakoś tam pracują. Więc mając już jakąś taką wiedzę okołoproduktową no wiedziałem, że okej nie chodzi tylko o to żebyśmy zbudowali to co oni chcą, ale też fajnie byłoby się dowiedzieć jakby czy to co zbudujemy będzie miało w ogóle sens, czy w ogóle powinniśmy to budować, czy może coś innego powinniśmy zbudować. Czyli generalnie zająć się tym tematem product discovery, my to produktowcy trochę zawłaszczyliśmy, nazwaliśmy product discovery, a uxowcy nazwą to ux researchem po prostu, bo to jest bardzo mocno zbliżone. No ale żeby zrobić to odkrywanie rzeczywiście tego realnego problemu użytkownika, który chcemy rozwiązać. No to product discovery pewnie to kojarzycie, double diamond, kto kojarzy, łapka w górę. No właśnie, więc to pewnie kojarzycie w większości. Podchodzimy do rozwiązania jakiegoś problemu od tego, że najpierw musimy mieć jakiś cel, w którą stronę gdzieś dążymy. Staramy się zrozumieć problem użytkownika klienta, czyli pracować w tym obszarze problem space, zrozumieć ten problem, o co w tym problemie chodzi. Dopiero potem podejść do wymyślania jakichś potencjalnych rozwiązań i zwalidowania, które rozwiązanie będzie najlepszym rozwiązaniem tego problemu. Więc taki typowy sposób pracy. W ogóle nie każdym featurem tak naprawdę to powinno wyglądać, pomysłem, produktem, pokazujący trochę ten product discovery czy UX research. No i prześledźmy jak to wyglądało w tej sytuacji. Do mnie przyszedł ktoś z czym? No nie z celem, tylko z rozwiązaniem. Zróbmy tą możliwość przenoszenia modeli AI między środowiskami, czyli że bierzemy jakieś pliki i przenosimy na drugi serwer i robimy to w bardzo prosty sposób, bo teraz jest to bardzo trudne. Ja mówię, okej, dobra, ale dlaczego chcemy to robić? Bo użytkownicy nie mogą pracować, jak bym to powiedzieli. Czy to jest problem użytkownika, w sensie taki realny? Pewnie nie do końca, więc o co tak naprawdę Wam chodzi? Chodzi o to, że przenoszenie tych botów z jednego środowiska na drugi trwa bardzo długo, bo trzeba przenieść pliki. Już mi się zapalała czerwona lampka, bo przecież mamy jakiś import-export tych botów i można to bardzo łatwo zrobić. Musimy przenieść pliki z jednego serwera na drugi serwer, żeby to w ogóle działało. No okej, ale przynajmniej wiem o co chodzi, jaki problem użytkownika tutaj potencjalnie jest. Trwa to długo. Podobno też jest błędogenne, bo jak przenosimy te pliki, tam trzeba pamiętać o jakiejś zmianie nazwy i tak dalej. Dużo błędów może się pojawić i przez to trwa to bardzo długo, kilka, kilkanaście godzin. Też te pliki z modelami są bardzo duże. No dobra, przynajmniej jakiś potencjalny problem użytkownika. Teraz warto jeszcze, żeby sobie odpowiedzieć na pytanie, czy w ogóle to powinno być w strefie naszego zainteresowania, czyli gdzieś... zbliża się do jakichś celów, które mamy w organizacji i tu akurat przyjmijmy, nie przyjmijmy, tylko rzeczywiście tak było, mieliśmy na następny kwartał taki cel, że rzeczywiście chcemy zmniejszyć czas potrzebny na to, żeby te boty sobie gdzieś tam utrzymywać, no bo zrobiliśmy tą platformę, klienci z niej korzystają, ale okazało się, że utrzymanie tego bota często jest kosztowne, bo dużo osób musi nad tym gdzieś tam pracować, spędzać dużo gdzieś czasu i chcemy to zoptymalizować. Taki jest cel naszej organizacji na najbliższe kwartał, chyba dwa kwartały, jeśli dobrze pamiętam. No dobra, więc teoretycznie moglibyśmy, znamy problem użytkownika, moglibyśmy przyjść do realizacji, no bo w sumie znamy problem, jeszcze się więcej dowiemy potencjalnie, co ci użytkownicy potrzebują, jak ten problem dokładnie wygląda. No ale okej, pytanie czy to jest rzeczywiście ten realny problem, który chcemy rozwiązywać. Więc robimy jakieś wywiady, żeby z tymi użytkownikami się trochę więcej czegoś od nich dowiedzieć. No i nagle się okazuje, że może tym problemem nie jest wcale to, że tam trzeba jakieś pliki przenosić bardzo długo, tylko oni wspominają też o takim problemie. że hej, że jak my przerobiliśmy ten import i export, to ten bot na tym innym środowisku to on inaczej się uczył. To znaczy wyniki były podobne, ale nie dokładnie takie same. No to ja z jednej strony sobie myślę, my tak trochę zaprojektowaliśmy tą platformę, myśleliśmy, że tak działa sztuczna inteligencja. To nie jest tak, że jak bot dostaje jakieś pytanie, to dokładnie w taki sam sposób zawsze powinien odpowiedzieć. I na każde pytanie dokładnie w taki sam sposób jakby i odpowiadać i na te wszystkie same pytania reagować. Natomiast z drugiej strony rzeczywiście tu się okazało, że jeśli... duży klient to kupuje, jakiś bank, no to on sobie nie może pozwolić na tego typu sytuacje i musi mieć taką sytuację, że jeśli rzeczywiście coś działało w pewnym momencie, to musi na 100% działać w drugim momencie. Więc jakby te boty uczą się trochę inaczej, trochę takie z tymi modelami właśnie, że jeśli rzeczywiście nic z nimi nie robimy, no to jak przetrujemy jeszcze ponownie, no to trochę to może wyjść inaczej, mimo że uczymy nawet na tym samym zbiorze uczącym, bo tak działają sieci neuronowe. Natomiast okazuje się, że taki problem wcale nie trzeba. Może potencjalnie rozwiązywać tą kwestią przenoszenia tych plików i zrobienia w interfejsie, na przykład to, że wskazuje, gdzie te pliki mają się przenosić i użytkownik sam to może robić, a nie za pomocą deweloperów czy DevOpsów. Tylko może, tutaj nam podpowiedział to zespół researchowy, może trzeba ustawić tylko jakieś ID konkretne, które spowoduje, że ten trening wygląda dokładnie taki sam, czyli zupełnie inne rozwiązanie. Teoretycznie tego samego problemu. Ale możemy pójść dalej. Mieliśmy cel zmniejszyć koszty maintenanceu bota. Ale pytanie, czy ten problem rzeczywiście to jest najważniejszy problem, który powinniśmy rozwiązać, żeby zmniejszyć ten maintenance. Może są inne problemy użytkowników. Więc zaczęliśmy rozmawiać z innymi użytkownikami. I na przykład ludzie, którzy testują boty mieli swoje problemy. Jednym z takich problemów było to, że oni przygotowują jakieś takie testy automatyczne, które testują tego bota. Te testy to jest tak naprawdę konwersacja, co mówił użytkownik, co powinien powiedzieć bot. I taki scenariusz można odpalać wielokrotnie czy właśnie jakby cyklicznie i sprawdzać, czy te rzeczywiście odpowiedzi są takie same. No i mówi, że bardzo długo trwa przygotowanie tych przypadków testowych, więc może jakieś rozwiązanie, które ułatwi im przygotowanie tych przypadków testowych. Więc jakby mamy potencjalnie dwa inne jakieś następne rozwiązania, które odpowiadają na ten problem, a kierują do tego samego celu. te rozwiązania to mogą być właśnie albo możemy im ułatwić, że hej wcale nie musicie pisać tych testów sami tylko weźmy historyczne rozmowy i z nich zróbmy test bo one są przecież prawidłowe albo zróbmy wam na przykład nie wiem zaawansowany język psania takich testów gdzie możecie po prostu robić jakieś pętlę, jakieś ify i w ogóle dzięki temu będziecie mogli robić super testy. To są dwa różne rozwiązania znowu. I zobaczcie co się wydarzyło jakby od tej jakiegoś pomysłu na feature My po tym double diamondzie biegaliśmy w lewo i w prawo. Problem space, solution space. Tu mamy jakieś takie problemy tych użytkowników, tych użytkowników. Tu mamy rozwiązania, które pasują do tego problemu, do innego jakiegoś problemu, które sobie zindycyfikaliśmy. Jak się trochę w tym połapać? I to jest jakby mój problem, który ja miałem właśnie z takim odkrywaniem i z tym discovery, że to jest jakby fajny model i jakby ja jestem... wielkim fanem, ale trochę mi to przeszkadzało w sensie takie linearne myślenie w pracy, no bo jak to trochę tak zorganizować? Oczywiście starałem się ten research organizować w jakiejś dzirze, w jakiejś konfluensie, w jakichś takich notatkach i tak dalej, że mamy jakiś problem space i rzeczywiście tam robimy jakieś badania, wywiady z użytkownikami, dokumentujemy to, odkrywamy problemy, tak samo z rozwiązaniami. No tylko widzieliście, my tak nawet trochę biegaliśmy w lewo i w prawo. I teraz pytanie, co planować naszą pracę? Zmieramy? Chcemy w ogóle zaplanować naszą pracę, na którym się skupić, na którym tym problemie, na którym rozwiązaniu, czy robić wszystkie, w którą stronę iść. No i tak jakby bardzo ciężko było się w tym pułapać. Jak porównać te poszczególne pomysły, które w ogóle realizować, czy może realizować pomysł ten na końcu co wyszedł, czy ten pierwotny, w jaki sposób w ogóle wybrać, które te pomysły robić. No a w ogóle pokazanie firmie, gdzie my w tym momencie takiego odkrywania jesteśmy, no to to już w ogóle, okej, fajnie, miałem tą kartę jakąś inicjatywy, opisane, ten problem space, solution space, ale nikt tego w ogóle nie rozumiał. Nawet deweloperzy bardzo często, z którym chciałem jak najbardziej ten kontekst biznesowy i użytkownika przedstawiać. Więc tego typu problemy ja miałem z taką typową pracą linearną. No bo często to nasze discover, odkrywanie bardziej wygląda w taki sposób, a nie tak, że sobie przechodzimy bardzo łatwo przez ten problem space, a potem przechodzimy do tego wymyślania rozwiązania. Bardzo często biegamy w jedną i w drugą stronę, robimy jakieś wywiady, robimy jakieś testy jakiegoś pomysłu, ale okazuje się, że te testy pomysłu coś pokazały, więc musimy wrócić do wywiadu. Okazuje się, że może jakiś inny problem użytkownika jest ważniejszy do rozwiązania i tak trochę biegamy. Oczywiście im bojrzalszy produkt, im dłużej pracujemy nad zwykle tym produktem, tym bliżej jesteśmy tego końca. Natomiast bardzo często na początku wygląda to w taki sposób. I coś, co mi mega pomogło właśnie w takim ustrukturyzowaniu tej pracy na discovery, odkrywanie, zrozumienia problemów użytkownika, to jest jakby metoda, która nazywa się Opportunity Solution Tree. Z tej książki właśnie wtedy, jak robiłem tę inicjatywę, o której mówiłem, miałem tę książkę w rękach, zacząłem ją czytać i ona właśnie tutaj Teresa Torres, która autorką tej książki zaproponowała taką metodę, która nazywa się Opportunity Solution Tree, takie rzewko, żeby te nasze pomysły rozpisywać. w taki trochę mineralny sposób, tylko bardziej w sposób taki drzewkowy. Na czym to polega? Polega to na tym, że nie piszemy sobie po prostu właśnie, że oj, tutaj mamy jakiś cel, chcemy rozwiązać jakiś problem jakimś rozwiązaniem, tylko staramy się podejść do tego właśnie, żeby zrobić to w formie takiego drzewka bardzo wizualnie dwuwymiarowo, a nie jednowymiarowo, jak do tej pory bardzo często to mieliśmy. Czyli mamy jakiś outcome, do którego chcemy dążyć, są jakieś potrzeby, problemy użytkownika, które do tego outcomeu, tego celu powinny prowadzić. Są jakieś rozwiązania, które pozwalają nam te opportunity teoretyczne, czyli problemy użytkownika wykorzystać. Jak to może wyglądać na realnym przykładku? Zaraz zobaczymy sobie to na moim przypadku, ale spróćmy najpierw, co na pewno wszyscy znamy, czyli jakiś Netflix, streaming video. Jakie oni mogą mieć cel, do którym podążają w danym kwartale? Na przykład chcą zwiększyć zaangażowanie w produkcie, bo użytkownika wykorzystają albo Albo po prostu chcą zwiększyć zamianowanie, żeby dłużej użytkownicy z tego produktu korzystali. Taki mamy cel. Co robimy? Zaczynamy rozmawiać z tymi użytkownikami, żeby znaleźć te potencjalne problemy i potrzeby, które mogą do tego celu prowadzić. Zwykle jakimiś wywiadami na początek. No i szukamy tych różnych właśnie problemów i potrzeb. Teresa Torres nazywa to opportunity. Woli to słowo opportunity niż problem. Często używamy tego słowa problem, bo nie zawsze to musi być problem użytkownika. Czasem to może być potrzeba, to jest raz. A dwa, że dosyć fajnie to pokazuje tą kwestię taką, że to jest pewna szansa do korzystania, a nie pewne, że musimy w tą stronę iść. Więc jakby szukamy jakichś różnych problemów użytkownika, które mogą prowadzić do tego outcome'u, do tego celu takiego biznesowego. I co to może być w przypadku Netflix, który chce zwiększyć zaangażowanie? Jaki problem mogli sobie wykryć? Pewnie część z Was tego doświadcza. No nie mogę znaleźć nic ciekawego do oglądania. I pewnie by się w wywiadach bardzo często coś takiego powtarzało, że nie mogę znaleźć nic ciekawego do oglądania, ale to nie będzie jedyny problem, który ludzie w końcu będą wskazywać. Na przykład skończyły się odcinki mojego ulubionego serialu Nie wiem co dalej oglądać. Nie wiem czy serial, który lubię i chciałem zawsze obejrzeć jest teraz dostępny i się pojawił, a nie będę tylko co chwilę sprawdzał. Takich problemów użytkownika... I dlatego Teresa proponuje właśnie tą strukturę taką drzewkową, żeby sobie rozpisać te różne opportunities, czyli problemy. Czasem jeden problem będzie się wkładać z różnych podproblemów. Po to, żeby wywołać się potem pojedynczo gdzieś tam, zastanawić się, w jaki sposób można jest atakować jakimi rozwiązaniami, czyli jakimi pomysłami na rozwiązanie tego problemu użytkownika. I to są jakieś nasze najlepsze pomysły, zwykle rozwiązania w naszym produkcie, naszej aplikacji, jakaś funkcja, która przyniesie korzyść temu użytkownikowi, przez co rozwiąże ten problem. na tą potrzebę. No tu warto tylko pamiętać, że to są różne różnego rodzaju hipotezy. No i przykład takiego pokazania rekomendacji po zakończonym odcinku. To może być jakaś funkcja, która problem użytkownika nie wiem co oglądać po zakończonym na przykład serialu, który będzie prowadziło do tego zaangażowania, który jest celem naszej organizacji. Oczywiście znowu tych rozwiązań, które do tego prowadzą może być wiele. To może być rekomendacje po obejrzeniu filmu, to może być to, że na stronie głównej pojawią się jakieś, nie wiem, rekomendacje na przykład. To może być to, że od razu się film włączy następny na przykład po zakończeniu tego, który oglądałem. Więc jakby tych sposobów jest cała, może być cała masa. No i zwróćcie uwagę, że tam u góry pracujemy nad tym obszarzem jakby takim problemowym, czyli staramy się zrozumieć problem użytkownika, niżej nad tym solution space, czyli jakie rozwiązania potencjalnie mogą do tego prowadzić. No i jak testujemy te rozwiązania? Jakimi zwykle komentami. Wydróżmy na produkcję i zobaczmy czy ludzie z tego korzystają. Ale może mamy jakieś inne pomysły. Na przykład zrobimy jakieś testy, fake dory tak zwane, żeby zobaczyć czy w ogóle ludzie w to klikną. Można zrobić jakiś landing page, czy ludzie się znalazją na coś. I to już jest jakaś tam sprawdzanie jakiejś propozycji wartości. Może jakieś MVP bardzo ograniczone, ale też będziemy testować już to gdzieś to rozwiązanie. Więc jakby tych sposobów znowu przetestowania tego rozwiązania może być cała masa. Dzięki temu, że to ma taką strukturę drzewkową, to możemy sobie właśnie te różne problemy pod ten cel, pod te rozwiązania potencjalnie rozpisać, znaczy coś jest, z czym potencjalnie gdzieś tam łączy. Ja bardzo lubię jeszcze do tej struktury drzucić jedną rzecz, nazywam to aktorem, zwykle to jest użytkownik, czyli jakiego użytkownika dotyczy dany problem. aktorem, bo nie zawsze może być klient na przykład, kto płaci, a nie użytkownik, albo na przykład czasami nawet wewnętrzny interesariusz, natomiast zwykle to będą użytkowników, zwykle pomaga zastanowić się na przykład dobra, to których użytkowników my powinniśmy przebadać i z którymi zrobić wywiady, albo których nie przebadaliśmy i nie mamy przydatków i opportunitiesów. No i tak to Teresa jakby układ w jedno, to jest dokładnie to samo, co ja tutaj pokazałem. obudowuje to całkiem, całkowicie jeszcze takim metodą, którą nazywa continuous discovery, żeby cały czas odkrywać te różne problemy użytkowników i rozwiązania, żeby stawiać sobie gdzieś ten cel na początku kwartału, co tydzień do objawy z użytkownikami, żeby odkrywać właśnie te problemy użytkowników i co tydzień też sobie planować różne eksperymenty, które będą testowały te różne... potencjalne rozwiązania. Nie będziemy aż tak w szczegóły wchodzić samej metody, polecam w ogóle książkę, żeby sobie gdzieś przeczytać, ona więcej o tym pisze, ale chciałem wam pokazać właśnie jak takie opportunity solution tree może wyglądać na konkretnym przykładzie tym, który sobie gdzieś przed chwilą omówiliśmy, czyli właśnie tej mojej inicjatywy związanej z tym wesołym botem. Więc zrobimy to hands on i jestem bardzo ciekawy co nam tutaj wyjdzie. Dobra, więc to jest ta inicjatywa, mam nadzieję, że tutaj widać. I spróbujemy sobie takie drzewko zbudować. Od czego tutaj wyszliśmy? Od szliśmy od tego właśnie rozwiązania, tak? I to jest początek tego naszej pracy. Więc z tym przyszli do mnie rozwiązaniem, które teoretycznie było dla nich problemem, że chcemy zbudować rozwiązanie, możliwość przenoszenia modeli AI między środowiskami. Tu jest też, od razu pogadałem ze swoim zespołem deweloperskim, jak to może być potencjalnie duże, żeby tak bardzo, bardzo... oszacować z grubsza, nie wchodzi w jakieś takie bardzo duże dywagacje, będzie to bardzo duże koszulkowo XL. OK, no dobra. Potem zrobiłem to, co już właśnie wam mówiłem, czyli OK, no to w takim razie jaki problem użytkownika, jakiego użytkownika chcemy rozwiązać i jaki będzie tego cel. Sej pozwolę to skopiować, bo to już sobie gdzieś robiliśmy. OK, czyli celem było to zmniejszenie kosztów maintenanceu bota, bo taki mieliśmy cel ten kwartalny, a problemem było przenoszenie między środowiskami TST, produkcja także trwa to bardzo długo. Okej, co w takiej sytuacji ja robię, mając taki początek tego drzewka tak naprawdę, tak? Okej, trzeba co zrobić? Wyeksplorować ten obszar problem space, czyli lepiej spróbować zrozumieć ten problem użytkownika i teraz tego użytkownika, a może za chwilę nam wyjdą problemy innych użytkowników. Jak to zrobić? Zwykle najczęściej wywiadami. To jest jakaś podstawowa taka technika. Więc okej, zaplanowałem sobie z razem z moim tak zwanym product trio, miałem tam product ops, product researcher taką osobę i trzecią devleet. Będziemy robić wywiady z naszymi bot managerami, bo oni zajmowali się tym wdrażaniem botów. Okej, robimy wywiady. No i to co się dowiedzieliśmy to jest to co wam dokładnie powiedziałem, że jakby Wyszliśmy od tego problemu rozmawiając o tym co oni tak naprawdę robią. Wyszło nam, że te problemy, ten problem tak naprawdę składa się z dwóch jakichś takich potencjalnych podproblemów. Jednym jest właśnie to, że modele NLU się uczą za każdym razem inaczej. Uczenie jest za każdym razem inne. I tak naprawdę to jest jakiś problem użytkownika jeden, który my potencjalnie możemy rozwiązać. A drugi to rzeczywiście jest to, co oni mówili, czy rzeczywiście jakby to, że przenoszenie plików jest bardzo długie. No bo jest taki realny problem użytkownika, tak? Jeśli użytkownicy cały czas realizują to w ten sam sposób. Przenoszenie plików trwa długo. No dobra, więc tak naprawdę mamy dwie, dwa już potencjalne opportunitiesy, do których możemy szukać rozwiązań. Jedno potencjalnie mamy od moich jakby interesariuszy, którzy przyszli, że teoretycznie można by rzeczywiście zrobić jakiś mechanizm przenoszenia tych plików, no ale jest też drugi, w którym też już sobie krótko powiedzieliśmy, że to może być jakieś tam ustawianie tego tak zwanego numeru SID. Tylko wtedy jak porozmawiam o tym zespołem, to okazało się, że to wcale nie jest wielkim rozwiązaniem typu XL, tak jak koszulka, tylko to jest jakaś prosta eska. XSK nawet. Wystarczy zrobić bardzo proste jakieś rozwiązanie, które to umożliwi. Z literówki przepraszam. Okej, mamy coś takiego, nie? Natomiast pytanie, czy na tym powinniśmy poprzestać, że hej, w sensie fajnie, nie? Znaleźliśmy jakieś potencjalnie różne rozwiązania. Powinniśmy pewnie wybrać mniejsze, czy na tym powinniśmy poprzestać? Jak myślicie? Szukać dalej, ale czego będziemy szukać? Dokładnie, możemy albo szukać innych problemów tych użytkowników, które do tego będą prowadziły. i też takie rzeczy robiliśmy albo można pójść jeszcze w prawą stronę, czyli jakby hej kto jeszcze korzysta z tej platformy, produktu, jakie mamy inne persony w tym naszym produkcie i jakie potencjalnie oni mają, które do tego mogą prowadzić. I rzeczywiście są takie persony w tym produku, oczywiście poza tym, że ktoś musi zarządzać też, czy ktoś musi robić, więc mamy tak, są tak zwani projektanci botów, którzy używają tego systemu, żeby coś zaprojektować, projektanci. Mamy też testerów, też delikatnie o tym wspominałem, testerzy. Ok, no to żeby teraz poznać jakie oni potencjalnie mają problemy, które mogą do tego celu prowadzić, co zrobimy? Wywiady. Warto zacząć tak naprawdę zwykle od wywiadu. Więc to co zrobiliśmy, fajnie, zaplanowaliśmy sobie wywiady z tymi grupami, segmentami użytkowników. Robimy wywiady i zobaczcie, buduje nam się drzewko. Od razu też widzę co robię dla poszczególnymi grupami docelowymi i jak to się wszystko na siebie gdzieś rozkłada. Ok, zrobiliśmy te wywiady, wyszły nam inne opportunities, inne problemy, które mają ci użytkownicy. Tutaj trochę skipnę, żebyśmy nie musieli robić całości, ale też to zobaczycie, że wyszły nam problemy, że projektanci botów mają takie problemy, że jest bardzo trudna współpraca grupowa, kiedy utrzymują tego bota i muszą naprawiać jakieś błędy. Powiedzieli też, że to publikowanie bota, że jest bardzo trudne, że... Jak oni publikują bota tak, żeby on był dostępny, to muszą wciśnięć przycisków, kliknąć, żeby tam przetrenować wszystkie modele AI, wszystkie tam te elementy tego bota, żeby one były spublikowane i że to jest trudne. A może nie trudne, tylko czasochłonne. I takie wyszły na przykład u nich problemy, a u tych, którzy testują boty, no to wyszło im, że właśnie pisanie tych testów automatycznych jest bardzo długie. No okej, dobra, więc mamy te problemy, zrozumieliśmy je trochę lepiej właśnie wywiadami. Co możemy zrobić dalej? Co byście zrobili dalej? Tak, możemy zrobić ideację, czyli zastanowić się, jakie potencjalne rozwiązania mogły być do tych problemów. Można też zrobić trochę inaczej, ale za chwilę o tym opowiem. Wymyślamy potencjalne jakby rozwiązania. No i my myśleliśmy rzeczywiście te rozwiązania. Zrobiliśmy po prostu z zespołem, usiedliśmy, jakie potencjalne pomysły, czyli nasze jakieś hipotezy mogą do tego prowadzić. I do współpracy grupowej nie mieliśmy pomysłu, ale wiedzieliśmy, że to będzie duże, jeśli cokolwiek będzie miało tam w jakikolwiek sposób zadziałać, bo tym problemem się już zajmowaliśmy. że to będzie jakaś wielkość LXL, że do publikowania bota mamy dwa małe rozwiązania, które prawdopodobnie większość tych problemów rozwiążą. XS-ki, że jednym przyciskiem można opublikować tego bota zamiast klikać kilkanaście, kilkadziesiąt razy. Testerzy, tu mieliśmy te dwa potencjalne rozwiązania, o których wam mówiłem, że możemy ułatwić jakieś generowanie tych testów albo dać im specjalny język, że specjalnie będą mogli zaawansowane te bardzo testy pisać. Zespół deweloperski był w stanie to mniej więcej oszacować jak to jest gdzieś duże, znowu nie dokładnie, ale jakie to jest mniej więcej gdzieś duże, więc jakby mamy jakieś te wielkości. Co dalej, nie? Mamy ideacje, czyli mamy potencjalne rozwiązania, mamy, rozumiemy potencjalnie te problemy użytkowników, co dalej powinniśmy zrobić? Co byście zrobili? Przetestować, ale co? I to jest mocne pytanie, nie? W sensie co powinniśmy przetestować, bo tych pomysłów możemy mieć całe masę. No właśnie, trzeba by jakoś spriorytetyzować. I teraz pytanie po czym będziemy priorytetyzować. I to jest właśnie problem, kiedy nie robimy sobie takiego drzewka, bo często mamy jakiś ten, czasem mamy ten cel, a czasem nawet go nie mamy. Potem mamy to rozwiązanie typu publikacja całego bota na przykład. I teraz pytanie, czy ta publikacja całego bota, ona rzeczywiście wpływa na ten impact, albo jak bardzo wpływa na ten cel, który my chcemy osiągnąć. Kiedy mamy tę rzecz pośrednią, to dużo łatwiej nam sobie często wyobrazić, jakby jak to może być duże. Teraz pytanie jak to się dowiedzieć jakby jak to jest duże, bo to znowu to się nie kończy nam research, bo możemy sobie sami powiedzieć okej, ten problem jest prawdopodobnie ważniejszy, ale na jakiej podstawie? Jeśli tutaj mamy zmniejszenie czasu na ten maintenance to prawdopodobnie powinniśmy się dowiedzieć jakby jak dużo czasu rzeczywiście ci ludzie na to poświęcają i jak dużo tych ludzi czy użytkowników jest, którzy to robią, bo multiplikacja tego da nam jakiś pewnie mniej więcej czas jaki oszczędzamy jeśli wprowadzimy, rozwiążemy ten konkretny problem. No i my to rzeczywiście zrobiliśmy, ale nie zrobiliśmy tego tak po prostu, dobra to teraz wymyślamy, chociaż też wiadomo, jeśli nie mamy czasu macie na discovery, to czasem się to tak robi, ale my to zrobiliśmy po prostu i ankietami, czyli ilościowo, żeby zobaczyć, czyli problem, kogo, jak dużo osób dotyka, a też robiliśmy takie specjalne badania, żeby przebadać jakby ile czasu coś zajmuje. I w ten sposób byliśmy w stanie sobie określić jakby jak potencjalny impact na nasz cel ma rozwiązanie konkretnego problemu. I co nam tutaj wyszło? O, trochę, trochę przyspieszyłem. Więc sobie zostańmy tutaj. I co nam tutaj wyszło? Dobra. Co nam tutaj wyszło? Wyszło nam, że na przykład to przenoszenie bota między środowiskami, jeśli to rozwiążemy, to rzeczywiście będzie miało bardzo duży wpływ na to, ile czasu zaoszczędzimy, ale wyszło nam też, że równie duży wpływ będzie miało to, jeśli pomożemy tym naszym testerom tych botów. a tu stąd z tymi projektantami botów no to wyszły nam też koszulkowo to sobie oceniliśmy. Tu jest jeśli ułatwimy im współpracę grupową to jest jakiś tam poziom M, czyli jakiś taki średni wpływ na ten impact. Jeśli publikowanie bota to będzie miało mały wpływ no bo to jest zaoszczędzienie kilkunastu, kilkudziesięciu kliknięć. No i teraz pytanie mamy sobie te szacunki, zrobiliśmy to na bazie jakiegoś researchu i właśnie jak to spriorzować. Co wy byście wybrali? Właśnie którymi byście się w pierwszej kolejności zajęli, jeśli macie tego typu informacje. Najmniejszym, okej. Czyli najmniejszym co? Najmniejszym rozwiązaniem, tak? Okej, czyli byś zaczęła od tego, tak? Publikacje, bo to dlaczego? Ale ma też mały wpływ. Okej, czyli tutaj, znaczy to chyba największym, czyli jakby ten trud miał największy wpływ na impact pewnie. Okej, możemy pójść w tą stronę. Ktoś inny pomysły? No właśnie, to jest pewnego rodzaju multiplikacja, nie? Zobaczcie, możemy mieć małe potencjalnie rozwiązania, które przenoszą trochę mniej wpływu. ale marzymy też duże potencjalne rozwiązania, które mogą mieć nie wiem, może trochę więcej wpływu, ale musimy bardzo dużo na to czasu poświęcić. I właśnie na tej podstawie możemy sobie wybrać potencjalnie, którymi rzeczami chcielibyśmy się zająć. My co my wybraliśmy? W tym kontekście wybraliśmy to rozwiązanie, a właściwie opportunity, za którymi chcemy podążać, mamy jakiś potencjalny pomysł, który chcemy realizować. W tym tutaj też sobie wybraliśmy, wybraliśmy to, mimo że to miało mniejszy. potencjalny wpływ na ten cel, mniej byśmy zaowszczędzili, ale tam widzieliśmy bardzo proste rozwiązania, które by od razu ten problem rozwiązały. Więc małym tak zwany low hanging fruit, bardzo małym effortem byśmy mogli trochę zyskać jakby. W tej trzeciej tutaj też sobie wybraliśmy, bo tutaj był duży potencjalny wpływ. Zaczęliśmy od tego, no bo było potencjalnie mniejszym rozwiązaniem. Tylko jakby na tym nasza praca się nie kończy, to nie jest tak, że powinniśmy teraz właśnie od razu usiąść i wdrażać sobie te rzeczy, tylko znowu jesteśmy w obszarze solution, czyli co robimy? Testujemy, tak jak powiedzieliście. Powinniśmy przetestować, czy te pomysły nasze na rozwiązania to są dobre pomysły, może się okaże, że nie. Albo, że to nie ten pomysł powinien rozwiązać ten problem użytkownika. Jak my to przetestowaliśmy? Jeśli chodzi o część tych rzeczy, to poprzedliśmy w realizację. bo po prostu one były do realizacji tak naprawdę. Były proste, wiedzieliśmy, że mają małe ryzyko. Możemy to spróbować przetestować, że tak powiem na produkcji, czy przyniesie odpowiedni rezultat niż robienie eksperymentów. Natomiast tutaj z tym dużym rozwiązaniem generowanie testów na podstawie historii rozmowy, wiedzieliśmy, że to będzie duże. Więc zrobiliśmy bardzo mały prototyp, taki skrypt w przeglądarce, który pozwalał jakby zasymulować to działanie, a sami byliśmy w stanie potem sprawdzić jakby jak dużo osób tego korzysta, czy wracają do tego, bo jeśli rzeczywiście rozwiąże im to problem, to będą do tego wracać, jak są osatysfakcjonowani. Jak zwrócicie uwagę, to dzięki temu też nam to pozwala trochę wybrać odpowiednie metryki i nie barwimy się w tę metrykę, że hej. to teraz będziemy tylko weryfikować, czy coś nam zmniejszyło koszty maintenanceu, bo tego się dowiemy tak bardzo często po kilku miesiącach i nie będziemy w stanie sterować naszą pracą na podstawie tych danych, bo skończymy sprint i co będziemy wiedzieli? Nic nie będziemy wiedzieli. To za kilka miesięcy będziemy wiedzieli, czy zmniejszyliśmy ten maintenance. Ale na przykład to, czy ktoś już z tego skryptu skorzystał, czy wrócił do tego skryptu, to będziemy wiedzieli już wcześniej, więc możemy sobie robić różnego rodzaju metryki na tym poziomie. No i to właśnie Opportunity Solution Tree może nam pomóc usługować tą pracę nad discovery i nad odkrywaniem tego, co powinniśmy gdzieś tam w tym naszym produkcie robić. To co też jest tutaj fajne, no to tak naprawdę możemy sobie wchodzić w głąb i tutaj na przykład jeśli robimy te wywiady możemy dorzucić linka i od razu to jest widoczne i możemy przejść od razu takiego, nie wiem, wyników na przykład tego badania jakiegoś czy do prowadzenia wywiadów. Możemy dorzucić jakiś przykład bardzo prosty, który pokazuje, że ten problem na przykład istnieje, żeby był bardziej obrazowy dla naszych interesariuszy. W taki sposób właśnie to Opportunity Solution Tree możemy dla konkretnej inicjatywy budować. Tylko bardzo krótko Wam chciałem pokazać inny też przykład, trochę niezgodny z książką, znaczy nie wiem czy niezgodny, w sumie trochę inny niż w książce podawany, do czego innego zastosowany. My na przykład też zaczęliśmy Opportunity Solution Tree używać do planowania bardzo długoterminowego strategii, gdzie mieliśmy jakieś bardzo wysokopoziomowe cele na górze. To jest realne jakby planowanie naszej strategii. Tu są Opportunity na rynku, na którymi my już potencjalnie chcemy gdzieś podążać. Nie schodziliśmy w ogóle już w którymś momencie do w ogóle etapu rozwiązań, tylko szacowaliśmy jak duże te poszczególne opportunity na rynku są, jaki może to przynieść jakby impact i decydowaliśmy o priorytety, ten rynek, na przykład ten obszar jakoś atakujemy, a do rozwiązań przechodziliśmy dopiero w dalszej części i zespół produktowy tak naprawdę pracował nad tym konkretnym opportunity'sem i sam wymyślał najlepsze rozwiązania do tego problemu. Także tak wygląda Opportunity Solution Tree. Przeszliśmy sobie przez właśnie ten case i ten drugi, który bardzo krótko Wam chciałem pokazać. Jeszcze tylko moje lekcje z tego Opportunity Solution Tree. Zacząłem z tego korzystać, bo teraz już staram się tam, gdzie mogę korzystać. No to po pierwsze bardzo fajna jest ta forma wizualna. To jest coś, czego mi brakowało, kiedy właśnie zaczynałem spisywać to w jakichś dokumentach, Jira, Confluenceach. Wizualnie dużo łatwiej się w tym odnaleźć, szczególnie jeśli chcemy poznać jakiś taki big picture. w planowaniu. Duży game changer to jest to, że teraz mamy mural, chciało się to robić kiedyś na kawałku papieru, no to nie da się zrobić zbliżenia, oddalenia i tak dalej, minomural super, nie? Wielkością możemy pracować i nie wiem, prezes, manager, ktokolwiek widzi z wysokiej perspektywy na przykład gdzie my teraz jesteśmy, a my chcemy zejść do, nie wiem, widoku jakby co robiłyśmy w badaniach, schodzimy coraz niżej jakby po prostu zmniejszając opportunity solution tree. Trzeba uważać na rozrastanie się, to się może mega rozrząć, żeby nas zawężał, ale jakby taki problem ja spotkałem, pewnie jeśli będziecie coś zastosować to też spotkacie, że to wam nagle trzeba na to uważać. Dokumentacja dalej jest potrzebna i repozytorium to nie jest tak, że to nam to zastąpi. Nie chcę jakby też, mimo że jestem product managerem, nie chcę zastąpiować UX researcherów. Super jeśli mam UX researcherów i oni mogą tą pracę wykonywać razem ze mną na przykład w jakimś product trio. gdzie możemy sobie, ja mogę mieć na przykład taki big picture tego jak w ogóle wygląda odkrywanie tego, w którą stronę z produktem powinniśmy iść. I ostatnie, no to nie jest jakiś święty graal, to jest tylko drzewko i sposób jakby prezentacji, wizualizacji, to nie rozwiąże waszych wszystkich problemów, ale właśnie wszystkich problemów, jeśli nie robicie, nie wiem, badm, nie rozmawiacie z użytkownikami, nie sprawdzacie jakby, nie robicie testów użyteczności, nie robicie eksperymentów testujących wasze pomysły, to jakby to nie pomoże samo z siebie, ale może trochę pchnąć organizm. Hej, my tak naprawdę trochę nie wiemy, czy mamy iść za tym opportunitiesem, czy za tym opportunitiesem. Czy to rozwiązanie jest lepsze od tego drugiego? Jakby może trochę sfacylitować to, a jeśli robicie te wszystkie rzeczy, no to mi na przykład bardzo mocno ustrukturyzowało pracę i taki sposób... myślenia. Też bardzo mocno przekonało np. zespół developerski do tego, bo na początku jak na to patrzyli mówią Tomek co ty w ogóle robisz, w sensie my nie chcemy na to patrzeć, a po chyba w jednym czy dwóch kartałach sami to otwierają i mówią kurczę przecież dlaczego my robimy to jak my jesteśmy tutaj w tym drzewku Opportunity Solution Tree i to powinniśmy np. robić. Albo przychodzi nie wiem prezes i mówi, że powinniśmy coś innego robić. deweloperzy sami zobacz, tu jest nasze Opportunity Solution Tree. My jesteśmy tutaj, badamy ten problem, w sensie jeśli chcemy robić coś innego to pytanie czy rzeczywiście to w ogóle wpasowuje się w cele filmy i w problemy, które chcemy rozwiązać. Więc to nie jest coś co jakby rozwiąże wasze wszystkie problemy, ale mi bardzo pomogło w strukturyzowaniu pracy nad Discover. I do tej jakby metody drzewka was chciałem zachęcić, polecam bardzo tą książkę. Jeśli macie jakieś pytania odnośnie Opportunity Solution Tree to zachęcam albo mojej prezentacji lub gejstwa. Może jeszcze parę pytań. Dziękujemy ślicznie. Kto chce zadać pytanie? Ja podejdę z mikrofonem. Cześć. Ja mam takie pytanie. Ile czasu trwał ten proces tworzenia jakby całego tego drzewka dla tego case'u, który przedstawiłeś? Bardzo krótko. W sensie to zależy od wielkości organizacji, ile chcemy na to poświęcać czasu, ale to od nas zależy, ile chcemy właśnie włożyć w to discovery czasu. Samo drzewko jakby... stworzyłem teraz w 10 minut tak naprawdę. Te badania, pytanie ile w to chcemy poświęcić czasu, wywiadów, nawet jakieś minimum by mnie jakby nie odrzucał, w sensie no musimy poznać tą perspektywę użytkownika, chyba że nie wiem, sami jesteśmy jakimiś hard userami, rzeczywiście trochę lepiej rozumiemy te problemy, ale to i tak jest droga zwykle donikąd. A pytanie ile chcemy poświęcać na testowanie zwykle jakby tych pomysłów na rozwiązania, tak jak tu pokazałem na przykład dwóch nie testowaliśmy wcale, zrobiliśmy po prostu, bo tam mieliśmy przynajmniej według naszej wiedzy, jak mieliśmy małe ryzyka związane z tym, czy jesteśmy w stanie to zbudować, jaki jest problem użytkownika wiedzieliśmy, jakie jest potencjalne rozwiązanie wiedzieliśmy, więc ryzyko tego i rozwiązanie samo było małe, więc jakby ryzyko wdrożenia tego było niskie. Woleliśmy to zrobić, niż moglibyśmy poświęcać jakiś czas na eksperymenty, ale pewnie czas poświęcony na te eksperymenty zajęły więcej niż eksperyment finalny, którym jest wdrożenie finalnej wersji. Natomiast jakby całość, no właśnie, to jest taka ważna, która była na początku, byśmy na to spędzili... prawdopodobnie od trzech do sześciu miesięcy, a osiągnęliśmy dużo większy efekt w trzy miesiące, w jeden kwartał, bo poszliśmy właśnie w te różne ścieżki, a sam ten problem rozwiązaliśmy w inny sposób, bo to był inny problem tak naprawdę. Czy jeszcze jakieś pytanka? Tu jeszcze tam jedno z tyłu. Cześć, mam takie pytanie. Jaki sposób badania użytkowników w tym przypadku przyjęliście, użytkowników waszego produktu? Znaczy prowadziliśmy wywiady, tak jak mówiłem, to byli użytkownicy. Ja miałem trochę łatwiejszy dostęp do użytkowników części, bo z samej platformy, zanim klient to wdrożył, znaczy klient to wdrażał u siebie, ale pierwszą wersję bota przygotowują... przygotowywali nasi bot designerzy, projektanci botów, klient to dopiero po pierwszej wersji przyjmowa, więc oni też miały jakby tych, którzy korzystają, użytkowników. Pierwsza wersja i tak powstawała u nas, więc ja miałem pewnych hard userów, do których miałem łatwy dostęp, ale z użytkownikami jakby klientów też jakby rozmawialiśmy. No bo tak jak mówiłem, to było wdrażane on-premise, więc to jest inna jakby środowisko, a klienci, jako że to są jakieś tam dane poufne i tak dalej, nie chcą się dzielić jakby żadnymi informacjami trochę jasnymi. Niestety mało mieliśmy danych ilościowych odnośnie zachowań użytkowników klienta. Tam dużo było, czyli wywiadami. Dobrze, ja idąc do kolejnego pytającego, zadam pytanie z czatów. Jakbyś jeszcze raz mógł powtórzyć tytuł autora książki. Teresa Torres. Cześć Tomku. Dzień dobry. Dzięki za taką fajną, plastyczną opowieść. Czy masz sposób... receptę na to rozrastanie drzew, bo ja akurat spotkałem się z tym problemem jako obserwator i nie mam jakby z pierwszej ręki praktyki, ale może może właśnie poradziłeś sobie w jakiś sposób z tym, że ono trzeba je scrollować w poprzek dosyć mocno. Ja nie mam jakieś wielkie recepty na to, też się z tym problemem jakby spotkałem, nie wiem, w sensie wiem, że wiele zespołów ma właśnie ten problem, dlatego go zaznaczam. Jednym z takich rzeczy, które my jakby robiliśmy, to jest po pierwsze jakby ważny jest ten cel u góry i powinniśmy zawężać do opportunitiesów, które rzeczywiście jeśli szacujemy jaki to może mieć wpływ na ten cel jakby nadrzędny, no to to nam trochę ogranicza w którą stronę w lewo i w prawo idziemy, bo jeśli widzimy, że zaczynamy myśleć o jakichś opportunitiesach, które jakby widać od razu, że mają mały potencjalny wpływ, mogą mieć, ale mały wpływ, a mamy całą masę innych, które mają duży wpływ, no to nie idźmy w tą stronę, jakby nie poświęcajmy na to. ale to też jest łatwo mówić tak teoretycznie. W praktyce to jest trudne, trzeba jakby trochę tak intuicjnie to gdzieś określić, to jest jedna. A druga, jeśli idziemy w stronę continuous, ja nigdy tak... 100% continuous nie miałem w stanie zrobić, bo nie miałem dedykowanego zespołu, kilku researcherów, którzy mogli nad tym pracować. Mieliśmy takie opportunity, na którym pracowaliśmy, ale nie było tak, że co tydzień prowadziliśmy po dziesiątki wywiadów. Natomiast to, co chciałem powiedzieć, to że trochę jak z backlogiem w dzirze, po prostu te, których nie używamy, usuwamy przynajmniej. I z których nie użyliśmy przez na przykład rok, to znaczy z jakiegoś powodu na razie to nie jest ważne. Jest obawa, że stracimy jakieś informacje. ale z drugiej strony namiar informacji też to powoduje, że tracimy informację, bo nie jesteśmy w stanie się w tym odnaleźć. Więc jakby cel, podsumowując cel i usuwanie jakby co jakiś czas starych rzeczy i to jedyna rzecz, którą ja gdzieś widziałem. Może być taka spoko opcja, to raz testowałem, żeby po prostu w pewnym momencie zacząć budować to drzewo od nowa, w sensie spróbować od zera jeszcze raz z tym nowym celem, który gdzieś tam mamy i trochę to wtedy jakby ukróca te pomysły, które... widzimy, że to nie ma jakby sensu, bo musimy wybrać i nie chcemy wszystkich przeglądać z poprzedniego drzewka. Spoko, dzięki metodą ogrodniczą. Przesadzamy i obcinamy. Dzięki. Okej, dziękujemy ślicznie. Ja dziękuję, tylko mam jeszcze książkę dla pierwszej pytającej. Proszę.

Tytuł prezentacji: "Jak zacząć z Opportunity Solution Tree? Moja praktyka i case studies" - Tomek Tomaszewski

"Opportunity Solution Tree to jedno z najlepszych narzędzi product discovery, które pomoże Ci ustrukturyzować pracę nad odkrywaniem tego co powinniście zbudować w Waszym produkcie. Przyjrzymy się najważniejszym założeniom tego narzędzia oraz opowiem, jak realnie wykorzystywałem go w praktyce."

Prezentacja miała miejsce 21.02.2024r.