Product Discovery

Wiele produktów nie odpowiada na żadną prawdziwą potrzebę klienta, albo odpowiada w sposób niesatysfakcjonujący i z tego powodu nie odnosi sukcesu biznesowego. By zmniejszyć ryzyko braku sukcesu naszego produktu, możemy zastosować podejście Product Discovery (odkrywanie produktu). Eksplorujemy ten nurt, formułujemy możliwe etapy do zrealizowania by dobrze odkryć produkt i podpowiadamy jak zacząć stosować te techniki.

Jak sprawić, aby tworzone produkty odpowiadały na prawdziwe potrzeby klienta? Jak wspomóc sukces biznesowy produktu, za który odpowiadasz? I w końcu czym jest Product Discovery i dlaczego warto wykorzystać to podejście w Twoim zespole.

Każdego roku powstaje ogrom produktów, jednak tylko nieliczne z nich odnoszą sukces biznesowy. Częstą przyczyną porażki jest nieprawidłowe podejście i brak ukierunkowania na prawdziwe potrzeby konsumentów. To ryzyko porażki produktu można zmniejszyć, stosując podejście Product Discovery, które omówimy w tym artykule.

Jak powstają „nieudane” produkty?

Poprzez produkt “nieudany” rozumiemy produkt, który jest po prostu niedopasowany do rynku. Nawet pomimo inwestycji w jego promocję, brak jest oczekiwanych efektów sprzedażowych. 

Tego typu produkty powstają zarówno w firmach, które pracują w sposób klasyczny, jak i w tych wykorzystujących techniki zwinne. Jednym z powodów takiego stanu rzeczy jest brak znajomości realnych potrzeb użytkowników. Może się nam wydawać, że jest na rynku przestrzeń na dany typ produktu, natomiast w momencie, gdy jest on gotowy i chcemy go udostępnić potencjalnym użytkownikom, to okazuje się, że problemy lub potrzeby, które chcieliśmy zaadresować tym produktem, nie występują. Innymi słowy, ludzie go nie potrzebują. 

O nieudanym produkcie mówimy również wtedy, gdy przygotowujemy błędne rozwiązania. Tu, w przeciwieństwie do wcześniejszego przykładu, dobrze rozumiemy, co jest problemem użytkowników, wiemy, jaka jest potrzebna na rynku, jednakże rozwiązanie, które dostarczamy, okazuje się niewłaściwe, np. nieintuicyjne, z dużym progiem wejścia, nie działa tak, jak oczekują tego użytkownicy. 

Posługując się mniej ogólnymi przykładami, to problemem mogą być dojazdy do pracy. Konsument, codziennie pokonuje długą drogę do pracy i jego potrzebą jest skrócenie czasu dojazdu. Chętnie więc kupi produkt, który zapewni mu teleportację. To jest jego prawdziwa potrzeba, jednak sugestia, aby skorzystał z autobusu, niekoniecznie będzie dla niego rozwiązaniem problemu i zaspokojeniem potrzeby szybkiego przemieszczania się. Autobus zatrzymuje się na wielu przystankach, a w dodatku może utknąć w korku. 

Przykładem rzeczywiście stworzonego rozwiązania, które nie spełnia dobrze swojej funkcji, są duże elektroniczne bilboardy na wjeździe do Poznania od strony Wrocławia. Wyświetlają one informacje o korkach, czasie oraz pokazują bardzo uproszczoną mapkę. Zapewne w zamyśle ich autorów było ułatwienie poruszania się po mieście, jednak w rzeczywistości ta mapka jest bardzo nieczytelna i dużo lepiej korzysta się z Google lub Apple Maps. 

Kolejnym powodem powstawania “nieudanych” produktów jest bardzo literalne rozumienie słowa “wymagania” i odbieranie go jako coś niezmiennego, nienegocjowalnego, obowiązkowego. W takim podejściu jakiekolwiek zmniejszenie zakresu nawet jeśli stoi za tym logiczne uzasadnienie, nie wchodzi w grę i powoduje poczucie, że powstałe rozwiązanie będzie niekompletne. A z doświadczenia wiemy, że zwykle jest przestrzeń na negocjowanie tzw. wymagań i jeśli są ku temu powody, zawsze warto takie rozmowy podjąć.

Product Discovery – podejście do tworzenia produktów

To, co może nas uchronić przed tworzeniem “nieudanych” produktów jest podejście Product Discovery, czyli odkrywanie produktu. Nie jest to jeden, z góry sprecyzowany proces, a bardziej filozofia działania, która kładzie nacisk na zrozumienie, co jest do zrealizowania przed podjęciem jakichkolwiek innych działań wytwórczych.

Przede wszystkim staramy się zrozumieć dla kogo to tworzymy, jaka to grupa ludzi, jakie ma potrzeby, czego jej potrzebuje. Innymi słowy, staramy się wejść w buty potencjalnego odbiorcy, aby mając jak najlepsze zrozumienie jego sytuacji, wejść w fazę developmentu.

Nie jest to niestety częste podejście w firmach produktowych, a fokus ukierunkowany jest głównie na dostarczanie czy to wymagań, czy konkretnego pomysłu. Rynek jest jednak bezlitosny i sam weryfikuje wszystkie inicjatywy.

Podkreślmy, że chodzi nam tutaj o rozwój produktu z perspektywy całego biznesu, bo wewnątrz samego IT od dawna zwraca się uwagę, aby najpierw rozpoznać, jakie są potrzeby, a dopiero potem projektować i realizować. W Product Discovery podobną filozofię przenosimy na poziom całego produktu, a nie tylko na aplikację czy stronę internetową, bo być może zauważony problem można rozwiązać w jeszcze inny sposób. Co więcej, ów problem należy jeszcze zweryfikować, bo może się okazać, że to jest tylko nasze wyobrażenie lub przeczucie i nikt nie zechce zapłacić za jego rozwiązanie.

Warto jeszcze wspomnieć, że o Product Discovery powinniśmy myśleć w kategoriach powtarzalnego procesu, a nie jednorazowej czynności. Jest to sposób na weryfikowanie naszych pomysłów w sposób ciągły, który prowadzony jest symultanicznie z procesem wytwarzania. Dopiero kiedy mamy zwalidowane te nasze pomysły i otrzymaliśmy z rynku informacje, że są one właściwe i potrzebne, to wtedy decydujemy się na przesunięcie tego do developmentu. 

Można spotkać się tu z pewną śmieszną dwoistością, przed którą chcemy Cię przestrzec. Z jednej strony, jak słucha się o błędach popełnionych przez inne firmy (np. wypuściły aplikację, która nic nie zmieniła i nikt z niej nie korzysta), to bardzo łatwo stwierdzić post factum, że było to oczywiste, że im się nie uda. Bez problemu dostrzegamy, że ktoś czegoś nie przemyślał, zwłaszcza jeśli przyzna, że źle myślał. Z drugiej strony, gdy sami jesteśmy zaangażowani w jakiś projekt, to trudniej nam dostrzec ten błąd, który okazał się błędnym rozwiązaniem w innej firmie. Pokazuje to, jak trudno jest oceniać coś perspektywistycznie i warto mieć ten fakt z tyłu głowy.

Etapy Product Discovery

Tak, jak wspomnieliśmy wcześniej, Product Discovery nie jest jasno zdefiniowanym procesem, w którym możemy wymienić konkretne kroki następujące jeden po drugim. Dlatego przedstawimy Ci po prostu potencjalnie możliwe etapy Product Discovery.

Przede wszystkim zaczęlibyśmy (“I etap”) od poszukania odpowiedzi na pytanie: dlaczego chcemy to zrobić? Dobrze do tego pasuje technika Golden Circle od Simona Sinek’a, czyli “Start with why”, gdzie pytaniem otwierającym wszelkiego rodzaju inicjatywy lub pozwalającym podjąć decyzje, jest pytanie: “dlaczego?”. Zaczynając od tego pytania i szukając odpowiedzi, co stoi za naszym pomysłem i decyzją, żeby zająć się tym konkretnym tematem, zaczynamy stopniowo określać wizję, coś, co będzie nam towarzyszyło w dalszej podróży z produktem. 

Przy tej eksploracji “dlaczego” często pojawia się wątek strategii tego, jaką firmą jesteśmy i jakie potrzeby zaspokajamy. No i najważniejsze, jak dobrze rozumiemy strategię tego, co robimy. Bez wiedzy na ten temat trudno będzie wejść w konkretną strategię tworzonego lub rozwijanego produktu.

Gdy mamy już strategię, znamy nasze “why” i mamy pewną wizję, w którą stronę idziemy, możemy zacząć zastanawiać się, jakie są możliwe rozwiązania. Pomocnym w tym etapie ćwiczeniem jest zaangażowanie zespołu do znalezienia, jak największej liczby sposobów rozwiązania problemu: Product Owner stoi po jednej stronie rzeki, po drugiej stronie jest produkt, który chce zdobyć. Jak może to osiągnąć? Pojawia się mnóstwo pomysłów. Takim najbardziej oczywistym rozwiązaniem jest zbudowanie mostu, które jest może i dobrym pomysłem, jednak wiemy, że istnieje szereg innych rozwiązań, które warto przemyśleć, poddać krytyce, może szybko jakoś je zwalidować, aby upewnić się, że to rozwiązanie, które wybierzemy, jest sensownie dopasowane do użytkowników i da oczekiwany rezultat.

Mając już wybrane konkretne rozwiązanie, kolejnym etapem jest stworzenie prototypu. Nie zaczynamy od razu realizować dostarczanie pełnego rozwiązania, tylko zastanawiamy się tu, jak najprościej i najtaniej możemy zwalidować nasze rozwiązanie.

W zrozumieniu tego czym może być prototyp i jak szybko go zbudować pomaga książka “Sprint: How to Solve Big Problems and Test New Ideas in Just 5 Days”. Prezentowane są w niej cykle tygodniowe, tzw. Design Sprint, w celu przejścia całego cyklu odkrywania produktu – od zrozumienia potrzeby do ostatniego dnia tygodnia, w którym mamy już gotowy prototyp i walidujemy go z użytkownikiem. 

Prototyp pomaga nam zweryfikować nasz pomysł z prawdziwymi użytkownikami i zebrać informację zwrotną już na bardzo wczesnym etapie. 

Za przykład niech posłuży prototyp systemu sterowanego głosem testowany przez IBM. Ludzie biorący udział w eksperymencie siadali przed komputerem i dostawali instrukcję, że: „Napisaliśmy system, który można sterować głosem, po prostu wejdź w interakcję z tym systemem”. Ludzie wydawali komendy głosowe, system reagował perfekcyjnie, a jednak na koniec tego testu ludzie mówili: „To nie jest tak użyteczne, jak możliwość korzystania z klawiatury i myszki”. W rzeczywistości po drugiej stronie siedział człowiek, który słuchał, co osoba biorąca udział w eksperymencie oczekuje od komputera, a następnie perfekcyjnie wykonywał te wszystkie czynności. Tak więc bardzo niskim kosztem i bez pisania systemu rozpoznawania mowy, hipoteza, że jest potrzeba na rynku produktu sterowanego głosem, została bardzo szybko zweryfikowana.

Gdy zweryfikujemy nasze pomysły i poddamy je testom z reprezentantami naszych potencjalnych użytkowników, możemy zacząć rozmawiać o konkretnych rozwiązaniach. Warto tu także zastanowić się, co jest nam tak naprawdę potrzebne w pierwszej iteracji produktu, czyli w takiej jego najprostszej formie. Na tym etapie dopiero możemy mówić o kształtowaniu się Backlogu Produktu i realizacji Sprintów, których efektem ma być implementacja tego rozwiązania.  

Jak w praktyce stosować podejście Product Discovery?

Naszą pierwszą sugestią jest rozpoczęcie wdrażania podejścia Product Discovery od małych kroków. Wszystko, co do tej pory opowiedzieliśmy, i to w dosyć dużym skrócie, to spory kawałek wiedzy i bardzo duża liczba rozmaitych technik, stąd próg wejścia może wydawać się nie do przeskoczenia. Nie musisz jednak zaczynać od implementacji wszystkich etapów, wystarczy, jak zaczniesz od skorzystania na początku z niektórych technik i stopniowo wdrażać kolejne.

Podzielimy się z Tobą naszym własnym przykładem. Przygotowując podcast, skorzystaliśmy z technik Product Discovery, jednak nie przechodziliśmy wszystkich wcześniej opisanych etapów. Zaczęliśmy od tego, co nas najbardziej interesowało i wybraliśmy to, czego najbardziej potrzebowaliśmy.

I to jest właśnie druga wskazówka: zacznij tam, gdzie chcesz i czujesz się dobrze. My przy starcie podcastu nie sformułowaliśmy jakoś szczegółowo strategii, mieliśmy też w miarę wykształconą wizję, z technik Product Discovery skorzystaliśmy przy rozmowie o tym, co jest dla nas takim absolutnym minimum, wartością, którą chcemy zwalidować. Celowo też nie kupowaliśmy na początku najlepszego sprzętu do nagrywania, tylko nagrywaliśmy na telefon.

Trzecią wskazówką jest traktowanie tych wszystkich technik jako pewne wytyczne. One przecież wciąż ewoluują, są wymienne i można je zastosować na różne sposoby. Powiemy więcej, stwórz swoje własne techniki na bazie tych już istniejących. Nie chodzi o to, aby sztywno trzymać się jakichś zasad, tylko dopasowywać je do własnych potrzeb i realiów pracy.

Warto też zadbać o kompetencje. Można zacząć od rozwoju samego siebie, jeśli oczywiście jest to obszar, który wydaje się nam atrakcyjny i mógłby wnieść wartość do firmy. Na rynku dostępnych jest ogrom książek, blogów czy różnego rodzaju eventów zorientowanych na budowanie produktów. My rekomendujemy wcześniej wspomnianą książkę “Sprint”, a także “Lean Startup” (Eric Ries) i “Inspired” (Marty Cagan). Bardzo ciekawy jest też newsletter Mind the Product.

Ostatnią radą, jaką dla Ciebie mamy podczas próby wykorzystania podejścia Product Discovery, to po prostu przygotowanie się. Jeśli jesteś Scrum Masterem albo Product Ownerem, który ma ochotę uczestniczyć w tym procesie, nawigować, facylitować, wprowadzić go do organizacji, to nie rób tego z marszu po przeczytaniu kilku artykułów. Wiele z technik Product Discovery to praca warsztatowa, grupowa, z bardzo konkretnymi instrukcjami do przekazania, być może z szablonami do przygotowania, z materiałami do wspólnej pracy kreatywnej. Jeśli się do tego odpowiednio nie przygotujemy i nie przemyślimy sobie, jak to przeprowadzić, to osoby, z którymi będziemy pracować, mogą czuć się niekomfortowo lub nie będą się w tym odnajdywały. 

I na sam koniec, jeśli słuchasz też naszego podcastu i skoro podzieliśmy się kilkoma  rzeczami z backstage powstawania podcastu, to chętnie też poznamy Twoją opinię na temat tego, jaki może być kolejny krok w rozwoju naszego produktu, jakim jest podcast. Co Twoim zdaniem jeszcze moglibyśmy poprawić czy rozbudować, żeby nasz produkt jeszcze bardziej odpowiadał na Twoją potrzebę?

Sprawdź też artykuł Jacka na Agile247, który również opisuje to, czym jest Product Discovery.

Jeśli materiał Ci się podobał, koniecznie podziel się nim z innymi osobami, które Twoim zdaniem mogą go potrzebować.

Dodatkowe materiały

• Marty Cagan „Inspired„
• Jake Knapp „Sprint„
• Eric Ries „Lean Startup„
• blog SVPG – Silicon Valley Product Group
• newsletter „Mind The Product„
• przykłady MVP z Jacka bloga

Transkrypcja podcastu „Product Discovery”

Kuba: W dzisiejszym odcinku poruszymy temat Product Discovery, zamiennie będziemy używać też słowa „Odkrywanie Produktu”. W ramach całego nagrania zaczniemy od tego, jaki problem często spotykają zespoły, które rozwijają produkty. Czy też – jakiego typu problemy. Opowiemy o tym, jak Product Discovery może być rozwiązaniem na ten temat, przedstawimy etapy podejścia Product Discovery i skończymy odcinek kilkoma podpowiedziami, jak zacząć lub jak wzmocnić pracę w ten sposób. Zanim przejdziemy do konkretu, obchodzimy tym odcinkiem mały jubileusz z Jackiem, siedzimy tu sobie w samochodzie pod szkołą, otwieramy umownego szampana, bo jest to dla nas już 10. odcinek, cieszymy się, że możemy być z Wami. Możliwe, że jeszcze w ramach tego docinka trochę nawiążemy do tego, jak proces powstawania podcastu w ramach tych ostatnich 10. odcinków się kształtował.

Jacek: Opowiemy dzisiaj konkretnie o tym i wokół tego będziemy się poruszać, jak radzić sobie z tworzeniem właściwych produktów. Problem, który bardzo łatwo można zauważyć i to właściwie w firmach, które zarówno pracują w sposób zwinny, jak i w firmach, które pracują w sposób klasyczny. Jest problem dostarczania błędnych produktów. Czy może inaczej mogłem powiedzieć – „nieudanych produktów”. To, że produkt jest nieudany czy że jest taki niedopasowany do rynku, zwykle oznacza po prostu, że zainwestowaliśmy w niego dużo pieniędzy (w przygotowanie, w stworzenie go, często też w promocję), natomiast efekty, które otrzymujemy na wyjściu, są niezadowalające. Mówiąc najprościej – najprawdopodobniej ten produkt nie przynosi spodziewanych efektów. I gdyby tak się zastanowić, co jest powodem tego, że powstają produkty, których na koniec dnia nikt nie używa bądź nikt nie kupuje, to taka pierwsza rzecz, która przychodzi mi do głowy, jest związana z tym, że często nie znamy realnych potrzeb użytkowników. Na takiej zasadzie, że wydaje nam się, że jest przestrzeń na rynku na pewne rozwiązanie, na pewien produkt, aplikację (w sumie nie ma to znaczenia, czy mówimy o produkcie fizycznym czy cyfrowym), natomiast w momencie, kiedy mamy ten produkt już stworzony i chcemy go udostępnić potencjalnym użytkownikom czy klientom, okazuje się, że te problemy, które rozwiązujemy bądź potrzeby, które chcieliśmy zaadresować produktem, one po prostu nie występują. W sensie, ludzie nie mają potrzeby, żeby używać naszego produktu do rozwiązywania swoich problemów.

Innym przypadkiem, kiedy mówimy o nieudanym produkcie jest przykład, kiedy przygotowujemy błędne rozwiązania. Na takiej zasadzie, że – w przeciwieństwie do tego pierwszego przykładu – rozumiemy dobrze, co jest problemem, doskonale czujemy, jaka jest potrzeba czy luka na rynku, natomiast rozwiązanie, które dostarczamy, okazuje się po prostu niewłaściwe. I ono może być niewłaściwe na wielu płaszczyznach. To rozwiązanie może być nieużywalne, nieintuicyjne, ze zbyt dużym progiem wejścia bądź może to być rozwiązanie, które nie spełnia jakichś oczekiwań odnośnie tego, jak działa. W sensie: jak szybko reaguje, np. na dotyk, czy jak szybko wyświetlają się jakieś konkretne informacje. Po prostu użytkownik korzystając z takiego produktu ma poczucie, że coś mocno z tym produktem nie gra i po prostu ostatecznie porzuca ten produkt, no i szuka alternatywnych rozwiązań.

Kuba: Pokusimy się o jakieś przykłady, żeby tak nie było ogólnie? Bo mi przychodzi do głowy problem związany z dojazdami – codziennie dojeżdżam dosyć długą drogę do pracy i tutaj moja potrzeba to jest: „szybko dostać się do pracy”, więc chętnie kupię produkt, który zapewni mi teleportację. To jest moja prawdziwa potrzeba, natomiast niekoniecznie rozwiązaniem mojej potrzeby będzie jakaś sugestia typu autobus, który będzie zbierał wszystkich moich sąsiadów i po kolei po kolejnych wioskach, aż w końcu nas dowiezie do Poznania – i superrozwiązanie potrzeby, tylko np. błędne, bo to będzie trwało dwie godziny i to niekoniecznie jest rozwiązaniem skutecznym na moją potrzebę.

Jacek: Bardzo podobny przykład, który mi przychodzi do głowy też motoryzacyjny – na wjeździe do Poznania w szczególności od strony Wrocławia wyświetlane są takie duże bilbordy elektroniczne z informacjami, gdzie są korki, z jakimiś czasami – tam jest też widok takiej bardzo uproszczonej mapy. Zakładam, że w zamyśle autorów chodziło o to, żeby ułatwić przemieszczanie się po mieście, natomiast z mojej perspektywy ta mapka jest nieczytelna, nic mi nie mówi i 10 razy bardziej wolę włączyć Google Maps czy mapy od Apple’a i tam po prostu mam to samo, tylko w superdopasowanej do mnie formie. W sensie: moja droga, którą ja pojadę w swoim tempie – wszystko ma ręce i nogi. Tak więc zakładam, że te bilbordy czy te tablice kosztowały dużo pieniędzy, ale…

Kuba: …i nadal kosztują, bo i prąd na to, żeby się dobrze wyświetlało, i tam jakiś maintenance pod spodem. „Świetna” robota.

Jacek: „Świetna” i nikomu niepotrzebna. Chyba że nie zrozumieliśmy intencji twórców.

Kuba: No, nie jesteśmy odbiorcami tego produktu.

Jacek: Myślę, że problem, który jeszcze dotyka tych nieudanych produktów, nieudanych rozwiązań, jest takie bardzo ltieralne – w szczególności w świecie produktów cyfrowych – podejście do słowa „wymagania”. Wymagania jako pojedyncze słowo czy często słyszę o „wymaganiach biznesowych”. „To są wymagania biznesowe, które musimy dostarczyć”. I w tym słowie mam takie poczucie, że to słowo determinuje taki odbiór, że te wymagania to jest coś, z czym nie możemy negocjować, więc jest takie naturalne założenie, że ktoś – często nawet nie wiemy dobrze kto – ale że ktoś te wymagania zebrał, przygotował, być może zwalidował. No i przyjmujemy, że to jest ta właściwa rzecz. W sensie: dokładnie te rzeczy w tym zakresie, często nawet bez możliwości negocjowania zakresu, bo często można usłyszeć odpowiedź: „To musi wejść w całości, bo tylko w całości ma sens. Jakiekolwiek pomniejszenie zakresu spowoduje, że to rozwiązanie będzie niekompletne/niefunkcjonalne”. Moje doświadczenie w pracy w środowisku IT – i to jeszcze te długo przed pracą w środowisku zwinnym – pokazuje, że zwykle jest przestrzeń na negocjowanie tzw. wymagań, natomiast przez tą konstrukcję tego słowa bardzo często mam wrażenie, że ta dyskusja po prostu się zamyka, ucina i to jest bardziej coś w stylu „Musimy to zrobić, bo takie są wymagania, bo tak ktoś od nas wymaga”.

Kuba: No i zahaczyłeś też o taki wątek, że ktoś z góry wie, co jest potrzebne, co jest oczekiwane, co jest wymagane, no i wiele produktów, które albo widziałem z boku w czasie rozwoju albo jestem jakoś tam wtajemniczony, jak ten produkt został stworzony – to jest po prostu gotowe rozwiązanie, do którego dopisano resztę uzasadnienia, czyli ktoś tam sobie wymyślił: „My też chcemy mieć serwis zakupów grupowych” i cała reszta już nie ma żadnego znaczenia. Nieważne czy to odpowiada na jakąś potrzebę, czy mamy pomysł na rozwiązanie – cała reszta nie ma znaczenia, bo ktoś sobie to wymyślił. I ten ktoś, to w różnych realiach mogą być różne osoby – członek zarządu, żona członka zarządu czy jakiś Product Manager, Product Owner – ktoś z zespołu wpadł na świetny pomysł, natomiast pomysł niestety nie był tak świetny, bo zaczynał się od bardzo konkretnego rozwiązania, które już kotwicuje się, betonuje nam w głowach konkretny kierunek i tylko jego już się trzymamy – nie wnikamy, czy to jest potrzebne, czy to jest dobre, czy to jest najlepsze rozwiązanie, czy ono jest wartościowe.

Jacek: Jak powiedziałeś o tych przykładach, to mi się skojarzyły automatycznie wszystkie te unijne aplikacje webowe, które za okrutne pieniądze były tworzone i gdzieś tam mignęło mi jakiś czas temu zestawienie, ile z tych inicjatyw przetrwało, no i wynik był druzgocący. Chyba więcej pożytku by było, gdybyśmy tymi pieniędzmi ogrzewali domy.

Kuba: Mówisz o portalach dla właścicieli psów i fryzjerów? [śmiech]

Jacek: Taak i portale organizujące wesela itd. W sensie: wierzę, że są na rynku gracze, którzy zrobili to dobrze i wierzę też, że podeszli do tego od innej strony niż: „Hmmm, a może tak zróbmy portal. Jaki można zrobić portal? No, pomagający zorganizować ślub”. Świetny pomysł.

Kuba: Myślę, że akurat ten system grantów unijnych tutaj nie ma nic wspólnego z realiami biznesowymi, a w realiach biznesowych w takim razie, jak takich problemów można uniknąć?

Jacek: Podejściem, które pomaga radzić sobie z problemem dostarczania niewłaściwych produktów albo – mówiąc z drugiej strony – podejściem, które pomaga tworzyć właściwe produkty, jest Product Discovery. Mówię o Product Discovery jako o podejściu, ponieważ nie jest to jakiś taki z góry określony, superdoprecyzowany proces, jeden jedyny istniejący, a raczej jest to pewna taka filozofia działania, mówiąc w uproszczony sposób, która kładzie nacisk na to, żebyśmy dobrze zrozumieli najpierw co jest do zrealizowania, zanim zaczniemy jakąkolwiek inicjatywę realizować. I tak patrząc na Product Discovery – i powiedziałbym, że to jest raczej kierunek czy sposób myślenia o budowaniu produktu, w którym zaczynamy przede wszystkim od tego, żeby zrozumieć, co chcemy wytworzyć, dla kogo, dla jakiej grupy, jakie ta grupa ma potrzeby, czego dzisiaj tej grupie brakuje – tak, żeby jak najbardziej wejść w buty potencjalnego użytkownika, i dopiero potem mając pełne zrozumienie dlaczego, co i jak – dopiero przechodzić do fazy developmentu. I generalnie moje obserwacje są takie, że to podejście to nie jest coś takiego domyślnego w firmach, które wytwarzają produkty. Tak, jak można powiedzieć, że podejście zwinne – najczęściej pod postacią Scruma – to jest dzisiaj niemal standard (oczywiście kompletnie inna rozmowa, jakiej jakości są te implementacje czy dojrzałość wykorzystania Scruma). Tak jeśli chodzi o to podejście takie produktowe, na zasadzie: „zwalidujmy w ogóle czy ten nasz pomysł na produkt/inicjatywę czy ma sens”, no to z moich doświadczeń jest to podejście, które jest rzadko stosowane i częściej firmy skupiają się po prostu na dostarczaniu – tak jak wspominałem – jakichś konkretnych wymagań albo tak jak ty podałeś w przykładzie – konkretnego pomysłu, kogoś – tu w sumie nawet nie ma znaczenia, kto jest autorem, tzn. w sensie: im wyżej umocowana tym osoba, tym oczywiście inicjatywa zyskuje na wartości – wewnątrz firmy. Natomiast nie ma to żadnego znaczenia. Rynek i tak jest bezlitosny i po prostu w brutalny sposób te wszystkie inicjatywy będzie weryfikował.

Kuba: To ja może dołożę jeden ważny akcent w tej twojej definicji, że chodzi nam tutaj o rozwój produktu z perspektywy całego biznesu, bo wewnątrz pracy IT, nawet już w takich czasach waterfallowych mówi się o tym, żeby rozpoznać, co jest potrzebne, żeby potem dopiero to projektować i realizować, natomiast podobną filozofię, która – ogólnie mówiąc – jest słuszna, przenosimy tutaj na poziom całego produktu, a nie tylko tą apkę – „to róbcie najpierw to, potem to”, tylko w ogóle „czy apkę?” – to pytanie sobie zadać, bo może problem da się rozwiązać jeszcze w ogóle innymi rozwiązaniami niż apka czy website.

Jacek: I jakby jeszcze głębiej schodząc, zweryfikować, czy jest problem.

Kuba: Tak.

Jacek: Bo często to, że jest problem, to też jest jakieś nasze wyobrażenie albo tylko przeczucie, albo my mamy taki problem. No i to niekoniecznie oznacza, że znajdzie się ileś tam innych osób, które będą gotowe zapłacić nam pieniądze. To, co warto powiedzieć też o podejściu Product Discovery, to jest to, że zwykle nie jest jednorazowa „akcja”. To nie jest jakaś jednorazowa czynność, że rozpoznajemy i następnie już wszystko wiemy. Raczej bliższe mi jest myślenie o Product Discovery, jako o takim pewnym powtarzalnym procesie, który w sposób symultaniczny jest prowadzony z procesem wytwarzania, czyli raczej myślę o Product Discovery jako o sposobie na weryfikowanie naszych pomysłów, opcji, domysłów, intuicji w sposób ciągły, no i dopiero kiedy mamy zwalidowane pewne pomysły, mamy potwierdzenie z rynku, że nasz pomysł jest właściwy czy rozwiązanie pewnego problemu jest właściwe – to dopiero wtedy decydujemy się na przesunięcie tego tematu do developmentu. Natomiast takie jednorazowe rozpoznanie i dalszy development – z moich doświadczeń – powoduje, że ta odkrywka, którą zrobiliśmy, zwykle jest niedostateczna i w procesie dalszego developmentu niestety zespół zaczyna wpadać w pętlę założeń, że: „No, w sumie już wiemy wszystko, więc po prostu róbmy”, co uważam, że jest podejściem błędnym.

Kuba: Ta historia bardzo mi przypomina pewien case z konferencji z zeszłego roku, gdzie opowiadał CEO czeskiej firmy, która zajmuje się drukarkami biurowymi, takimi systemami masowych wydruków, gdzie zaczynali od Scruma rozumianego jako „najpierw wymyślamy, co jest potrzebne, potem Zespół Scrumowy sobie iteruje, oni nam dostarczają produkt i go wdrażamy na rynek”. Natomiast gość mocno powiedział, że zwinność ich firmy to się dopiero zaczęła po tym, jak odkryli, że ta symultaniczność, o której powiedziałeś, musi istnieć, czyli: mamy pomysł, implementujemy go w postaci kodu, ale też sprawdzamy go na rynku, wyciągamy z tego wnioski i te wszystkie czynności są robione równolegle. Nawet nie jedna po drugiej, że w jakichś tam etapach robimy, myślimy, potem znowu robimy, potem znowu myślimy, tylko tak naprawdę i robimy, i myślimy, i walidujemy, i sprawdzamy, i jeszcze szukamy kolejnych głębi w tym, co dostajemy w postaci feedbacku ze strony klienta. Wszystko naprzemiennie i wszystko w bardzo krótkich cyklach. W sensie: ta długość cyklu od rozpoczęcia myślenia o produkcie, do wdrożenia, wyciągania kolejnych wniosków i kolejnego wdrożenia – to to są liczby, które warto zauważyć i zobaczyć, jak długo to trwa. Nie tylko, ile trwa kod od wymagania do wdrożenia na produkcję, ale też, ile trwa wymyślanie i jak szybko z tego wymyślania mamy zaspokojoną potrzebę klienta.

Jacek: Tutaj poruszyłeś w naturalny sposób też ważny aspekt. Ja zrozumiałem to, co powiedziałeś, w ten sposób, że: eksplorujemy, walidujemy, powstaje coś, jakieś rozwiązanie i my je dostarczamy, zbieramy informację zwrotną – to jest dla nas wsad do dalszej eksploracji. I to tak zwrócę na to uwagę, bo to, o czym mówisz, to jest takie przyrostowe czy też iteracyjne – można by podyskutować – podejście do wytwarzania produktu, ale, co ważne, to nie jest tak, że my rozpoznaliśmy potrzebę, mamy teraz taką wewnętrzną pewność: „To jest to” i następuje długa faza developmentu i na końcu wielkie wdrożenie, nawet jeśli ta faza developmentu była robiona np. Scrumem, no to właśnie straciliśmy tą podstawową możliwość inspekcji i adaptacji naszego produktu, no i dowiemy się wprawdzie, czy produkt „siądzie” na rynku, ale dowiemy się tego z bardzo dużym opóźnieniem.

Kuba: Natomiast używając tych przykładów, które już wymieniliśmy – zarówno z naszego życia osób dojeżdżających do centrum miasta, jak i z tych przykładów, które przywołałem przed chwilą, jedną rzecz, którą bym chciał przestrzec Ciebie, słuchaczu, to to, że jest taka śmieszna dwoistość, że z jednej strony, jak się słucha, że inne firmy zrobiły jakieś błędy (wypuściły apkę, która nic nie zmieniła; stworzyła portal, który nie przyniósł sukcesu biznesowego), to jest taka łatwość stwierdzenia post factum, po wszystkim, że oczywiste było to, że im się nie uda, natomiast ironią losu jest to, że jak osądzamy innych, to przychodzi nam łatwo dostrzeganie, że czegoś ktoś nie przemyślał – zwłaszcza jeśli przyzna się, że źle myślał – natomiast o wiele częściej sami jesteśmy w środku takich sytuacji, gdzie albo myślimy rozwiązaniem, albo nie rozpoznaliśmy potrzeby, albo wybraliśmy złe rozwiązanie na daną potrzebę. I o wiele trudniej jest się wybić z tych pułapek myślowych, gdy jesteśmy w środku, gdy jesteśmy zaangażowani – i u siebie samego nie zobaczymy tego błędu, który bez problemu dostrzegamy jako błędne rozwiązania innych firm.

Jacek: Zgadza się. No to trochę też pokazuje, że często poruszamy się w obszarach złożonych, no i łatwo jest nam oceniać coś retrospektywnie, a nie jesteśmy już tacy mądrzy, kiedy trzeba przewidzieć przyszłość. Tu mi się przypomina anegdota, że – w szczególności, jak ktoś się interesuje inwestowaniem i techniczną analizą wykorzystywaną do inwestowania – te wszystkie formacje, które można wyczytać z wykresów, one są oczywiste i tak pięknie je można sobie tam obserwować, patrząc na lewą stronę wykresu, natomiast kiedy przychodzi przewidywanie, jak i w co się układają ostatnie trzy dni i w co się ułożą w następnym tygodniu, no to niestety tutaj skuteczność jest słabsza, mówiąc delikatnie. No dobrze. Czyli powiedzieliśmy sobie trochę o problemie, trochę powiedzieliśmy o tym, czym jest Product Discovery i jakie problemy może nam rozwiązać, to myślę, że warto byłoby powiedzieć słowo na temat tego, z jakich etapów może składać się Product Discovery. I celowo mówię tutaj, że „może się” składać, ponieważ – tak, jak wspomniałem na początku – nie ma jasno zdefiniowanego procesu, krok po kroku, który by pokazywał, jak powinniśmy postępować. Raczej w moim odczuciu jest to pewna filozofia podejścia, którą można sobie… w te etapy, o których zaraz powiemy, można sobie wkładać narzędzia i też samodzielnie decydować, ile czasu, na który z tych etapów poświęcić. Więc takim pierwszym etapem, od którego bym zaczął, to był taki etap, kiedy w ogóle odpowiadamy sobie na pytanie: dlaczego robimy albo dlaczego chcemy zrobić konkretną rzecz. Bardzo mocno rezonuje ze mną ostatnio technika Golden Circle od Simona Sinka, czyli „Start with why”, gdzie tak naprawdę pytaniem otwierającym wszelkiego rodzaju inicjatywy czy pozwalającym nam podjąć decyzję, dlaczego chcemy się jakimś konkretnym zająć, jest pytanie: „dlaczego?”. I zaczynając od tego pytania, trochę też eksplorując, co stoi za naszym pomysłem, za decyzją, żeby się konkretnym tematem zająć, no, z tej rozmowy potrafią wypłynąć bardzo fajne wizje, potrafi wypłynąć fajny kierunek. Coś, co za chwilę będzie nam potrzebne, żeby było taką naszą latarnią morską, pokazującą nam, w którą stronę zmierzamy, no bo tak naprawdę bardzo często jesteśmy na etapie totalnej mgły. Nie do końca jeszcze wiemy, co konkretnie chcemy zrealizować, natomiast dostrzegamy jakąś potrzebę, dostrzegamy jakiś problem i wykonujemy kolejne kroki, które pozwolą nam zwalidować, czy te nasze odczucia faktycznie mają sens. Tak więc trochę o celu, trochę próba zrozumienia „dlaczego” – no, tak żeby z tego określić jakąś taką wizję, coś, co będzie nam towarzyszyło w dalszej podróży z produktem.

Kuba: Już na tym etapie określania strategii, gdy jestem  w tego typu ćwiczeniach czy fazach, często wraca wątek, że ta strategia – zapytanie o strategię  w kontekście danego produktu, danej inicjatywy czy danego projektu – często wiąże się z szerszym pytaniem: „Kurczę, ale jaką w ogóle mamy strategię? Jaką firmą jesteśmy? Jakie potrzeby zaspokajamy? Czym nasz produkt już jest i czym ma być?”. Często z tej rozmowy może wyjść wątek poboczny, jak dobrze rozumiemy strategię w ogóle tego, co robimy, jak organizacja, zespoły czy zespół. No i wtedy, jeśli tego nie wiemy, to strasznie też ciężko będzie wejść w konkretną strategię wewnątrz danego produktu, który dopiero zaczynamy budować lub produktu, który rozbudowujemy.

Jacek: Jasne. Ja myślę, że też świadomie nie będziemy w tym odcinku wchodzić w jakieś konkretne techniki. Jeżeli to, co mówimy, jest dla Ciebie, słuchaczu, interesujące, skontaktuj się z nami – chociażby zostawiając komentarz pod odcinkiem – i wtedy będziemy mogli przygotować odcinek bardziej skupiony na tym, jak konkretnie to robić, natomiast dzisiaj chcemy w ogóle zarysować problem i zachęcić do jego dalszej eksploracji. Czyli jak mamy już tę strategię, wiemy dlaczego, mamy pewną wizję, wiemy, w którą stronę idziemy, no to jest to moment, w którym możemy zacząć się zastanawiać, jakie są możliwe rozwiązania. To jest ten moment, kiedy rozumiejąc, jakie są potrzeby użytkowników i jakie mają oni problemy, powinniśmy stanąć przed pewnym wachlarzem dostępnych rozwiązań. Prowadząc warsztaty i szkolenia, w momencie, kiedy dotykam tematu właściciela produktu w Scrumie, bardzo często proponuję uczestnikom takie ćwiczenie: Product Owner chciałby zdobyć coś, co jest po drugiej stronie rzeki, ma jakąś potrzebę i proszę grupę, żeby zastanowiła się, jakie są możliwe sposoby rozwiązania tego problemu. I tam się pojawia oczywiście masa rozwiązań, co można zrobić, żeby ten produkt zdobyć i to ćwiczenie to jest taka kwintesencja tego, jak ja rozumiem proces eksplorowania rozwiązań. Czyli to takie najbardziej oczywiste rozwiązanie – zbudujmy most – być może to jest dobre rozwiązanie, ale istnieje szereg innych rozwiązań, które warto poddać przemyśleniu, krytyce, zastanowić się, być może szybko jakoś zwalidować, żeby upewnić się, że to rozwiązanie, które wybierzemy do naszego konkretnego problemu i potrzeb użytkowników, jest po prostu sensownie dopasowane. I to zarówno daje spodziewany rezultat, ale też jesteśmy w stanie je wykonać. Mamy takie możliwości kosztowe, czasowe. Mamy umiejętności, żeby takie rozwiązanie dostarczyć. Mając już wybrane konkretne rozwiązanie, kolejnych naturalnym etapem jest stworzenie pewnego prototypu. Na takiej zasadzie, że: to nie jest moment, w którym już rzucamy się na konkretne rozwiązanie – to docelowe, które chcemy dostarczyć – tylko zastanawiamy się, jak najprościej i najtaniej możemy zwalidować nasze rozwiązanie. Bardzo ciekawą lekturą, która pokazuje, czym może być prototyp i w jak szybkim czasie można takie prototypy budować, jest książka „Sprint” od Jake’a Knappa. Jest to książka od ludzi od Google Ventures, którzy wykorzystują takie cykle tygodniowe, tzw. design sprint, na to, żeby przejść przez cały cykl odkrywania produktu. W sensie: od zrozumienia potrzeby do ostatniego dnia tygodnia, w którym mamy już gotowy prototyp i walidujemy go z użytkownikiem. Tak więc ten prototyp to nie jest finalne rozwiązanie. To jest tylko coś, co pozwala nam się nauczyć, zdobyć wiedzę, no i zderzyć się też z tymi naszymi prawdziwymi użytkownikami, żeby otrzymać od nich informację zwrotną. Podejście takie pozwala nam zweryfikować pomysły na bardzo wczesnym etapie. Te prototypy to mogą być bardzo uproszczone fizyczne rozwiązania i np. pojawia się w książce przykład robota, gdzie użyto iPada, jakiegoś robota, który był stworzony z prostej aplikacji, która właściwie nie była aplikacją tylko była prezentacją zrobioną w Keynocie, czyli takim apple’owskim odpowiedniku PowerPointa. Czyli to wszystko to była taka fasada, za którą nie kryła się prawdziwa technologia i prawdziwe rozwiązania, ale była to dostatecznie dobra imitacja produktu końcowego, żeby pokazać to użytkownikom i zobaczyć, w jaki sposób oni reagują – akurat w tym przypadku, jak wchodzą w interakcję z tym robotem.

Kuba: Ja znam takie też przykłady – „Obiecujemy, ci, że pod spodem jest jakiś automat, jakaś sztuczna inteligencja”, a tak naprawdę pod spodem to w trzech z kumplami założycielami na razie robimy to ręcznie, ale jeśli się okaże, że ludzie kupują ten produkt, tzn., że go potrzebują i docelowo faktycznie mamy pomysł, jak go rozwiązać automatycznie.

Jacek: Tak. To z kolei przychodzi mi do głowy pomysł IBM – tak to zapamiętałem i tak to też pisałem na blogu – historia była taka, że IBM testował systemy sterowane głosem i ludzie biorący udział w tym eksperymencie siadali przed komputerem, dostawali instrukcję, że: „Napisaliśmy system, który można sterować głosem, po prostu wejdź w interakcję z tym systemem”. No i ludzie wydawali komendy głosowe, system reagował perfekcyjnie, jednak na koniec tego testu ludzie mówili: „To nie jest tak użyteczne, jak możliwość korzystania z klawiatury i myszki”. No i IBM to zweryfikował bardzo tanio, bo po drugiej stronie lustra, w tym pokoju, w którym testowali, po prostu siedział człowiek, który słuchał, co osoba biorąca udział w eksperymencie oczekuje od komputera, no i po prostu perfekcyjnie wykonywał te wszystkie czynności, tak więc bez pisania systemu rozpoznawania mowy, który dzisiaj w 2018 nawet nie działa dobrze, no i bez całej logiki stojącej pod spodem – superminimalnym kosztem ta hipoteza, że jest potrzeba na rynku produktu sterowanego głosem została bardzo szybko zweryfikowana.

Kuba: Powiedziałeś „osiemnasty”, na szczęście mamy dziewiętnasty, ale nadal rozwiązania te rozpoznawania głosu i sterowania nie są aż tak dobre.

Jacek: Dokładnie tak – jest tak, jak mówisz. Czyli, tutaj chwilę porozmawialiśmy o tym etapie weryfikacji pomysłów i dopiero tak naprawdę, kiedy zweryfikujemy nasze pomysły, poddamy je testowi użytkownika (reprezentacji naszych potencjalnych użytkowników), dopiero wtedy możemy zacząć rozmawiać o konkretnych rozwiązaniach i zastanawiać się w ogóle jaka część z tego wielkiego rozwiązania jest tak naprawdę nam potrzebna w pierwszym kroku, czyli to, co mówiłeś przed chwilą, do czego nawiązywałem – żeby ten nasz produkt też dostarczać od takiego superprostego produktu, przez trochę lepszy i trochę lepszy. Chcę zwrócić uwagę, że dopiero gdzieś na tym etapie tak naprawdę możemy mówić o kształtowaniu się Backlogu Produktu w takim rozumieniu scrumowym, gdzie zaczynamy realizować Sprinty, których efektem będzie implementacja tego rozwiązania, więc zwróć uwagę, ile wcześniej aktywności się odbyły, które odsiały w ogóle te wszystkie pomysły, opcje, hipotezy, inicjatywy od tego jednego konkretnego rozwiązania, które my będziemy implementować w superuproszczonej wersji, żeby to, co wytworzymy, poddawać jak najszybciej weryfikacji z klientem końcowym.

Kuba: Opowiedziałeś trochę o sposobie postępowania z produktem. On jest – już to powiedziałeś, ja też to powtórzę – wcale nie taki popularny, żeby to ująć delikatnie, a tak naprawdę to niezwykle rzadko widzę świadome postępowanie w ten sposób. To są jakieś tajemnicze przemyślenia na zarządach, wymyślania przez Product Managera, który pojechał na jakąś konferencję i się natchnął albo przeczytał TechCruncha i też mu coś przyszło do głowy – czyli raczej podejście, nazwę to, amatorskie, a nie tak poukładane, jak tutaj mówisz, że przechodzimy od strategii przez kolejne etapy rozpoznawania, aż po eksperymentowanie, prototypowanie, wyciąganie z tego wniosków. No to, załóżmy, że mnie przekonałeś i chcę tak postępować. Jak w praktyce zacząć? Może resztę odcinka poświęćmy na ten wątek, jak zastosować to podejście, jak go spróbować?

Jacek: No, pierwszą sugestią, która przychodzi mi do głowy, to jest sugestia, żeby zacząć małymi krokami. To, o czym powiedziałem – w dosyć dużym skrócie – to jest olbrzymi kawałek wiedzy, bardzo duża liczba technik, bardzo duża liczba publikacji, więc ten próg wejścia może się tak na pierwszy rzut oka wydawać, że to jest w ogóle coś takiego… magma nieogarnialna i trudna do uchwycenia, natomiast tutaj  bym rekomendował zacząć od małych kroków. Nie musimy zaczynać od implementacji wszystkich etapów. Nie musimy zaczynać od pierwszego etapu. Moim zdaniem – użycie pewnych technik, takich jak np. storymapping, które są z tych dalszych faz Product Discovery, już może być wartościowe, jeżeli oczywiście sensownie z tych technik skorzystamy i np. zaczniemy trochę eksplorować temat, czego my się spodziewamy jako rezultatu pracy nad produktem. Inny prosty przykład – bardzo łatwo jest użyć technik, które pomagają sformułować wizję. Tak jak wspomniałem – to może być „Start with why”, ale to może być Product Vision Board, tak więc na poziomie bardzo prostych poszczególnych technik obserwuję, że wprowadzając je do zespołów, który nigdy wcześniej tego nie stosowały, to nawet takie pojedyncze aktywności dają bardzo dużą wartość i totalnie zmieniają optykę zespołu na to, co jest produktem i dlaczego my się nim zajmujemy.

Kuba: I jest spora szansa, że ten mały krok zapoczątkuje kolejne, jeśli się okaże, że porozmawiamy o strategii i się okaże, że jeszcze nie mamy pełnego obrazu – albo odwrotnie, zrobimy storymapę i się okaże, że nie umiemy decydować, co jest tym naszym eksperymentem, jakie przyjmujemy założenia, które chcemy walidować, bo brakuje nam jakichś innych produktów z innych etapów, o których wspomniałeś. Ja zarysowałem we wprowadzeniu, że uchylimy trochę rąbka tajemnicy, jak powstaje podcast i tu też jest taki nasz osobisty przykład – przygotowując podcast skorzystaliśmy z technik Product Discovery, natomiast nie jest tak, że mamy rozbudowaną całą wielką mapę wszystkiego, co do tej pory wymieniłeś, ale zaczęliśmy sobie od tego, co nas najbardziej interesowało i wybraliśmy spośród całego arsenały Product Discovery to, co chcieliśmy i czego najbardziej potrzebowaliśmy.

Jacek: No i tutaj płynnie przechodzimy do drugiej sugestii – parafrazując to, co Kuba powiedział – zacznij tam, gdzie chcesz. Zacznij tam, gdzie czujesz się dobrze. My akurat – trzymając się tego przykładu – nie formułowaliśmy jakoś mocno strategii. Przez to, że znamy się długo i też często rozmawiamy, no to my już gdzieś tam wcześniej między wierszami mieliśmy w miarę wykształconą wizję, że obaj widzieliśmy podcast, natomiast z kolei tu, gdzie konkretnie skorzystaliśmy z technik Product Discovery, to była ta dyskusja na temat tego – z tego całego zakresu wytworzenia podcastu, co jest dla nas takim absolutnym minimum, wartością, którą chcemy zwalidować. No i my celowo nie poszliśmy w najlepszy mikrofon od początku, tylko nagrywaliśmy na telefonie. Jak ktoś wejdzie na naszą stronę porzadnyagile.pl, no to widzi, że naprawdę jest to surowa i prosta strona, która nie jest wybitnie rozbudowana.

Kuba: Na razie nie robiliśmy się jeszcze ostatecznego logo.

Jacek: Tak jest. I nie ma naszych zdjęć na stronie. Natomiast umówiliśmy się z Kubą, że to, co chcemy zwalidować, to jest ta wartość, którą dostarczamy, no i też w procesie dyskutowania o tym, co jest wartością, doszliśmy do wniosku, że tak naprawdę zwalidować, czy dostarcza nam wartość, tylko po prostu dostarczając tę wartość. Na zasadzie: dla nas wartością jest odcinek, treść, która płynie, no i dosyć mocno akcentowaliśmy w pierwszych odcinkach – nad to akcentujemy – prośby o informację zwrotną od słuchacza, żeby dostać sprzężenie zwrotne, czy te odcinki rezonują ze słuchaczami czy nie.

Kuba: Zaznaczyłeś też już – opowiadając o tym, że trudnością Product Discovery – jest to, że to jest pewien zbiór technik. One ewoluują, one są wymienne, można je zastosować na różne sposoby. To jest też taka moja rada, żeby dokładnie tak je traktować – jako pewne opcje, wytyczne. Niektórzy, gdy widzę, że próbują jakichś technik z tej rodziny – zaczynają je stosować bardzo „religijnie”, na zasadzie: „na szkoleniu dowiedziałem się, że persony to się buduje dokładnie tak, tutaj mam dokładny schemat, tu mam dokładny szablon, to trzeba wypełnić tak a tak, a to jest zabronione”. Ja poszedłbym w model: twórzmy sobie swoje własne techniki na bazie podanych technik. Czyli nawet jeśli uczestniczymy w jakimś warsztacie albo przeczytamy książkę czy zainspirujemy się jakimś wpisem na blogu czy stronie, to dopasowujmy sobie te techniki. Tutaj nie będzie błędem spróbowanie użycia tego po swojemu – zwłaszcza jeśli czegoś nie rozumiemy i czujemy, że coś jest nieadekwatne, to o wiele lepiej, żeby spróbować tego sposobu myślenia, a nie zablokować się, że: „kurczę, mamy narzędzie wewnętrzne, więc tutaj tak za bardzo rozpoznanie rynku nie może być zastosowane, bo gdzieś tam coś przeczytałem i to musimy zrobić inaczej”.

Jacek: Kolejna porada dotyczy tego, że warto zadbać o kompetencje. i myślę sobie tutaj na dwóch płaszczyznach, czyli: będąc w firmie, jeżeli czujemy, że jest to obszar, który wydaje nam się atrakcyjny albo że jest to obszar, który mógłby wnieść wartość do firmy, no to możemy zacząć po prostu od rozwoju samego siebie. Jak to można zrobić? Chociażby czytając książki, czytając blogi, uczestnicząc w spotkaniach społeczności zorientowanych na budowanie produktów i jeśli miałbym zarekomendować jakieś książki, od których warto zacząć, no to na pewno „Sprint”, o którym wspomnieliśmy, Jake Knapp, dodatkowo „Lean Startup” (Eric Ries) i „Inspired” od Marty Cagana. Blogi – nie mam tutaj jakichś konkretnych, tak myślę sobie, w głowie, ale na pewno…

Kuba: SVPG.

Jacek: Okej, tak. SVPG to jest blog m.in. Marty’ego – tam wydaje mi się, że trochę więcej osób pisze. Ale też nie konkretnie blog, ale np. newsletter „Mind the Product”. Bardzo często te artykuły, które rekomendują, po prostu dotyczą konkretnych technik Product Discovery. I jeśli myślę sobie o konferencjach, no to po prostu zachęciłbym do odfiltrowania konferencji takich bardziej produktowych niż typowo takich „agile’owych”, czyli bardziej jednak skupionych często na procesie.

Kuba: I ostatnią radą, jaką byśmy sugerowali w czasie próby wykorzystania kierunku czy podejścia Product Discovery, to przygotowanie się. Jeśli jesteś Scrum Masterem albo Product Ownerem, który ma ochotę uczestniczyć w tym procesie, nawigować, facylitować, wprowadzić go do organizacji, no to wiele prób może się bardzo prosto rozjechać przez to, że robimy to po prostu z marszu, na zasadzie: gdzieś tam przeczytaliśmy w 5 minut artykuł i próbujemy znienacka na Refinemencie zupełnie bez przygotowania to zrobić. Wiele z tych technik Product Discovery to jest praca warsztatowa, grupowa, z bardzo konkretnymi instrukcjami do przekazania, być może z szablonami do przygotowania, z materiałami do wspólnej pracy kreatywnej, no i tu akurat wychodzi jednak, że jeśli się do tego przygotujemy, przemyślimy sobie, być może w kilka osób się umówimy, jak takie ćwiczenie przeprowadzić, no to cała reszta grupy pracującej razem z nami, po pierwsze, będzie się czuła komfortowo, będzie się w tym odnajdywała i też skupimy się na tym, żeby fajnie pracować, a nie nagle się zorientujemy w połowie ćwiczenia, że nam się markery skończyły albo tablica nie odpowiada naszym potrzebom, w czasie, gdy wykonujemy tego typu ćwiczenia czy tego typu przemyślenia.

Jacek: W dzisiejszym odcinku mówiliśmy głównie o tym, co powoduje, że produkty, które tworzymy, nie są tymi właściwymi produktami, czemu nie odnoszą takiego sukcesu, jak byśmy się spodziewali. Powiedzieliśmy też, czym jest Product Discovery. Omówiliśmy, w skrócie, z jakich etapów może się składać i podzieliliśmy się naszymi doświadczeniami, jeśli chodzi o to, jak zacząć przygodę z Product Discovery w Twojej firmie.

Kuba: Skoro podzieliśmy się też kilkoma informacjami z tła na temat tego, jak powstaje podcast, to chętnie też poznamy Twoją opinię na temat tego, jaki może być kolejny krok w rozwoju naszego produktu, jakim jest podcast. Nie chcemy nic więcej sugerować – kilka rzeczy, których wiemy, że nam na razie brakuje, już wymieniliśmy, ale chętnie usłyszymy od Ciebie, czy przeczytamy – w zależności od sposobu, w jaki się z nami skontaktujesz – co Twoim zdaniem jeszcze moglibyśmy poprawić czy rozbudować, żeby nasz produkt jeszcze bardziej odpowiadał na Twoją potrzebę.

Jacek: Tymczasem, to będzie wszystko na dzisiaj. Dzięki, Kuba.

Kuba: Dzięki, Jacek.

Jacek: I do usłyszenia…

Kuba i Jacek: …wkrótce!