Od frustracji do zrozumienia: jak user researcher nauczyła się Jobs-to-be-Done #EN358

Nota redakcyjna: Ten artykuł stanowi zbiór notatek z webinaru JTBD Untangled, który odbył się w grudniu 2024 roku. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od prowadzących (Jim Callback i Elaine Matthias z Jobs to Be Done Toolkit) oraz głównej gościni – Nikki Anderson, qualitative user researcher i konsultantki. Prezentowane podejścia i metody odzwierciedlają ich praktyczne doświadczenia w implementacji frameworka Jobs-to-be-Done.

TL;DR

Anderson po raz pierwszy zetknęła się z JTBD w 2017-2018 i początkowo czuła się przytłoczona abstrakcyjnością frameworka
W pierwszym case study popełniła błąd tworzenia zbyt szerokich need statements niemożliwych do wdrożenia
Kluczowa lekcja: lepiej zacząć wąsko i rozszerzać zakres, niż próbować zawężać zbyt szeroki projekt
Niektóre deliverables okazały się nieprzydatne (switch timeline, four forces), inne dostarczyły wartości (personas, journey maps)
W B2B kluczowa jest triangulacja danych: qual + quant + customer support + account management
Research musi być dostosowany do priorytetów biznesowych – user-centricity generuje przychody tylko gdy skupia się na właściwych rzeczach
AI może wspierać research, jednak nie zastępuje ludzkiego osądu i peripheral vision z bezpośrednich rozmów

Wprowadzenie

W grudniu 2024 roku gościnią webinaru JTBD Untangled była Nikki Anderson – user researcher z 11-letnim doświadczeniem, specjalizująca się w jakościowych badaniach UX. Do zawodu trafiła w nietypowy sposób: odkryła research dopiero gdy uświadomiła sobie, że projektowanie zupełnie jej nie wychodzi. Z ulgą odkryła, że istnieje osobna dyscyplina, całkowicie oddzielona od tworzenia czegokolwiek wizualnie estetycznego.

Anderson budowała swoją karierę zarówno w Stanach Zjednoczonych, jak i w Niemczech. Obecnie mieszka na wyspie Jersey – tej oryginalnej, położonej u wybrzeży Francji, nie nowojorskiej. Prowadzi tam konsultacje i advisory dla startupów, zarówno realizując projekty badawcze, jak i pomagając w budowaniu procesów research. Środowisko startupowe przyciąga ją możliwością szybkiego działania oraz brakiem nadmiernej biurokracji i polityki korporacyjnej.

Podczas rozmowy z Jim Callback i Elaine Matthias z Jobs to Be Done Toolkit Anderson podzieliła się swoją podróżą z frameworkiem Jobs-to-be-Done – od początkowej frustracji, przez konkretne błędy w pierwszym projekcie, aż po praktyczne lekcje dla zespołów badawczych.

1. Czym jest discovery research

Zanim przejdziemy do JTBD, warto zrozumieć fundamenty podejścia Anderson do badań. Według niej discovery research polega na rozumieniu umysłów i modeli mentalnych ludzi, w odróżnieniu od ewaluacji konkretnych rozwiązań. Metody badawcze dzieli na dwa główne rodzaje: generatywne/discovery oraz ewaluacyjne/usability.

Discovery oznacza generowanie nowego zrozumienia. Może być bardzo otwarte (rozumienie ludzi w danej przestrzeni) lub wąskie (głębsze poznanie konkretnego tematu w określonych okolicznościach). Wspólny mianownik stanowi praca z ludźmi lub odkrywanie informacji o ich myśleniu i procesach mentalnych, bez narzucania konkretnego rozwiązania do oceny.

Anderson w swojej praktyce opiera się głównie na wywiadach jeden na jeden, contextual inquiry oraz diary studies. Czasem stosuje również card sorting, pod warunkiem że ćwiczenie ma charakter bardzo otwarty. Wszystko co pozwala odkrywać i pracować z informacjami od ludzi o ich myśleniu, mieści się w tym paradygmacie badawczym.

2. Pierwsza próba z Jobs-to-be-Done: od chaosu do struktury

Jak to się zaczęło

Po raz pierwszy Anderson zetknęła się z JTBD w latach 2017-2018. Inicjatywa nie wyszła od niej – jeden z product managerów pojawił się z wymaganiem: „musimy zrobić Jobs-to-be-Done, bo wszyscy to robią”. Jej pierwsza reakcja była paniczna. Zaczęła czytać wszystko co dostępne – od słynnego case study o milkshake z „Competing Against Luck” Claytona Christensena po inne publikacje o JTBD. Paradoksalnie, im więcej czytała, tym większy był chaos w jej głowie.

Początkowa frustracja

Największym problemem okazała się abstrakcyjność frameworka. Anderson wprost przyznaje, że go znienawidziła, ponieważ nie rozumiała. Wielokrotnie rysowała koncepty na tablicy, kasowała je i zaczynała od nowa. Nie mogła pojąć, co dokładnie ma osiągnąć i jak przełożyć to na konkretne działania. Podobnie jak wielu innych researchers, czuła presję interesariuszy, którzy chcieli „wyłuskać joby”, nie rozumiejąc do końca czym one są i po co je identyfikować. Product manager mówił o „odkrywaniu jobów”, ona odpowiadała bezradnym pytaniem.

Co pomogło

Przełomem okazała się lektura „Jobs to Be Done Playbook” autorstwa Jima Callback. Dopiero ta książka nadała frameworkowi konkretny kształt i uczyniła go możliwym do zastosowania w praktyce.

3. Case study: From A to B – badanie użytkowników platformy travel

Kontekst projektu

Anderson pracowała w niemieckim startupie From A to B – aggregatorze transportu umożliwiającym porównanie różnych opcji podróży (pociąg, autobus, samolot, samochód) i rezerwację biletu. Firma już nie istnieje, dlatego Anderson może swobodnie dzielić się szczegółami projektu.

Product manager i jej bezpośredni przełożony przyszli z prośbą o głębsze zrozumienie „jobów” wykonywanych przez użytkowników. Prawdziwym problemem było to, że zespół w ogóle nie rozumiał, dlaczego ludzie korzystają z platformy i jakie mają potrzeby. To był idealny moment na zastosowanie JTBD.

Decyzje dotyczące zakresu

Anderson podjęła kluczową decyzję o zawężeniu zakresu badania. Zamiast próbować objąć wszystkich użytkowników platformy, wybrała trzy konkretne ograniczenia:

Leisure travel (podróże rekreacyjne, nie biznesowe)
Non-families (pary lub osoby solo)
Booking process (sam proces rezerwacji, bez etapu po dokonaniu zakupu)

Jej uzasadnienie było proste: niemożliwe jest zrozumienie wszystkich osób rezerwujących podróże oraz całego procesu travel naraz. To po prostu zbyt szeroki zakres jak na pojedynczy projekt badawczy.

Dlaczego zawężanie ma sens

Anderson dzieli się praktyczną zasadą wypracowaną przez lata: lepiej zacząć z wąskim zakresem i stopniowo go rozszerzać, niż próbować retrospektywnie zawężać zbyt szeroki zakres. Używa prostej metafory ze spotkań: lepiej zaplanować 30-minutowe spotkanie i zakończyć je po 20 minutach, niż zaplanować je na 30 minut i ciągnąć 45. Wszyscy cenią czas zwrócony, nikt nie lubi zostawać dłużej.

Jim Callback dodaje ważną obserwację: innowacja często działa lepiej w wąskim zakresie. Zbyt szerokie podejście prowadzi do sytuacji, w której ludzie wychodzą z warsztatów z głowami pełnymi pomysłów, jednak bez jasności co dalej robić. Abstrakcyjna wizja wielkiej zmiany przytłacza i paraliżuje. Wszyscy po prostu chcą wiedzieć: gdzie jest ticket w backlogu?

4. Co poszło nie tak: błędy w pierwszej implementacji JTBD

Need statements zbyt szerokie

Anderson otwarcie przyznaje, że jej need statements były zbyt ogólne. Po pierwszej rundzie zespół musiał rozbić je na bardziej szczegółowe elementy.

Przykładem takiego zbyt szerokiego sformułowania jest: „Zwiększ prawdopodobieństwo zarezerwowania najlepszej opcji podróży dla danej destynacji”. Taki zapis może znaczyć wiele różnych rzeczy. Product manager czy designer patrząc na taką potrzebę nie wie, co z tym zrobić – nie da się tego przełożyć na funkcje, wymagania czy wireframe’y.

Podobnie było z kolejnym przykładem: „Zmniejsz ryzyko wystąpienia problemu podczas podróży”. Anderson żartuje, że gdyby zespół faktycznie to zrealizował, firma prawdopodobnie nie zbankrutowałaby. Pokazuje to, jak odległy od konkretnego działania był ten need statement.

Kluczowy punkt: mimo że badanie było już zawężone do solo/couple leisure trips i fokusowało się tylko na procesie bookingu, zespół mógł pójść jeszcze głębiej w konkretyzacji potrzeb. Nawet przy tym zawężeniu need statements wyszły zbyt ogólne i ostatecznie wymagały dalszego rozbicia na elementy actionable.

Niepotrzebne deliverables

Podczas projektu Anderson stworzyła switch timeline oraz four forces diagram. Retrospektywnie ocenia je jako nieprzydatne. Zespół skupiał się na zrozumieniu procesu, który przechodzą użytkownicy, nie na push/pull forces. Dlatego te narzędzia po prostu nie pasowały do celu badania.

Co nie zadziałało vs. co zadziałało:

Nie zadziałało:

Switch timeline (niepasujący do celu badania)
Four forces diagram (zespół skupiał się na procesie, nie na push/pull forces)
Opportunity Gap Survey oparty na mglistych need statements

Zadziałało:

Personas (wartościowe dla interesariuszy, stworzone z informacjami których faktycznie potrzebowali)
Journey maps (pomocne w podejmowaniu decyzji)

Problem z Opportunity Gap Survey

Anderson zastosowała Opportunity Gap Survey, który bada różnicę między ważnością a satysfakcją z danej potrzeby. Problem? Skoro need statements były zbyt ogólne, survey po prostu priorytetyzował ogólne rzeczy. Zasada garbage in, garbage out zadziałała w pełni.

Anderson przypomina, że w Jobs-to-be-Done łatwo o przytłoczenie liczbą możliwych deliverables, a interesariusze uwielbiają deliverables. Dlatego warto skupić się wyłącznie na tym, co faktycznie pomoże w podejmowaniu decyzji.

Jej rada dotycząca person: nie należy ślepo używać gotowych szablonów. Szablony mogą służyć jako punkt wyjścia, jednak persony należy tworzyć z interesariuszami, używając informacji których faktycznie potrzebują do swoich decyzji.

5. Praktyczne lekcje dla user researchers

Checklist: Jak uniknąć błędów Anderson w implementacji JTBD

Przed startem projektu:

Czy JTBD to właściwa metoda na ten konkretny problem?
Czy masz dostęp do wystarczającej liczby uczestników badania?
Czy interesariusze rozumieją, czego naprawdę chcą się dowiedzieć?
Czy zakres badania jest wystarczająco wąski?

Podczas definiowania zakresu:

Czy wybrany segment jest dostosowany do strategicznych priorytetów biznesu?
Czy potrafisz jasno określić, kto jest job performerem?
Czy fokus jest na jednym produkcie/procesie, nie na wszystkim naraz?

Przy tworzeniu deliverables:

Czy need statements są na tyle konkretne, że product manager/designer wie, co z nimi zrobić?
Czy wybrane deliverables faktycznie pomogą interesariuszom podejmować decyzje?
Test decyzyjności: czy na tej podstawie mogę stworzyć ticket w backlogu?

Po zakończeniu badania:

Czy triangulowałeś dane z różnych źródeł (qual + quant + customer support)?
Czy pokazałeś ryzyko NIErobienia czegoś na podstawie research?

Kiedy JTBD to właściwa metoda?

Anderson podkreśla wagę weryfikacji, czy Jobs-to-be-Done to właściwa metoda na dany problem. Callback często pyta swoich klientów wprost: „Dlaczego chcecie Jobs-to-be-Done?” Framework ma pewien „efekt połysku” i ludzie rzucają go na wszystko, podobnie jak w latach 90. usability testing był odpowiedzią na każdy problem badawczy.

Anderson wymienia sytuacje, w których JTBD było właściwe dla jej zespołu: głębokie zrozumienie potrzeb użytkowników (zespół nie rozumiał dlaczego ludzie w ogóle korzystają z platformy), mapowanie procesów i mental models oraz identyfikacja miejsc do innowacji i poprawy.

Jednak ostrzega: jeśli nie ma dostępu do wystarczającej liczby uczestników badania, nie warto forsować metodologii. Każde podejście wymaga dopasowania do kontekstu organizacji.

Anderson wspomina też o buzzwordach w research. Podobnie jak continuous discovery, JTBD stał się terminem który ludzie rzucają bez pełnego zrozumienia. Ludzie szukają skrótów, ponieważ są ograniczeni czasowo. Chcą zrozumieć te wielkie koncepty w kontekście tego, co może im pomóc robić rzeczy lepiej i ostatecznie – co może pomóc im w uznaniu, awansie czy bezpieczeństwie zatrudnienia.

Problem polega na tym, że koncepty te są źle rozumiane i mylone. User research nie ma standardowego playbooku ani kursu certyfikacyjnego jak inne zawody. Dlatego gdy ktoś słyszy „Spotify robi Jobs-to-be-Done”, myśli „musimy robić dokładnie tak jak oni”. Anderson wspomina analogię do IDEO design thinking process – organizacje chciały replikować dokładnie ten sam proces, mimo że nie pasował do ich kontekstu.

Segmentacja: demografia vs. desired outcomes

Podczas sesji Q&A pojawia się pytanie: co zrobić gdy ta sama potrzeba dotyczy różnych grup demograficznych?

Anderson odpowiada pragmatycznie: używa obu podejść jednocześnie. Segmentacja wyłącznie po potrzebach brzmi pięknie w teorii, jednak w praktyce często nie wiadomo jakie są potrzeby, zanim nie porozmawia się z ludźmi. A żeby z nimi porozmawiać, potrzebne są jakieś kryteria rekrutacji.

W projekcie B2B Anderson segmentowała po roli, wielkości firmy oraz ogólnych potrzebach znanych z account management. Dopiero później, po wywiadach, odkryła że dwie podobne role faktycznie mają różne potrzeby i wymagają osobnej analizy.

Radzi też priorytetyzację: jeśli starsze i młodsze grupy mają podobne potrzeby, należy wybrać tę która jest bardziej strategiczna dla biznesu. To trudne pytanie, jednak trzeba je zadać w kontekście priorytetów biznesowych.

Dostosowanie do priorytetów biznesowych

Callback wprowadza metaforę Venn diagram: co ważne dla użytkowników × co ważne dla organizacji.

Anderson rozbudowuje tę myśl: bycie user-centric generalnie generuje przychody, jednak trzeba upewnić się że jesteśmy user-centric wobec najbardziej priorytetowych rzeczy. Bez zarabiania firmy nie będzie pracy dla researchers – to brutalna, ale uczciwa prawda.

Kiedy Anderson pracuje z mniejszymi firmami, radzi znalezienie segmentów przynoszących największe przychody i rozpoczęcie od nich. To punkt w którym user-centricity spotyka się z business reality.

6. JTBD w kontekście B2B SaaS

Case Hugo: jak badać użytkowników produktów SaaS

Hugo, uczestnik webinaru, pracuje dla platformy e-commerce B2B (biżuteria, diamenty). Przez długi czas research był taktyczny i CEO-driven. Po otrzymaniu fundingu firma przechodzi do strategic research. Designerzy mówią wprost: lecimy na ślepo, jak mamy monetyzować SaaS skoro nie wiemy kto go używa?

Hugo planuje wykorzystać JTBD do zmapowania kontekstu, potrzeb, głównych i powiązanych jobów, a na końcu stworzyć persony oraz opportunity gap analysis.

Framework triangulacji danych w B2B

Anderson, która uwielbia B2B SaaS research, dzieli się konkretnym frameworkiem podejścia:

KROK 1: Zawęź zakres

Jeden produkt SaaS (nie wszystkie naraz)
Jeden job performer (np. sales manager w dużych firmach LUB owner/director w SME)
Jeden proces lub część platformy (jeśli cały produkt to za dużo)

KROK 2: Priorytetyzuj strategicznie

Który produkt przynosi najwięcej przychodów?
Który job performer jest kluczowy dla biznesu?
Zacznij od high-value segments

KROK 3: Zbierz dane wtórne (przed wywiadami)

Dane quantitative o użytkownikach (usage-based, nie demograficzne)
Customer support tickets (jakie problemy zgłaszają?)
Account management insights (co mówią customer success teams?)
Usage data z platformy

KROK 4: Trianguluj w wywiadach

Prowadź wywiady jakościowe, jednak już z kontekstem
Pytaj o top pain points w ich roli (nie hipotezy o przyszłości)
Fokus na konkretnych częściach platformy, nie całości

KROK 5: Iteruj i rozszerzaj

Po pierwszym cyklu możesz rozszerzyć na kolejne segmenty
Lub zagłębić się w inne części produktu

Anderson podkreśla kluczowy punkt: nienawidzi wchodzić na wywiady bez żadnego zrozumienia z kim rozmawia, ponieważ wtedy bardzo trudno się skupić na tym co faktycznie powinno być tematem rozmowy. Jeśli nie zna potrzeb, zaczyna od krótkiego quant survey z pytaniami usage-based, nie demograficznymi.

Radzi też Hugo, żeby nie próbował objąć wszystkich produktów SaaS naraz i nie zakładał że jeden „SaaS user persona” wystarczy. Różne produkty mają różnych job performers. Należy wybrać produkt który przynosi najwięcej przychodów, zidentyfikować konkretnego job performera i dopiero wtedy zagłębiać się w szczegóły.

Anderson dzieli się też praktycznym przykładem z własnego doświadczenia: w B2B SaaS platformie pracowała z prawie czterema różnymi stream’ami. Zamiast próbować objąć wszystko naraz, skupiła się na dwóch stream’ach które dobrze ze sobą współpracowały. To pozwoliło zachować focus i dostarczyć actionable insights.

7. Rola AI w user research

AI jako praktykant, nie mędrzec

Gdy Callback żartobliwie pyta czy AI nie zastąpi wywiadów z ludźmi, Anderson odpowiada zdecydowanie: nie.

Niedawno prowadziła badanie z AI-moderated interviews – meta-projekt badający jak researchers czują się wobec AI, używając AI do prowadzenia wywiadów. Wkrótce publikuje raport z tego projektu.

Jej główna zasada: należy traktować AI jak praktykanta, nie jak mądrego doradcę. AI nie ma mądrości. To echo chamber. Jeśli szuka się czegoś konkretnego, AI powie dokładnie to czego się szuka. Problem w tym, że nie jest wystarczająco inteligentne żeby powiedzieć o tym czego się nie szuka.

Anderson dzieli się osobistym przykładem. Złamała palec u nogi i zapytała ChatGPT o plan rehabilitacji. AI jednocześnie ją gaslightowało, kłamało i mówiło że wszystko robi dobrze. Palec nadal ją boli i całkowicie przejął jej życie, mimo że to był tylko mały pęknięcie. Doktor nie był zbyt pomocny, więc sięgnęła po AI – to był błąd.

Kluczowy punkt: jeśli nie ma się peripheral vision z prawdziwych wywiadów, jak można sprawdzić czy AI generuje sensowne rzeczy? Callback dodaje: robienie wywiadów daje sensibility potrzebną do oceny co jest prawdziwe, a co nie. Bez tego kontekstu jest się ślepym.

Anderson, mimo że jest introwertyczką, uważa że wywiady twarzą w twarz są niezbędne dla uchwycenia niuansów. AI może wspierać w pewnych zadaniach, jednak nie może zastąpić ludzkiego kontaktu. Poza tym – co ironiczne – AI często dodaje więcej pracy niż oszczędza. Trzeba włożyć dane, sprawdzić je, promptować w różny sposób, i w końcu zadać sobie pytanie: dlaczego nie zrobiłam tego po prostu w sposób który już znam i który działa?

Anderson podkreśla też że research community narzeka na product managers i interesariuszy którzy robią założenia o userach bez rozmowy z nimi. Mówią: nie możemy zakładać że znamy naszego usera, nie możemy zakładać że skoro raz podróżowaliśmy to znamy wszystkie potrzeby podróżnych, musimy rozmawiać z ludźmi. A teraz to samo robią z AI – to po prostu wrapped in AI assumption-making.

8. Feature factory: jak nie stać się wąskim gardłem

Wolfram zadaje pytanie które rezonuje z wieloma researchers: co robić gdy funkcja jest już we wdrażaniu, a nie jest jasne jaki problem rozwiązuje?

Anderson odpowiada z doświadczenia: to dzieje się cały czas. Firmy często mają feature factory mentality – musimy to wypuścić, musimy to zrobić, musimy dodać AI do produktu – bez głębokiego zrozumienia jaki problem próbują rozwiązać.

Strategia „nie blokuj, wspieraj”

Kluczowa rada Anderson: nigdy nie próbuj ich zatrzymać. W momencie gdy stajesz się wąskim gardłem w czymkolwiek, wszyscy cię nienawidzą. Wtedy nikt nie chce cię już ciągnąć do żadnych projektów, ponieważ jesteś osobą która powiedziała nie, to nie jest dobry pomysł – nawet jeśli miałeś rację.

Nawet mając rację, staje się osobą której wszyscy unikają. Zamiast tego Anderson radzi:

Jeśli możesz, wyprzedź plan działania:

Porozmawiaj z zespołem o tym co jest planowane
Nawet bez czasu na pełne user research, zbierz secondary research
Pracuj z data analytics team, przejrzyj customer reviews, customer support tickets
W przypadku B2B, porozmawiaj z account management
Daj zespołowi dane żeby mogli zacząć myśleć: na podstawie tego co teraz wiemy, co faktycznie próbujemy osiągnąć?

Anderson podkreśla: co można zrobić żeby faktycznie wspierać wdrażanie i powiedzieć: hej, zebrałam te dane, wiem że ta funkcja idzie do produkcji, ale może jest inny kąt z którego moglibyśmy na to spojrzeć żeby dalej rozwijać to w świetny sposób.

Ustaw success metrics:

Upewnij się że po wdrożeniu funkcji zespół będzie patrzeć na dane
Czy za miesiąc sprawdzimy usage data?
Czy feature adoption rate jest taki jak zakładano?
Anderson wie że to nie jest rola researcher śledzić to, jednak daje to argument

Iteruj i ucz organizację:

Hej, mieliśmy success metric dla tej funkcji, feature adoption. Zakładaliśmy 60% klientów adoptujących tę funkcję, a mamy tylko 20%
Wierzę że to dlatego, że nie mogliśmy zrobić wystarczająco dużo research z góry
Może następnym razem możemy zrobić research i po prostu kontynuować ten proces

Anderson podsumowuje realnie: wiem że to brzmi minimalnie, wiem że to frustrujące, jednak tak powoli się w to wkopuje. To nie jest satysfakcjonujące, jednak jest to sposób na powolne wprowadzanie kultury research-driven decision making. Jedna cegła na raz.

9. Jak przekonać interesariuszy do research

Od krzyczenia do zrozumienia obaw

Anderson przyznaje że przez lata próbowała różnych metod przekonywania ludzi do słuchania jej wniosków. Jedną z nich było krzyczenie na ludzi. Jako niska osoba wygląda to dość komicznie. To nie było zbyt pomocne.

Co działało lepiej? Zrozumienie czego interesariusze faktycznie chcą osiągnąć i czego się boją. Najczęściej chodzi o pieniądze, przychody i mitygowanie ryzyka. Rzadko chodzi o „nie wierzenie w research”, częściej o strach przed ryzykiem.

3-stopniowy proces przekonywania interesariuszy

KROK 1: Zrozum czego interesariusze się boją

Według Anderson trzeba zacząć od empatii. Ludzie nie ignorują research z przekory, tylko ze strachu. Najczęściej boją się: stracić pieniądze, zrobić coś źle, stracić pracę. Rzadko chodzi o „nie wierzenie w research”.

Anderson radzi pytać: o co faktycznie im chodzi, co chcą zmienić, co ich obchodzi? Odpowiedź zazwyczaj: money, przychody, mitygowanie ryzyka w organizacji. Jakikolwiek byłby smak tego ryzyka, normalnie zawsze wraca do jakiejś metryki związanej z przychodami.

KROK 2: Pokaż research jako mitygację ryzyka

Anderson zwraca uwagę na coś kluczowego: research jest zawsze lagging indicator, nigdy nie będzie leading indicator. Wyniki research zawsze są opóźnione względem działań. Nie dowiemy się od razu do czego prowadzą rekomendacje. Anderson przyznaje że byłoby cudownie gdyby to było możliwe. Właśnie dlatego tak ważne jest pokazanie ryzyka z góry.

Radzi: pokaż jakie ryzyko firma ponosi NIE robiąc research. Pokaż ROI jeśli research zostanie zrobiony. Połącz wnioski z metrykami na których interesariuszom zależy (przychody, retention, adoption). Jakie są rzeczy które ludzie obchodzą? I jak pitchujemy te rzeczy do ludzi których one obchodzą w sposób który brzmi przekonująco?

KROK 3: Przenieś piłkę na ich stronę

Anderson mówi: wskazałam ryzyko jeśli nie zrobicie tego research i ROI jeśli go zrobicie, piłka jest na waszym boisku, to wasza decyzja czy coś z tym zrobicie czy nie.

Do jakiego stopnia chce się siedzieć i błagać „proszę słuchajcie, proszę słuchajcie”? Anderson jest w tym bardzo realna: do jakiego stopnia też chcesz stawiać się w pozycji gdzie ciągle siedzisz i mówisz proszę słuchajcie, proszę słuchajcie, proszę słuchajcie?

Dodatkowe taktyki

Jeśli zespół ignoruje ostrzeżenia, Anderson radzi prowadzić log problemów. Elaine dzieli się swoim doświadczeniem: pracując ze startupem financial planning zauważyła że jeśli była cierpliwa, wiele problemów które przewidziała wyłaniało się naturalnie w delivery pipeline. Wtedy mogła pokazać: mówiłam o tym trzy miesiące temu.

Anderson dodaje: bardzo polecam jeśli z tym walczysz, prowadzenie logu pojawiających się problemów. To daje dokumentację i argumenty na przyszłość.

Im więcej źródeł danych można połączyć (qual + quant + customer support + account management), tym łatwiej przebić się przez strach interesariuszy przed podjęciem złej decyzji. Anderson wspomina: triangulacja tych danych, ponieważ niestety nadal, mimo że sample sizes w jakościowych badaniach są niższe, ludzie nadal chcą więcej… ponieważ to jest oparte na strachu. Ludzie się boją zrobić błąd. Jeśli rozumie się że to przychodzi ze strachu przed zepsuciem czegoś, robieniem słabo, zwolnieniem, można zacząć mówić: och, rozumiem ten strach. Jak mogę to wzmocnić innymi danymi które pomogą wesprzeć tę próbkę lub decyzję której się boisz?

Kiedy przestać walczyć

Anderson mówi wprost: był job w którym pracowała dwa miesiące i prawdopodobnie płakała w łazience co drugi dzień.

Jej rada: jest moment kiedy przestaje się walić głową w mur i szuka wyjścia z sytuacji. Nie każda kultura organizacyjna jest gotowa na research-driven decision making. Jest pewien punkt w którym przestajesz walić głową w betonowy mur i znajdujesz sposób żeby wydostać się z tej sytuacji.

Podsumowanie: główne wnioski

Podróż Nikki Anderson z Jobs-to-be-Done pokazuje że nawet doświadczeni researchers mogą się gubić w abstrakcji frameworka.

Kluczowe zasady według Anderson:

Należy zaczynać wąsko – łatwiej rozszerzyć zakres niż go zawężać. Trzeba upewnić się że JTBD to właściwa metoda na dany problem oraz że istnieje dostęp do wystarczającej liczby uczestników. Need statements muszą być konkretne. Test decyzyjności: czy product manager może z tego zrobić ticket w backlogu?

Dobieraj deliverables pod interesariuszy, nie pod framework. Interesariusze uwielbiają deliverables, jednak nie wszystkie są równie użyteczne. Warto łączyć demografia + desired outcomes w segmentacji, dopóki nie pozna się głębiej potrzeb użytkowników.

Research powinien być dostosowany do priorytetów biznesowych. User-centricity musi generować wartość biznesową. Venn diagram: co ważne dla użytkowników × co ważne dla organizacji. Należy triangulować dane z wielu źródeł (qual + quant + support + account management). Prowadzenie logu przewidzianych problemów okazuje się bardzo pomocne.

Nie należy blokować wdrażania, lepiej wspierać go danymi wtórnymi i success metrics. Jako wąskie gardło traci się wpływ. AI może wspierać, jednak nie zastępuje ludzkiego osądu i peripheral vision z wywiadów. Research jest lagging indicator, dlatego kluczowe jest pokazanie ryzyka z góry.

Każda metodologia wymaga dopasowania do kontekstu organizacji. Nie należy robić JTBD tylko dlatego że „wszyscy to robią”.

Jak podsumowuje Jim Callback: Jobs-to-be-Done to jedno z wielu narzędzi w toolkicie. Trzeba rzucić właściwe narzędzie na właściwy problem.

Kluczowy insight

Start narrow, expand later

Standardowo myślimy: Żeby naprawdę zrozumieć użytkowników, trzeba zbadać cały ich kontekst – wszystkie typy podróży, wszystkich użytkowników, cały proces od początku do końca. Im więcej danych, tym lepsze decyzje.

W praktyce okazuje się że: Można zawsze wejść w projekt zbyt wąski i rozszerzyć go później. Ale wejście w projekt zbyt szeroki i retrospektywne próby jego zawężenia są znacznie trudniejsze. Wąski zakres daje konkretne, actionable wnioski. Szeroki zakres daje ogólniki które lądują w szufladzie.

Dlaczego to jest istotne: Anderson segmentowała tylko do leisure travel, non-families, booking process – i mimo to jej need statements wyszły zbyt szerokie. Musiała je dalej rozbijać. Callback dodaje: ludzie wychodzą z szerokich warsztatów innowacyjnych z głowami pełnymi pomysłów, ale bez jasności co dalej. Wszyscy chcą wiedzieć: gdzie jest ticket w backlogu?

Test na jutro: Następnym razem gdy planujesz badanie, zamiast pytać „jak możemy zrozumieć całą kategorię użytkowników”, zapytaj „jaki jeden konkretny moment w ich procesie blokuje im postęp”. Zbadaj tylko ten moment. Daj zespołowi coś co mogą wdrożyć w następnym sprincie, nie wizję wymagającą kwartału pracy.

Lista polecanych książek i zasobów

Książki wymienione w webinarze:

„Jobs to Be Done Playbook” – Jim Callback (autor wspomina że książka pomogła Nikki uporządkować chaos wokół JTBD)
„Jobs to Be Done Pyramid” – Scott Burleson (zapowiedziany gość kolejnego webinaru JTBD Untangled)
„Competing Against Luck” – Clayton Christensen (jedna z pierwszych książek które Nikki czytała o JTBD)

Kursy i warsztaty:

Applying the Core Process – 3-dniowy mini-kurs od Jobs to Be Done Toolkit
Foundations of Jobs to Be Done – video learning course (~2,5h treści wideo)

Notka końcowa

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ć. Oryginalny webinar „From Confusion to Clarity: A User Researcher’s Journey with Jobs-to-be-Done” odbył się w ramach cyklu JTBD Untangled prowadzonego przez Jobs to Be Done Toolkit (Jim Callback i Elaine Matthias). Gościnią była Nikki Anderson, qualitative user researcher i konsultantka.

Więcej informacji o JTBD Untangled i nadchodzących wydarzeniach znajdziesz na stronie Jobs to Be Done Toolkit.