Jobs to Be Done i OKRs: jak ratować bilion dolarów rocznie

Nota redakcyjna: Ten artykuł to notatki z webinaru „Driving Value with OKRs and Jobs to Be Done” prowadzonego przez Jima Kallbacha i Elaine Mathias z Jobs to Be Done Toolkit. Gościem był Fred Pernet, założyciel Elevating Work. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od uczestników dyskusji.

TL;DR

95% firm nie potrafi wspólnie zdefiniować potrzeby klienta (badanie MIT Sloan Management School)
70% projektów informatycznych zawodzi lub przekracza budżet i terminy, co oznacza ponad bilion dolarów rocznie w zagrożeniu
Fred Pernet proponuje połączenie Jobs to Be Done (precyzyjne zrozumienie potrzeb) z OKRs (skuteczna egzekucja strategii)
Key results muszą opisywać zmiany w zachowaniu klientów, nie ilość wykonanych zadań
Trigger Model pomaga przejść od struggle statement przez desired outcomes do konkretnych OKRs
W kontekście B2B liczy się cały ekosystem decyzyjny, nie tylko użytkownik końcowy
Dobry OKR mówi „co” osiągnąć, ale nie narzuca zespołowi „jak”

O uczestnikach webinaru

Jim Kallbach, autor Jobs to Be Done Playbook i współzałożiciel Jobs to Be Done Toolkit, prowadził wydarzenie wspólnie z Elaine Mathias. Fred Pernet specjalizuje się w łączeniu trzech metodyk: Jobs to Be Done dla rozpoznania potrzeb klientów, OKRs dla egzekucji strategicznej oraz Lean Agile dla przepływu wartości. W swoim dorobku ma między innymi szkolenia dla McKinsey z Jobs to Be Done. Jest instruktorem Agile Academy i OKR Mentors.

Dwa krytyczne problemy biznesu

Brak zgody co do potrzeb klienta

Pernet rozpoczął webinar od interaktywnego pytania do uczestników. Jaki procent firm nie potrafi wspólnie zdefiniować potrzeby klienta? Odpowiedzi wahały się od 45% do 95%. MIT Sloan Management School zbadało ten problem i ustaliło: 95% firm nie osiąga konsensusu w tej kwestii.

Według Perneta przyczyny są trzy:

Przeciążenie informacjami – organizacje toną w nadmiarze informacji o klientach
Wielość definicji – zbyt wiele różnych sposobów definiowania customer need
Niejednoznaczność – ogromna niejasność wokół zachowań klientów

W rezultacie powstaje bardzo słaby stosunek sygnału do szumu.

Porażki w egzekucji strategii

Drugie pytanie dotyczyło projektów informatycznych. Standish Group przeanalizowało 10 000 projektów w 2020 roku. Uczestnicy typowali różne liczby, jednak rzeczywistość okazała się brutalna: 70% projektów albo zawiodło, albo było opóźnionych, albo przekroczyło budżet.

Standish Group podaje szczegóły: 30% odnosi sukces, 50% jest „challenged” (opóźnione, nad budżetem lub z brakującą funkcjonalnością), natomiast 20% całkowicie zawodzi.

Pernet wskazuje główne przyczyny. Brak jasnych celów i spójności w działaniach zespołów. Słabe wsparcie ze strony zarządu. Ponadto rozlewanie się zakresu (scope creep) i problemy z priorytetyzacją. Około 70% tych przyczyn można rozwiązać poprzez odpowiednie zastosowanie OKRs.

Jeśli branża oprogramowania jest warta 7,5 biliona dolarów w 2025 (według Gartner), to 20% porażek oznacza ponad bilion dolarów rocznie w zagrożeniu. Jak podkreśla Pernet, to nie jest mały problem.

Jobs to Be Done jako precyzyjna lupa

Zmiana perspektywy

Pernet opisuje Jobs to Be Done jako fundamentalną zmianę optyki. Firmy muszą przejść z perspektywy produkt-rynek na rynek-produkt. Zamiast pytać „jak sprzedać nasz produkt”, kluczowe pytanie brzmi „dlaczego klient zatrudnia lub zwalnia produkt, aby osiągnąć postęp w życiu”.

Podczas prezentacji pokazał dwa zdjęcia: jedno z kamery nocnej, drugie z kamery termowizyjnej. Ta sama scena, jednak klient jest wyraźnie widoczny tylko na drugim obrazie. W tym kontekście JTBD działa jak termowizyjna kamera. Pokazuje to, czego inne narzędzia nie wychwytują.

Pomóc kupić, nie sprzedać

Pernet przywołuje Bob Moesta z „Demand Side Sales”. Kluczowa różnica: nie powinniśmy próbować sprzedawać rozwiązań klientom, powinniśmy pomagać klientom kupować rozwiązania.

Brzmi podobnie, ale to zasadnicza różnica. Klient zmaga się z zadaniem do wykonania. Dlatego firma musi zrozumieć, w którym momencie tej walki klient się znajduje. Wtedy może pojawić się we właściwym czasie i pomóc mu zrobić postęp w podróży zakupowej. Według Perneta to niemal obrót o 180 stopni w myśleniu o sprzedaży.

OKRs jako narzędzie egzekucji

Problem z dojrzałością

Pernet wskazuje na paradoks w branży:

Około 70% firm używa OKRs
Tylko około 20% przyznaje, że robi to dobrze

Współpracuje z grupą OKR Mentors nad mierzeniem dojrzałości OKR. Cel: powiązać poziom dojrzałości z „value at risk”. Jeśli firma nie jest dobra w egzekucji strategii, nie powinna się dziwić, że nie realizuje swoich strategicznych projektów.

Brak przyczynowości w key results

Według Perneta wiele key results jest przypadkowych. Firmy nie rozumieją, jaki łańcuch wydarzeń powoduje, że klienci kupują produkty. W rezultacie brakuje zrozumienia przyczynowości.

Tu pojawia się związek z JTBD. Jeśli firma dobrze rozumie Jobs to Be Done, widzi jakie zmiany zachodzą w kliencie. Widzi, co klient próbuje osiągnąć. Wtedy rozumie, jakie zmiany w zachowaniu powinna mierzyć w swoich OKRs. Pernet podkreśla istnienie związku między tymi dwoma frameworkami.

Trigger Model i Four Forces

Trigger Model: od problemu do zakupu

Pernet wprowadza tzw. Trigger Model oparty na customer journey i switch model Boba Moesty. Klient przechodzi przez kilka etapów, próbując pokonać swoją trudność. Trigger Model koncentruje się na punktach decyzyjnych. Co dzieje się w umyśle klienta w każdym z tych momentów:

First thought → Seeking solutions
Seeking → Shopping
Shopping → Buying
Buying → Evaluating

Na szkoleniu, które Pernet prowadzi z Elaine Mathias (13-14 maja), uczestnicy przeprowadzają wywiady z klientami. Pytają o ostatni zakup. Następnie analizują podróż decyzyjną.

Pytania do wywiadów z Trigger Model

Podczas wywiadów Pernet rekomenduje skupienie się na kluczowych momentach przejścia:

Kiedy po raz pierwszy pomyślałeś o rozwiązaniu tego problemu? Pomaga zidentyfikować trigger event, który uruchomił podróż zakupową.

Co spowodowało, że zacząłeś szukać rozwiązań? Odkrywa push of the situation – co sprawiło, że obecny stan stał się nie do zniesienia.

Jakie opcje rozważałeś? Dlaczego odrzuciłeś niektóre? Pokazuje konkurencyjne rozwiązania i powody eliminacji (anxiety of the new).

Co ostatecznie skłoniło Cię do podjęcia decyzji? Identyfikuje pull of the new – co przyciągnęło do wybranego rozwiązania.

Co Cię powstrzymywało lub martwiło w procesie? Ujawnia habit of the present i inne siły hamujące zakup.

Four Forces Model

Pernet pokazuje Four Forces Model podczas prezentacji. To narzędzie pomaga zrozumieć, co się dzieje w umyśle klienta podczas podróży zakupowej. Model składa się z czterech sił:

Siły pchające do przodu:

Push of the situation – co powoduje, że obecna sytuacja jest nie do zniesienia
Pull of the new – co przyciąga w nowym rozwiązaniu

Siły hamujące:

Anxiety of the new – lęk przed nowym rozwiązaniem, niepewność
Habit of the present – przyzwyczajenie do obecnego stanu, comfort zone

Podczas wywiadów z klientami Pernet wydobywa te cztery siły. To pozwala zrozumieć nie tylko co klient chce osiągnąć, ale też co go powstrzymuje. Dzięki temu można zaprojektować rozwiązanie, które adresuje właściwe forces.

Proces 5-krokowy: od struggle do OKRs

Eksploracja problemów klienta
Rozpakowanie podróży decyzyjnej
Ujawnienie struggle statement (głównej trudności)
Zdefiniowanie desired outcomes (miar postępu według klienta)
Sformułowanie OKRs w oparciu o te outcomes

Pernet pokazuje szablon do tego procesu. Uczestnicy przechodzą przez niego krok po kroku podczas szkolenia.

Key results to zachowania, nie działania

Analogia z podróżą do Chicago

Kallbach poprosił Perneta o wyjaśnienie różnicy między KPIs a key results. Wielu ludzi myli te pojęcia. Pernet podaje analogię z jazdą samochodem. Jesteś w Nowym Jorku i chcesz dotrzeć do Chicago:

Objective (cel) = Chicago (gdzie chcesz dotrzeć)
Key Result (miara postępu) = Nawigacja GPS pokazująca, jak zbliżasz się do Chicago
KPIs (wskaźniki zdrowia) = Prędkość, paliwo, ciśnienie w oponach (pilnują, czy pojazd jest sprawny)

KPIs pilnują „zdrowia pojazdu”. Z kolei key results mierzą, czy zbliżasz się do celu. Pernet dodaje: z czasem OKRs stają się KPIs. Dlaczego? OKR bowiem popycha do wyższego standardu. Kiedy osiągniesz ten nowy poziom, staje się on nowym KPI. Jednak na początku key result wyznacza ambitny cel, którego jeszcze nie osiągnąłeś.

Anticipated vs desired key results

Uczestnik Brett zadał pytanie o naturę key results. Czy key result powinien opisywać pożądany rezultat, czy realnie oczekiwany rezultat?

Używając analogii Perneta: czy mówimy „chcę dotrzeć do Chicago w 12 godzin” (idealny czas), czy „dojadę do Chicago w 17 godzin” (realistyczny czas uwzględniający przystanki, zmęczenie, ruch)?

Pernet odpowiada, że key result to przede wszystkim zmiana w zachowaniu. Nie chodzi o to, czy jest „desired” czy „anticipated”. Chodzi o to, żeby był rezultatem (outcome), nie wykonanym działaniem (output). Liczba nie powinna być fantazyjna, ale ambitna. Powinna pchać zespół do wyższego poziomu.

Rezultat vs działanie: podstawowa weryfikacja

Jak sprawdzić, czy Twój key result jest dobry?

✅ Key result (REZULTAT) opisuje:

Zmianę w zachowaniu klienta
Efekt, który chcesz osiągnąć
Postęp mierzony z perspektywy klienta
Przykład: „Pracownicy zachowują się bezpieczniej w 90% sytuacji”

❌ To NIE jest key result (to DZIAŁANIE):

Liczba przeprowadzonych szkoleń
Ilość wysłanych emaili
Liczba spotkań z klientem
Przykład: „Przeprowadziliśmy 10 szkoleń BHP”

Pytanie testowe: Czy to opisuje, co zrobiłeś, czy to, co się zmieniło u klienta?

Kompleksowa weryfikacja jakości celów

Pernet proponuje pięć dodatkowych pytań kontrolnych do weryfikacji OKRs:

1. Czy Twój Key Result opisuje konkretną zmianę zachowania użytkownika? Unikaj mierzenia aktywności zespołu. Szukaj mierzalnej zmiany po stronie klienta.

2. Czy unikasz ogólnikowych sformułowań, takich jak „zrobić coś łatwiej”? Jak podkreśla Pernet: „make it easier” to cop out. Musisz wiedzieć CO KONKRETNIE jest trudne.

3. Czy cel wynika bezpośrednio z analizy trudności klienta? OKR powinien adresować zidentyfikowany struggle, nie przypuszczenia zespołu.

4. Czy zespół posiada pełną autonomię w wyborze drogi do celu? Dobry OKR mówi „co”, ale nie „jak”. Zespół decyduje o sposobie realizacji.

5. Czy miernik skupia się na rezultacie rynkowym zamiast na postępie prac? „Ukończono 8 z 10 zadań” to postęp prac. „30% użytkowników przeszło onboarding w <5 min” to rezultat rynkowy.

Związek z Jobs to Be Done

Pernet wyjaśnia różnicę między OKR a JTBD w kontekście zachowań. Zmiana w zachowaniu jest widoczna, mierzalna. To zewnętrzna obserwacja. Natomiast Jobs to Be Done odkrywa, co dzieje się w głowie i sercu osoby, co napędza chęć zmiany zachowania. To wewnętrzny wgląd.

Podczas wywiadów z klientami pytamy o drivers: co cenisz, w co wierzysz, z czym się zmagasz, kiedy to się dzieje. Celem jest dotarcie do przyczyny źródłowej. W rezultacie ten wgląd pozwala zdefiniować właściwy rezultat (key result), który następnie napędza wszystkie działania i szkolenia.

Pernet podkreśla: to krytyczna separacja. Jeden z głównych powodów, dla których key results nie działają: są wykonanymi działaniami, nie rezultatami. Liczba wykonanych rzeczy to nie key result. Zmiana w zachowaniu to key result.

Studium przypadku: ograniczenia w projektowaniu rozwiązania

Problem Medicare i opieki domowej

Evan, jeden z uczestników, zadał fascynujące pytanie o rozbieżność między Jobs to Be Done a tym, jak firma dostaje zapłatę. Pracował z firmą zajmującą się opieką nad seniorami (caregiving). Firma rozpoczęła z solidnym podejściem JTBD. Chcieli pomagać rodzinom i opiekunom robić postęp w różnych aspektach opieki nad starzejącą się osobą.

Evan poprosił o plan działania. Pokazali mu listę funkcji. Następnie zapytał o priorytetyzację. Odpowiedzieli: większość z tego znika, bo Medicare za to nie płaci. Medicare nie zwraca kosztów za rzeczy, które nie poprawiają clinical outcome lub nie redukują medical costs. Jednak wiele z tych rzeczy przynosi korzyści konsumentom.

Przykład: senior zmaga się z utrzymaniem domu w porządku. Jeden z największych problemów to home maintenance. Mimo to Medicare nie płaci za sprzątanie czy konserwację domu. Firma musiała ograniczyć rozwiązanie tylko do tego, za co dostanie zwrot.

Jak JTBD pomaga z ograniczeniami

Kallbach zauważył: to brzmi jak ograniczenie po stronie rozwiązania, nie problemu. Jobs to Be Done mówi jaki problem rozwiązać, ale nie narzuca rozwiązania. Dlatego ograniczenie związane z tym, że Medicare nie zwraca kosztów, musi być częścią projektowania rozwiązania.

Pernet dodaje kluczową obserwację: jeśli Medicare nie płaci za home maintenance, to brzmi jak niezaspokojona potrzeba. Jest ważne dla osoby. Nie jest zaspokajane przez obecnych providerów. Jest to coś, za co ludzie mogliby być skłonni zapłacić.

Pojawia się tutaj możliwość biznesowa:

Standardowa usługa pokrywana przez Medicare
Dodatkowa usługa (home maintenance) opłacana bezpośrednio przez konsumenta lub rodzinę
Dwa źródła przychodów obsługujące różne jobs

Mathias podkreśla: definicja customer progress zawsze musi uwzględniać ograniczenia. Wewnętrzne, zewnętrzne, czasowe. Nawet przy definiowaniu job as progress musisz myśleć o ograniczeniach.

Medicare to jedno rozwiązanie w miksie rozwiązań. Nawet jeśli Medicare jako provider nie może rozwiązać tego job, to job nadal istnieje. Są inne możliwości rozwiązania tego job przez inne kanały.

Lekcja o regulacjach i JTBD

Kallbach podsumowuje: w przestrzeniach regulowanych, z ograniczeniami rządowymi, z prawami, spektrum zastosowania JTBD może być węższe. Nie zawsze dostaniesz silver bullet solution jak w case studies.

Jednak wprowadzenie customer needs do dyskusji jest wartościowe. Większość ludzi tego nie robi, bo nie mają uzgodnionej definicji need czy struggle. Nawet jeśli JTBD nie da prostej odpowiedzi, pomaga w nawigacji po złożonych sytuacjach.

JTBD poza typowym biznesem

Kontekst military i government

Brett, uczestnik pracujący w kontekście militarnym i rządowym, poruszył fascynujący wątek. W military i government koncepcja „klienta” jest inna. Nie ma tradycyjnego B2C ani nawet prostego B2B.

Brett opisał swoje doświadczenie jako knowledge manager wewnątrz organizacji. Staff directorate, z którym pracuje, to nie jest klient per se. Nie kupują rzeczy. Natomiast organizacja ma tzw. battle rhythm – sposób, w jaki organizacja dochodzi do decyzji z odpowiednią szybkością w trzech horyzontach: now, next, future.

Próbując pomóc im myśleć o OKRs, Brett używa koncepcji JTBD. Jaki jest ten kluczowy objective i key result, który próbują osiągnąć? Proces będzie wykonywany przez rok fiskalny.

Kiedy jednak zaczynają pracować z organizacjami podległymi (subordinate organizations), wtedy staje się to bardziej customer-centric. To bardziej jak consulting wewnątrz community.

Brett zauważa też, że pracując z lokalnymi small businesses w Yorktown, Virginia, to jest B2B. Małe firmy próbują coś poprawić u siebie, żeby lepiej obsługiwać swoich klientów. Jaka jest niezaspokojona potrzeba wewnątrz organizacji, którą można odkryć lub zrealizować lepiej, żeby mogli skuteczniej angażować swoich klientów?

Pytanie o niezaspokojoną potrzebę w różnych kontekstach

Brett opisuje reakcje ludzi, kiedy pyta o „niezaspokojoną potrzebę”. Najpierw robią listy. Wymieniają KPIs i OKRs. Następnie kłócą się czy je osiągnęli. Jednak kiedy naprawdę zapytasz: jaka jest niezaspokojona potrzeba? – zatrzymują się i myślą głębiej.

W kontekście organizacji dostarczającej usługi (training, instruction), Brett pyta: czy niezaspokojona potrzeba to samo szkolenie? Czy instrukcja? Pernet odpowiada: nie. Szkolenie to wykonane działanie. Niezaspokojona potrzeba to zmiana w zachowaniu, którą szkolenie ma umożliwić.

Przykład: bezpieczeństwo jest problemem. Ludzie giną. Zmiana w zachowaniu: jak ludzie zaczynają zachowywać się bezpieczniej? To jest rezultat. Właśnie to mierzysz jako key result.

Jak to się ma do JTBD? Jobs to Be Done pomaga zrozumieć, co się dzieje w głowie i sercu osoby, co napędza chęć zmiany zachowania. To internal insight. Natomiast OKR to external observation tej zmiany.

Kontekst B2B i ekosystem decyzyjny

Kupujący vs użytkownik końcowy

Kallbach zapytał o kontekst B2B. W takiej sytuacji kupujący często jest całkowicie oddzielony od użytkowników końcowych. Decyzje finansowe są odseparowane od wartości, jaką tworzy rozwiązanie. Pernet zgadza się. Jednak uważa, że dobry kupujący w B2B powinien dbać o wartość tworzoną dla ludzi downstream. Wartość, jaką ludzie otrzymują z rozwiązania, powinna być kryterium zakupowym.

Value at risk jako argument

Pernet podaje przykład z OKR Mentors. Grupa stworzyła świetne rozwiązanie dla ekspertów OKR: narzędzie do oceny dojrzałości klienta (tzw. scan). Produkt jest skierowany do ekspertów, ale rynek istnieje dzięki klientowi końcowemu. Jeśli zabierzesz klienta, ekspert nie ma pracy. Tak wiesz, że klient jest beneficjentem.

Klient ma jednak też job buyera. Ktoś jak CFO czy CEO pyta: „Dlaczego mam wydać na to pieniądze?” Odpowiedź w języku value at risk. Jeśli robisz OKRs dobrze, prawdopodobieństwo osiągnięcia ambicji strategicznych rośnie. Jeśli źle, spada. Z perspektywy kupującego to prawie jak ubezpieczenie.

W rozmowie z buyerem w Jobs to Be Done koncentrujesz się na konsekwencjach. Można myśleć o „consequent ad negativa”. Jeśli tego nie zrobisz, jaka będzie konsekwencja? Ile wartości jest w zagrożeniu?

Ekosystem ludzi w B2B

Kallbach zauważył, że w szablonie Perneta widać etapy shopping i buying. Jednak w dużych organizacjach B2B nie shoppingujesz ani nie buyujesz. Rozwiązania po prostu do ciebie przychodzą.

Pernet odpowiada: istnieje ekosystem ludzi, który musisz zrozumieć:

Job beneficiary (beneficjent końcowy) – kto rzeczywiście korzysta z rozwiązania
Job buyer (kupujący) – kto podejmuje decyzję finansową (CFO, CEO)
Doradcy – kto wpływa na obie strony
Użytkownicy końcowi – kto pracuje z rozwiązaniem na co dzień

Aby naprawdę zrozumieć sytuację B2B, trzeba przeprowadzić wywiady z całym ekosystemem. Buyer konsultuje się z wieloma osobami w wielu sprawach. Ostatecznie sprowadza się to do ekonomii, ale buyer zbiera rady od innych ludzi.

Wiele rozwiązań obsługujących ten sam job

Studium przypadku: Healthcare w Kanadzie vs USA

Uczestnik John poruszył interesujący punkt o kompromisach strategicznych. Użył przykładu z własnego doświadczenia jako Kanadyjczyk.

Jedno rozwiązanie (kanadyjski healthcare):

Tańsze (publiczny system)
Wolniejsze dla elective surgery
Dostępne, ale z ograniczeniami czasowymi

Drugie rozwiązanie (amerykański healthcare):

Droższe
Szybsze dla elective surgery
„Best healthcare in the world” dla określonych procedur

John zauważył: job to be done jest oddzielony od solution space. Niezaspokojona potrzeba: „Nie mogę używać mojego ramienia tak, jak chcę”. Jak to rozwiązać?

Mniej kosztownie ale wolniej przez kanadyjski system. Albo bardziej kompleksowo i szybciej w amerykańskim facility. To nie jest „lepiej” vs „gorzej”. To kompromis oparty o dostępne zasoby i czas.

Lekcja o strategii i JTBD

Brett dodał obserwację: to nie jest getting it done „worse” vs „better”. To jest po prostu wiele rozwiązań może obsługiwać ten sam job to be done.

Pernet potwierdził: dokładnie. I to właśnie dlatego strategia musi być przed OKRs. Nie możesz projektować dla każdego customer job to be done. Musisz wybrać gdzie chcesz konkurować i dlaczego.

Strategia określa:

Czy robisz job lepiej czy gorzej
Czy jesteś droższy czy tańszy
Jaki segment klientów obsługujesz
Jakie kompromisy akceptujesz

Dopiero potem możesz definiować OKRs, które napędzają tę konkretną strategię.

Empowerment zespołów przez jasność celu

Transition z SAFe do product operating model

Jonas, uczestnik z dużej organizacji, opisał wyzwanie związane z transformacją. Firma przechodzi z modelu SAFe Agile na product operating model. Mają wiele różnych zespołów. Używają OKRs.

Jonas zauważa jednak problem: zespoły wciąż nie są samosterujące. OKRs przychodzą jak popcorn. Brakuje strategii i wyjaśnienia, które pozwoliłoby zespołom intuicyjnie czuć, gdzie powinna iść ich mapa drogowa. Zespoły nie mają intuicyjnego wyczucia kierunku.

Jonas widzi, że jako designer może to intuicyjnie wyczuć. Jednak zespoły jako całość nie mają tej samej jasności. Potrzebują czegoś więcej niż tylko OKRs pojawiających się ad hoc.

Autonomia i motywacja

Kallbach zauważył: znajomość struggle może być bardzo empoweringująca dla zespołu. Zamiast „zrób to szybko i łatwo”, konkretny problem daje zespołowi moc.

Pernet całkowicie się zgadza. Nazwa jego firmy (Elevating Work) pochodzi stąd, że widzi disconnect między tym, co ludzie robią na co dzień, a tym jak pomagają klientowi. Kombinacja JTBD i OKRs zamyka tę lukę:

Zespół rozumie konkretny struggle klienta (z JTBD)
Widzi pożądany rezultat (z OKR)
Wie, że jego praca bezpośrednio pomaga klientowi osiągnąć postęp
Ma jasność co do „co”, ale swobodę w „jak”

OKR to rezultat klienta. Klient może być zewnętrzny, ale może być też wewnętrzny. Jesteś zespołem platformowym wspierającym zespół aplikacyjny? Twoja praca to pomóc im dostarczać aplikacje szybciej, bezpieczniej, z większą funkcjonalnością. Wiedza, że pomagasz komuś innemu osiągnąć postęp i poprawić życie, jest bardzo motywująca.

Cultural OKRs

Pernet często pisze tzw. cultural OKRs. Sposób, w jaki zachowujesz się wobec innych ludzi, to samo w sobie OKR. Dlaczego? Bo próbujesz wywołać zmianę w zachowaniu. Kultura to zachowanie. Dlatego cultural OKR promuje zmianę behawioralną w pozytywnym kierunku.

Jak, nie co

Wracając do punktu o autonomii: jeśli OKR jest dobrze napisany, mówi „co” osiągnąć, ale nie „jak” to zrobić. Zespół musi to wymyślić. Pernet dodaje element time-boxingu (z Agile). Masz dwa tygodnie. Masz zmienić rezultat dla klienta. Jak zamierzasz to zrobić w dwa tygodnie z pięcioma ludźmi? To jest empoweringujące i motywujące. W połączeniu z Agile i Lean daje impetus do działania.

Praktyczne wskazówki

Dwa kluczowe needs w JTBD

Jeden z uczestników zapytał o needs w kontekście Jobs to Be Done. Czy zawsze chodzi o „lepiej” i „szybciej”? Pernet odpowiada: podczas szkolenia zgłębiają to szczegółowo. Jednak jeśli chcesz się skupić tylko na dwóch needs, wybierz te:

1. Certainty (pewność)

Klient chce pewności, że dostanie to, czego potrzebuje, 100% czasu
Minimalizacja zmienności i ryzyka
Zwiększenie prawdopodobieństwa sukcesu

2. Speed (szybkość)

Minimalizacja czasu potrzebnego do osiągnięcia celu
Czas to pieniądz
Czas jest uniwersalnym zasobem, którego każdy ma skończoną ilość

Wykręt „ułatwić”

Kallbach przywołał książkę Jeffa Gotheifa i Josha Seidena „Who Does What By How Much” o customer-centric OKRs. Format: who (job performer) + does what (zmiana zachowania) + by how much (konkretna liczba).

Kallbach zauważył: Jeff i Josh mieli przykład, gdzie „does what” brzmiało „accomplish their task easily”. Pernet zareagował na słowo „easily”. Każdy dostawca rozwiązań może powiedzieć „chcemy, żeby było łatwe”. Ale co konkretnie jest trudne?

JTBD może uniknąć takich mglistych OKRs. „Chcemy, żeby klienci robili to łatwo do końca kwartału” to słaby key result. „Easily” nie znajdzie przewagi konkurencyjnej ani wyróżnika.

Pernet jest bezpośredni: jeśli mówisz „make it easier”, to nie rozumiesz problemu wystarczająco dobrze. To wykręt. Potrzebujesz wywiadów z klientami, żeby wydobyć, co się naprawdę dzieje. Kallbach żartuje: wszyscy na callu mają pozwolenie. Jeśli widzicie OKR „make something easier”, podnieście rękę i powiedzcie „to wykręt”.

Strategia przed OKRs

Uczestnik John zapytał: czy nie ma niebezpieczeństwa w informowaniu OKRs przez JTBD? Jego zdaniem punktem wyjścia powinien być business model, który priorytetyzuje jobs. OKRs to business outcomes, JTBD to user outcomes.

Pernet zgadza się. Przed OKRs potrzebna jest strategia. Nie można iść prosto z JTBD do OKRs. Strategia jest pomiędzy.

Pernet przywołuje model strategii: kompromis między „getting the job done better or worse” i „cheaper or more expensive”. Różne strategie prowadzą do różnych wyborów.

Przykłady strategii:

Uber Lux robi job lepiej niż zwykła taksówka, ale kosztuje więcej. W rezultacie OKRs skupiają się na quality i premium experience. Uber Pool robi job gorzej (dzielisz auto z obcym), ale jest tańszy, bo dzielisz opłatę. Dlatego OKRs skupiają się na redukcji kosztów przy akceptowalnym doświadczeniu.

Disruptive innovation Claya Christensena polega na robieniu jobu gorzej za mniejsze pieniądze. Z czasem zwiększasz możliwości i przejmujesz premium brand. W rezultacie OKRs ewoluują od cost reduction do quality improvement.

Jeśli strategia to „robić job gorzej i taniej”, OKRs będą o redukcji kosztów. Jak obniżyć koszty, robiąc wystarczająco, żeby klient był zadowolony? Model budżetowy jak Ryanair. To jest coś, czego Pernet uczy na szkoleniu, choć tutaj upraszcza.

Red flags: czego unikać w OKRs

Pernet i Kallbach wskazują typowe pułapki w formułowaniu OKRs:

„Zwiększyć satysfakcję klienta o 20%”

Problem: Zbyt ogólne. Nie wiesz, co konkretnie ma się zmienić w zachowaniu klienta. Satysfakcja to efekt, nie przyczyna.

Lepiej: „90% nowych użytkowników ukończy onboarding w <5 minut bez kontaktu z supportem”

„Przeprowadzić 50 szkoleń BHP”

Problem: To output, nie outcome. Mierzysz aktywność zespołu, nie zmianę u klienta.

Lepiej: „Zmniejszyć liczbę incydentów bezpieczeństwa o 60% w ciągu kwartału”

„Zrobić produkt bardziej intuicyjny”

Problem: Dla kogo? W jakim kontekście? Co konkretnie jest nieintuicyjne? Brakuje specificity.

Lepiej: „80% użytkowników znajduje funkcję eksportu danych w <30 sekund bez pomocy”

„Poprawić user experience”

Problem: UX to nie cel, to środek. Nie wiadomo, jaką konkretną trudność klienta rozwiązujesz.

Lepiej: „Zredukować czas potrzebny na stworzenie pierwszego raportu z 45 do 10 minut”

„Stać się liderem rynku”

Problem: Vague ambition bez mierzalnej zmiany zachowania użytkowników.

Lepiej: „Osiągnąć 40% market share w segmencie małych firm (<50 pracowników)”

Implementacja JTBD + OKRs w organizacji

Pernet proponuje systematyczne podejście do wdrożenia metody w trzech fazach:

Faza 1: Przygotowanie strategiczne

Zdefiniuj strategiczny kontekst Czy robisz job lepiej/gorzej? Czy jesteś droższy/tańszy? Odpowiedź na te pytania określa, jakie OKRs będziesz pisać.

Zmapuj ekosystem stakeholders Kto jest buyer, user, beneficiary? W B2B to krytyczne – musisz rozumieć cały łańcuch decyzyjny.

Wybierz jeden kluczowy segment Nie próbuj rozwiązać wszystkich problemów naraz. Focus jest kluczem do skuteczności.

Faza 2: Badania i odkrywanie

Przeprowadź customer interviews Użyj pytań z Trigger Model. Szukaj struggle statements, nie feature requests.

Zidentyfikuj core struggle Jaki jest główny problem klienta? Co sprawia, że obecna sytuacja jest nie do zniesienia?

Zdefiniuj desired outcomes Jak klient mierzy postęp? Jakie są jego kryteria sukcesu?

Faza 3: Tworzenie OKRs

Napisz customer-centric objectives Co chcesz zmienić w życiu klienta? Nie w swojej organizacji, ale u klienta.

Unikaj wykrętów w key results Bądź konkretny. „Ułatwić” to za mało. Co dokładnie jest trudne?

Zmierz behavioral change Nie outputs (co zrobiliśmy), ale outcomes (jak klient się zmienił).

Polecenia AI do wdrożenia metody

Poniższe polecenia pomogą wdrożyć zasady omówione przez Perneta w praktyce:

1. Analiza trudności klienta

Działanie: „Przeanalizuj poniższy zapis wywiadu z klientem i zidentyfikuj wszystkie trudności (struggle statements). Wypisz momenty, w których klient czuł frustrację lub brak postępu”.

Uzasadnienie: Pozwala to precyzyjnie określić, gdzie Twoje rozwiązanie może dostarczyć największą wartość. Według Perneta, zrozumienie struggle jest fundamentem dla dobrego JTBD.

Przykład zastosowania: Po wywiadzie z 5 użytkownikami wklej transkrypcję do AI i poproś o wyodrębnienie wszystkich momentów frustracji. Otrzymasz mapę struggle statements, które możesz priorytetyzować.

2. Projektowanie OKR skupionych na rezultatach

Działanie: „Na podstawie zidentyfikowanej trudności, zaproponuj trzy Key Results, które mierzą zmianę zachowania użytkownika, a nie tylko ukończenie prac programistycznych”.

Uzasadnienie: Pomaga to uniknąć mierzenia samej pracy zespołu na rzecz realnych efektów rynkowych. Jak mówi Pernet: output to nie outcome.

Przykład zastosowania: Po zidentyfikowaniu struggle „klient nie wie, czy jego zamówienie zostało przyjęte”, AI może zaproponować KR: „90% klientów otrzymuje potwierdzenie w <30 sekund po złożeniu zamówienia” zamiast „zbudowano system notyfikacji email”.

3. Mapowanie ekosystemu B2B

Działanie: „Zidentyfikuj potencjalnych interesariuszy w procesie zakupu rozwiązania dla danej branży. Uwzględnij decydentów, doradców oraz użytkowników końcowych”.

Uzasadnienie: W analizie Perneta zrozumienie całego ekosystemu jest kluczowe dla skutecznej realizacji celów w modelu B2B. Nie możesz ignorować job buyera, nawet jeśli projektujesz dla job beneficiary.

Przykład zastosowania: Dla rozwiązania SaaS HR, AI pomoże zidentyfikować: CFO (job buyer), HR Director (decision influencer), HR Manager (daily user), pracownicy (end beneficiary). Każdy z nich ma inne jobs do wykonania.

Polecane zasoby

Książki:

„Demand Side Sales” (Bob Moesta) – o pomaganiu klientom w kupowaniu zamiast sprzedawaniu im rozwiązań
„Jobs to Be Done Playbook” (Jim Kallbach) – przewodnik po frameworku JTBD
„Who Does What By How Much” (Jeff Gothelf, Josh Seiden) – o customer-centric OKRs

Artykuły Freda Perneta:

Artykuły o połączeniu JTBD, OKRs i Lean Agile (dostępne na jego blogu)
Artykuł o cultural OKRs
Artykuł o value at risk w kontekście software industry

Szkolenia Jobs to Be Done Toolkit:

Writing OKRs with Jobs to Be Done (13-14 maja, Fred Pernet i Elaine Mathias)
Applying the Core Process (mini-kurs, poniedziałek-środa-piątek)
Jobs to Be Done Untangled (comiesięczne wydarzenia community)

Kluczowy insight

Zajęty nie znaczy skuteczny

Standardowo myślimy: Jeśli zespoły są zajęte i dostarczają dużo funkcjonalności, robimy postęp. Mierzymy ile szkoleń przeprowadziliśmy, ile funkcji wydaliśmy, ile spotkań zorganizowaliśmy. Aktywność oznacza produktywność.

W praktyce okazuje się, że: 70% projektów kończy się niepowodzeniem mimo intensywnej pracy, bo mierzymy outputs (co robimy) zamiast outcomes (czy klient się zmienił). Jak mówi Pernet: „jeśli prowadzisz kurs szkoleniowy o safety, to jest output. Outcome to zmiana w tym, jak ludzie się zachowują w bezpieczniejszy sposób”. Zespoły mogą być maksymalnie produktywne w tworzeniu rzeczy, które nie zmieniają życia klientów.

Dlaczego to jest istotne: To właśnie generuje ponad bilion dolarów value at risk w branży oprogramowania. Firmy inwestują w działania, nie w rezultaty. Koncentrują się na tym, co robią, nie na tym, co osiągają. W rezultacie budżety rosną, harmonogramy się wydłużają, ale klienci nie widzą różnicy w swoim życiu.

Test na jutro: Następnym razem gdy patrzysz na swoje key results lub metryki, zamiast pytać „ile zrobiliśmy?” spróbuj zapytać „czy klient zachowuje się inaczej niż wcześniej?” i sprawdź czy potrafisz to zmierzyć. Jeśli nie potrafisz odpowiedzieć na drugie pytanie, mierzysz outputs, nie outcomes.

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: Webinar „Driving Value with OKRs and Jobs to Be Done with Fred Pernet„

Tag: Key Results

Jak połączyć Jobs to Be Done z OKRs? Fred Pernet #EN162