Uwaga: Ten artykuł to notatki z webinaru „Inside Out” organizowanego przez Dovetail. Wszystkie opisane tutaj metody, obserwacje i przemyślenia pochodzą od Teresy Torres – autorki książki „Continuous Discovery Habits” i doświadczonej product coach. Materiał powstał na podstawie jej wypowiedzi podczas rozmowy z przedstawicielami Dovetail.

TL;DR

Continuous discovery to trzy elementy: outcome (cel), opportunities (potrzeby klientów) i solutions (rozwiązania) – zespoły produktowe pracują nad nimi równolegle co tydzień
Wywiady co tydzień nie zastępują badań UX – to różne cele i metody, które się uzupełniają, a nie wykluczają
Story-based interviewing działa lepiej niż pytanie o opinie – „opowiedz o ostatnim razie gdy…” daje realne zachowania zamiast deklaracji
Testuj założenia, nie całe rozwiązania – zamiast prototypować cały produkt, rozbij go na małe, testowalne założenia
Pierwsza rozmowa z klientem > perfekcyjna rozmowa – lepiej rozmawiać z kimkolwiek niż czekać na idealnego uczestnika
Szybkość to warunek przetrwania discovery – organizacje wymagają tempa, więc trzeba dostarczać „crummy first drafts” i iterować
Nie potrzebujesz zgody CEO – zacznij od własnych nawyków, masz więcej kontroli nad procesem niż myślisz

Czym w ogóle jest continuous discovery?

Torres podchodzi do tematu bardzo pragmatycznie. Discovery potrafi być bałagan – pełen zakrętów, niespodzianek i zmian kierunku. Dlatego proponuje dodać strukturę do tego chaosu.

Według Torres continuous discovery opiera się na trzech filarach:

Outcome – dokąd zmierzamy jako zespół. Musi to być coś, co mierzy wpływ, nie tylko output. Nie „zbudujemy feature X”, ale „zwiększymy zaangażowanie użytkowników w sposób Y”
Opportunities – czego potrzebują klienci. Torres celowo używa szerszego określenia niż „problemy”. Obejmuje ono needs (potrzeby), pain points (bolączki) i desires (pragnienia). Nie każdy produkt rozwiązuje problem – czasem po prostu spełnia pragnienie. Torres przytacza osobisty przykład: jej rower górski nie rozwiązuje żadnego problemu, a wręcz można argumentować, że jazda po górach jest mniej bezpieczna niż ćwiczenia na siłowni. Mimo to kocha swój rower i nie odda go za nic – bo zaspokaja pragnienie, stając się częścią jej stylu życia
Solutions – jakie rozwiązania odpowiadają na te opportunities. Torres zauważa, że większość zespołów żyje w świecie rozwiązań. Prawdziwa siła leży jednak w dopasowaniu rozwiązania do opportunity

Co robi zespół praktykujący continuous discovery tydzień po tygodniu? Kilka wywiadów z klientami i dużo testowania założeń. Brzmi prosto, ale diabeł tkwi w szczegółach.

Dlaczego rozmawiać z klientami co tydzień?

Torres stawia sprawę jasno: zespoły produktowe nie mają czasu. Kiedy pojawia się pytanie badawcze, nie ma luksusu zatrzymania wszystkiego i rekrutacji uczestników. Inżynierowie czekają, spotkania roadmapowe się nie zatrzymają.

Stąd pomysł na rozmowę zawsze wpisaną w kalendarz – bez względu na wszystko, co tydzień. Daje to możliwość szybkich odpowiedzi na bieżące pytania.

Jest jednak jeszcze ważniejszy powód.

Torres dzieli się historią o pracownicy administracyjnej, która zapytała: „Teresa, jak umieszczasz te klikalne słowa w mailu?” Kobieta nie wiedziała, czym jest link. Nie wiedziała, jak go stworzyć.

Ci, którzy budują technologię, nie są normalni. To brutalna prawda. Spędzamy cały dzień z produktem, znamy go na wylot. W rezultacie łatwo zacząć zakładać, że klienci myślą tak samo. Regularne rozmowy to przypomnienie – oni nie używają czterech różnych przeglądarek, nie są zaznajomieni z generative AI, nie są jak my.

Co z customer support jako źródłem wiedzy?

Torres zauważa, że niektóre firmy każą wszystkim pracować w dziale wsparcia przez dzień lub tydzień przy onboardingu. To świetne, ale wsparcie techniczne to tylko jeden widok na klientów – i to klientów, którzy mają problem.

Support nie pokazuje szerszego kontekstu: jaki jest Twój cel? Co próbujesz osiągnąć? Jak nasz produkt wpisuje się w Twoje życie? Dlatego potrzebujemy regularnych rozmów, które wykraczają poza troubleshooting.

Czy badacze UX mogą pakować manatki?

Na LinkedInie może to wyglądać jak wrogie przejęcie. Torres jest w tej kwestii bardzo wyraźna i powtarza to kilkukrotnie podczas webinaru. Według niej continuous discovery nie zastępuje wykwalifikowanych badaczy wykonujących dobre badania.

Czego product team nigdy nie zrobi:

Longitudinal study – kto ma na to czas?
Porządnego pricing study – zbyt czasochłonne
Badań tego, co potencjalni klienci myślą o produktach konkurencji
Badań wymagających rygorystycznej metodologii naukowej

Torres zwraca uwagę na coś ważnego: nie każdy badacz chce uczyć product teams, jak robić wywiady. I nie musi – to właśnie dlatego ona uczy interviewing, żeby badacze mogli skupić się na tym, co robią najlepiej.

Rzeczywistość decyzji w biznesie

Torres stawia temat bardzo otwarcie. Jeśli pomyślimy o liczbie decyzji podejmowanych codziennie w firmie – nie tylko przez zespoły produktowe, ale też finance, marketing, sales, customer success – przytłaczająca większość jest podejmowana bez researchu.

Większość badaczy UX nie będzie argumentować, że powinniśmy aplikować research do 100% tych decyzji. Niektóre z nich są naprawdę ważne i powinniśmy poświęcić czas na dobry research.

Torres proponuje takie myślenie: robisz 100 decyzji. 80 z nich podejmujesz na czuja, bo tak działa biznes. Może 10 z nich można wesprzeć lekkim researchem przez nie-badaczy, a kolejne 10 wymaga dobrego researchu.

Co to daje? 10 więcej decyzji, które mają jakąś pętlę feedbacku. W tym tkwi prawdziwa siła tego podejścia.

Badacze nie znikają. Każda firma musi jednak zdecydować: ilu badaczy zatrudnić? Jaką rolę będą pełnić? Czy będą robili project-based research, czy może day-to-day discovery z zespołami?

Torres widzi szarą strefę i wiele możliwości. Badacze embedowani w zespołach robią codzienne discovery razem z PM-ami, designerami i inżynierami – to wspaniałe. Z kolei badacze wspierający wiele zespołów koncentrują się na projektach i najbardziej krytycznych pytaniach – też działa.

Kluczowa obserwacja: zawsze będzie więcej pytań badawczych niż badaczy, którzy mogą na nie odpowiedzieć. Dlatego inne role – jak product management – muszą wypełnić tę lukę.

Jaki jest cel każdego wywiadu?

Torres uczy zespoły jednego rodzaju wywiadu. To nie jest uniwersalne narzędzie badawcze – to konkretna metoda dla konkretnego celu.

Badacze UX potrafią zaprojektować różne rodzaje wywiadów pod różne pytania badawcze. To ich skill. Torres uczy product teams jednej rzeczy: jak nauczyć się kontekstu, w którym liczy się ich outcome.

Przykład: zespół w Netflix pracuje nad zwiększeniem viewing engagement. Pytanie brzmi: „Opowiedz mi o ostatnim razie, gdy oglądałeś Netflix.”

To nie jest rocket science. To sposób na zdobycie ekspozycji i budowanie banku wiedzy o tym, jak klienci używają produktu. Torres podkreśla: celem wywiadu jest budowanie empatii, nie znajdowanie wzorców. To nie jest projekt badawczy, gdzie trzeba rozmawiać z wieloma osobami i identyfikować tematy. To inwestycja – jak odkładanie pieniędzy do banku. Im więcej kontekstu mamy, tym lepsze decyzje podejmujemy.

Story-based interviewing – powiedz mi, co zrobiłeś

Torres nazywa siebie empirystką. Zespoły produktowe próbują zmieniać zachowania, więc muszą nauczyć się rzeczywistych zachowań.

Dlatego promuje story-based interviewing: „Opowiedz mi, co dokładnie zrobiłeś.” Jeśli można to sparować z „pokaż mi, co zrobiłeś” – jeszcze lepiej.

Co skupienie na zachowaniu daje zespołowi:

90% informacji potrzebnych do codziennych decyzji
Konkretne przykłady zamiast ogólników
Realne wzorce użycia produktu
Kontekst, w którym produkt jest używany

To co myślisz i co czujesz też ma znaczenie. Jednak dla zespołu produktowego, który potrzebuje odpowiedzi na małe, codzienne pytania, skupienie się na zachowaniu wystarcza.

Torres podkreśla: moglibyśmy wyciągnąć o wiele więcej wartości z tych wywiadów. Moglibyśmy wejść w sentiment analysis i więcej. Ona jednak próbuje sprawić, żeby product teams skupili się na tym, co najbardziej actionable: jaka jest potrzeba, którą mogę zaspokoić? Jaka bolączka? Jakie pragnienie?

Resztę – uczucia, sentyment, różnicę między tym co mówisz a co robisz, plany na przyszłość – można zostawić badaczom UX.

Podstawowe pytanie można dostosować do zespołu. Jeśli pracujesz w zespole search w Netflix: „Opowiedz o ostatnim razie, gdy wybierałeś nowy serial.” Zespół mobile: „Opowiedz o ostatnim razie, gdy oglądałeś Netflix w drodze.”

Rekrutacja – rozmawiaj z kimkolwiek, kto zechce

Torres ma kontrowersyjne podejście do pierwszego wywiadu: rozmawiaj z kimkolwiek, kto się zgodzi. Nawet z kimś z rodziny, kto pasuje do profilu klienta.

Dlaczego? Bo coś magicznego dzieje się przy pierwszym kontakcie z klientem. Ludzie myślą, że wiedzą o swoich klientach mnóstwo. Potem rozmawiają z pierwszym człowiekiem – i są zszokowani.

Jak myśleć o rekrutacji na różnych etapach:

Pierwszy wywiad: Kimkolwiek, kto się zgodzi. Przełam opór. Jeśli ta osoba okaże się dziwnym outlinerem, wyjdzie to w drugiej rozmowie.

Po kilku wywiadach: Zacznij myśleć o różnorodności. Czy rozmawiamy tylko z ludźmi z tego samego regionu? Tylko z super zaangażowanymi użytkownikami? Tylko z tymi, którzy sami podnoszą rękę?

Automatyzacja pomaga: Najczęstsza metoda to wbudowane w produkt pytanie „Czy masz 20 minut na rozmowę z nami?” Tak, są tu biasy – odpowiedzą tylko ci, którzy chcą. Torres zauważa jednak: w praktyce to nie jest tak duży problem, jak się wydaje. Ludzie, którzy się zgłaszają, są zazwyczaj dobrymi rozmówcami, a ich doświadczenia traktujemy jako indywidualne historie, nie jako prawdę uniwersalną.

Testowanie założeń zamiast całych pomysłów

Zbyt wiele zespołów myśli o testowaniu pomysłów w trybie projektowym: mamy pomysł, prototypujemy cały pomysł (designer robi całą robotę z góry), robimy długie usability studies i sprawdzamy, czy zbudowaliśmy właściwą rzecz.

Problem? Usability study nie testuje desirability, nie testuje viability ani feasibility, ani założeń etycznych.

Torres proponuje coś innego: pracuj z wieloma pomysłami jednocześnie, które rozwiązują tę samą potrzebę. Stwórz sytuację porównania, a potem rozbij każdy pomysł na założenia leżące u jego podstaw.

Dlaczego „założenia” zamiast „hipotezy”?

Torres używała wcześniej słowa „hipoteza”. Jeśli przeszukasz jej blog Product Talk, znajdziesz to słowo wielokrotnie. Przestała go jednak używać, pisząc książkę.

Dlaczego? Bo widziała to setki razy: prezentujesz research, ktoś się nie zgadza z wynikami. Co robi? Zaczyna krytykować metody. Nie rozmawiałeś z właściwymi ludźmi, nie rozmawiałeś z wystarczającą liczbą osób, zadałeś złe pytanie.

Nie wierzymy w research, z którym się nie zgadzamy. Każdy człowiek tak ma.

Kiedy używasz słów „eksperyment” i „hipoteza”, ustawiasz standard, że stosujesz metodę naukową. Robisz double-blind, randomized controlled studies. Otwierasz drzwi do „nie muszę wierzyć w to, czego się nauczyłeś, bo nie zrobiłeś tego poziomu eksperymentu.”

To nie jest cel assumption testingu. Nie dowodzisz niczego, nie jesteś naukowcem, nie masz czasu na prawdziwą naukę. Tak, metody mają znaczenie. Absolutnie, metody mają znaczenie. Jednak próbujesz zbierać sygnały: czy jesteśmy na właściwej ścieżce? Czy to rozwiązanie wygląda lepiej niż tamto?

Torres stara się nie używać słowa „hipoteza” w ogóle. Mówi o założeniach i próbuje zebrać jakieś dane o tym, czy to założenie wygląda na wadliwe czy nie. Nie dowodzi, nie obala, nie waliduje, nie invaliduje. Po prostu szuka dowodów, które mogą pomóc w podjęciu decyzji.

Torres podsumowuje: Kiedy mówimy o eksperymentach i hipotezach, zaczynamy słyszeć „nie podoba mi się Twoja metoda.” OK, ale dzisiaj podjąłeś 17 decyzji bez żadnych dowodów. Czy możemy porozmawiać o Twoich metodach?

Język ma znaczenie.

Przykład z Netflix i live sports

Zespół rozważa dodanie sportów na żywo. Jakie założenia się za tym kryją?

Nasi subskrybenci chcą oglądać sport
Chcą oglądać sport na naszej platformie
Rozumieją, że oferujemy sport
Wiedzą, jak znaleźć sport na platformie
Możemy stworzyć dobre viewing experience dla sportu

Torres dzieli się osobistą frustracją: jest fanką hokeja. Jeśli platforma pokazuje jej, o której godzinie mecz się skończył, psuje overtime. 90% platform sportowych to robi. Każde założenie to cegiełka – jeśli jedna jest wadliwa, całe rozwiązanie się zawali.

Wartość rozbijania rozwiązań na założenia: można testować szybko. Nie trzeba robić większości pracy designerskiej.

Chcesz wiedzieć, czy subskrybenci są fanami sportu? Wbuduj w produkt ankietę z jednym pytaniem:

Złe pytanie: „Czy oglądasz sport?” – każdy widział kiedyś jakieś wydarzenie sportowe, dostaniesz śmieciowe dane

Dobre pytanie: „Czy w ostatnim tygodniu oglądałeś wydarzenie sportowe?” – konkretne zachowanie w przeszłości z time boxingiem

Torres lubi „one-two punch”: zadaj jedno pytanie (zwiększa szansę na odpowiedź), ale jeśli ktoś odpowie „tak”, zadaj drugie: „Co to było?” Każ wypełnić to ręcznie. Teraz możesz ocenić, czy to wydarzenie sportowe jest relevantne dla Twojego planu – to bardziej kwalifikowane „tak”.

Takie pytanie w Netflix zajmie godzinę lub dwie. Nie trzeba prototypu, można ocenić, czy jest popyt na rozwiązanie.

Narzędzia do szybkiego testowania

Torres zauważa, że nie każdy ma dostęp do zaawansowanych narzędzi. Niektórzy mogą testować prototypy w swoich wywiadach – ale to wolne. Jeśli robisz jeden wywiad tygodniowo, nie chcesz czekać 10 tygodni, żeby zebrać wystarczająco odpowiedzi do testowania założeń.

Dlatego warto polegać na świetnych narzędziach, które mamy dziś do dyspozycji. Platformy do unmoderated testingu nie są idealne dla całych, złożonych rozwiązań z długimi zadaniami. Jednak jeśli pokażesz bardzo prosty prototyp i poprosisz o wyjaśnienie czegoś, możesz ocenić zrozumienie.

Torres podkreśla: jeśli dajesz micro task – Twoje wideo trwa 10 sekund i możesz ocenić wyniki o wiele szybciej. W tym tkwi siła mniejszych testów i prostszych zadań.

Dokumentacja – dwa poziomy syntezy

Torres uczy continuous synthesis na dwóch poziomach: indywidualnym wywiadzie i cross-interview.

Poziom 1: Indywidualny wywiad

Dla każdego story-based interview zespół rysuje historię – experience mapę tego, co się wydarzyło. Rysowanie pomaga zespołom nietrenowanym w syntezie zobaczyć kluczowe momenty: najpierw A, potem B, potem C.

Drugi krok: gdzie było tarcie w tej historii? Gdzie były niezaspokojone potrzeby, bolączki, pragnienia? Powstaje lista opportunities – specyficzna dla tego wywiadu.

Torres stworzyła interview snapshot template, który wygląda trochę jak persona template. Ostrzega jednak: nie chce, żeby nie-badacze tworzyli persony. Chce, żeby skupili się na „Rozmawiałem z Seanem. To jest historia Seana.”

Poziom 2: Cross-interview (co 3-4 wywiady)

Po zebraniu kilku wywiadów – Torres poleca po 3-4 – robią pierwszą rundę syntezy cross-interview. Tworzą wspólną experience mapę obejmującą wszystko, co usłyszeli, i wspólną listę opportunities, które trafiają na opportunity solution tree.

Robiąc to co 3-4 wywiady, nigdy nie muszą robić theme analysis ani affinity mapping. Nigdy nie tworzą research decku, bo nie mają głównego pytania badawczego. Po prostu rozumieją kontekst klientów – i to je napędza.

Różnica między typami map:

Torres jest precyzyjna w nazewnictwie, bo jak mówi: „mapping language is so messy”:

Typ mapy	Co pokazuje
Story map	Jak ktoś używa produktu
Customer journey map	Wszystkie touch pointy z całą firmą (produkt, success, sales)
Experience map	Kim jest Sean i co robi – niezależnie od produktu/firmy

Torres używa terminu „experience map”, żeby zespoły myślały szerzej niż „hej, spójrz na moje błyszczące rozwiązanie.” To nie o Twoje rozwiązanie – jesteśmy tu, żeby nauczyć się o kliencie.

Jak to wygląda w pierwszym miesiącu – tydzień po tygodniu

Torres daje bardzo konkretny timeline. Załóżmy, że jest początek kwartału, masz nowy outcome. Co teraz?

Tydzień 1: Skoncentruj maksymalnie dużo wywiadów na początku. Jeśli to zupełnie nowy outcome, zrób 3-4 wywiady w pierwszym tygodniu. Do końca tygodnia: pierwszy draft wspólnej experience mapy i pierwszy draft opportunity space.

Torres używa często frazy „crummy first draft”. Widzi, że zespoły się zapętlają, dlatego radzi: po prostu zrób słaby pierwszy draft. Będziesz do tego wracać co 3-4 tygodnie. To żywe dokumenty, które będą ewoluować. Do końca tygodnia: wybierz target opportunity i zacznij eksplorować rozwiązania.

To sprawia, że wielu ludzi jest niekomfortowo. „Ledwo coś wiemy!” Tak, ale w zeszłym kwartale po prostu budowaliście cokolwiek wymyśliliście, bez żadnego inputu.

Tydzień 2: Brainstorming pomysłów, story mapping, identyfikacja założeń, uruchomienie assumption testów. Dalej robisz wywiady – kolejny w tym tygodniu.

Dlaczego to musi iść tak szybko? Bo jeśli przez 3-4 tygodnie tylko przeprowadzasz wywiady i mapujesz opportunity space, a interesariusze pytają „Jak idzie kwartał?”, przez cały miesiąc odpowiadasz „Nie wiem jeszcze.” To nie przejdzie.

Torres jest brutalna: trzeba pushować w stronę rozwiązań. Prawdopodobnie wybierzesz złe target opportunity w tygodniu 2, prawdopodobnie zbadasz kiepskie rozwiązania, nie będziesz dobry w assumption testing.

Mimo to dalej jesteś lepszy niż w zeszłym kwartale, kiedy po prostu wyciągałeś rzeczy z głowy. Budujesz coś – prawdopodobnie złe rzeczy, ale przynajmniej budujesz. Możesz pokazać progress, masz co powiedzieć interesariuszom, którzy są zbyt skupieni na delivery.

Potem robisz to znowu. Dalej przeprowadzasz wywiady, więc uczysz się więcej o klientach. Uczysz się o więcej opportunities. Za drugim razem, gdy wybierasz target opportunity, będzie trochę lepiej.

Torres mówi wprost: musimy iść szybko, bo organizacja tego od nas wymaga. To prawda.

Kiedy zwalniamy, tracimy prawo do robienia jakiegokolwiek discovery. Wszyscy tracą – biznes, zespół, klienci. Trzeba iść szybko, żeby zarobić na prawo do dalszego discovery. Z każdym cyklem będzie lepiej – bank wiedzy urośnie, staniesz się lepszy w assumption testach, zakłady w Twoim bet backlogu będą coraz silniejsze.

Nie potrzebujesz zgody CEO – zacznij od siebie

Ktoś pyta Torres o promowanie kultury continuous discovery w organizacji.

Torres jest realistyczna: to wymaga wsparcia na poziomie C-level. CEO musi być on board do pewnego stopnia, potrzebny jest product executive, który będzie coachował zespoły, prawdopodobnie też design executive i engineering executive. To trudne.

Jednak Torres ma radę dla individual contributorów: przestań się martwić, jak działa cała organizacja.

Dzieli się osobistą historią: zmarnowała dużo czasu jako full-time employee martwiąc się, co robią wszyscy inni w organizacji. Mądrzej byłoby skupić się na tym, co ona robi.

Co możesz kontrolować już dziś:

Sposób, w jaki rozwiązujesz problemy
Czy rozmawiasz z klientami przed budowaniem
Jak testujesz swoje założenia
Czy masz outcome mindset

Ludzie nie doceniają, jak dużą mają kontrolę nad swoim sposobem pracy. Nawet jeśli dostają fixed roadmap z fixed dates, mogą robić całe discovery wokół rozwiązań. Mogą rozmawiać z klientami i sprawić, że rozwiązania są lepsze dla właściwych klientów.

Torres podsumowuje: łatwo się rozproszyć myślą, że nikt inny w organizacji tak nie pracuje, że aktywnie mówią, że nie możesz. Dużo z tego to sposób pracy, sposób myślenia, sposób podejścia do problem solving. My wszyscy możemy indywidualnie kontrolować, jak rozwiązujemy problemy.

Jeśli każdy PM, designer, software engineer i UX researcher zdecyduje się zacząć tak pracować jutro, organizacje zmienią się dużo szybciej niż myślimy.

Praca z wieloma pomysłami jednocześnie – jak uniknąć biasu

Torres widzi, że zespoły zakochują się w swoim pomyśle. Robią research szukając walidacji, że mieli rację, nie mają intellectual honesty, nie podchodzą do researchu z dobrego miejsca.

Jej rozwiązanie? Generuj 20 pomysłów.

Chce złamać fiksację na jednym dobrym pomyśle, chce dziesiątków dobrych pomysłów. Kiedy dochodzi się do tego poziomu, zespół przestaje myśleć „to był mój pomysł”, „to był twój pomysł”, „to musi być zrobione w ten sposób”.

Torres zauważa, że dużo biasu w researchu pochodzi z over-commitment. Zespoły hyper-fokusują się na pierwszym pomyśle, ona chce złamać ten over-commitment.

Designerzy to wiedzą – zawsze dostarczają wiele opcji, nie jedną. To ta sama idea co w decision making research: im więcej opcji rozważamy, tym lepszą decyzję podejmujemy.

Jak podejmować decyzje, gdy masz wyniki testów?

Torres zauważa, że to częste pytanie. Rozmawiałem z 5 klientami – czy ich feedback jest wystarczająco dobry? To jest trudne.

I to dlatego, że wpadamy w pułapkę testowania jednego pomysłu na raz. Pokazujesz prototyp, może ktoś go kocha, ale nie wiesz, czy naprawdę go użyje. Naprawdę ciężko jest ocenić „czy to wystarczająco dobre?”, gdy pracujesz z jednym pomysłem.

To jest część powodu, dlaczego ważne jest, żeby product teams porównywały i kontrastowały rozwiązania. Designerzy to wiedzą – każdy designer na świecie wie, żeby dostarczyć wiele opcji, nie tylko jedną.

Jeden ze sposobów na podejmowanie decyzji na bazie assumption testów: testuj założenia dla wielu pomysłów jednocześnie i oceniaj wyniki:

Wszystkie trzy pomysły są okropne – wyrzuć wszystko i zacznij od nowa
Wyniki są mętne, brak wyraźnego zwycięzcy – w książce Torres to znaczy, że pomysły są okropne, zacznij od nowa
Masz clear front runnera – jeden pomysł jest jakościowo lepszy, idź w tym kierunku

Torres kończy tę część pragmatycznie: uczymy się względnego feedbacku. Musimy porównywać i kontrastować. I nigdy nie usuniemy judgement z procesu – dalej musimy podejmować najlepszą decyzję z niedoskonałymi danymi.

Quick start: Twoje pierwsze dwa tygodnie

Jeśli chcesz zacząć jutro, to są jedyne rzeczy, które musisz zrobić:

Tydzień 1:

Zarezerwuj 3-4 sloty na wywiady (po 30 min każdy)
Wyślij zaproszenia do klientów z prostym pytaniem: „Czy masz 20 minut na rozmowę?”
W każdym wywiadzie zadaj jedno pytanie: „Opowiedz mi o ostatnim razie, gdy [zrobiłeś X związane z Twoim produktem]”
Po każdym wywiadzie narysuj prostą mapę: co zrobili najpierw, potem, na końcu
Zapisz 3-5 rzeczy, które Cię zaskoczyły

Tydzień 2:

Kolejny wywiad (to już nawyk)
Zbierz swoje mapy z tyg. 1 – co się powtarza?
Wybierz jeden problem do rozwiązania
Wymyśl 5-10 różnych sposobów jego rozwiązania (nie jeden!)
Zadaj sobie: „Co musi być prawdą, żeby to zadziałało?” – masz założenia do testowania

Nie potrzebujesz perfekcji. Potrzebujesz startu.

Kluczowy insight

Najpierw rozmowa, potem pytanie

Standardowo myślimy: Aby zacząć rozmawiać z klientami, musimy mieć jasno zdefiniowane pytanie badawcze, przygotowany prototyp lub konkretną hipotezę do sprawdzenia.

W praktyce okazuje się, że: Największą wartość przynoszą rozmowy, które zaczynamy bez żadnego celu poza zrozumieniem kontekstu klienta. To właśnie z tych otwartych, eksploracyjnych rozmów wyłaniają się najważniejsze pytania i problemy do rozwiązania.

Dlaczego to jest istotne: Czekanie na „idealny moment” lub „właściwe pytanie” prowadzi do paraliżu i podejmowania decyzji w oparciu o wewnętrzne domysły, a nie realną wiedzę. Największym ryzykiem jest nie rozmawianie wcale.

Test na jutro: Następnym razem gdy Twój zespół powie „nie mamy jeszcze nic do pokazania klientom”, zamiast odkładać rozmowę, umów jednego klienta na 20-minutowe spotkanie. Poproś go, by opowiedział historię o ostatnim razie, gdy używał Waszego produktu, i sprawdźcie, ile nieoczekiwanych problemów i możliwości odkryjecie bez żadnego scenariusza.

Polecane źródła

Podczas webinaru Torres wspomina:

Swoją książkę „Continuous Discovery Habits”
Książkę Marty’ego Kagana „Transform” (SVPG – Silicon Valley Product Group) – zawiera rozdział o tym, co musi być na miejscu dla udanej transformacji: wsparcie C-level, CEO on board, product executive coaching teams, design executive, engineering executive
Prace Davida Blanda w obszarze assumption testing

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Continuous discovery: A tactical deep dive with Teresa Torres

Tag: Experience Mapping

Continuous discovery w praktyce – jak rozmawiać z klientami co tydzień i nie zwariować #EN312