#010 – 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.

Zobacz wersję wideo

O czym usłyszysz w nagraniu?

  • 01:20 – Jak radzić sobie z tworzeniem właściwych produktów.
  • 04:18 – Przykłady nietrafionych produktów.
  • 09:16 – Anegdoty w temacie nieudanych rozwiązań.
  • 10:21 – O Product Discovery.
  • 20:20 – Z jakich etapów może się składać Product Discovery.
  • 32:46 – Jak spróbować podejścia Product Discovery.

Materiały i techniki, o których m.in. wspominamy w nagraniu:

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

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

Daj nam znać co sądzisz o samym odcinku:

Chcemy usprawniać podcast z każdym kolejnym odcinkiem, więc podpowiedz nam, jakie kolejne aspekty naszego produktu możemy rozwinąć, a których obecnie Tobie brakuje.

Mamy sporo pomysłów na to, co jeszcze moglibyśmy nagrać, ale jesteśmy bardzo otwarci na Twoją sugestię – przekaż nam hasło albo temat, o którym moglibyśmy opowiadać w kolejnych odcinkach.

Transkrypcja odcinka

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óią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 te 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!


5 Replies to “#010 – Product Discovery”

  1. Iwona

    Jacku i Kubo,
    bardzo Wam dziękuję za wszystkie podcasty. Wszystkie z wielką przyjemnością odsłuchałam. Jestem na samym początku współpracy ze Scrumem 😉 na razie nie jest mi dane pracować w zespole Scrumowym. Codziennie poświęcam 4-5h na wnikanie w ten temat. Powiedzmy wiedzę teoretyczną na poziomie średnim już posiadam i brak mi doświadczenia, a jak wiemy Scrum opiera się na doświadczeniu. Dlatego jako ćwiczenie dla mnie, chce pomóc mężowi w efektywniejszym zarządzaniu dużym sklepem (nie będę pisać nazwy – wiadomo reklama). Struktura jest taka, że jest dyrektorem, ma 9 kierowników, każdy kierownik ma swój zespół pracujący na powierzchni sprzedaży. Oczywiście pierwszym krokiem będzie wprowadzenie tablicy scrumowej z karteczkami dla każdego działu. Każdy kierownik będzie jakby PO, który ustala elementy do wykonania. Tylko jest problem w codziennym Scrumie, bo praca jest zmianowa i nie ma fizycznej możliwości, aby wszyscy mogli zebrać się w jednym miejscu. Sprinty np. raz na tydzień też odpadają, ponieważ nie może być sytuacji takiej, że nie ma ani jednego pracownika na dziale :/ Myślałam o retrospektywie – każdy pracownik może na tablicy przykleić karteczkę z problemem. Ale to nadal nie będzie rozmowa face to face i wszyscy na raz. Aby nie okazało się, że anonimowo ludzie będą na siebie najeżdżać.
    Chłopaki jesteście dla mnie guru w tym temacie. Możecie rzucić hasła, jakby ugryźć ten temat? Macie większe doświadczenie, może jakaś hybryda z innym podejściem agile’owym?
    Dziękuję Wam jeszcze raz za te podcasty!
    Życzę wszystkim developerom pracy w PRAWDZIWYM zwinnym podejściu, a nie tylko z nazwy 😉

    • Jacek Wieczorek

      Cześć Iwona,

      Cieszy nas, że odsłuchałaś dostępne odcinki. Taka informacja jest dla nas budująca 🙂

      Temat, który opisujesz, brzmi ciekawie.

      Żeby lepiej zrozumieć temat który opisujesz, potrzebowałbym zrozumieć, jaki problem chcielibyście rozwiązać / jaki cel osiągnąć?

      Mam pewne przemyślenia czytając to, co piszesz, jednak bez zrozumienia kontekstu, trudno mi coś więcej napisać.

      Pozdrawiam,
      Jacek

  2. Ewa

    Dzień dobry Panowie. Super odcinek. Słucham Was od jakiegoś czasu i jestem pod mega wrażeniem. Dziś wracam do odcinka o Product Discovery. Jako analityk biznesowy chętnie posłucham szerzej o Product Discovery. Czy planujecie takie odcinki?

  3. Łukasz

    Cześć Jacku i Kubo,
    Bardzo podobają mi się wasze podcasty, śledzę każdy odcinek na bieżąco 🙂
    Przyłączam się również do prośby o rozwinięcie wątku pracy nad odkrywaniem produktu.

    Wróciłem dzisiaj do tego odcinka, ponieważ szukam możliwości wykorzystania podejścia Product Discovery tworząc produkt w zespole mocno rozproszonym po świecie (Klient i PO – UK ; SM, Dev, Test – Polska + Argentyna + Indie). Może znacie jakieś techniki, które rekomendowalibyście w takiej sytuacji? Od czego zacząć? A może znacie jakąś książkę/artykuł, gdzie można poczytać o sposobach pracy przy odkrywaniu produktu w zespołach rozproszonych?

    Ogólnie chętnie posłuchałbym o sposobach pracy zwinnej w zespołach rozproszonych po świecie. np. jak radzić sobie z wyzwaniami realizacji w sposób zwinny zarówno nowych produktów jak i rozwijaniem istniejących od wielu lat, w jaki sposób budować zespołowość, zaufanie, usprawniać produkt i proces itp.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń Podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial