10 błędów poznawczych w zarządzaniu produktem i jak się przed nimi bronić

Inspiracją do napisania tego artykułu była dla mnie książka „Thinking, Fast and Slow” w której psycholog i ekonomista – Daniela Kahnemana opisuje odkryte przez siebie błędy poznawcze. Czytając ją często byłem w stanie odnieść się do moich różnych doświadczeń w pracy Product Managera. Postanowiłem więc wybrać 10 błędów poznawczych, które moim zdaniem mają największy wpływ w zarządzaniu produktem. Postaram się opisać na czym polegają, jakie mają zastosowaniem w pracy Product Managera i jak można się przed nimi ustrzec. Ruszajmy więc.

Złudzenie planowania

Jest to po prostu tendencja do niedoceniania kosztów i czasu wykonania przyszłego zadania. Myślę że nikomu nie trzeba w tym przypadku wyjaśniać jakie to ma zastosowanie w zarządzaniu produktem, przejdźmy więc do możliwych rozwiązań tego dylematu.

Jak się bronić?

Oczywiście najbardziej oczywistym sposobem jest zastosowanie mnożnika, czyli do wyliczonego czasu pracy / wielkości zadania dodajemy np. 50%.
Innym ciekawym sposobem, którego osobiście jestem dużym zwolennikiem, jest po prostu nie szacować czasu pracy, a jedynie apetyt jaki mamy na rozwiązanie danego problemu.

Jest to koncept opisany w szczegółach w książce „Shape Up” Ryana Singera. Najłatwiej opisać go na przykładzie. Załóżmy, że naszym celem jest zwiększenie współczynnik konwersji z formularza rejestracji o 10% i zależy nam na rentowności tego projektu w 2-letnim horyzoncie czasowym. Znając koszty pracy zespołu produktowego i wpływ tej zmiany na nasz roczny przychód, możemy z grubsza oszacowaliśmy, że nasz “apetyt” na ten projekt to maksymalnie 2 miesiące. Jest to termin nieprzekraczalny, gdyż według naszych obliczeń po tym czasie projekt przestaje być rentowny. Zespół produktowy postawiony przed takim problemem nie estymuje ile czasu zajmie projekt. Zamiast tego skupia się na znalezieniu rozwiązania, które zmieści się w zadanym czasie (apetycie). Jest to tzw. podejście “fixed time, variable scope”.

Złudzenie ponadprzeciętności

Błąd poznawczy objawiający się skłonnością jednostki do przeceniania swoich umiejętności i cech w stosunku do innych ludzi.

Zastosowanie w zarządzaniu produktem

Czy Twój CEO wpadł kiedyś na pomysł tak świetny, że od razu chciał go zrealizować? Bez zastanawiania się jaki problem właściwie ten pomysł rozwiązuje, jak istotny ten problem jest dla użytkowników i jak jego rozwiązanie wpłynie na biznes.

Z resztą to nie jest tylko domena CEO (chodź faktycznie CEO zdarza się to pewnie najczęściej). Sam, nawet teraz, po wielu latach doświadczenia, ciągle się na tym łapię. Wydaje mi się że to jest bardzo silny aspekt ludzkiej natury.

Jak się bronić?

Stwórz rygorystyczny proces priorytetyzacji oparty o kontekst strategiczny, który mówi o tym jaki cel biznesowy chcemy uzyskać i przez rozwiązanie jakich problemów dla naszych obecnych i potencjalnych klientów będziemy do niego dążyć. Jeśli dany „świetny” pomysł nie przyczynia się do rozwiązania żadnego z tych problemów – odrzuć go. I najtrudniejsze, przekonaj swojego CEO o słuszności tego procesu i wyciągnij od niego zobowiązanie stosowania się do niego. Teraz, szybko, zanim wpadnie na kolejny genialny pomysł ;).

Efekt potwierdzenia

Jest to tendencja do szukania jedynie faktów potwierdzających naszą opinię, a nie weryfikujących ją. Wszystkie fakty niezgodne z naszą opinią są mniej lub bardziej świadomy sposób przez nas ignorowane.

Zastosowanie w zarządzaniu produktem

Więc udało Ci się stworzyć proces priorytetyzacji oparty o kontekst strategiczny? Brawo! Nie trać jednak czujności. Fakty mają ten minus, że można je naginać. Naszym celem strategicznym jest zwiększenie konwersji z bezpłatnego okresu próbnego? Chcemy to osiągnąć poprzez minimalizację czasu użytkownika do uzyskania wartości z produktu? Przecież mój pomysł na dodanie fanfar i konfetti przy pierwszym logowaniu świetnie się do tego nada! Ludzie uwielbiają fanfary i konfetti, a jak będą w lepszym nastroju to chętniej przejdą przez set up aplikacji. Co może pójść nie tak?

Jak się bronić?

Moim zdaniem dobrym pomysłem jest pisanie write-upów, czyli dokumentów opisujących w dużych szczegółach dany pomysł. Niektórzy Product Managerowie takie dokumenty nazywają uzasadnieniem biznesowym. Taki write-up powinien zawierać opis problemu, rozwiązania, możliwe ryzyka i oczekiwane rezultaty. Następnie write-up jest czytany przez członków „komisji”. Potem pomysłodawca staje przed „komisją” i broni swojego pomysłu. Taki trochę „Dragon’s Den”, albo obrona pracy naukowej. Wariacje tego rozwiązania są stosowane np. przez Amazon (słynny 6-pager i 2-pager) i Basecamp (rozdziały „Write the Pitch” i „The Betting Table” we wspomnianej wcześniej książce „Shape Up”).

Klątwa wiedzy

Ten błąd poznawczy polega na tym, że osoba z wiedzą o danym zagadnieniu nieświadomie przecenia łatwość przyswajania tej wiedzy przez innych i zatraca umiejętność empatyzowania z osobami nie posiadającej tej wiedzy.

Zastosowanie w zarządzaniu produktem

Pierwszym miejscem gdzie może dopaść nas klątwa wiedzy jest projektowanie UX i Architektury Informacji. Projektanci są tak „oswojeni” z projektem, że nie są w stanie wychwycić potencjalnych trudności związanych z jego używaniem.

Drugim jest komunikacja z zespołem produktowym o logice biznesowej tworzonego rozwiązania. Product Manager najczęściej posiada dużo większą wiedzę na temat strony biznesowej niż deweloper, czy UX designer. Podczas jej przekazywania łatwo o nieporozumienia wynikające z używania niezrozumiałego języka domenowego, skrótów myślowych czy enigmatycznych akronimów.

Jak się bronić?

W pierwszym przypadku z pomocą przychodzą oczywiście testy użyteczności. 5-8 testów najczęściej wystarczy do wykrycia większości problemów. Zachęcam Product Managerów do współuczestniczenia w projektowaniu i przeprowadzaniu takich testów.

Uwaga! Podczas przeprowadzania testów będą momenty, w których pomyślicie o użytkowniku „Jak on może tego nie rozumieć?”. Zduście tę myśl w zarodku. 9 na 10 przypadków problem leży po stronie złego UX, nie poziomu inteligencji użytkownika.

W drugim przypadku najlepiej sprawdza się User Story Mapping. Ta technika wspólnego „opowiadania” historii użytkownika skutecznie minimalizuje ryzyko niedogadania się Product Managera z zespołem produktowym co do szczegółów analizowanego problemu biznesowego.

Dobrze też, aby każdy członek zespołu produktowego zwracał uwagę na to, by jak najlepiej swoją wiedzę przekazywać innym – czy to prowadząc spotkania, pisząc user stories czy dzieląc się z interesariuszami raportem z przeprowadzonych badań.

Efekt świeżości

Polega na silniejszym oddziaływaniu informacji, które nadeszły jako ostatnie (najświeższe), niż tych, które pojawiły się wcześniej.

Zastosowanie w zarządzaniu produktem

Ten problem najczęściej występuje w zarządzaniu backlogiem. Świeższe pomysły, błędy i zadania często wydają nam się podświadomie istotniejsze i niejako wypierają te starsze. Efektem jest trzymanie zadań w „backlogowym limbo” na wieczne niezrobienie i w konsekwencji sztuczne „pompowanie” backlogu do niezarządzalnych rozmiarów.

Jak się bronić?

Ustal sobie z zespołem maksymalny czas jaki dany element może leżeć w backlogu. 1-2 sprinty przed końcem okresu „leżakowania” postaw sprawę na ostrzu noża → albo zadanie ląduje w sprincie albo w koszu. Wprowadzenie i bezwzględne trzymanie się tej zasady „wóz albo przewóz” świetnie weryfikuje faktyczną istotność elementów backlogu.

Efekt utopionych kosztów

Zjawisko polegające na tym, że ludzie mają skłonność do trzymania się wcześniej podjętych decyzji nawet w sytuacji, gdy okazały się one niekorzystne, jeśli tylko były związane z poniesieniem dużych kosztów lub ze znacznym wysiłkiem.

Zastosowanie w zarządzaniu produktem

Często występuje w połączeniu ze złudzeniem planowania, złudzeniem ponadprzeciętności i efektem potwierdzenia. To połączenie stanowi „wybuchową mieszankę” błędów poznawczych, która zatopiła już niejedną firmę. Schemat jest zawsze ten sam: Wpadamy na „genialny” pomysł, który wystrzeli nasz biznes w stratosferę. Mocno niedoszacowujemy koszty związane z wdrożeniem naszego pomysłu w życie.

Zamiast weryfikować pomysł szukamy tylko sygnałów potwierdzających jego „geniusz”. Kiedy już jasne staje się, że projekt będzie kosztował wielokrotnie więcej niż zakładaliśmy, a szanse na zwrot z inwestycji topnieją w oczach konsekwentnie dążymy do realizacji projektu. Nie mogąc pogodzić się z poniesioną stratą, paradoksalnie stratę powiększamy.

Jak się bronić?

Buduj MVP. Szukaj najmniejszego możliwego nakładu pracy jaki pozwoli zweryfikować wartość danego rozwiązania. Im większy projekt tym większa powinna być liczba checkpointów – np. wersja alfa do testowania z wybranymi kilkoma użytkownikami, wersja closed beta do testowania z większą ilością użytkowników zapisanych do programu Early Adopters, wersja open beta dostępna dla wszystkich użytkowników. Każdy etap powinien mieć założony „minimalny próg przejścia”. Jeśli próg nie jest osiągnięty projekt nie przechodzi do kolejnego etapu. Np. możemy założyć, że z 200 użytkowników którym udostępniliśmy wersję closed beta minimum 100 musi skorzystać z dostępu w ciągu 30 dni, aby projekt przeszedł do fazy open beta.

Innym ciekawy, choć dość drastycznym sposób radzenia sobie z wymykającym się spod kontorli kosztem i czasem realizacji projektu jest „short circut” opisany we wspomnianej już książce „Shape up”. Podejście to polega na tym, że projekt jest automatycznie przerywany, jeśli zespół produktowy nie dowiózł go w wyznaczonym terminie. Jedynym odstępstwem od tej reguły jest sytuacja, gdzie zostały już odkryte i rozwiązane wszystkie „niewiadome” i istnieje bardzo duże prawdopodobieństwo, że zespół skończy projekt z maksymalnie dwutygodniowym opóźnieniem (w tzw. cooldown). Takie podejście motywuje zespół do bezwzględnego obcinania zakresu rozwiązania do absolutnego „must have”.

Zaniedbanie miarodajności

Błąd logiczny polegający na podejmowaniu decyzji w oparciu o dane, które są nieistotne, i pomijaniu danych, które są istotne – w szczególności, gdy dane statystyczne na temat miarodajności tych danych są dostępne.

Zastosowanie w zarządzaniu produktem

Ten błąd może występować często na etapie mierzenia skuteczności wdrożonego rozwiązania. Wyobraźmy sobie, że naszym celem jest podniesienie współczynnika konwersji z bezpłatnego okresu próbnego o 10%. Wdrożyliśmy rozwiązanie i porównujemy współczynnik konwersji przed i po. Miesiąc przed wdrożeniem skonwertowało 50 z 200 użytkowników, miesiąc po 62 z 220. Czy współczynnik konwersji podniósł się o 10%? Tak. Kusi nas więc żeby uznać to za sukces i otworzyć szampana. W końcu cały zespół ciężko na to pracował. Jest niestety jeden mały szkopuł – miarodajność (a raczej jej brak).

Jak się bronić?

W podanym wyżej przykładzie poza brakiem miarodajności jest jeszcze jeden problem: wpływ czynników zewnętrznych na wynik testu. W końcu istnieje wiele czynników wpływających na konwersję: praca supportu, działania marketingowe i sprzedażowe itd. Każdy z nich może w istotny sposób zaburzyć wyniki testów w jedną lub drugą stronę.

Aby wyeliminować oba te problemy polecam robienie A/B testów i sprawdzanie istotności statystycznej za pomocą kalkulatora (np. tego: http://tools.ppcblog.com/calculators/split-test.html). W przytoczonym przypadku moglibyśmy wdrożyć rozwiązanie tylko dla połowy wybranych losowo użytkowników i sprawdzać co jakiś czas, czy segment użytkowników z wdrożonym rozwiązaniem konwertuje częściej i czy wynik ten jest istotny statystycznie.

Niestety na istotne statystycznie wyniki często trzeba czekać bardzo długo. W dodatku narzędzia do A/B testów mierzą nam tylko istotność statystyczną faktu że jedna wersja jest lepsza od drugiej, ale nie o ile lepsza. Nie spotkałem się nigdy z narzędziem, które wskazywałoby np. że wersja A jest na 95% lepsza od wersji B o przynajmniej 10%.

Jak sobie z tym radzić? Moim zdaniem najlepiej inaczej podchodzić do definicji samych metryk sukcesu. Zamiast wyznaczać cel zwiększenia współczynnika konwersji o 10%, załóżmy sobie że chcemy poprawić współczynnik konwersji w sposób istotny statystycznie w ciągu maksymalnie 3 miesięcy. Można też założyć większą tolerancję na ryzyko błędu i obniżyć próg z przyjętego powszechnie 95% do np. 90%, czy nawet 80%. Dobrym sposobem jest też wybieranie za cel A/B testu proxy metryki, czyli metryki która jest ściśle skorelowana z metryką, którą chcemy poprawić, lecz dużo łatwiej jest dla niej uzyskać istotność statystyczną A/B testu. Jeśli na przykład zależy nam na poprawieniu konwersji ze strony Cennika, możemy za cel obrać sobie przejście do formularza rejestracji, zamiast samą rejestrację. Zakładając, że nie mamy w planach zmieniać samego formularza rejestracji, a jedynie Cennik, można z dużym prawdopodobieństwem założyć, że zwiększenie konwersji cennik -> formularz rejestracji przełoży się na konwersję cennik -> rejestracja.

Zaniedbanie zakresu

Ten błąd poznawczy charakteryzuje się nie braniem pod uwagę zasięgu problemu przy ocenianiu jego istotności.

Zastosowanie w zarządzaniu produktem

Zaniedbanie zakresu, podobnie jak efekt świeżości może występować przy priorytetyzacji backlogu. Jeśli jakiś problem wydaje nam się istotny do rozwiązania, często zapominamy zadać sobie pytanie jak dużej części użytkowników ten problem faktycznie dotyczy.

Jak się bronić?

Przy priorytetyzacji bugów można zastosować wykres krytyczności problemu i zasięgu (% ilość użytkowników) jego występowania do ustalania priorytetu. Np. błąd możemy uznać za krytyczny jeśli blokuje on zupełnie wykonywanie podstawowych zadań w systemie dla znacznej ilości użytkowników.

Przy priorytetyzacji nowych rozwiązań lub usprawnień z pomocą przychodzi model do priorytezacji RICE, który wyróżnia zakres potencjalnego użycia jako jeden z czterech równoważnych kryteriów (Reach, Impact, Confidence, Effort).

Efekt posiadania

To tendencja do przypisywania wyższej wartości przedmiotom przez nas posiadanych, niż dokładnie tym samym przedmiotom, których nie posiadamy. Mówiąc prościej, człowiek przywiązuje się do rzeczy które posiada.

Zastosowanie w zarządzaniu produktem

Kiedy ostatnio usuneliście nieużywaną funkcję z waszego produktu? Jeśli odpowiedź brzmi „nigdy” no całkiem możliwe, że staliście się ofiarą efektu posiadania. Efekt posiadania jest w tym sensie pewnego rodzaju przedłużeniem efektu utopionych kosztów. O ile jednak efekt utopionych kosztów każe nam skończyć co już zaczęliśmy, o tyle efekt posiadania nie pozwala się nam z tym rozstać.

Jak się bronić?

Des Traynor, współzałożyciel Intercom radzi, aby zmapować wszystkie ważne funkcje naszego systemu na wykresie częstotliwości w zasięgu ich używania. Funkcje używane bardzo rzadko przez bardzo małą część użytkowników są oczywistym kandydatem do usunięcia z systemu. Jednak zanim to zrobisz spróbuj dowiedzieć się jaki jest powód braku adopcji danej funkcji. Może problem nie leży w braku wartości, ale w słabej użyteczności lub odkrywalności. W takim wypadku nie musisz koniecznie spisywać jej na straty. Można nad tym popracować.

Jeśli zainteresowała Cię to podejście polecam przeczytać artykuł Desa.
I na sam koniec pozytywny akcent. Tak, tak, nawet błędy poznawcze mogą mieć pozytywny wymiar 🙂

Efekt Ikea

Ten efekt polega na przypisywaniu większej wartości rzeczom w których powstanie włożyliśmy sami wysiłek. Nazwa pochodzi od eksperymentu w którym badacze udowodnili, że grupa osób którą poproszono o całkowite złożenie mebli IKEA była gotowa zapłacić za nie więcej niż grupa, która składała je tylko częściowo.

Zastosowanie w zarządzaniu produktem

Ten efekt pokazuje dlaczego najlepsze firmy produktowe przywiązują tak wielką wagę do kolaboratywnego rozwiązywania problemów przez wszystkich członków zespołu produktowego.

Jak się bronić? Jak wykorzystać?

Daj zespołowi produktowemu problem do rozwiązania, nie rozwiązanie do wdrożenia. Wyjaśnij zespołowi dlaczego warto rozwiązać dany problem. Jaką wartość dla użytkowników i biznesu może przynieść jego rozwiązanie.

Włącz inżynierów i projektantów w proces discovery. Używaj kolaboratywnych technik rozwiązywania problemu jak warsztaty Design Studio czy User Story Mapping.

Wreszcie przekaż zespołowi informację zwrotną o tym jak użytkownicy zareagowali na wdrożony produkt lub funkcję.

Podsumowanie

Błędy poznawcze są zjawiskiem bardzo powszechnym i dotykają praktycznie każdego z nas. Są bowiem efektem kierowania się intuicją. Intuicja z kolei jest bardzo silnie w nas zakorzeniona i potrzebna. Dzięki niej jesteśmy w stanie szybko wykryć i uniknąć zagrożeń. Problem pojawia się gdy podjęcie dobrej decyzji wymaga logicznego myślenia i wzięcia pod uwagę wielu danych.

Ilość i poziom skomplikowania decyzji podejmowanych w zarządzaniu produktem sprawiają, że Product Managerowie są szczególnie mocno narażeni na błędy poznawcze. Mam nadzieję, że ten artykuł pomoże wam lepiej je rozpoznawać, a zaproponowane techniki ułatwią ich unikanie.