Czytam ostatnio książkę “Inspired”, na którą natrafiłem przypadkiem, czytając bloga o budowaniu produktów Silicon Valley Product Group. Lektura tej książki to obowiązkowa pozycja dla każdego, kto tworzy nowoczesne produkty i chciałby zrozumieć, jak robią to najwięksi gracze, tacy jak m.in. Apple, Netflix, Facebook czy Tesla.
O książce być może napiszę więcej innym razem, natomiast w tym wpisie chciałbym się skupić na ciekawym cytacie autorstwa Johna Doerra, szanowanego inwestora z Doliny Krzemowej:
“We need teams of missionaries, not teams of mercenaries”
Czyli, po polsku mówiąc, potrzebujemy zespołów misjonarzy, a nie najemników. Gdy pomagam klientom usprawniać sposób, w jaki budują produkty, wielokrotnie trafiam zarówno na zespoły najemników, jak i na zespoły misjonarzy. Jak łatwo się domyśleć, te drugie zespoły spotykam zdecydowanie rzadziej. Obserwowałem to zjawisko od lat, jednak brakowało mi dobrej metafory, żeby dobrze zobrazować to rozgraniczenie.
Jak rozpoznaję zespół najemników?
Zespół najemników zbuduje to, co im każesz. Płacisz złotem, więc wymagasz. Nie ma znaczenia co to będzie, ten zespół w sposób rzemieślniczy podejdzie do tego zadania. Będą realizować dokładnie to, co dostarczysz im w precyzyjnych wymaganiach. Nie spodziewaj się wybitnego zaangażowania w zespole, wychodzenia poza realizację swojego kawałka roboty, poczucia odpowiedzialności za produkt, przywództwa czy zrozumienia dla kogo i po co go budujemy. Jak będzie do zrobienia zielony guzik na stronie, to dostaniesz zielony guzik na stronie. Kropka.
Jak rozpoznaję zespół misjonarzy?
Zespół misjonarzy wierzy w wizję produktu i jest zaangażowany w rozwiązywanie rozwiązywanie problemów użytkowników. Znają i rozumieją produkt, który tworzą. Chcą zrozumieć dlaczego coś mają zrobić, i dopiero kiedy to zrozumieją, zaproponują Ci paletę możliwych rozwiązań #chińskiemenu. Dbają o produkt, który budują, identyfikują się z nim i chcą, aby był możliwie najwyższej jakości. Nie akceptują — jak to zwykł określać Tomek Włodarek — dziadostwa, wychodzą poza utarte schematy i zrobią dla produktu więcej, niż mógłbyś się spodziewać.
Jak zamienić zespół najemników w zespół misjonarzy?
Nie rozum mnie źle. To nie jest tak, że najemnicy są źli. W końcu ktoś zatrudnił tych ludzi, prawda? Zwykle to firmy, poprzez swoje działania (lub ich brak), wykształcają sobie takie, a nie inne zespoły. Wynika to najczęściej z braku wiedzy, uwarunkowań systemowych, kultury organizacyjnej oraz tego, jak budowane są produkty w firmie.
Poniżej zamieszczam kilka wybranych, sprawdzonych sposobów na to, co można zrobić, aby zespoły najemników miały szansę stać się zespołami misjonarzy.
- Zapewniaj wizję produktu – zespoły potrzebują wiedzieć, dlaczego budują konkretny produkt, kto jest jego odbiorcą/użytkownikiem oraz jakie problemy produkt ma rozwiązać. Kiedy znają ten kontekst, ich praca nabiera sensu. Narzędziem z którego osobiście korzystam najczęściej jeśli chodzi o wizję produktu, to Product Vision Board.
- Angażuj zespół w proces product discovery – budowanie wizji produktu jest elementem większego proces odkrywania produktu. Proces ten pozwala nam na szybką naukę oraz walidowanie hipotez produktowych. Uczestnictwo zespołu w tym procesie daje mu bezcenny kontekst, którego znajomość procentuje w przyszłości. Przykładowo, na etapie odkrywania produktu może powstać persona użytkownika będąca osobą na emeryturze, przez co gdy zespół będzie budował aplikację mobilną będzie wiedział, że design produktu powinien być czytelny a wszelkie przyciski i napisy wystarczająco duże.
- Umożliwiaj zespołowi kontakt z końcowym użytkownikiem – możliwość doświadczenia i obserwowania tego, jak użytkownik korzysta z naszego produktu, najlepiej w faktycznym miejscu jego pracy, jest doznaniem, które trudno porównać z czymkolwiek innym. Taka możliwość pozwala zespołowi spojrzeć na produkt z perspektywy użytkownika oraz odczuć jego codzienne problemy oraz frustracje, co przekłada się na późniejsze zaangażowanie w rozwiązywanie dostrzeżonych problemów. Na bazie mojego doświadczenie, pośród grupy użytkowników zawsze znajdą się osoby, które chętnie pomogą Ci usprawnić Twój produkt.
- Zapewniaj kontekst biznesowy w Backlogu Produktu – niezmiennie często widzę elementy w Backlogu Produktu, które nie dostarczają wystarczającej informacji na temat kontekstu biznesowego. Jest wprawdzie napisane, co należy zrobić, ale nie jest napisane dlaczego. Zwykle wystarczą jedno-dwa zdania obrazujące tło biznesowego elementu, aby zespół, na bazie dostarczonej wiedzy, mógł zaproponować sensowne rozwiązanie.
- Buduj trwałe zespoły wokół produktów/ficzerów/obszarów – rozwiązywanie zespołów po realizacji projektu, ciągłe przenoszenie ludzi z zespołu do zespołu oraz rozkładanie jednej osoby na kilka zespołów, nie wpiera procesu budowania zaangażowanych zespołów. Jeśli ciągle przenosimy ludzi z miejsca na miejsce, trudno oczekiwać, że wykształci się w nich poczucie odpowiedzialności za produktu, skoro co chwilę coś innego jest dla nich produktem.
- Zapewnij sensownego Właściciela Produktu – porządny Właściciel Produktu umie zaangażować zespół, dostarczając mu niezbędny kontekst biznesowy oraz zbliżając go do końcowego użytkownika. Nabór na Właścicieli Produktu nie powinien odbywać się na zasadzie łapania przypadkowej osoby na korytarzu firmowym, na zasadzie “Hej, od dzisiaj będziesz PO!”. To odpowiedzialna rola, która ma duży wpływ na to, jak funkcjonować będzie zarówno produkt, za który odpowiada, jak i sam zespół.
- Usuwaj przeszkody, które demotywują zespół – nie rozwiązywane przez dłuższy czas problemy (np. brak indywidualnego środowiska testowego, nieobecność Właściciela Produktu, brak wizji firmy) potrafią pozbawić motywacja najwytrwalszych członków zespołów. Wspieraj osoby, którym (jeszcze) chce się walczyć z przeszkodami i mają energię, aby pomimo problemów nie poddawać się. Co ważne, taką osobą nie musi być Scrum Master — może to być zaangażowany deweloper lub osoba z biznesu.
- Dawaj autonomię zespołom – Dan Pink, autor książki Drive, wyróżnia trzy czynniki mające wpływ na wewnętrzną motywację ludzi: mistrzostwo, poczucie celu oraz autonomii. Nie oznacza to, że zespoły mogą robić co chcą i jak chcą. Oznacza to, że w określonych ramach, mogą podejmować autonomiczne decyzje. Przykładem autonomii może być jasne sformułowanie problemów oraz potrzeb użytkowników, przy jednoczesnym pozostawieniu sposobu rozwiązania zespołowi.
- Przeanalizuj swój proces rekrutacji – miejsca, w których poszukujesz kandydatów, pytania które im zadajesz, sposób w jaki prowadzona jest rekrutacja — wszystko to może zarówno przybliżać Cię jak i oddalać od zaangażowanych zespołów. Warto omówić z kandydatem zarówno to, w jaki sposób pracował we wcześniejszych firmach, jak i przedstawić wizję sposobu pracy w nowej firmie.
Powyższe przykłady to zapewne wycinek możliwości. Widzisz dodatkowe lub alternatywne opcje? Napisz o nich w komentarzach.
Photo by Jonathan Brinkhorst on Unsplash
8 odpowiedzi
Jacku, wielkie dzięki za wpis. Potrzebna mi była taka synteza sposobów na pozytywne „poruszenie” zespołu. Bardzo podoba mi się to co napisałeś i zgadzam się z Twoim podejściem 100%. Lubię szczególnie ten kawałek dotyczący wyboru PO, bo wciąż wraca do mnie takie przekonanie, że jak mamy mocnego PO to osiągnęliśmy połowę sukcesu.
Dziękuję Daniel za komentarz. Cieszę się, że trafiłem w potrzebę :) Dobry PO to połowa sukcesu = pełna zgoda.
Kazdy medal ma dwie strony.
Zespół najemników zrobi Ci zielony przycisk według Twojej specyfikacji. Na Tobie jako kliencie spoczywa odpowiedzielność za racjonalność tego pomysłu. Ty musisz wiedzieć czy stworzenie tego guzika ma sens i czy kolor zielony to właściwa barwa. Zespół najemników nie będzie tego rozważał, za to zadba o testy jednostkowe i zgodność ze specyfikacją.
Zespół misjonarzy przed podjęciem pracy zrobi spotkanie na którym podważy sens umieszczania tego przycisku. Zaproponuje umieszczenie wzamian dwóch przycisków, które co prawda będą bardziej elastycznym rozwiązaniem, ale za to czas realizacji i koszty wzrosną dwukrotnie. W zamian będziesz miał lepszy produkt choć lepszy w sensie technicznym nie zawsze oznacza lepszy w sensie biznesowym.
Zauważ, że dążenie do technicznej i funkcjonalnej perfekcji stoi często w opozycji do efektywności finansowej inwestycji, a z doświadczenia wiem, że o ile członkowie zespołu bardzo chętnie usparawniają, optymalizują czy uniwersalizują projektowane rozwiązania to z dużą niechęcia podchodzę do pomysłów redukcji, ograniczania czy minimalizacji z uwagi na koszty.
Reasumując zespół misjonarzy tak, ale bez najemnika z kalkulatorem się nie obejdzie.
Dziękuję Zbigniew. Trafia do mnie Twoja obserwacja o niechęci do redukowania, ograniczania czy minimalizacji z uwagi na koszty, mam podobne obserwacje.
Dostrzegam ryzyko o którym piszesz, że kreowanie rozwiązań może podnosić koszty. Natomiast oczami wyobraźni widzę, że misjonarz też może obsługiwać kalkulator.
Celne określenia. Myślę, że większość, jeśli nie każdy zespół, zaczyna jako najemnicy. Na zaangażowanie w produkt i uznanie go za swój, potrzeba czasu. Zwykle zespoły są gdzieś pomiędzy najemnikami a misjonarzami:) Dobrze jak zmierzają w stronę misjonarzy.
Dziękuję Agnieszka. Słuszna uwaga dotycząca czasu. Nawet jak wiemy co trzeba zrobić aby przesunąć się w stronę misjonarzy, to nadal potrzebujemy na to czasu.
Jest już druga edycja książki Inspired:
https://www.amazon.com/INSPIRED-Create-Tech-Products-Customers/dp/1119387507/
Dzięki Paweł. Zaktualizowałem link we wpisie.