Clayton Christensen opowiadał kiedyś historię o sieci fast foodów, która chciała sprzedawać więcej koktajli mlecznych. Firma przepytywała klientów o preferencje smakowe, poziom słodyczy i rozmiar kubka. Żadna wprowadzona zmiana nie poprawiła sprzedaży. Wtedy badacz zastosował inne podejście: stanął na parkingu i obserwował ludzi kupujących koktajle. Zadał jedno pytanie — „co chciałeś osiągnąć, kiedy dziś rano zdecydowałeś się kupić koktajl?”
Odpowiedź: większość porannych kupujących miała przed sobą długą, nudną drogę do pracy. Chcieli czegoś, co zajmie im ręce i nie pozwoli zgłodnieć przed lunchem. Koktajl robił to lepiej niż banan (zbyt szybko się kończy), bagietka (zbyt brudzi) czy kawa (zbyt mała). Produktem, z którym konkurował, nie były inne koktajle — to była nuda i głód.
Ta historia jest istotą Jobs to Be Done. Ludzie nie kupują produktów. Zatrudniają je, aby wykonały zadanie w ich życiu.
W terminologii JTBD „zadanie” (job) to postęp, jaki dana osoba próbuje osiągnąć w określonych okolicznościach. To nie jest czynność („muszę wysłać plik”). To nie jest cel („chcę być bardziej produktywny”). To konkretny postęp, który konkretna osoba próbuje osiągnąć w konkretnej sytuacji — ze wszystkimi okolicznościami, ograniczeniami i emocjami towarzyszącymi tej chwili.
Zadanie ma trzy składowe: sytuację (wyzwalacz, który tworzy potrzebę), motywację (co osoba próbuje osiągnąć) i rezultat (definicję sukcesu z jej perspektywy). Wszystkie trzy mają znaczenie. Produkt, który trafia w motywację, ale ignoruje sytuację, będzie używany w niewłaściwych momentach. Produkt, który trafia w sytuację, ale ignoruje rezultat, zostanie zatrudniony i szybko zwolniony.
Pisanie formalnych opisów zadań JTBD wymusza jasność co do tego, do jakiego zadania twój produkt jest naprawdę „zatrudniany” — i ujawnia luki między tym, co uważasz za zadanie, a tym, czego faktycznie doświadczają użytkownicy.
Zwróć uwagę, że każdy opis ujawnia coś, czego lista funkcji nigdy by nie pokazała: stawkę emocjonalną, kontekst konkurujących sił i definicję sukcesu z perspektywy użytkownika. Nic z tego nie wyszłoby na jaw w ankiecie z pytaniem „jakich funkcji chcesz?”
Każde zadanie ma trzy wymiary, a produkty, które odpowiadają tylko na ten funkcjonalny, zostawiają na stole realną wartość.
Slack nie urósł dlatego, że był lepszy od e-maila w wysyłaniu wiadomości (wymiar funkcjonalny). Urósł, bo sprawił, że zespoły czuły się bardziej połączone i żywe (wymiar emocjonalny), a poszczególne osoby — częścią rozmowy toczącej się w czasie rzeczywistym, a nie kolejką w skrzynce odbiorczej (wymiar społeczny). Funkcje, które odpowiadają tylko na zadanie funkcjonalne, łatwo stają się towarem masowym (commodity). Produkty, które odpowiadają na wszystkie trzy wymiary, znacznie trudniej zastąpić.
Najlepsze badania JTBD koncentrują się na momencie zatrudnienia — decyzji o rozpoczęciu korzystania z produktu — oraz momencie zwolnienia — decyzji o przestaniu. Oba momenty są pełne cennych sygnałów.
W wywiadzie o „zatrudnieniu” zapytaj: „Cofnij się myślami do ostatniego razu, gdy zdecydowałeś się użyć [produktu]. Co się wtedy działo? Co chciałeś osiągnąć? Czego próbowałeś wcześniej?” W wywiadzie o „zwolnieniu”: „Kiedy przestałeś używać [produktu]? Co robiłeś tuż przed podjęciem decyzji o zmianie? Co robiła inaczej alternatywa?”
Odpowiedzi prawie zawsze będą cię zaskakiwać. Użytkownicy opiszą sytuacje, frustracje i motywacje, których twój zespół nigdy nie przewidział. I o to chodzi. Badania JTBD to nie badania walidacyjne — to badania eksploracyjne. Nie testujesz swoich założeń; zastępujesz je dowodami.
Gdy zidentyfikujesz główne zadania, do których zatrudniany jest twój produkt, używaj ich jako filtra dla każdej istotnej decyzji produktowej. Dla każdej proponowanej funkcji zapytaj: w którym konkretnym zadaniu pomaga to użytkownikom robić postępy? Jeśli odpowiedź brzmi „w żadnym z naszych głównych zadań”, to mocny sygnał, by obniżyć jej priorytet — nawet jeśli funkcja brzmi atrakcyjnie.
JTBD pokazuje też, gdzie przesadzasz z obsługą (over-serving). Jeśli użytkownicy mają zadanie, które jest już wykonywane wystarczająco dobrze, dodawanie kolejnych funkcji w tym obszarze przynosi malejące korzyści — i potencjalnie zwiększa złożoność, przez którą produkt jest trudniejszy w użyciu dla osób z innymi zadaniami. Perspektywa zadań pokazuje, gdzie inwestować, a gdzie przestać.