Fundamenty pracy z celami oraz frameworka OKR

Pierwsza część poradnika o OKRach dla product managerów - po co nam cele i podstawy frameworka OKR

OKRy to popularny framework zarządzania celami, który jest wykorzystywany przez firmy produktowe na całym świecie. Większość z nas albo pracuje z OKRami, albo będzie z nimi pracować i musi wiedzieć jak dobrze definiować, raportować, prowadzić komunikację i uczestniczyć w spotkaniach związanych z OKRami.

Mateusz Paprocki to jeden z moich guru OKRów w Polsce. Matt pracuje jako COO w Neoteric oraz jest co-ownerem OKR Poland, gdzie pomaga firmom wdrażać OKRy i budować strategię.

Mateusz przygotował dla Was 5-częściowy praktyczny poradnik pracy z OKRami, ale z naciskiem na naszą rolę product managerów:

W pierwszym artykule zaczniemy od fundamentów pracy z celami (po co nam cele, problem z tradycyjnym podejściem, jakie są dobre cele?) oraz podstaw frameworka OKR (co to jest OKR, przykład OKRa, rola PM-a w kontekście OKR).

ℹ️ Więcej wartościowych treści od Matt-a znajdziesz na jego LinkedIn oraz profilu OKR Poland, gdzie wspólnie z Leną Zhukovą prowadzi cykliczne spotkania “Kawki z OKRami”.

1️⃣ Fundamenty pracy z celami

Zanim zagłębimy się w teorię i praktykę OKRów - zacznijmy najpierw od tego co najważniejsze, czyli istoty celów w świecie product managementu. Po co nam cele? Które cele są praktyczne i nam pomagają? Jak takie cele stawiać?

Po co nam cele?

Na początek rozłóżmy na czynniki pierwsze pytanie - po co nam w ogóle cele w pracy produktowej?

Decyzje o priorytetach

Jako product managerowie balansujemy między potrzebami użytkowników, oczekiwaniami biznesowymi, technicznymi ograniczeniami i zmiennymi rynkowymi, jednocześnie znajdując czas na analizę danych, planowanie, komunikację z zespołem i zarządzanie ryzykiem. To jak żonglowanie pięcioma piłkami jednocześnie, gdy każda piłka reprezentuje inny aspekt produktu.

Ograniczony czas, ograniczone możliwości i mnóstwo pomysłów. Potrzebujemy priorytetyzacji, by wybrać to co jest w tej chwili najważniejsze.

Sprowadzając to wprost do naszej operacyjnej pracy i naszych DECYZJI:

  • Funkcjonujemy w ograniczonym czasie i budżecie, więc krytyczne jest mądre wybieranie inicjatyw, które będziemy realizować. Trudno wybierać, która z nich jest najlepsza nie rozumiejąc jakie są cele strategiczne (o ile w ogóle takie są).

  • Ustalanie priorytetów backlogu jest trudne lub wręcz niemożliwe gdy nie wiemy jakie są ograniczenia i zależności pomiędzy działami w naszej organizacji, a finalnie jakie są nasze cele.

Samodzielność i alignement zespołów

Inicjatyw produktowych nie robimy oczywiście sami, ale we współpracy z ludźmi i całymi zespołami. Rzeczywistość takiej współpracy w większości firm nie jest, delikatnie mówiąc, różowa:

  • Ludzie skupiają się na pracy w swoich działach/zespołach, koncentrując się na osiągnięciu sukcesu mierzonego wynikami indywidualnymi bądź wynikami działu.

  • Często sukces (lub jego brak) są ściśle połączone z systemami premiowymi. Nie motywuje to pracowników do interesowania się jak pracują inne działy, nie wspominając już o aktywnej kooperacji.

Potrzebujemy czegoś co pozwoli ukierunkować pracę tych zespołów, by podążały w jednym kierunku, prowadzącym do sukcesu produktu.

Ponownie sprowadzając to wprost do naszej operacyjnej pracy:

  • Biznesowy sukces produktu zależny jest od ścisłej koordynacji działań różnych zespołów marketingu, sprzedaży, developerów, customer supportu oraz zarządu. Trudno koordynować zespołami, które nie pracują razem i które mają sprzeczne cele albo, co gorsza, nie mają celów w ogóle. Taka koordynacja potrzebna jest też w ramach jednego zespołu, by wszyscy jego członkowie podążali w jedną stronę.

  • Zespół, który ma jasno postawione cele może samodzielnie podejmować wiele decyzji, bo ma zawsze kierunek, do którego przy podejmowaniu decyzji (np. o priorytetach) może się odwołać.

Problem z tradycyjnym podejściem do celów

Zarządzanie przez cele nie jest nowym wynalazkiem. Peter Drucker w latach 50. ubiegłego wieku stworzył metodę MBO (Management By Objectives), która opiera się na prostej zasadzie: zarząd określa jasny cel dla organizacji.

Brzmi prosto, jednak w zdecydowanej większości przypadków firmy kończą na:

  • celach przychodowych - „urośniemy X razy w ciągu najbliższego roku”,

  • dotyczących liczby pracowników - “podwoimy nasz headcount w ciągu roku”

  • dotyczących zostania liderem w danej branży czy lokalizacji geograficznej - „zostaniemy liderem na rynku UK”.

Problem z takim podejściem jest zauważalny od razu: takie cele nie pomagają nam podejmować DECYZJI co mamy robić. Product manager, marketingowiec, szef zespołu customer success, czy choćby programista dalej nie będą wiedzieli jak taki cel się przekłada na ich codzienną pracę i podejmowane decyzje.

Stawianie dobrych praktycznych celów jest trudne. Wymaga pracy i zaangażowania oraz… zmiany sposobu myślenia.

Dobre cele = eksperymenty

Jak definiować lepsze cele? Skupić się na eksperymentowaniu. Ktoś zapyta: „Ale jak to, zarząd stawiający cele strategiczne ma eksperymentować z moją firmą? Product Leader odpowiedzialny za linię biznesową ma eksperymentować z produktem?” Właściwie… to TAK.

Świat jest nieprzewidywalnym miejscem, w którym dużo nieoczekiwanych rzeczy może zdarzyć się nagle. Firmy konsultingowe mają na to nawet swoje akronimy - świat VUCA / BANI (używaj, by mądrzej brzmieć). Jeżeli zaakceptujemy ten fakt nieprzewidywalności, to naturalne jest, że plany się szybko dezaktualizują, a naszym celem powinno być ich jak najszybsze walidowanie.

Dochodzimy tu do miejsca, w którym możemy połączyć kropki: dobre cele = eksperymenty (czyli walidowanie hipotez).

Stawiając dobre cele sprawdzamy swoje hipotezy

Stawiając cele chcemy sprawdzić określone hipotezy w możliwie najkrótszym czasie. Dlaczego? Bo weryfikacja długoterminowego planu małymi etapami zmniejsza nam ryzyko i umożliwia sprawną adaptację do zmieniających się warunków.

I teraz coś co wszyscy czujemy intuicyjnie: Tak, sprawdzanie czy jesteśmy w stanie zwiększyć przychody razy X to słaba hipoteza do weryfikacji.

Natomiast już wysokopoziomowy cel: „W ciągu roku zostaniemy wiodącym rozwiązaniem automatyzującym Contact Center dla 5 dużych banków z rynku UK”, który powstał na bazie hipotezy „Banki z rynku UK potrzebują dedykowanego rozwiązania do automatyzującego Contact Center” pozwala już myśleć jakimi eksperymentami będziemy w stanie go zwalidować.

Ta prosta zmiana sposobu myślenia pozwala sprawić, że:

  • cele stają się dużo przydatniejsze dla ludzi - łatwiej możemy to przełożyć na konkretne decyzje (i operacyjne cele) w naszych zespołach. Wiemy jaką hipotezę realizujemy → szukamy najlepszych rozwiązań by ją zwalidować, a potem ją zrealizować.

  • przestajemy się bać stawiać na konkretne liczby w celach - przecież te cele potrzebne są nam do tego by monitorować postęp w walidacji naszej hipotezy. Hipoteza może okazać się błędna, dzięki celom będziemy to szybciej wiedzieli i szybciej mogli zareagować.

Oczywiście wybór hipotez powinien opierać się na wcześniejszym procesie discovery.

2️⃣ Framework OKR

Fundementy, które opisałem przed chwilą, są podstawą popularnego od ponad 20 lat frameworka OKR (skrót od angielskiego "Objectives and Key Results").

Co to są OKRy?

OKR to metoda zarządzania, której głównym celem jest wspieranie organizacji w realizacji jej strategii poprzez jasno zdefiniowane cele (Objectives) oraz konkretne wskaźniki ich realizacji (Key Results).

Objectives (cele) powinny reprezentować nasze aspiracje, kierunek, w którym firma/zespół ma podążać. Powinny być ambitne, inspirujące, ale też osiągalne. Powinien wynikać z postawionej przez nas hipotezy.

Przykłady: Zwiększyć zaangażowanie użytkowników, Zdobyć rynek Y, Zostać wiodącą aplikacją dla użytkowników X, Zauważalnie przyspieszyć działanie aplikacji…

Key results (kluczowe rezultaty) reprezentują postęp jaki firma/zespół poczyniły w kierunku osiągnięcia celu. Powinny być mierzalne, ograniczone czasowo i konkretne. Każdy kluczowy rezultat powinien bezpośrednio przyczyniać się do osiągnięcia celu.

Przykłady: X użytkowników skorzysta z funkcji/produktu X, Zwiększenie satysfakcji CSAT o 10%, 70% użytkowników z grupy docelowej skorzystało z funkcji Z, przyspieszenie działania strony o 30%…

Aby pomóc sobie w określeniu kluczowych rezultatów dla celów - warto sobie wprost zadać pytanie: „po czym poznamy, że osiągnęliśmy cel?”. Odpowiedź na to pytanie będzie kluczowymi rezultatami tego celu.

Przykład OKRa: Aplikacja TO DO

Załóżmy, że jesteś product managerem aplikacji do zarządzania zadaniami: TO-DO listy. Aplikacja jest dostępna przez web oraz aplikację mobilną. Zauważyliście problem, że mało użytkowników aplikacji mobilnej wraca do niej na codzień.

Przeprowadziliście Discovery i waszą hipotezą jest to, że użytkownik będący “w biegu” potrzebuje listę swoich zadań mieć szybko “tu i teraz” - tak by jednym rzutem oka zobaczyć co jest do zrobienia lub oznaczyć zadanie jako zrobione. Konieczność otworzenia aplikacji mobilnej w tym przeszkadza. Dlatego chcecie umożliwić dostęp do dzisiejszej listy zadań od razu z ekranu startowego telefonu za pomocą widgetów.

Jak mógłby wyglądać OKR w takiej sytuacji?

OBJECTIVE: Użytkownicy mobilni mają natychmiastowy dostęp do listy zadań

KEY RESULTS:

  • 20% użytkowników aplikacji mobilnej zainstaluje widget

  • dzienna retencja dla użytkowników korzystających z widgetu wzrośnie o 30%

  • satysfakcja (CSAT) dla widgetu wyniesie 70%

Wiem jaką strukturę mają zdefiniowane OKRy i… tu bardzo często kończy się wiedza o OKRach. A przecież brakuje nam odpowiedzi na kluczowe pytania: Jakie cele mamy sobie stawiać, nad jakimi pracować? Na jakiej podstawie je wybierać?

Dlatego sama metodyka OKR ma w sobie dużo więcej niż sama struktura definiowania celów.

OKRy w produktowej praktyce

Jak więc wygląda używanie OKRów w praktyce? Przede wszystkim musimy spojrzeć na cele w kontekście całej organizacji. Poniższy trójkąt jest modelem organizacji, który dobrze obrazuje gdzie i jak używamy OKRów:

  • na górze mamy misję i wizję, czyli po co firma istnieje i jak będzie definiować swój sukces

  • poziom niżej mamy strategię, która określa 2-3 letni horyzont działań, adresuje konkretny problem/szansę, definiuje co powinniśmy osiągnąć (cele strategiczne), jak powinniśmy to osiągać (polityki) oraz gdzie i czym (rynki, produkty/usługi, zasoby)

  • praca na celach, które sięgają daleko w przyszłość jest trudna, więc poziom niżej używamy OKRów, żeby skrócić czas, w którym weryfikujemy naszą strategię

    • definiujemy cel roczny, który jest naszym najlepszym pomysłem na sprawdzenie sensowności naszej strategii i będzie służył jako kontekst do krótszych iteracji (cele kwartalne); zawiera on tzw. lag metrics, czyli metryki opóźniające (zmianę widzimy po dłuższym czasie i jest ona zwykle zależna od innych niż nasza praca czynników);

    • na podstawie celu rocznego tworzymy nasz najlepszy pomysł na zweryfikowanie celu rocznego w kwartał - staje się naszym celem kwartalnym; zawiera on głównie lead metrics, czyli metryki wyprzedzające (zmieniają się szybko, zmiana zależy od naszej pracy)

  • na dole trójkąta jest nasza bieżąca praca, czyli projekty i inicjatywy; dzięki OKRom mamy szansę zobaczyć, które z nich rzeczywiście pomogą nam zrealizować nasz cel;

Tak w praktyce wygląda zwykle poziom OKRów w naszym modelu organizacji (przyjrzymy mu się bliżej wkrótce):

Rola Product Managera w kontekście OKRów

W tym momencie dochodzimy do roli Product Managera i tego jak on może uczestniczyć w pracy z OKRami. Mamy tutaj 2 opcje:

  1. Product Manager aktywnie uczestniczy w definiowaniu celów (OKRów) rocznych i kwartalnych - kluczowe działania:

    1. definiowanie celów

    2. określenie właścicieli celów i kluczowych rezultatów

    3. budowanie zespołów do realizacji celów

    4. komunikacja celów do organizacji

    5. monitorowanie i raportowanie postępów

    6. wyciąganie wniosków.

  2. Product Manager pracuje na celach (OKRach), które już są w organizacji - kluczowe działania:

    1. zrozumienie celów oraz szukanie powiązań ze strategią, weryfikacja ich zasadności

    2. monitorowanie i raportowanie postępów

Niezależnie od tego w jakiej sytuacji jesteście, najważniejsze jest dogłębne zrozumienie jak cele odnoszą się do strategii organizacji oraz Waszego produktu - bez tego nie będziecie w stanie efektywnie planować działań zespołu.

➡️ W kolejnej części…

W 2 części poradnika skupimy się na definiowaniu celów, czyli jak pisać / definiować dobre OKRy, natomiast w części 3 bardziej szczegółowo przyjrzymy się pozostałym zadaniom product managera w cyklu OKR.

Join the conversation

or to participate.