10 powodów skutecznego rozwoju produktu
Dokładnie rok temu zostałem zaproszony na konferencję Craft w Budapeszcie, gdzie mówiłem o 10 głównych powodach niepowodzeń zespołów produktowych. Mówiłem wtedy głównie o tym, dlaczego wiele zespołów jest tak nieefektywnych, i – wbrew wszelkim twierdzeniom – większość organizacji nadal nie jest naprawdę „zwinna", bo nadal działa według modelu kaskadowego. Dlatego w tym roku zostałem ponownie zaproszony na konferencję, by opowiedzieć o tym, jak pracują najlepsze znane mi zespoły. Ten artykuł jest podsumowaniem mojego wystąpienia.
Po moim pierwszym wystąpieniu skontaktowało się ze mną kilka osób z prośbą o więcej informacji. Oprócz rady, by przeczytały moją książkę lub wzięły udział w warsztacie, nie czułem, że jestem w stanie dać im satysfakcjonującej odpowiedzi. To zainspirowało mnie do głębszego zastanowienia się nad najważniejszymi cechami wyjątkowo silnych zespołów produktowych. Opracowałem więc swoją osobistą Top 10.
Continuous Discovery i Delivery
Tak jak opisałem dziesięć największych problemów z modelem kaskadowym, opisałem też dziesięć cech udanych zespołów w kontekście Continuous Discovery i Delivery (zwanych też Dual Track Agile, Discovery Sprints lub Delivery Sprints). Jakie są więc czynniki sukcesu w skutecznym wytwarzaniu produktu?
1. Upełnomocnione zespoły produktowe
Najważniejszym czynnikiem jest absolutnie fundamentalna koncepcja silnych zespołów produktowych. Ale co to właściwie oznacza?
Po pierwsze ważne jest, żeby zespół istniał przez dłuższy czas w tej konfiguracji, a członkowie nie byli przesuwani jak figury szachowe. Jeśli zespoły mają być innowacyjne, potrzebują czasu, by dowiedzieć się więcej o sobie, technologii, klientach i kontekście biznesowym.
Po drugie istotna jest również chemia między członkami zespołu. Oznacza to, że powinni się wystarczająco dobrze znać i szanować, by każdy członek czuł się wystarczająco komfortowo, by proponować rozwiązania i motywować siebie i innych do coraz lepszych wyników.
Po trzecie zespół powinien dysponować pewną różnorodnością umiejętności, która zazwyczaj obejmuje zarządzanie produktem, projektowanie UX i programowanie. Często dochodzi do tego analiza danych i badania użytkowników.
I wreszcie korzystne jest, gdy wszyscy członkowie zespołu pracują razem w jednym miejscu – choć dla wielu firm nie jest to prosta sprawa. Menedżerowie produktu, projektanci produktu i deweloperzy (lub przynajmniej lider zespołu deweloperskiego) powinni mieć biurka obok siebie. Niestety nie zawsze jest to możliwe, ale można przynajmniej próbować. I żeby to wyjaśnić – nie chodzi o to, że poszczególne zespoły w różnych miejscach stanowią problem. Negatywny wpływ na velocity, a przede wszystkim na innowacje, ma sytuacja, gdy członkowie tego samego zespołu są rozdzieleni geograficznie.
2. Wizja i strategia produktu
Aby uzyskać naprawdę upełnomocnione i autonomiczne zespoły produktowe, członkowie muszą dobrze rozumieć kontekst biznesowy. Zaczyna się to od jasnej i przekonującej wizji produktu i drogi do jej realizacji: strategii produktu.
Wizja produktu opisuje świat, który chcemy stworzyć w ciągu najbliższych dwóch do pięciu lat (w przypadku sprzętu zazwyczaj nieco dłużej).
Wizja produktu musi być inspirująca. Dobra wizja produktu jest jednym z naszych najskuteczniejszych narzędzi rekrutacyjnych i motywuje ludzi do codziennego przychodzenia do pracy. Inspirująca wizja przyciąga dobrych specjalistów, bo chcą być częścią czegoś znaczącego.
Strategia produktu to kolejność produktów, które chcemy dostarczać na drodze do realizacji wizji. Złą strategią byłoby próbowanie zadowolenia wszystkich interesariuszy jednym wydaniem. Zamiast tego mamy priorytetową listę rynków, geografii lub person i skupiamy się na dopasowaniu produktu do danego rynku.
Im więcej zespołów produktowych, tym ważniejsza jest jednolita wizja i strategia, by każdy zespół mógł podejmować właściwe decyzje.
Najważniejsze jest jednak to, by wizja produktu była inspirująca, a strategia produktu świadomie określona.
3. Business Outcome
Drugą częścią kontekstu biznesowego, której potrzebuje upełnomocniony i autonomiczny zespół, by podejmować dobre decyzje, jest zestaw priorytetowych celów biznesowych. System OKR (Objectives and Key Results) jest do tego właśnie przeznaczony.
OKR odzwierciedlają listę konkretnych problemów biznesowych, które zespół ma rozwiązać. Nie są to jednak funkcje. Funkcje to tylko potencjalne rozwiązania problemów. Ukończenie funkcji nie czyni zespołu sukcesem; sukcesem jest rozwiązanie rzeczywistego problemu.
Dwie zasady stojące za tymi metodami zarządzania wydajnością to:
1) Zespoły osiągają lepsze wyniki, gdy daje się im problemy do samodzielnego rozwiązania, zamiast podawać gotowe rozwiązania.
2) Zespół jest mierzony na podstawie rezultatów, a nie outputu. Dostarczanie funkcji z roadmapy to output; rozwiązanie problemu biznesowego to rezultat.
4. Kompetentny menedżer produktu
Niestety większość deweloperów nigdy nie miała okazji pracować z kompetentnym menedżerem produktu. Ci, którym się to zdarzyło, to właśnie ci, którzy nalegają, by zawsze mieć taką osobę w zespole. I co gorsza, wielu deweloperów nie wie nawet dokładnie, co menedżer produktu powinien wnosić do zespołu.
Wyobraź to sobie tak: aby zespół produktowy mógł rozwiązywać prawdziwe problemy biznesowe, nie wystarczy, że rozwiązanie działa technicznie lub że klient je pochwala. Rozwiązanie musi też działać dla Twojego biznesu – i to często jest najtrudniejsza część.
Zastanów się, co to oznacza. Wyobraź sobie, że pracujesz dla Ubera lub Airbnb i musisz radzić sobie ze złożonymi przepisami, grupami pracodawców i związkami zawodowymi. Albo weź eBay, gdzie trzeba było pokonać poważne ograniczenia, by być klasyfikowanym jako marketplace, a nie strona e-commerce. Albo Tesla, gdzie należało wyjaśnić kwestie odpowiedzialności za autopilota. Każda firma ma własną listę takich przeszkód do pokonania:
Prawne, finansowe, sprzedażowe i cenowe, związane z marką i marketingiem, ochrona danych, bezpieczeństwo, warunki współpracy itd.
Niestety jedyną osobą, która to wszystko rozumie, jest dyrektor generalny, i w tym przypadku można zrozumieć, dlaczego tak trudno mu upełnomocnić zespół do samodzielnego podejmowania właściwych decyzji.
Są trzy sposoby pracy zespołu. Pierwszy: dyrektor lub inny przełożony decyduje o wszystkim. Drugi: menedżer produktu zwołuje duże spotkanie i dyskutuje wszystko z całym zarządem („Design By Committee"), co zazwyczaj daje słabe wyniki. Trzeci: menedżer produktu wykonuje swoją pracę, zajmuje się przeszkodami i przekazuje je członkom zespołu, by mogli samodzielnie opracować rozwiązanie problemu.
Połącz to z dobrym rozumieniem technologii i dogłębną znajomością użytkowników i klientów – a wtedy masz nadzieję zobaczyć, dlaczego jest to trudna, ale absolutnie niezbędna rola dla zespołu produktowego, zwłaszcza gdy zespół ma mieć sensowny stopień autonomii.
5. Rozwiązania przez współpracę
„Współpraca" nie powinna być tu tylko hasłem. Chodzi mi po prostu o to, że trzy obszary – produkt, design i programowanie – powinny współpracować przy rozwiązywaniu problemu, zamiast menedżer produktu „przekazywał wymagania", designer opakowywał wszystko ładnie, a deweloperzy pisali kod, który jest od nich wymagany. Powód jest taki, że w dobrych rozwiązaniach technologia i funkcjonalność napędzają się nawzajem. Technologia umożliwia określone opcje designu, podobnie jak design wpływa na wybór technologii. A decyzje designowe wpływają na funkcjonalność – i odwrotnie.
Technologia, projektowanie UX i funkcjonalność są ze sobą splecione. Dobre rozwiązania powstają przez ciągłe wahania tam i z powrotem, nieustanne dawanie i branie między trzema obszarami.
To też główny powód, dla którego zespoły pracujące razem w jednym miejscu są w zasadzie zawsze lepsze od tych, które tak nie pracują.
6. Product Discovery: Szybkie uczenie się
Świetne produkty mają wiele wspólnego ze zdolnością zespołu do szybkiego testowania wielu pomysłów. Chcemy jak najszybciej oddzielić dobre pomysły od złych. Product Discovery obejmuje cały zestaw technik, które pomagają nam szybko ustalić, które pomysły są świetne, a które nie do końca. Niektóre pomysły są naprawdę doskonałe, inne mniej. Jedne są ryzykowne, inne kosztowne. Czasem potrzebujemy dowodów, innym razem wystarczą poszlaki.
Ludzie opisują to na różne sposoby. Niektórzy trzymają się powiedzenia „fake it before you make it", co znaczy „udawaj, zanim zrobisz to naprawdę". Inni podkreślają, że należy budować rzeczy, które się nie skalują. Ważne, żebyśmy szybko się uczyli i minimalizowali marnotrawstwo.
Zlecanie zespołowi deweloperskiemu zbudowania prawdziwego produktu i wypuszczenia go na rynek w celu przetestowania pomysłu to chyba najwolniejsza i najdroższa metoda nauki.
7. Skupienie na głównych ryzykach
W Product Discovery jest kilka ważnych kwestii do rozważenia.
Przede wszystkim musimy skupić się na czterech głównych ryzykach:
Wartość – czy ktokolwiek kupiłby ten produkt lub chciał go używać?
Użyteczność – czy klienci rozumieliby, jak go używać?
Wykonalność – czy nasi deweloperzy mogą zbudować produkt przy dostępnej im technologii, czasie i umiejętnościach zespołu?
Interesariusze – czy wszyscy zainteresowani w firmie zgadzają się z proponowanym rozwiązaniem?
Product Discovery to poszukiwanie dobrych odpowiedzi na te cztery pytania. Gdy je znajdziemy, mamy niezbędne dowody i jesteśmy pewni, że zespół deweloperski może wdrożyć i dostarczyć wysokiej jakości, skalowalnie rozwiązanie.
8. Rola MVP
Koncepcja Minimum Viable Product jest jedną z najważniejszych koncepcji w wytwarzaniu produktu, a jednocześnie jedną z najczęściej błędnie stosowanych i rozumianych.
Generalizowanie jest zawsze ryzykowne, ale odważę się stwierdzić, że MVP nigdy nie powinno być produktem. Za każdym razem, gdy trafiałem na zespół, który z dużym nakładem czasu i pieniędzy zbudował MVP, mogłem im następnie pokazać, jak mogliby uzyskać ten sam efekt uczenia się przy znacznie niższych kosztach i znacznie mniejszym marnotrawstwie.
MVP to zatem eksperyment – test. Zazwyczaj jest to rodzaj prototypu. Często jest to prototyp dla użytkownika, ale czasem też prototyp oparty na danych na żywo lub stosowany w badaniach wykonalności. I czasem jest mieszanką tych rzeczy. W każdym przypadku jest to zawsze tylko mała część wytwarzania prawdziwego produktu.
9. Product Delivery: Bez kompromisów przy wydaniu
Nie chodzi mi tutaj o mówienie deweloperom, jak mają wytwarzać i wydawać oprogramowanie. Wręcz przeciwnie. Problem, który pojawia się, gdy zespół deweloperski musi wytwarzać MVP, polega na tym, że często czuje się zmuszony do wydawania oprogramowania, co do którego nie jest przekonany. Nie stoi za nim w pełni. Może istnieją problemy z niezawodnością, skalowaniem lub wydajnością, ale menedżer produktu ciągle powtarza: „To tylko MVP, spokojnie!"
Mówię po prostu, że nie należy robić kompromisów w kwestii oprogramowania, na którym klienci polegają, by utrzymać swój biznes. Istnieje wiele dobrych technik Product Discovery do testowania MVP, które chronią naszych klientów, przychody, reputację i pracowników.
Korzystaj więc z najlepszych praktyk i wydawaj produkty tylko wtedy, gdy masz pełne zaufanie do danego wydania.
10. Obsesja na punkcie klienta
Ten ostatni punkt idzie w nieco innym kierunku. W prawie każdej firmie, do której trafiam, mówi się mi, jak bardzo kocha się klientów. Zazwyczaj jest to część wartości lub misji firmy. Łatwo to powiedzieć, ale znacznie trudniej naprawdę tak postępować.
Szybko to zauważam, gdy rozmawiam z zespołem. Jak zespół reaguje, gdy pojawia się problem z klientem? Jak pilne to jest? Czy zespół kontaktuje się z klientem, by w razie potrzeby lepiej go zrozumieć? Czy członkowie zespołu znają klientów z imienia? Jaką mają z nimi relację? Czy klienci ich irytują, czy może są dla nich raczej jak współpracownicy?
Najlepszym sposobem na wzbudzenie prawdziwej empatii i zaangażowania wobec klientów jest bezpośredni kontakt członków zespołu (zwłaszcza deweloperów) z klientem.
Mam nadzieję, że pomoże Ci to lepiej zrozumieć, co cechuje świetne zespoły produktowe.
Tekst pochodzi z bloga Marty'ego Cagana i został przetłumaczony przez nas na język polski.
Outcome vs. Output
=> Zrozumieć Minimum Viable Product (MVP)
