Accountability w product managemencie: dlaczego RACI nie działa i co zamiast tego #EN319

Notatki z prezentacji Lisy Kamm (Head of Product and Design, Dow Jones) na temat budowania kultury odpowiedzialności w zarządzaniu produktem.

TL;DR:

Product managerowie funkcjonują w paradoksie – są rozliczani za wszystko, jednak nie mają bezpośredniej władzy nad realizacją. Jedynym narzędziem staje się wpływ, perswazja i storytelling
Prawdziwa accountability to skupienie na rezultatach, nie na wprowadzeniach – trzeba mierzyć skuteczne wdrożenia funkcji (landings), nie tylko ich wypuszczanie (launches)
RACI i podobne frameworki są zorientowane na zadania, podkreślają brak zaufania i w praktyce nigdy nie są używane. Powstają jako symptom problemu, nie jego rozwiązanie
Framework GROW (Goals, Responsibilities, Outcomes, Wins) stawia na wspólną odpowiedzialność, transparentność i realną autonomię zamiast biurokratycznych matryc
PM bez bezpośredniej odpowiedzialności za P&L mogą równoważyć presję na krótkoterminowe wyniki z perspektywą długoterminową – są balancerami, nie executorami
Źle dopasowane zachęty są problemem – prawdziwym testem dojrzałości organizacji jest promowanie za deprecation i upraszczanie produktu
Collaborative escalation path zmienia dynamikę z „wygrać” na „posunąć sprawę do przodu” – eskalacja przez współpracę, nie konflikt

Accountability to więcej niż puste hasło

Lisa Kamm zauważa, że o accountability w product managemencie mówi się za mało. Gdy już się pojawia, zwykle w kontekście rozliczania, a nie budowania kultury odpowiedzialności. Według niej właśnie ta kultura stanowi fundament sukcesu w PM. Problem polega na tym, że większość product managerów tkwi w paradoksie, który spowalnia realizację i frustruje zespoły.

Paradoks PM – odpowiedzialność bez władzy

Każdy product manager zna ten układ. Jesteś rozliczany za realizację wszystkiego. Jednocześnie nie ustalasz budżetu, nie zarządzasz bezpośrednio inżynierami i nie możesz im dokładnie powiedzieć, co mają robić. Do tego masz więcej stakeholderów niż wiesz, co z nimi zrobić.

Kamm podkreśla, że PM może prowadzić tylko przez wpływ – storytelling, negocjacje, budowanie relacji. To wpływ bez autorytetu. W organizacjach matrycowych, gdzie brakuje realnej odpowiedzialności, ten układ naprawdę spowalnia efektywność i trzyma Cię z tyłu.

Jak zauważa Kamm, wszystko, co pozostaje PM-owi, to leadership przez influence. To prowadzenie bez władzy – umiejętność, której mało kto uczy formalnie, a która staje się kluczowa dla sukcesu w tej roli.

Cztery wymiary prawdziwej accountability

Kamm definiuje prawdziwą accountability przez konkretne wymiary, które każdy PM powinien weryfikować regularnie.

1. Outcomes ponad tasks – zobowiązania i metryki

Pierwsze pytanie brzmi: czy robisz konkretne zobowiązania i je śledzisz? Jakie metryki monitorujesz? Czy wszystko jest transparentne dla zespołu? To fundament – bez tego accountability to tylko puste słowo.

Nie chodzi o odhaczanie kolejnych zadań na liście. Chodzi o osiąganie realnego wpływu.

2. Transparentność jako możliwość odtworzenia ścieżki

Nie chodzi tylko o komunikowanie decyzji. Chodzi o możliwość cofnięcia się i pokazania, jak tam dotarłeś oraz dlaczego podjąłeś konkretne kompromisy. Czy możesz odtworzyć całą ścieżkę myślenia? Czy potrafisz rozwiązywać problemy w ten transparentny sposób?

Ludzie muszą wiedzieć dlaczego, jak i jakie są kompromisy. Z kolei stakeholderzy muszą rozumieć wpływ na obszary, z których są rozliczani – i że ich nie ignorujesz po prostu.

3. Odpowiedzialność za sukcesy i porażki – bez tego nie ma uczenia się

Kamm przywołuje klasyczne powiedzenie: „Success has many parents, but failure is an orphan.”

Jeśli nie bierzesz odpowiedzialności za porażki, dwie rzeczy się dzieją. Po pierwsze – nie uczysz się i nie możesz się poprawić. Po drugie – podważasz zaufanie. Im częściej to robisz, tym mniejsza szansa na posiadanie możliwości i autorytetu do realizowania rzeczy w przyszłości.

Kluczowe pytanie: Kiedy ostatnio publicznie wziąłeś odpowiedzialność za porażkę i pokazałeś, czego się z niej nauczyłeś?

Trzy obszary, za które PM jest odpowiedzialny

Kamm wyróżnia trzy kluczowe obszary, w których każdy product manager musi być accountable.

Strategia produktowa – co budujemy i dokąd idziemy. To rdzeń wszystkiego w PM. Jak myślimy o tym, co próbujemy zbudować? Czy mamy jasną wizję i czy wszyscy ją rozumieją?

Egzekucja – czy rzeczy wychodzą za drzwi? Czy rozbijamy pracę w sposób pozwalający poruszać się szybko i efektywnie? Czy w ogóle się poruszamy, czy tkwimy w miejscu?

Mierzenie rezultatów – to kluczowe przejście od „czy wdrożyłeś?” do „czy to zadziałało?”. Prawie każdy PM był w sytuacji, gdzie wszystko kręciło się wokół pytania o wdrożenie. To daje dużo funkcji, jednak niekoniecznie pozytywne rezultaty. Musisz pytać: czy funkcja miała pozytywny wpływ, którego oczekiwaliśmy? Jeśli nie – dlaczego? Jak możemy się dostosować na podstawie tego?

Przed kim odpowiadamy – trzy grupy i ich priorytety

Klienci – zawsze na pierwszym miejscu

W Dow Jones Kamm pracuje z publikacjami consumer-facing (Wall Street Journal, Barron’s, MarketWatch) i produktami B2B (Factiva, risk & compliance). Bardzo różne przypadki użycia, różni odbiorcy, jednak we wszystkich przypadkach próbują rozwiązać problem klienta – zazwyczaj związany z informacją w różnych kontekstach. Jeśli tego nie robisz, nie budujesz dobrego produktu.

Stakeholderzy – komunikacja w ich języku

Nigdy nie pracowała w miejscu, gdzie nie było wielu stakeholderów. Trzeba z nimi komunikować się w ich języku i prowadzić przez proces. Jeśli nie mówisz do nich w ich języku – to nie zadziała. Dlatego musisz wyjaśniać, co robisz, dlaczego to robisz i dlaczego podejmujesz konkretne decyzje – w ich kontekście biznesowym, używając terminologii, którą rozumieją.

Biznes – długoterminowy strażnik, nie wykonawca

Na koniec dnia, jeśli firmy, dla których pracujemy, nie są sukcesywne – reszta nie ma znaczenia. Możesz zbudować coś niesamowitego, czego użylibyśmy codziennie i na czym nam głęboko zależy. Wszyscy klienci tego używają. Mimo to, jeśli nie zbudowaliśmy modelu przychodów – nie ma znaczenia, jak świetne to jest.

PM jako balancer, nie executor

W większości przypadków product managerowie nie mają bezpośredniej odpowiedzialności za P&L. Niektórzy mają, jednak większość nie. Oznacza to, że nie są rozliczani kwartał po kwartale z konkretnych liczb.

To daje PM unikalną perspektywę. Mogą patrzeć na długoterminową stabilność biznesu i równoważyć presję innych stakeholderów i zespołów, które myślą „muszę wypuścić to dzisiaj, żeby zamknąć liczby przed końcem kwartału”.

PM może powiedzieć: rozumiem, czasem to będzie dobra odpowiedź. Jednak spójrzmy na kolejny rok, na kolejne pięć lat. Czy nie tworzymy zbyt dużego długu technicznego lub produktowego? Czy ten kierunek nie jest błędny długoterminowo?

Kamm podkreśla kluczowy punkt: accountability wobec biznesu to nie robienie tego, co mówią i skakanie na komendę – to prowadzenie rozmowy o tym, jak równoważyć krótko i długoterminowe kompromisy.

W praktyce: Następnym razem gdy ktoś prosi o pilną funkcję „bo inaczej stracimy klienta”, zadaj pytanie: czy to prawdziwa krytyczna potrzeba, czy manufactured urgency? Jaki będzie koszt długoterminowy tej decyzji?

Zarządzanie oczekiwaniami – fundament, który trzyma wszystko razem

Kamm bardzo mocno podkreśla: jeśli nie zarządzasz oczekiwaniami, wszystko leci z szyn. Musisz zarządzać w górę i w dół równocześnie.

Zarządzanie w górę – dostarczanie pełnego kontekstu dla leadership. Co robisz? Dlaczego to robisz? Jaki jest szerszy kontekst? Czy zaligniowałeś się ze wszystkimi stakeholderami? Czy wszystkie elementy są na miejscu? To bardzo krytyczne.

Zarządzanie w dół – dostarczanie kontekstu osobom, które mogą go mieć mniej. Dajesz im to, czego potrzebują do autonomicznych decyzji, budujesz poczucie odpowiedzialności i pokazujesz, jakie kawałki pracy muszą wykonać i dlaczego to ma znaczenie.

Kluczowe jest skupienie na zarządzaniu w obie strony i łączeniu tego w całość. Gdy pracujesz nad kierowaniem odpowiedzialnością, to management expectations w obu kierunkach trzyma wszystko razem.

Pięć śmiertelnych grzechów accountability

Kamm widzi wiele sposobów na porażkę w organizacjach. Oto pięć najczęstszych i najbardziej destrukcyjnych.

1. Niejasna odpowiedzialność vs rozproszona accountability – dwa oblicza tego samego problemu

To faktycznie dwa różne problemy, które Kamm wyróżnia.

Niejasna odpowiedzialność to sytuacja, gdzie każdy trochę myśli, że jest odpowiedzialny. Wszyscy są „jakby” ownerami. Jednak gdy dochodzi do momentu decyzji – rzeczy nie idą dobrze, bo nikt nie ma faktycznej odpowiedzialności.

Rozproszona accountability to drugi scenariusz. Wszyscy mówią „to nie jest naprawdę mój problem, nie mam tu udziału”. Nikt nie czuje się odpowiedzialny. Oba scenariusze prowadzą do rozpadania się rzeczy.

2. Brak transparentności – absolute fail

Jeśli ludzie nie wiedzą, dlaczego podejmujesz decyzje, jak je podejmujesz i jakie są kompromisy – to problem. W przypadku stakeholderów muszą rozumieć wpływ na obszary, z których są mierzeni, oraz że ich nie ignorujesz.

Kamm nazywa to wprost: absolute check fail. To będzie problematyczne długoterminowo i podważy każdą próbę budowania kultury odpowiedzialności.

3. Feature factory – launches zamiast landingów

Wszyscy znają obsesję na punkcie pytania „ile funkcji wdrożyłeś?”. Wdrożenie, wdrożenie, wdrożenie. Czy wykonałeś zadanie? Czy napisałeś tę rzecz?

To nie działa. Daje dużo funkcji, jednak niekoniecznie pozytywne rezultaty. To różnica między aktywnością a wpływem.

4. Short-term firefighting – interroguj każdy „pożar”

Kamm jest bardzo precyzyjna w tym punkcie. Zastrzega: jeśli sales przychodzi i mówi „nasz największy klient nie odnowi kontraktu, jeśli nie dostarczymy tej funkcji w tym miesiącu, a biznes nie przetrwa” – dostarczasz funkcję. Nie chce sugerować, że nigdy nie powinieneś skakać do krótkoterminowych spraw.

Jednak musisz je interrogować ostrożnie. Zadaj pytania:

Czy to prawdziwa potrzeba, którą absolutnie musimy obsłużyć teraz?
Czy ktoś po prostu chce tego szybko i robi z tego pożar?
Jaki jest faktyczny koszt biznesowy nierobienia tego teraz?

Musisz mieć odpowiedzialność i gotowość do powiedzenia „nie, nie powinniśmy tego robić”. To zawsze trudna rozmowa, jednak to część bycia accountable za długoterminowy kierunek.

5. Misaligned incentives – lekcja z Google

Case study: od launches do landings

Kamm opisuje fascynującą transformację w Google, która ilustruje, jak źle dopasowane zachęty niszczą kulturę odpowiedzialności.

Stary system: Ludzie dostawali awanse za wprowadzanie funkcji. Jeśli coś wdrożyłeś, byłeś brany pod uwagę do awansu. W rezultacie ludzie, którzy chcieli awansów, skupiali się na funkcjach. Wprowadzali funkcję, później szukali roli, gdzie mogą wprowadzić kolejną – bo mogli pokazać „ścieżkę wprowadzeń”.

Nowy system: Google przestało mówić o launches i zaczęło mówić o landings. Zmiana językowa, która zmieniła całą kulturę. Pytania przestały brzmieć „czy wdrożyłeś?” i zaczęły brzmieć:

Czy wdrażasz funkcje skutecznie?
Czy miały rezultaty i wpływ?
Czy zrobiły właściwą rzecz?

Kluczowy insight Kamm: Jeśli promujesz ludzi tylko za wprowadzenia, dostaniesz wiele wprowadzeń – jednak niekoniecznie właściwych.

Prowokacyjne pytanie o deprecation

Powiązane jest pytanie, które Kamm zadaje każdej organizacji: czy kiedykolwiek promowałeś kogoś za wycofanie czegoś? Za usunięcie funkcji? Za zabicie feature’a?

Sama promowała ludzi za to. To zawsze wyzwanie, bo trzeba tłumaczyć dwie rzeczy:

Ile pracy wymaga czyste wycofanie czegoś
Jak często prowadzi to do większego wpływu niż dodawanie na wierzch

Pytanie do przemyślenia: Czy zachęcasz i promujesz właściwe rzeczy w organizacji? Nawet gdy są przeciwieństwem wprowadzeń? Nawet gdy chodzi o porządkowanie dla lepszych rezultatów?

Dlaczego RACI (i podobne frameworki) nie działają – trzy fundamentalne problemy

Kamm przyznaje wprost – nie jest fanką RACI. Dla kontekstu: to format decyzyjny, struktura, gdzie kończysz z siatką określającą, kto jest odpowiedzialny (responsible), rozliczany (accountable), konsultowany (consulted) i informowany (informed).

Nie jest wielką fanką z trzech konkretnych powodów.

Problem 1: Zorientowanie na zadania i budowanie silosów

RACI jest zorientowany na zadania i wspiera silosy zamiast współpracy i komunikacji. Jeśli musisz rozbijać wszystko w ten sposób i definiować, kto robi co na poziomie szczegółowym – to sygnał, że coś głębszego nie działa w organizacji.

Problem 2: Pojawia się przy braku zaufania

Nikt nie mówi „pracujemy świetnie, mamy zaufanie, kolaborujemy doskonale – zróbmy RACI”. Tak to nigdy nie działa.

Kamm spędziła mnóstwo czasu na spotkaniach, gdzie ludzie kłócili się o RACI. To wyciąga na powierzchnię wszystkie napięcia i przenosi je na przód, jednak ich nie rozwiązuje ani nie ustawia współpracy i bieżącej wspólnej odpowiedzialności. To ją naprawdę niepokoi – RACI staje się polem bitwy, nie narzędziem rozwiązywania problemów.

Problem 3: Nigdy nie jest używany w praktyce – najbardziej ironiczny problem

Kamm zauważa coś fascynującego: ani razu w całej karierze nie doszło do sytuacji, gdzie przy trudnej decyzji ktoś powiedział „wyciągnijmy RACI i zobaczmy, kto ma to zrobić”.

Tyle czasu i energii na budowanie tych schematów. Tyle spotkań. Tyle napięć. A ani razu nie zostały faktycznie użyte jako odniesienie przy realnej, trudnej decyzji.

W praktyce: Jeśli Twoja organizacja ma wiele dokumentów RACI, zapytaj: kiedy ostatnio ktoś faktycznie użył RACI do rozwiązania konfliktu lub podjęcia trudnej decyzji? Jeśli odpowiedź brzmi „nigdy” – przestań tracić czas na ich tworzenie.

Framework GROW – praktyczna alternatywa dla RACI

Kamm proponuje własny framework myślenia o accountability. Zamiast RACI (lub nowszych frameworków jak DACI i RAPID) – framework GROW, gdzie patrzysz przez cztery wymiary: cele (Goals), odpowiedzialności (Responsibilities), rezultaty (Outcomes) i sukcesy (Wins).

G – Goals: jasność i komunikacja dwukierunkowa

Clarity of outcomes – fundament wszystkiego

Pierwsze pytanie: co robisz? Czy masz spójne priorytety? Czy rozumiesz, dokąd idziesz i dlaczego? To brzmi podstawowo, jednak Kamm widzi organizacje, gdzie tego brakuje.

Unified metrics and language – wszyscy mówią tym samym językiem

Ile razy byłeś na spotkaniach, gdzie ludzie patrzą na konkurujące metryki? Albo nie wypracowali, jak wygląda sukces? Dlatego upewnij się, że zespół używa spójnego języka i tych samych metryk.

Kamm widziała miejsca, gdzie zespoły współpracowały, jednak używały różnego języka i budowały totalnie różne rzeczy – przekonane, że robią właściwą rzecz i współpracują świetnie. Problem językowy staje się problemem produktowym.

Bidirectional communication – buying in, nie tylko informowanie

To bardzo ważny element. Gdy cele są budowane, nie mogą być tylko z góry na dół. Pewnie musi być jakiś poziom kierunku strategicznego z góry, jednak ludzie najbliżej pracy naprawdę muszą mieć długą drogę w ustalaniu celów i braniu za nie odpowiedzialności.

Jeśli cele są tylko przekazane z góry (handed down), ludzie nie będą mieli tego samego poczucia odpowiedzialności. Zupełnie inaczej, gdy sami mówią „hej, to powinniśmy robić” i naprawdę zobowiązują się do tego i angażują.

To nie jest participation – to jest ownership.

R – Responsibilities: współodpowiedzialność zmienia całą dynamikę

Co-ownership engineering-product-design – koniec finger-pointing

Kamm naprawdę lubi ustawienia, gdzie engineering, product i design – szefowie z każdego z tych obszarów – są współodpowiedzialni za rezultaty i pracują razem, żeby do nich dojść.

Jeśli nie masz współodpowiedzialnych, nieuchronnie dochodzi do:

„Zbudowałem, co product mi powiedział”
„Dobrze zdefiniowaliśmy, jednak engineering poszedł w innym kierunku”

To nie jest dobre dla nikogo, nie dla firmy. Kamm jest w tym bardzo bezpośrednia: ludzie zaangażowani tego nienawidzą. To po prostu złe ze wszystkich stron.

Z kolei środowisko ze wspólną odpowiedzialnością – gdzie musisz pracować razem, rozmawiać razem, prowadzić rzeczy razem i być rozliczanym razem – naprawdę zmienia całą konwersację. Nie ma miejsca na wskazywanie palcem, bo wszyscy są w tym razem.

Collaborative escalation path – prawdziwy game changer

Kamm jest wielką fanką tej koncepcji i opisuje konkretny przykład z jej praktyki.

Case study: współpraca z security team

Pracując z zespołem bezpieczeństwa, Kamm reprezentowała pewne potrzeby produktowe, oni reprezentowali potrzeby bezpieczeństwa. Były miejsca z absolutnymi kompromisami – nie było prostego rozwiązania, które zadowoliłoby obie strony.

Kluczowe było to, że oba zespoły się szanowały i dogadywały świetnie. Próbowały dojść do wspólnie uzgodnionego punktu. Gdy nie mogły, nie zaczynały wojny – robiły coś zupełnie innego.

Proces wyglądał tak:

Zespoły próbują znaleźć rozwiązanie
Gdy nie mogą, siadają razem i piszą wspólny dokument
Wykładają wszystko, w czym się zgadzają (zazwyczaj dużo)
Prezentują różne perspektywy obiektywnie, bez obwiniania
Proszą kogoś wyżej o przełamanie pata
Całość jest bardzo przyjacielska i kulturalna

To nie była eskalacja typu „ty jesteś w błędzie, idę do twojego szefa”. To było „potrzebujemy kogoś, kto przełamie ten pat i chcemy to zrobić szybko, bo nie chcemy spędzić kolejnych tygodni, kłócąc się między sobą”.

Kluczowa różnica: Nie chodzi o wygranie – chodzi o osiągnięcie porozumienia i posunięcie sprawy do przodu.

W praktyce: Następnym razem gdy napotkasz deadlock z innym zespołem, zaproponuj napisanie wspólnego dokumentu zamiast eskalacji przez konflikt. Zobaczysz, jak zmienia to dynamikę.

Empowered autonomy – kto faktycznie rozumie szczegóły

Przesuwając cele w dół organizacji i przesuwając odpowiedzialność do ludzi w triadach engineering-product-design, możesz mieć znacznie bardziej upełnomocnioną autonomię.

Ludzie, którzy naprawdę rozumieją, co się dzieje, są w lepszym miejscu do podejmowania wielu decyzji niż osoby wiele poziomów wyżej. Ci na górze mogą ustawić wielką wizję strategiczną, jednak nie rozumieją szczegółów na miejscu.

Kamm stawia to bardzo jasno: Naprawdę łatwo jest grupie wiceprezesów zebrać się i ustawić kierunek. Naprawdę trudno na poziomie implementacji zrozumieć szczegóły i co one oznaczają w praktyce. Dlatego pozwolenie tym zespołom na samodzielność jest ogromne.

O – Outcomes: konsekwencje i uczenie się

Pozytywne i negatywne konsekwencje

Ludzie potrzebują rezultatów i konsekwencji – pozytywnych i negatywnych. Jeśli ktoś robi wspaniałą robotę – świętuj to. Daj publicznie uznanie, nagrody, motywuj.

Oceniaj w kontekście momentu, nie z perspektywy czasu

Jeśli ktoś popełnia błąd – każdy błąd może być popełniony raz, bo ludzie muszą się uczyć. Kluczowe pytania, które musisz zadać:

Czy podjęli rozsądne i racjonalne decyzje z tym, co mieli w danym momencie?
Z wiedzą, którą mieli wtedy?
Czy biorą za to odpowiedzialność?
Czy uznają, co nie poszło dobrze i co poszłoby inaczej?

Wszystkie te rzeczy pozwalają na rozwój. To konsekwencje, które nie mówią „jesteś zły, jesteś ukarany”, ale „czy się z tego uczysz? Czy dzielisz się lekcjami?”. To świetny moment odpowiedzialności, który nie jest o obwinianiu za pomyłkę.

Zmiana w attitude – ownership bez strachu

To fundamentalna zmiana w nastawieniu. Gdy coś idzie źle i ktoś przychodzi i mówi:

„Ja to zrobiłem”
„To poszło źle”
„To dlaczego się nie powtórzy”
„To zamierzam zmienić”

To po prostu inna rozmowa niż sytuacja, gdzie próbujesz wykopać informacje i zrozumieć, co się stało, podczas gdy wszyscy unikają odpowiedzialności. Kamm podkreśla: to tak ważne dla budowania kultury.

W – Wins: celebrowanie i komunikacja sukcesów

Artikulacja wpływu

Na koniec – pomyślmy o sukcesach. Jakie są sukcesy? Jak odniosłeś sukces dla klientów, biznesu, wewnętrznych partnerów?

Upewnij się, że możesz jasno przedstawić, jak wyglądają i jak je oceniać. Ocena powinna być jasna z góry, gdy ustawiasz rezultaty i cele. Nie może być niespodzianka po fakcie „a, ale my mierzyliśmy coś innego”.

Acknowledge, celebrate, collaborate

To bardzo ważne, żebyś:

Uznał sukcesy publicznie
Świętował je w zespole i organizacji
Współpracował w celebrowaniu (nie solo show)
Jasno pokazał, czym był sukces i że od początku było jasne, do czego dążycie

Ustawienie na sukcesy od początku sprawia, że gdy przychodzą – wszyscy to widzą i rozumieją.

Quick Assessment GROW – szybka diagnoza dla Twojego zespołu

Zanim przejdziesz do pełnej checklisty, odpowiedz na te cztery podstawowe pytania. Jeśli którekolwiek brzmi „nie” – to sygnał, gdzie zacząć pracę.

Goals – wspólne rozumienie

Czy zapytany losowo członek zespołu opisze główne cele w ten sam sposób co Ty?

Jeśli nie – macie problem z alignment. Unified metrics i language to nie opcja, to konieczność.

Responsibilities – współodpowiedzialność

Czy Engineering, Product i Design czują się wspólnie odpowiedzialni za rezultat?

Jeśli nie – będzie finger-pointing przy pierwszej porażce. Co-ownership to fundament funkcjonalnej triady.

Outcomes – kultura uczenia się

Czy porażki są analizowane jako lekcje bez obwiniania i czy zespół dzieli się wnioskami?

Jeśli nie – ludzie będą ukrywać błędy zamiast się z nich uczyć. To najbardziej toksyczny scenariusz.

Wins – jasne kryteria

Czy definicja sukcesu była jasna i uzgodniona przed startem projektu?

Jeśli nie – będziecie kłócić się o to, czy projekt się udał. Nie można zmienić miary sukcesu po fakcie.

Jeśli 3-4 odpowiedzi to „tak” – jesteś w dobrej sytuacji, pełna checklista pomoże dopracować szczegóły.

Jeśli 2 lub mniej to „tak” – zacznij od fundamentów. Pełna checklista może być przytłaczająca, zacznij od jednego obszaru.

Jak wdrożyć framework GROW – praktyczny przewodnik

Kamm mówi konkretnie o wdrażaniu tego przez struktury, które zna z praktyki. Zauważa, że choć wizja produktu zwykle mówi się o 5-10 latach, w dzisiejszych czasach 1-2 lata może być szczęściem. Mimo to potrzebujesz wizji, regularnego procesu ustalania celów, sprawdzania i komunikacji.

Goals – ustaw fundamenty

Dokument wizji produktu:

Masz wizję na 1-5 lat (realnie 1-2 lata w obecnych czasach)
Wizja jest znana całemu zespołowi
Wszyscy rozumieją, dokąd zmierzamy i dlaczego

Kwartalne OKR:

Ustawiony regularny proces ustalania celów
Regularne spotkania kontrolne z zespołem
Regularna komunikacja o postępach i zmianach

Zunifikowane metryki:

Zespół używa tych samych metryk sukcesu
Nie ma konkurujących metryk między zespołami
Język i terminologia są spójne w całej organizacji

Quick win: W tym tygodniu zapytaj trzy osoby z różnych zespołów „jakie są nasze najważniejsze metryki sukcesu?”. Jeśli dostaniesz trzy różne odpowiedzi – masz problem z alignment.

Responsibilities – zbuduj wspólną odpowiedzialność

Zobowiązania zespołowe i negocjacje OKR:

Engineering, product i design są współodpowiedzialni za rezultaty
Negocjujesz OKR z zespołem, nie narzucasz z góry
Zespoły mają realny wpływ na ustalanie celów – akceptacja
Ludzie najbliżej pracy naprawdę zobowiązują się do celów

Kamm jest w tym bardzo jasna: jeśli nie negocjujesz z zespołem, jeśli nie prowadzisz tego procesu wspólnie – nie dostaniesz rezultatów, których chcesz.

Ciągłe odkrywanie i mapy drogowe:

Kontynuujesz odkrywanie przez cały czas
Mapa drogowa jest żywa i aktualizowana w miarę uczenia się
Wiesz, co nadchodzi i dlaczego to robisz
Wprowadzasz zmiany w miarę uczenia się nowych rzeczy

Ścieżka współpracującej eskalacji:

Masz jasny proces na przełamywanie patów
Eskalacja jest współpracująca, nie konfrontacyjna
Skupienie na osiągnięciu porozumienia, nie wygrywaniu
Zespoły piszą wspólne dokumenty przedstawiające różne perspektywy

Upełnomocniona autonomia:

Przesuwasz odpowiedzialność w dół organizacji
Triady engineering-product-design mają autonomię
Zespoły mogą podejmować decyzje na swoim poziomie
Leadership daje kierunek strategiczny, nie mikrozarządza szczegółami

Quick win: Przy następnej trudnej decyzji zamiast eskalować przez konflikt, zaproś drugą stronę do napisania wspólnego dokumentu z różnymi perspektywami.

Outcomes – mierz i ucz się

Przegląd rezultatów:

Przeglądasz je regularnie
Dzielisz się pozytywnymi rezultatami w organizacji
Dzielisz się lekcjami równie mocno
Jasno pokazujesz, że oba są wartościowe i akceptowalne

Kamm pyta wprost: jak je przeglądasz? Czy dzielisz się pozytywnymi i lekcjami w całej organizacji? Czy jasno pokazujesz, że szukasz obu i że oba są dobre i akceptowalne?

Konsekwencje – uczenie się, nie karanie:

Pozytywne rezultaty są nagradzane publicznie
Porażki są traktowane jako okazje do nauki
Oceniasz decyzje w kontekście wiedzy z momentu podjęcia
Ludzie biorą odpowiedzialność za błędy bez strachu
Dzielisz się lekcjami, żeby cała organizacja mogła się uczyć

Celebrowanie:

Celebrujesz sukcesy publicznie
Dzielisz się sukcesami w całej organizacji
Współpracujesz w celebrowaniu
Pokazujesz, jak sukcesy wpłynęły na klientów, biznes, zespoły

Quick win: Przy następnej porażce zespołu zamiast szukać winnego, zapytaj „czego się nauczyliśmy i jak to wykorzystamy w przyszłości?”. Udokumentuj to i podziel się z organizacją.

Wins – celebruj i komunikuj

Wpływ:

Możesz jasno przedstawić, jaki był wpływ
Kryteria oceny były jasne z góry
Rezultaty są mierzone względem początkowych celów
Dostarczyłeś wpływ dla klientów, biznesu, wewnętrznych partnerów

Kamm pyta: jaki jest wpływ? Czy dostarczyłeś wpływ? Czy dostarczyłeś świetne rezultaty? Czy naprawdę zmieniłeś rzeczy?

Lekcje:

Dostarczyłeś mocne lekcje, które możesz wpleść w procesy
Dzielisz się lekcjami w sposób pomocny całej organizacji
Lekcje są traktowane jako równie wartościowe co sukcesy

Albo nawet – czy dostarczyłeś naprawdę mocne lekcje, które możesz wpleść w swoje procesy i plany na przyszłość?

Quick win: Następnym razem gdy celebrujesz sukces, poświęć równie dużo czasu na omówienie, czego się nauczyliście w procesie – nie tylko końcowego rezultatu.

Red flags: diagnostyka problemów z accountability

Sprawdź, czy w Twojej organizacji pojawiają się te symptomy. Im więcej zaznaczysz, tym poważniejszy problem z kulturą odpowiedzialności.

Niejasna odpowiedzialność i rozproszona accountability

Przy trudnych decyzjach wszyscy patrzą po sobie „kto jest za to odpowiedzialny?”
Każdy myśli, że jest odpowiedzialny, jednak przy momencie decyzji nic nie działa
Ludzie mówią „to nie moja odpowiedzialność” / „nie mam tu udziału”
Przy porażkach każdy wskazuje na kogoś innego

Brak transparentności

Decyzje są podejmowane za zamkniętymi drzwiami
Stakeholderzy dowiadują się o zmianach już po fakcie
Kompromisy nie są komunikowane ani dokumentowane
Nie możesz pokazać, jak dotarłeś do decyzji i dlaczego

Obsesja na punkcie wprowadzeń – fabryka funkcji

Celebrujecie tylko wypuszczanie funkcji
Nikt nie pyta o rezultaty 2-3 miesiące po wprowadzeniu
Promujecie ludzi za liczbę wypuszczonych funkcji
Nikt nie jest nagradzany za usuwanie czy porządkowanie
Pomiar to „czy wykonałeś zadanie?” zamiast „jaki był rezultat?”
Roadmapa to lista funkcji, nie lista problemów do rozwiązania

Tryb gaszenia pożarów

Wszystko jest pilne i ważne
Nie ma czasu na długoterminowe myślenie i planowanie
Dług techniczny rośnie, bo zawsze „nie ma czasu”
Każde żądanie to „największy klient odejdzie”
Nie przesłuchujesz, czy to prawdziwe pożary, czy wykreowana pilność
Planowanie kwartalne jest fikcją, bo co tydzień zmieniacie priorytety

Zależność od RACI

Spędzacie spotkania na kłótniach o RACI
Macie dziesiątki schematów RACI, których nikt nie używa
Każdy nowy projekt zaczyna się od 2-3 godzinnego meetingu o RACI
Przy trudnych decyzjach i tak nikt nie zagląda do RACI
RACI wyciąga napięcia bez ich rozwiązywania
Ludzie cytują RACI jako broń w konfliktach („ale w RACI jestem accountable!”)

Źle dopasowane zachęty

Awanse tylko za wprowadzenia, nigdy za usuwanie
Nagradzacie aktywność i „shipping”, nie rezultaty i wpływ
Ludzie optymalizują pod metryki, nie pod wpływ dla klientów
Nikt nie chce brać odpowiedzialności za porządkowanie lub refaktoryzację
Musisz długo tłumaczyć, ile pracy wymaga czyste wycofanie
Deprecation jest postrzegana jako „nie robienie nic”

Brak współodpowiedzialności

Engineering mówi „zbudowałem, co product mi powiedział”
Product mówi „dobrze zdefiniowaliśmy, jednak engineering poszedł inaczej”
Design czuje się jak „służba do upiększania”
Ludzie zaangażowani nienawidzą tego układu i są sfrustrowani
Wskazywanie palcem zamiast wspólnej odpowiedzialności
Retrospektywy zamieniają się w sesje obwiniania

Jeśli zaznaczyłeś 5+ punktów: Masz poważny problem systemowy z accountability. Potrzebujesz fundamentalnej zmiany.

Jeśli zaznaczyłeś 10+ punktów: To kryzys kultury organizacyjnej. Framework GROW to dobry punkt startowy, jednak prawdopodobnie potrzebujesz głębszej interwencji.

Podsumowanie: od buzzword do kultury

Framework GROW to sposób myślenia o tym, jak ustawiasz systemy i procesy w całej organizacji, żeby kierować odpowiedzialnością i pomóc ludziom naprawdę czuć, że biorą odpowiedzialność za swoją pracę.

To otwiera możliwość znacznie lepszej realizacji celów – tego, co próbujesz osiągnąć, co organizacja próbuje zrobić i ostatecznie – jak pomagasz swoim klientom.

Według Kamm prawdziwa accountability w PM to:

Kultura odpowiedzialności zamiast pustego hasła
Współodpowiedzialność zamiast wskazywania palcem
Skuteczne wdrożenia zamiast samych wprowadzeń
Równoważenie krótko i długoterminowych celów zamiast skakania na komendę
Transparentność pozwalająca odtworzyć ścieżkę myślenia
Uczenie się z porażek bez strachu przed przyznaniem się do błędów

To fundamenty podejścia Lisy Kamm do product managementu w Dow Jones – organizacji, gdzie zarządza zespołami pracującymi nad bardzo różnymi produktami, od publikacji konsumenckich po skomplikowane narzędzia B2B.

Kluczem jest odejście od myślenia o odpowiedzialności jako o procedurze do wypełnienia. To kultura, którą należy świadomie budować każdego dnia – przez małe decyzje, sposób prowadzenia spotkań, reakcje na porażki i sukcesy, oraz to, co nagradzasz i celebrujesz.

Kluczowe spostrzeżenie

Wartość przez usuwanie, nie dodawanie

Standardowo myślimy: Że wartość zespołu produktowego mierzy się liczbą wdrożonych funkcji i rozmiarem tego, co zbudował. Awanse i nagrody dostają ludzie wypuszczający najwięcej. Im więcej wdrożyłeś, tym większa szansa na uznanie. Proaktywność = dodawanie nowych rzeczy. To głęboko zakorzenione w kulturze tech.

W praktyce okazuje się, że: Największy pozytywny wpływ może pochodzić ze strategicznego usuwania funkcji, upraszczania produktu i redukcji długu technicznego. Jeśli promujesz ludzi tylko za wprowadzenia, dostaniesz mnóstwo wprowadzeń – jednak niekoniecznie właściwych. Nikt nie chce brać odpowiedzialności za porządkowanie, wycofywanie czy dług techniczny, bo to „nieproduktywna” praca w oczach organizacji. W rezultacie produkt rośnie jak gąszcz, każda nowa funkcja dodaje złożoności, a wpływ biznesowy maleje mimo rosnącej liczby funkcji.

Lisa Kamm sama promowała ludzi za wycofywanie funkcji. To zawsze wyzwanie, bo trzeba przekonywać organizację i tłumaczyć dwie rzeczy: po pierwsze – ile naprawdę pracy wymaga czyste usunięcie czegoś (komunikacja z użytkownikami, migracja danych, deprecation path). Po drugie – jak często to daje więcej wpływu niż dodawanie kolejnych rzeczy na wierzch. Nagradzanie takich działań buduje znacznie zdrowszą kulturę.

Dlaczego to jest istotne: Twoje zachęty kształtują zachowania zespołu bardziej niż jakakolwiek strategia, OKR czy prezentacja CEO. Ta zmiana przesuwa motywację zespołu z pytania „co jeszcze możemy zbudować?” na „co przynosi największą wartość?”, co skutecznie zapobiega przeładowaniu produktu i jego nadmiernej komplikacji. Jeśli nagradzasz tylko za dodawanie, zespół będzie dodawać – bez względu na to, co mówisz o outcomes czy customer value. Jeśli naprawdę nagradzasz za rezultaty – dostaniesz rezultaty. Czasem największy rezultat dla klienta i biznesu to przestać robić rzeczy, które nie działają, zamiast dodawać kolejne.

Test na jutro: Następnym razem, gdy będziesz na spotkaniu podsumowującym pracę zespołu lub myślisz o publicznym uznaniu, zamiast chwalić wyłącznie za wdrożenie nowych funkcji, spróbuj publicznie docenić kogoś za odważną decyzję o usunięciu zbędnego elementu, za refaktoryzację, która uprościła system, lub za deprecation starego API, który blokował rozwój.

Zapytaj siebie: czy kiedykolwiek promowałem kogoś za deprecation? Za zabicie funkcji? Za uporządkowanie długu technicznego? Jeśli odpowiedź brzmi „nie” – Twoje zachęty są fundamentalnie źle dopasowane do tego, co mówisz głośno o outcomes i customer value.

Sprawdź, jak ta interwencja wpłynie na dyskusję o tym, co naprawdę jest wartością dla produktu. Pokaż organizacji, że to też jest droga do sukcesu i awansu. To zmieni więcej niż tysiąc prezentacji o „outcomes over outputs”.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych prezentacji, podcastów i webinarów, które uważam za wartościowe i do których sam chcę wracać. Wszystkie przemyślenia i obserwacje pochodzą od Lisy Kamm z jej prezentacji na konferencji Product. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Lisa Kamm – Accountability: The Bedrock of Success