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).

Niedziela, 14:42

Niedziela, 14:42.

Marcin G. zajmujący się w PizzaPortal social media wysłał maila o niespotykanie dużej liczbie komentarzy na Facebooku o zamkniętych w środku dnia restauracjach w PizzaPortal.pl na terenie Rumii, Białegostoku i Gdyni. Przeczytałem to szybko, sprawdziłem, że na moim iPhonie wszystko ok, na wszelki wypadek sprawdziłem także mobile web – nie widać nic podejrzanego. 

Na szybko w głowie znalazłem kilka powodów takiej sytuacji: chwilowa przerwa z dostępem do prądu w restauracjach, statusy ich dostępności nie odświeżyły się na czas jak w innych kanałach. Subiektywne połączenie kilku odseparowanych przypadków… Jednym słowem – wysokie prawdopodobieństwo fałszywego alarmu.

Chwilę później dostajemy wiadomość, że „Gdańsk także padł”. O 14:58 pisze do mnie Adam, nasz product owner, że sprawa zaczyna wyglądać poważnie. Minutę później zaczynamy rozmawiać przez telefon, w tym czasie zdążyłem już rozłożyć moje mobilne biuro w kawiarni na Saskiej Kępie obok której przechodziłem z moją Pauliną (widząc co się dzieje Paulina poprosiła o menu).

Podczas rozmowy sprawdziłem statystyki: zamówień wykonanych na Androidzie są trzykrotnie mniej niż powinno być w stosunku do analogicznych niedziel o tej samej porze, ale nie zauważyłem żadnych problemów z innymi platformami. Adam będąc ciągle na linii potwierdza, że aplikacja PP na Androidzie w każdym sprawdzanym mieście pokazuje wszystkie restauracje jako zamknięte. Czyli to już nie tylko Trójmiasto i Białystok…

Zaczynam w głowie wyliczać potencjalne hipotezy. Z nich ta,  że problem jest ograniczony tylko do Androida zaczyna mieć największy sens. Ma to swoje dobre i złe strony. Dobra jest taka, że tylko jeden kanał jest odcięty a zła, że to nie jest tymczasowa usterka całego backendu a systematyczny błąd.

Gdyby problem pojawił się na więcej niż jedna platformie to nasze poszukiwania skierowałyby się w stronę API, ale wszystko wskazywało na problem z samą aplikacją. Poprosiłem Adama, aby odczekał jeszcze 10 minut i jeśli nic się nie poprawi to żeby napisał wiadomość na specjalną skrzynkę Emergency do naszego działu IT Ops – chciałem dać ostatnią szansę przypadkowi. Kiedy my będziemy sprawdzać hipotezę z aplikacją, IT Ops zajmie się tematem API.

15:23. Informuję na kanale na Slacku nasz zespół w Senfino o problemie. Dawid (proxy product owner) z Marcinem L. (Android Dev) zaczynają analizować sytuację.

15:33. Wysyłam na grupę mailową managementu PP trzyakapitowe streszczenie sytuacji.

15:37. Przychodzi zamówiona przez Paulinę sałatka.

15:40. Dzwoni Tomek (CEO Senfino) i zestawia trójstronne połączenie z Dawidem (proxy product owner po stronie Senfino). Mamy dwie kwestie do przedyskutowania: skąd wziął się problem oraz, ważniejsze w tym momencie, jak możemy ograniczyć szkody.

Okazuje się, że błąd leżał w sposobie parsowania godzin otwarcia restauracji. Informacje o niedzieli podawane w API zostały źle zinterpretowane przez klienta (aplikację na Androidy). W poniedziałek sześć dni wcześniej wrzuciliśmy do Google Play wersję z ogromną dawką refactoringu kodu, w którym godziny otwarcia była jedynie małym fragmentem poprawek.

Ten błąd był na tyle paskudny, że jedynie dawał znać o sobie w niedzielę, więc nasze standardowe QA działające od poniedziałku do piątku nie miało jak go wykryć. W każdym razie błąd został znaleziony. Teraz tylko musimy szybko go naprawić, aby ograniczyć problemy.

Rozważaliśmy powrót do poprzedniej, działającej wersji, ale robiąc tak stracimy mnóstwo wartościowych poprawek, a także nasz nowy system wysyłania wiadomości do użytkowników wewnątrz aplikacji. Inną opcją było jak najszybsze wdrożenie poprawki i wgranie niej do Google Play. Obydwie z tych możliwości nie były dobre z prostego powodu: użytkownicy Androida bardzo wolno przechodzą na nową wersję software’u – większość z nich zauważyłaby aktualizację dopiero w przyszłym tygodniu, a my musimy zrobić coś teraz.

Zbliżał się wieczór, początek zwiększającego się ruchu w naszym serwisie.

Ostatecznie Tomek z Dawidem wpadają na pomysł, aby wykorzystać właśnie wdrożony system do komunikacji z użytkownikami, aby przekierować ruch z aplikacji na stronę mobilną. Każdy, kto otworzy aplikację zobaczy pełnoekranową informację, że aplikacja ma dzisiaj gorszy dzień i zapraszamy pod adres mobile.pizzaportal.pl aby wykonać zamówienie. Takie rozwiązanie nie będzie wymagało aktualizacji aplikacji, a jedynie stworzenia specjalnej kampanii reklamowej.

System komunikacji to jednak kawałek królestwa Ewy, nasze szefowej marketingu. Najpierw chcę uzyskać od niej zgodę na skorzystanie z tej metody (która może być inwazyjna dla niczego nie spodziewającego się użytkownika).
15:47. Ewa nie odbiera telefonu.

15:49. Dzwonię do Lecha, CEO PizzaPortal.pl. Tłumaczę sytuację, mówię, że nie możemy czekać. Lech daje zielone światło na akcję.

15:56. Informuję zaintresowane strony, że idziemy z planem wysłania wiadomości do użytkowników. Dawid zaczyna konfigurować komunikat – nabrał w tym wprawy przy implementacji i testowaniu systemu.

16:08. Ewa oddzwania. Tłumaczę sytuację do tego miejsca, nie może osobiście pomóc bo właśnie jedzie samochodem. Kontaktuje Dawida z Alicją z marketingu, która jest w domu przed komputerem i sprawdzi ze swojej strony poprawność konfiguracji wysyłki.

16:10. Czas posprzątać bałagan i powiązać ostatnie sznurki. Management PP dostaje aktualizację z naszym proponowanym rozwiązaniem. Customer Care i Social Media także. Kończymy z Pauliną sałatkę.

16:36. Dawid wysyła testową wiadomość. Zdzwaniamy się po raz jeszcze raz, aby poprawić ostatnie rzeczy. Spacerujemy już z Pauliną przez Saską Kępę do domu.

16:57. Nasze rozwiązanie jest aktywne. Rozmawiamy na Slacku o tym, że koniecznie musimy uodpornić nasze QA na ten przypadek – będziemy o tym dyskutować w poniedziałek na naszym product planningu.

Dotarliśmy pod nasze mieszkanie. Zasłużyliśmy na herbatę.

Straty tego dnia z braku zamówień na Androidzie bolą – nasza niedziela była całościowo gorsza o około 5% od standardowej. Widać to dobrze na wykresie zamówień poniżej – spadek niebieskiej linii 6.03 to właśnie omawiany przypadek. Nie ma jednak powodu, aby obwiniać kogoś (czy też siebie) za błąd popełniony po raz pierwszy tak jak w tym przypadku. Z czystej statystyki wynika, że przy tak wielowymiarowym produkcie to po prostu musi się zdarzyć. Ważne jest jednak jak się na nie reaguje.

  
Sytuacje takie jak ta mają swoją dynamikę podyktowaną emocjami. Wszyscy szukają klucza do zrozumienia co tak naprawdę się stało – i muszą to zrobić szybko, bo każda minuta to niezrealizowane zamówienia, a więc utracone pieniądze. Łatwo więc wpada się w paranoje i podważa swoje umiejętności, a emocje i stres potrafią doprowadzić do niepotrzebnej paniki. Dokładnie wtedy, gdy ważna jest koncentracja i jasne myślenie.

Ps. Ten wpis publikuję już po wdrożeniu poprawki i sprawdzeniu, że następnej niedzieli było już wszystko w najlepszym porządku:)

Jak piszę MDM – warsztat

Jakiś czas temu padło pytanie jak powstaje Mobile dla Managerów i jaki mam do tego przygotowany warsztat pracy.

Wychodzę z założenia że narzędzia są drugorzędne w samym procesie pisania. Im mniej funkcji tym lepiej, więc szukałem narzędzi, które nie wprowadzają szumu, nie wymagają zbytniej nauki i pozwalają zautomatyzować co tylko się da.

Pierwszym i centralnym elementem całej układanki jest LeanPub – serwis, który pozwala na samodzielne pisanie i publikację książki elektronicznej. Pierwszy raz tutaj trafiłem, gdy została mi polecona książka Agile w Praktyce Andiego Brandta. W LeanPub szczególnie ciekawe, jest to, że można publikować i sprzedawać swoją pracę, zanim jeszcze zostanie skończona (to jest dopiero szatańsko leanowe podejście!).

LeanPub zajmuje się całą stroną techniczną automatycznie: wystarczy wrać pliki z tekstem, a system sam generuje spis treści, podpisy, odnośniki i to w niezależnych plikach epub, mobi i pdf. Mają też całkiem fajne statystyki i gotowy landing page – oszczędza więc dużo czasu, który można przeznaczyć na pisanie.

Choć z LeanPuba można korzystać przez stronę www to ja preferuję synchronizację plików przez Dropbox. LeanPub wygenerował sobie katalog po tym jak dałem mu dostęp do Dropa i tam siedzą wszystkie moje pliki związane z MDM. Zgodnie z rekomendacją – każdy rozdział to oddzielny plik tekstowy.

Na tym etapie wiedziałem już, że muszę nauczyć się Markdowna – czyli specjalnego języka ze składnią, która pozwala na dodawanie do standardowego tekstu tabel, obrazów, cytatów i innych upiększaczy. W czym Markdown jest lepszy od tego co oferują natywne formaty Pages czy Word? Przede wszystkim jest minimalistyczny i uniwersalny – nie ważne jak i gdzie ktoś czyta twój tekst to i tak wiesz, że będzie dobrze wyglądał. Inna sprawa, że LeanPub wymaga, aby się go nauczyć:)

Kiedy już byłem pewien, że bez Markdowna się nie uda, to stwierdziłem, że muszę znaleźć sobie takie narzędzie do pisania, które będzie mi pomagało (nie przeszkadzając). Ostateczny wybór padł na Byword 2 – trafiłem wtedy na promocję i zapłaciłem trochę mniej niż standardowe $10.

Byword na OSX jest świetny do długich sesji pisarskich, na które mogę sobie pozwolić tylko w weekendy. Kiedy jednak gdzieś w drodze wpadnie mi do głowy fajna myśl to zapisuje je w Simplenote na iPhonie. Kocham Simplenote miłością nieprzerwaną od ponad czterech lat. Każdą notkę związaną z książką oznaczam w tekście z tagiem #mdm i później tak przefiltrowane notatki przelewam do książki.

Jeśli chodzi o newsletter to korzystam z Tinyletter. Jest prosty i darmowy. Myślałem o bardziej rozbudowanych systemach mailingowych jak MailChimp czy polskie GetResponse czy Freshmail, ale wszystkie wydają mi się zbyt skomplikowane. Odstawiłem więc kombajny na bok. Tinyletter ma limit 5000 subskrybentów, który raczej ciężko będzie mi zapełnić, ale jeśli już tak się stanie to zawsze mogę przenieść się gdzieś dalej.

Czasami do newslettera wrzucam link do fajnego fragmentu z książki (jak ten). Wtedy otwieram macowe Pages, wybieram jeden z predefiniowanych szablonów (są bardzo estetyczne!) i wrzucam tekst. Ten, w większości przypadków, sam się dobrze układa.

Generuję sobie wtedy PDFa i wrzucam na Dropboksa do publicznego katalogu. Zanim jednak udostępnię ten plik to korzystam jeszcze z Bit.ly czyli skracacza liników. Bit.ly daje mi kontrolę na linkiem – zawsze mogę podmienić co jest pod nim, wiem też ile osób i skąd na niego klika.

Niedługo będę chciał się dowiedzieć więcej o moich potencjalnych czytelnikach i odpalę ankietę. Tutaj mój wybór padł na Typeform – przede wszystkim ze względu na ergonomię i responsywny design. Da się ją wypełnić zarówno na desktopie jak i smartfonie.

Okładkę także zrobiłem sobie sam bo kiedyś, bardzo dawno temu kupiłem w promocji Pixelmatora (teraz kosztuje $30) – czyli takiego młodszego brata Photoshopa.

Mimo tego, że ten blogpost jest długi jak na moje standardy to sam proces jest bardzo prosty i szybki (szukałem najłatwiejszych rozwiązań jakie były). Jedynie LeanPub na początku przytłacza swoimi możliwościami, ale warto przebrnąć przez ich manual i wszystko powoli staje się jasne.

Nam sam koniec: jeśli nosisz się z zamiarem pisania książki to mam prostą radę: po prostu zacznij. Narzędzia mają marginalne znaczenie – korzystaj z tych, które masz pod ręką i olej porównywanie funkcji konkurencyjnych programów bo wpadniesz w pułapkę wyścigu zbrojeń – zamiast zająć się pisaniem.