Hipotetyczny model działu produktowego

Chodzi mi po głowie od jakiegoś czasu pewien koncept ustrukturyzowania działu produktowego. Widziałem wiele ciekawych modeli w działaniu, ale to, co chcę przedstawić poniżej opiera się na zupełnie nowej (dla mnie) idei. Gdy o niej usłyszałem wszystko „kliknęło” na swoje miejsce i powstał, mam nadzieje, całkiem sensowny sposób na zbudowanie zespołu produktowego. Ten model jest hipotetyczny, jego fragmenty widziałem w kilku organizacjach, ale jeszcze nigdzie nie został w pełni wdrożony (o ile wiem). Mam nadzieję, że mi się uda. Publikuje go tutaj, bo liczę, że inni doświadczeni produktowcy dodadzą swoje trzy grosze, wytkną mi dziury logiczne i potencjalne niezamierzone konsekwencje.

Idea

Podstawowe założenie wynika z obserwacji, że obecnie dwa główne cele produktu w środowisku cyfrowym to:

1. Wzrost (Growth, G)
2. Monetyzacja (Revenue, R)

Ze względu na charakterystykę rynku cyfrowego i dążącego do zera kosztu marginalnego uzyskania nowego użytkownika (klienta) łatwiej jest osiągać większą skalę działania – a jednym z najważniejszych czynników wpływających na wycenę produktu jest jego „trakcja” czy szybkość zdobywania skali (nasycania rynku). Skalę zdobywa się po to, aby w pewnym momencie zacząć zarabiać dzięki użytkownikom, a więc monetyzować produkt. Istotne jest, aby monetyzacja rozpoczęła się w odpowiednim momencie skalowania. Zbyt wczesna monetyzacja spowolnia wzrost. Zbyt wolna monetyzacja doprowadzi do braku funduszy na rozwój (rozwiązaniem tego problemu są fundusze VC, ale to temat na inny post).

Relacja między G i R

Celem G jest zwiększanie liczby użytkowników. Celem R jest zwiększanie wartości użytkownika. Faktyczna wartość produktu to (uogólniając) liczba użytkowników pomnożona przez średnią wartość użytkownika. Wartość produktu zmienia się gdy któryś z tych elementów (lub obydwa) się zmieniają.

Im dłuższa i intensywniejsza jest interakcja między użytkownikiem a produktem tym wartość tego użytkownika jest większa. Jednocześnie takich użytkowników jest znacznie mniej niż tych, którzy zetknęli się z produktem po raz pierwszy i nic więcej nie zrobili (np. nie przekowertowali na płacącego użytkownika):

Wracając do wartości produktu (czyli liczba użytkowników pomnożona przez średnią wartość użytkownika). Zwiększenie pierwszego czynnika poprawia biznes (więcej użytkowników to większa pula do konwersji) jak i zwiększenie drugiego poprawia biznes (lepsza konwersja pozwoli więcej wyciśnąć z tego co teraz mamy). Najlepiej oczywiście jednym ruchem podnosić obydwa wskaźniki, ale katalog takich działań jest bardzo mały, gdyż G i R mają różne cele, a więc różne obszary aktywności (z jednym wyjątkiem). 

G opiera się na poprawie wskaźników takich jak:

• szybkość zdobywania nowych użytkowników,
• zwiększanie powracalności obecnych użytkowników,
• wydłużanie/skrócenie czasu spędzonego na stronie*,
• zwiększenie/zmniejszenie liczby odsłon na użytkownika*
• konwersja na płacącego użytkownika

* W e-commerce i SaaS często lepiej jest skracać czas trwania sesji czy liczbę odsłon aby uprościć ścieżkę użytkownika. W mediach (biznesach opartych na wyświetlaniu reklam) dokładnie odwrotnie.

Efektem pracy nad G może być poprawienie szybkości działania aplikacji, stworzenie programu lojalnościowego, atrakcyjne oferty dla first-time user, tworzenie systemów „member gets member”, wplatanie social sharingu.

R opiera się na poprawie wskaźników takich jak:

• konwesja na płacącego użytkownika,
• koszt pozyskania użytkownika,
• średni koszyk użytkownika,
• wartość użytkownika w czasie (LTV),
• marża (jeśli dotyczy)

Efektem pracy R jest zwiększanie przychodu produktu przez tworzenie rozwiązań ułatwiających zakup lub inną formę monetyzacji (jak liczba klikniętych/obejrzanych reklam). Efektem pracy na R może być wdrożenie upsellingu, system segmentowania użytkowników w celu lepszego targetowania, system rekomendacji oparty na poprzednich zakupach.

Jak widać zarówno G jak i R zależy na podwyższaniu konwersji (CVR). Dla G konwersja jest ostatnim kulminacyjnym punktem. Dla R to początek pracy. W teorii wszystkie działania podwyższające CVR powinny podnosić zarówno Growth jak i Revenue.

Dział produktowy oparty o G i R

Jeśli założymy, że powyższa idea jest bliski rzeczywistości to należy zastanowić się jak ustrukturyzować dział produktowy, ale najlepieją ją odzwierciedlić.
Na ten moment mam poczucie, że najlepiej sprawdzi się struktura, w której mamy Head of Product, zespół odpowiedzialny za Growth i zespół odpowiedzialny za Revenue.

Head of Product jest arbitrem gwarantującym merytoryczne rozwiązywanie problemów oraz zapewnia jasną i transparentną komunikację między zespołami. Poza tym dba o wysokopoziome realizowanie strategii firmy oraz zarządza wymaganiami interesariuszy. Jest także właścicielem backlogu produktu.

Zespoły G zajmuje się rozwojem funkcji zwiększających liczbę użytkowników (i pochodnych wskaźników opisanych wyżej). Zespół R zajmuje się poprawą monetyzacji (i pochodnych). Obydwa są w pełni samodzielne kompetencyjne, tzn. każdy z nich bez większej pomocy z zewnątrz jest w stanie wymyśleć, zaprojektować i wdrożyć dowolną funkcję. 

Obydwa zespoły płynnie kooperują i współzawodniczą w zależności od tego,  co chcą osiągnąć. Wzajemnie też debatują całościową wartość wdrażanych funkcji szukając takich, których sumaryczna wartość będzie pozytywna zarówno dla Growth i Revenue (jak na przykład wspomniana wyżej konwersja). Tam gdzie nie jest to możliwe trwa debata (której katalizatorem jest Head of Product) i określanie w jakich warunkach dana funkcja jest akceptowalna. Każda ze stron (HoP, Growth team lub Revenue Team) może postawić veto czego efektem jest wykasowanie funkcji z backlogu.

Przykład 1: Growth chce wdrożyć kupon 50% dla każdego pierwszego użytkownika gdyż zdaniem zespołu to podwyższy dwukrotnie liczbę ściągnięć aplikacji. R ma wątpliwości, gdyż koszt pozyskania użytkownika znacznie wzrośnie na co nie mogą sobie pozwolić przy obecnej wielkości średniego koszyka. Trwa debata jaka wartość kuponu jest akceptowalna i co obydwa działy mogą zrobić aby bilans był pozytywny

Przykład 2: Revenue chce wdrożyć upselling w procesie płatności, aby zwiększyć średnią wielkość koszyka. Growth mówi, że rozpraszanie użytkownika na poziomie koszyka obniży konwersję a przy okazji może zbudować na rynku poczucie, że system jest skomplikowany i spamuje. Trwa rozmowa o charakterystyce upsellingu i sytuacjach gdy jest on potrzebny, a gdy przeszkadza. 

Intencjonalne zderzanie ze sobą zespołów, którym przyświecają różne cele, tworzy wewnętrzny system „check and balances” i ułatwia dochodzenie do sedna. Odpowiednio zdefiniowane zasady komunikacji (podstawowa rola Head of Product) pozwalają nawet z burzliwych dyskusji wyjść z merytorycznym rozwiązaniem, które nie jest zgniłym kompromisem. 

Head of Product wciąż jest właścicielem backlogu, a więc ostatecznie na nim spoczywa odpowiedzialność za realizowane zadania i spójność ze strategią firmy. Powinien jednak scedować codzienną prace nad rozwojem produktu na zespoły, które same mają decydować co jest najlepsze dla produktu.

Zespoły walczą o swoje cele, patrzą sobie na ręce, czasem zawiązują alianse, czasem kłócą o to, czyje ma być na wierzchu. To jest potrzebne – podczas tych tarć powstają najlepsze pomysły. Obydwa zespoły wiedzą, że nie ma sensu pokazywać konceptu, który nie jest dobrze przemyślany, bo druga strona szybko to zauważy. Gdy jednak trzeba współpracować to obydwie strony wnoszą całą swoje dziedzinowe doświadczenie. Oczywiście ten model zakłada, że zatrudniamy pracowników, którzy są w stanie bronić swoich racji, ale są jednocześnie otwarci na krytykę i debatę.

W wyjątkowych momentach (lub gdy zaczyna pojawiać się ryzyko rękoczynów:) wkracza Head of Product. Jego rolą jest studzenie nastrojów, klarowanie sytuacji i przypominanie jaki jest cel ich pracy – zwiększanie wartości produktu (czyli liczba użytkowników pomnożona przez średnią wartość użytkownika).